rfc: build system

rfc: build system

[Richard Henderson]

On Mon, Jan 31, 2000 at 09:08:56PM -0800, Zack Weinberg wrote:
> I had a much more complicated fix which got bogged down in the
> details.  I think this makefile is actually worse than glibc's
> Makerules, which is an achievement.

Speaking of which...  Being irritated with how poorly our build
system works with parallel make on SMP systems, I gave the make
system a half-hearted poke this weekend to see what level of
effort it would be to kill the (bulk of the) recursive makes.

I'm guessing that there are a number of folks that would be rather
pissed at gcc suddenly requiring gnu make.  My question is, what
sort of common denominator does that leave us with functionality-wise? 
And would folks be open to limitations in the make/configure process
to avoid things getting overly complex?

For instance, one can currently run configure with no args and do
"make LANGUAGES='c c++'".  The sanest way I can think to rework some
of the build rules is

    lang.fe: $(foreach lang,$(LANGUAGES),$(lang).fe)
or
    LIB2LANG_OBJS = $(foreach lang,$(LANGUAGES),$($(lang)_LIB2LANG_OBJS))

which clearly doesn't work without some sort of macro facility in make. 

Now, this same sort of thing could instead be expanded at Makefile
creation, at which point we aren't relying on gnu make features.  But
at the same time, we now require "configure --enable-languages='...'"
in order to change what builds.

Thoughts?


r~

Re: rfc: build system

[Zack Weinberg]

On Mon, Jan 31, 2000 at 10:48:11PM -0800, Richard Henderson wrote:
> On Mon, Jan 31, 2000 at 09:08:56PM -0800, Zack Weinberg wrote:
> > I had a much more complicated fix which got bogged down in the
> > details.  I think this makefile is actually worse than glibc's
> > Makerules, which is an achievement.
> 
> Speaking of which...  Being irritated with how poorly our build
> system works with parallel make on SMP systems, I gave the make
> system a half-hearted poke this weekend to see what level of
> effort it would be to kill the (bulk of the) recursive makes.
> 
> I'm guessing that there are a number of folks that would be rather
> pissed at gcc suddenly requiring gnu make.  My question is, what
> sort of common denominator does that leave us with functionality-wise? 
> And would folks be open to limitations in the make/configure process
> to avoid things getting overly complex?

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

> For instance, one can currently run configure with no args and do
> "make LANGUAGES='c c++'".  The sanest way I can think to rework some
> of the build rules is
> 
>     lang.fe: $(foreach lang,$(LANGUAGES),$(lang).fe)
> or
>     LIB2LANG_OBJS = $(foreach lang,$(LANGUAGES),$($(lang)_LIB2LANG_OBJS))
> 
> which clearly doesn't work without some sort of macro facility in make. 
> 
> Now, this same sort of thing could instead be expanded at Makefile
> creation, at which point we aren't relying on gnu make features.  But
> at the same time, we now require "configure --enable-languages='...'"
> in order to change what builds.

I think most recent makes have the $(var:x=y) substitution notation,
so you could write

lang.fe: $(LANGUAGES:=.fe)

I'm not so sure about $(indirect_$(var)).  They definitely don't all
have an include capability, which is the thing I find myself missing
most often.

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?

zw

Re: rfc: build system

[Richard Henderson]

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.

> I think most recent makes have the $(var:x=y) substitution notation,

Good...

> I'm not so sure about $(indirect_$(var)). 

This is the one that would most hurt, I think.

> They definitely don't all have an include capability, which is
> the thing I find myself missing most often.

This I don't mind so much.  We don't have that many subdirectories
and inlining is still managable.

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


r~

Re: rfc: build system

[Zack Weinberg]

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

Re: rfc: build system

[Jeffrey A Law]

  In message < 20000201000434.A801@cygnus.com >you write:
  > 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.
We need to stick with Posix compliant constructs.  That ultimately decides
whether or not we can use a particular feature.


jeff

Re: rfc: build system

[H . J . Lu]

On Mon, Jan 31, 2000 at 10:48:11PM -0800, Richard Henderson wrote:
> On Mon, Jan 31, 2000 at 09:08:56PM -0800, Zack Weinberg wrote:
> > I had a much more complicated fix which got bogged down in the
> > details.  I think this makefile is actually worse than glibc's
> > Makerules, which is an achievement.
> 
> Speaking of which...  Being irritated with how poorly our build
> system works with parallel make on SMP systems, I gave the make
> system a half-hearted poke this weekend to see what level of
> effort it would be to kill the (bulk of the) recursive makes.
> 

Thanks! I have been complaining this for years.


H.J.

Re: rfc: build system

[Richard Henderson]

On Tue, Feb 01, 2000 at 05:57:09AM -0700, Jeffrey A Law wrote:
> We need to stick with Posix compliant constructs.  That ultimately decides
> whether or not we can use a particular feature.

Do you happen to have the specs for posix make?  I have no idea
what features (or lack of them) are included.


r~

Re: rfc: build system

[Gerald Pfeifer]

On Tue, 1 Feb 2000, Richard Henderson wrote:
> Do you happen to have the specs for posix make?  I have no idea
> what features (or lack of them) are included.

I believe the documentation at
  http://www.opengroup.org/online-pubs
might contain what you are looking for, at least according to 
  http://www.UNIX-systems.org/version2/unix98.html
and the documentation of make there this was my conclusion.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: rfc: build system

[Marc Espie]

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.

Re: rfc: build system

[Alexandre Oliva]

On Feb  1, 2000, Richard Henderson <rth@cygnus.com> wrote:

> Thoughts?

I've been thinking of converting the whole GCC build system to use
automake Makefiles.  There are some rather tricky issues, but I think
I've got ideas about how to address all problems I've foreseen.  How
do you feel about this?

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

Re: rfc: build system

[Jeffrey A Law]

  In message < Pine.BSF.4.21.0002012149460.68246-100000@deneb.dbai.tuwien.ac.at >
you write:
  > On Tue, 1 Feb 2000, Richard Henderson wrote:
  > > Do you happen to have the specs for posix make?  I have no idea
  > > what features (or lack of them) are included.
  > 
  > I believe the documentation at
  >   http://www.opengroup.org/online-pubs
  > might contain what you are looking for, at least according to 
  >   http://www.UNIX-systems.org/version2/unix98.html
  > and the documentation of make there this was my conclusion.
A link to those docs from our web pages might prove useful :-)

jeff

Re: rfc: build system

[Tom Tromey]

>>>>> "Marc" == Marc Espie <espie@quatramaran.ens.fr> writes:

Marc> For instance, it could write Makefiles with inclusions and tests
Marc> on system where it can be done, and static `poor man' Makefiles
Marc> otherwise.

Marc> Would rewriting
Marc> include "file"
Marc> to
Marc> include "file"
Marc> really be so hard to implement ?


As far as I know every make in use these days supports "include".
If you definitely know of one that does not, please send me email
about it.

Tom

Re: rfc: build system

[Gerald Pfeifer]

On Tue, 1 Feb 2000, Jeffrey A Law wrote:
>>   http://www.opengroup.org/online-pubs
> A link to those docs from our web pages might prove useful :-)

Good point! Done. :-)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/