This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: rfc: build system
- To: egcs at egcs dot cygnus dot com
- Subject: Re: rfc: build system
- From: Marc Espie <espie at quatramaran dot ens dot fr>
- Date: Wed, 2 Feb 2000 03:24:30 +0100
- Organization: Ecole Normale Superieure de Paris
- References: <200002010316.WAA11443@caip.rutgers.edu> <20000131210856.A529@wolery.cumb.org> <20000131224811.D679@cygnus.com> <20000131233128.G529@wolery.cumb.org> <20000201000434.A801@cygnus.com>
Speaking for OpenBSD make, and probably for NetBSD and FreeBSD.
In article <20000201001355.A12406@wolery.cumb.org> you write:
>On Tue, Feb 01, 2000 at 12:04:34AM -0800, Richard Henderson wrote:
>> On Mon, Jan 31, 2000 at 11:31:28PM -0800, Zack Weinberg wrote:
>> > Sometimes I wonder if we're really doing people a favor allowing them
>> > to use vendor makes, given how buggy they all seem to be...
>> I'd mostly been thinking of *bsd, to be honest.
>Right. Pmake is nice, but I wish it shared more syntax with gmake.
Well, reading gmake's documentation, I'm not sure we want to share more
syntax with people who are so sure they are doing things the right
way... probably not the image gnu-make people want to project, but the
documentation does look a tad arrogant to me.... :)
Ok, ${var:x=y} is usually called system V substitution.
It works on all bsd makes, as far as I know.
As far as that --enable-languages issue goes, well, maybe there's room
for an autoconf test, that would try to find what a given make is able of
doing, and integrate it seemlessly.
For instance, it could write Makefiles with inclusions and tests on system
where it can be done, and static `poor man' Makefiles otherwise.
Would rewriting
include "file"
to
.include "file"
really be so hard to implement ?
>> > I'm not so sure about $(indirect_$(var)).
Nope, not yet... or at least, not everywhere... there are several distinct
places in pmake that need support for that. We have a few, NetBSD has a few
more, I believe it's quirky at best.
You're going to run into trouble with that.
>Well, there's the trick gmake uses:
>
>if (compiler supports -o with -c)
>OUTPUT_OPTION = -o $@
>else
>OUTPUT_OPTION = ; mv -f $(@F) $@
>endif
>
Check, we have $(@F)
Again, it's a system V hack...
Miscellanei you may want to care about:
- avoid one line builds, such as
a: b; touch b
most often, they will work... but handling of comments in that area is
definitely hard to do properly.
- be wary of $<. gmake defines it always, apparently, whereas it's only
documented (and implemented) for other makes for suffix rules. It would
be easy to implement it all the time, this is a design decision.
This is not really relevant to the problem at hand, as you want to compile on
older platforms as well, but I've been working a lot on OpenBSD make
recently, not all of that work has been approved yet, but many of the
weird quirks we were suffering from are now cured or will be.
Apart from the traditional BSD vs. GPL issues, being able to compile gcc
with something else that gnu-make is a proof of robustness and generality...
avoid inadvertently falling into idiosyncrasies, for instance.
Feel free to ask for details if you need to know what OpenBSD make
implements/doesn't implement in the set of features you need from a make.