[Top][All Lists]

[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.


reply via email to

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