This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: rfc: build system
- To: Richard Henderson <rth at cygnus dot com>
- Subject: Re: rfc: build system
- From: Zack Weinberg <zack at wolery dot cumb dot org>
- Date: Tue, 1 Feb 2000 00:13:55 -0800
- Cc: gcc at gcc dot gnu dot org
- References: <200002010316.WAA11443@caip.rutgers.edu> <20000131210856.A529@wolery.cumb.org> <20000131224811.D679@cygnus.com> <20000131233128.G529@wolery.cumb.org> <20000201000434.A801@cygnus.com>
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.
> > I'm not so sure about $(indirect_$(var)).
>
> This is the one that would most hurt, I think.
? Not sure what you mean by 'most hurt'.
> > You could make a first pass by moving all the logic in the subdir
> > Makefile.in's into the Make-lang.in's - those get inlined into the top
> > level Makefile, right?
>
> Yep. The biggest problem that turned up there was that I found I
> needed to use `-o' in the `.c.o' rule, which I know several vendor
> compilers don't support. Not sure how I'd want to work around that.
Well, there's the trick gmake uses:
if (compiler supports -o with -c)
OUTPUT_OPTION = -o $@
else
OUTPUT_OPTION = ; mv -f $(@F) $@
endif
.c.o:
$(CC) -c $(CFLAGS) $(CPPFLAGS) $< $(OUTPUT_OPTION)
The trouble with that is I don't know how portable $(@F) is.
AC_PROG_CC_C_O would also come in handy here.
zw