From: Michael Tokarev <mjt@tls.msk.ru>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Andreas Färber" <afaerber@suse.de>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries
Date: Mon, 01 Jul 2013 19:06:34 +0400 [thread overview]
Message-ID: <51D19AFA.2090707@msgid.tls.msk.ru> (raw)
In-Reply-To: <51D197D7.6070102@redhat.com>
01.07.2013 18:53, Paolo Bonzini wrote:
[]
> I don't think that's the problem. Simply I don't think that listing
> 1000 object files in a single makefile are manageable. Choosing the
> right directory per-target is also much easier if you can just do
>
> obj-y += hw/$(TARGET_BASE_ARCH)/
>
> instead of long if-elseif-elseif-elseif-endif conditionals.
it's not this. It is something like:
obj-$(TARGET_BASE_ARCH) += $($(target)-base-arch)
instead, where $(target)-base-arch still has to be defined
very much the same like it is defined today, with the exception
that it doesn't require to be listed in a separate Makefile.
Ie, today, we have, say, in hw/i386/Makefile.objs:
obj-y += msi.o irq.o kvm.o
obj-y += msi2.o kvm2.o
So instead of this, we may have in the top-level Makefile:
obj-i386-y += hw/i386/msi.o hw/i386/irq.o hw/i386/kvm.o
Or, if you prefer programmatic expansion,
list-i386-y += msi.o irq.o kvm.o
obj-i386-y += $(addprefix hw/i386/, $(list-i386-y))
So the difference is just the addition of the pathnames,
not the logic or ifdeffery.
> Conflicts in a small file are also way easier to solve, even if there
> are more conflicting files.
Conflicts? Which conflicts? You mean merge conflicts?
If yes, it does not really matter be it small file or large
file. If you list everything in one line, you're much more
likely to have a conflict, be it small file or large file.
If you always add stuff to the end of a file, you have much
more chance for a conflict, be it large or small file.
Single makefile may have sections so, say, you add a new
block device into a "block" section, maybe near the end of
it or alphabetically, so you're avioding conflicts the
same way as if you had multiple files.
> If you prefer to have _everything_ in a single file, you just have to
> post patches and justify them. I just doubt that the result will be
> better than what we have today, and the time would be better invested in
> cleaning up what we have today.
Well, the more I look into it, the more I dislike what we have
now, because of this non-obvious half-magic half-working stuff.
To me we should either do it recursively in submakes, or just
add the paths (be it single makefile or multiple small makefiles)
without the current half-working half-magic.
(Again, the "half" here refers to the fact that some variables
gets prefixed by the subdir automatically while some doesn't).
So before sending patches, can we at least agree (or not) that
specifying paths explicitly (either using dir/obj.o or by calling
addprefix) is not THAT bad or it should be avoided entirely?
(I dislike the recursive sub-make approach because when you have
everything in one make it is much easier to see all dependencies
and plan the work, instead of running a ton of submakes first,
each checking if its own subdir is up to date).
Thanks,
/mjt
next prev parent reply other threads:[~2013-07-01 15:06 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-18 17:34 [Qemu-devel] [RFC PATCH 0/4] per-object libraries Michael Tokarev
2013-06-18 17:34 ` [Qemu-devel] [RFC PATCH 1/4] build-sys: strip leading ./ from $(obj) Michael Tokarev
2013-06-18 17:34 ` [Qemu-devel] [RFC PATCH 2/4] build-sys: allow object-specific libraries to be used to link executables Michael Tokarev
2013-06-18 17:34 ` [Qemu-devel] [RFC PATCH 3/4] build-sys: allow per-object foo.cflags variables Michael Tokarev
2013-06-18 17:34 ` [Qemu-devel] [RFC PATCH 4/4] build-sys: move -lcurl out of libs and specify it for curl.o Michael Tokarev
2013-06-19 0:41 ` [Qemu-devel] [RFC PATCH 0/4] per-object libraries Michael Tokarev
2013-06-19 14:16 ` Stefan Hajnoczi
2013-06-19 14:58 ` Michael Tokarev
2013-06-19 16:46 ` Paolo Bonzini
2013-06-19 16:58 ` Paolo Bonzini
2013-06-19 18:18 ` Michael Tokarev
2013-06-19 18:52 ` Paolo Bonzini
2013-06-19 19:31 ` Richard Henderson
[not found] ` <51C2D03E.2030505@redhat.com>
2013-06-20 10:06 ` Peter Maydell
2013-06-20 12:39 ` Paolo Bonzini
2013-06-20 12:50 ` Peter Maydell
2013-06-20 17:09 ` Richard Henderson
2013-06-19 20:00 ` Michael Tokarev
2013-06-20 10:09 ` Paolo Bonzini
2013-06-30 15:23 ` Michael Tokarev
2013-07-01 10:08 ` Paolo Bonzini
2013-07-01 10:10 ` Michael Tokarev
2013-07-01 10:18 ` Paolo Bonzini
2013-06-30 15:28 ` Andreas Färber
2013-06-30 15:36 ` Michael Tokarev
2013-06-30 15:51 ` Peter Maydell
2013-06-30 16:49 ` Michael Tokarev
2013-07-01 8:00 ` Stefan Hajnoczi
2013-06-30 15:56 ` Andreas Färber
2013-07-01 13:39 ` Paolo Bonzini
2013-07-01 14:43 ` Michael Tokarev
2013-07-01 14:46 ` Andreas Färber
2013-07-01 14:52 ` Michael Tokarev
2013-07-01 14:53 ` Paolo Bonzini
2013-07-01 15:06 ` Michael Tokarev [this message]
2013-07-01 15:20 ` Paolo Bonzini
2013-07-01 15:52 ` Michael Tokarev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51D19AFA.2090707@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=afaerber@suse.de \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.