On Fri, Jul 09, 2010 at 01:36:19PM +0200, Diego Elio Pettenò wrote:
> 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,
well, my expectation was higher ;-)
> 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..).
>
> > 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
yes, that's my wish
> 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
Do you mean in the top level directory (aka $top_builddir)? hmm...
This solution could be attractive for developers (you don't have to
use paths to execute a binary), but the number of utils is large so
after "make all" there will be really many files the $top_builddir.
I guess that libtool will also use (only) $top_builddir/.lib for all
stuff, right? It would be also nice (sometimes I need to bypass
libtool scripts and execute binaries with LD_LIBRARY_PATH by hand).
Mike, Peter, Kay, others, ... any objection against this concept?
> > 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..
It is not overkill at all. The most important is to keep the package
maintainable. I don't want to have any exception for any subdirectory.
Please.
> > > 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.
Yes, I have added some "skip if non-root" tests there.
> 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...
OK, I'll agree to call the tests automatically from "make check",
but there has to be something like
if [ $(id --user) != 0 ]; then
tests/run.sh
fi
(or we can add tests/run-from-buildsys.sh with necessary UID check).
Unfortunately some crazy users use root's account to compile packages.
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
