> 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 = @[EMAIL PROTECTED]/ > > 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. _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
