[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU Mach's build system (partly) reworked
From: |
Thomas Schwinge |
Subject: |
Re: GNU Mach's build system (partly) reworked |
Date: |
Sun, 29 Jan 2006 13:13:39 -0500 |
User-agent: |
Mutt/1.5.6+20040907i |
On Sun, Jan 29, 2006 at 06:46:35PM +0100, Alfred M. Szmidt wrote:
> ./configure --prefix='$(libexecdir)/foo' --libexecdir=/foo
Do you really consider that as a valid use case? Putting libexecdir's
files into `/foo/' and everything else into `/foo/foo/{bin,share,...}/'?
If this really bothers you I can add that functionality, of course.
> 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?
Those are not used within GNU Mach.
> 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.
I was under the impression that his patches were for the Hurd only.
> `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
Although that's improper usage of `top_builddir' given the above
definition, ...
> 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'll adopt to it and make the code more robust.
> 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.
Ok, I'll do that.
Regards,
Thomas
Re: GNU Mach's build system (partly) reworked, Thomas Schwinge, 2006/01/31