Hi Diego,
On Mon, Jul 05, 2010 at 01:14:48PM +0200, Diego Elio 'Flameeyes' Pettenò wrote:
> After a couple of updates on my Gentoo systems (I'm a developer and I take
> care of automated testing, so I have a few installs around) I noticed that
> util-linux-ng takes an unexpected "long" time to build from scratch.
it would be nice to have some numbers from your system. I have tried
to play with your changes:
4xCPUs (Xeons)
recursive: 0m27.857s
non-recursive: 0m23.589s
the results are from (make -j and make -j8) ...nothing impressive.
Frankly, I need some motivation to accept the change. Try to found
something better than performance ;-)
> The problem is that by using recursive make, it cannot run all of it in
> parallel (I have an 8-way system), as it synchronises on each
> directory. Also, the recursion itself is quite expensive for make to
> handle.
Don't forget that util-linux is a set of small utils where (usually)
one source file is compiled to the one binary. It's completely
different situation that for example kernel or udev.
For example I don't recompile the whole package too often, I'm usually
happy with
make -C subdir/ utilname
and if I recompile the whole package then I usually call ./autogen.sh
and ./configure.
> I'm sending a series of patches that transform the build system from the
> current recursive Makefiles system to a non-recursive one. It's quite easy
> to deal with it, in general, you only have to remember that the target
> variables are prefixed with the relative path of the output (so it's
> misc_utils_blkid for instance, rather than simply blkid).
>From my point of view hardcode paths to variable names is a very ugly
convention. There should be a minimal dependence between a subdirectory
name and the stuff in the subdir/Makefile (or module.am, or so).
This convention is unnecessary for util-linux where all commands have
unique names (so blkid_CFLAGS is better than misc_utils_blkid_CFLAGS).
> I documented most of what is needed for non-recursive automake in my guide
> http://www.flameeyes.eu/autotools-mythbuster/ and if anybody have further
> doubts about it, feel free to drop me an email and I'll gladly extend the
> documentation. One thing that I have (yet) to document there is the
> handling of multiple .am files (module.am is what I called them) to avoid
I don't like the "module.am" filename. All build system stuff should
be visible in directories -- this is reason why we have "Makefile.am"
rather than "makefile.am". What about "Makemodule.am"?
> creating one huge Makefile.am file, and instead keep the rules tied with
> the sources themselves.
Yep, one huge Makefile.am is brain dead solution. It's completely
against the reason why people use subdirectories. It does not make
any sense to maintain code in subdirectory and description how to
compile the code outside the subdirectory.
Your idea with module.am is elegant, unfortunately you don't strictly
use these files. Your top level Makefile.am is still too large and it
includes information that should be in subdirectories, for example
stuff from include/ subdirectory, check_PROGRAMS.
I think you can define empty variables (for example noinst_HEADERS,
EXTRA_DIST, ...) in the top level Makefile.am and add filenames to
these variables in module.am files, for example:
--Makefile.am--
EXTRA_DIST =
--tests/module.am--
EXTRA_DIST += tests/run.sh tests/README
> Finally, I have wired out the testsuite to "make check"... it's mostly
Please, don't call tests/run.sh from build system. Many tests require
root permissions and are invasive. It should be executed by developers
on non-production systems only.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
