bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Mach's build system (partly) reworked


From: Alfred M. Szmidt
Subject: Re: GNU Mach's build system (partly) reworked
Date: Sun, 29 Jan 2006 18:46:35 +0100

   > You removed libexecdir (and maybe some other variables), why?
   > Doing something like `--prefix=$(libexecdir)/foo' is always OK.
   > All variables that can be substituted should be listed.  The
   > variables also get partially expanded, so that is one more reason
   > to list all of them ($(libexecdir) ==> $(exec_prefix)/libexec).

   I can't follow you here.  You mean running `make
   prefix=\$\(libexecdir\)/foo install' or what?  What should that be
   useful for?  And wouldn't that in fact yield a endless recursion?
   `$(libexecdir)/foo' -> `$(exec_prefix)/libexec/foo' ->
   `$(prefix)/libexec/foo' -> `$(libexecdir)/foo/foo' -> ...

./configure --prefix='$(libexecdir)/foo' --libexecdir=/foo

   I only left in those installation-related variables that are
   actually used: prefix, exec_prefix, bootdir and includedir.  I
   don't see the need for any others, but perhaps I'm overlooking
   something?

infodir/datadir/datarootdir?

   >   +top_builddir = @top_builddir@../
   > 
   > The following is equally effective (or should be): top_builddir =
   > ..

   Yes, as long as we don't let the build system create Makefiles in
   subdirectories, which we don't at the moment.  Changed.

Would be better to simply stop using manually maintained .in's, and
use automake, then one won't have to care about such changes.  Jeff
Bailey had such a patch.

   >   +include $(top_builddir)Makerules
   > 
   > That is unsafe, add a directory seperator inbetween.

   Why is it unsafe?

   `top_builddir' is the relative path from the current build
   directory to to top build directory.  So it's either empty or `../'
   or `../../' or similar.  I can add a slash if people are happy
   then.

$(top_builddir) := ..
==> include ..Makerules

It is always best to include the extra directory seperator since you
won't end up with code like that by accident for whatever reason.

I'd list the variables that have been changed/removed in the ChangeLog
too.  They are equally important to list as the targets.  And then add
a small explanatory note under the header about what happened.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]