Hi, Il giorno gio, 08/07/2010 alle 14.07 +0200, Karel Zak ha scritto: > recursive: 0m27.857s > non-recursive: 0m23.589s I wouldn't call that a small difference, if you count a single build, and just on a 4-way... the load on my workstation right now is a bit too high to get reasonable numbers (it's doing gentoo-testing and it'll take a couple of days before I can find some extra time to run a benchmark). But if you don't care about performance I guess there's no point arguing over it (even though I'd expect other package maintainers to agree with that not being too small a difference..). > 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. And that actually makes it even more suitable for non-recursive automake, as right now you're forcing just a few link stages to happen in parallel, before resuming with the compile phase, while non-recursive means a much wider parallel build. > make -C subdir/ utilname > > 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). These two points together can give you actually an even better result: make blkid and it should work just fine. The drawback is that all the binaries stay in the current directory (which for me is a positive note sincerely). If that's okay for you, I can make the change sorta easily during the weekend. > 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"? Good point, I'll fix that up during the weekend as well. > 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. Well for include/ at least it seemed overkill to use a separate file to list them.. > > 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. Hmm I would think that running these during distcheck at least would be positive (beside there was one that failed on my system), and it seems to deal nicely with limited (non-root) permissions on my system. Are you sure it's so bad to have them wired to run? Most packages have some, and distributions like Gentoo rely on the tests to make sure the users' systems are running more or less properly... -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ -- 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
