Re: autoconfiscation -- questions about make usage

Re: autoconfiscation -- questions about make usage

[Nathanael Nerode]

On Wed, 30 Jan 2002, mike stump wrote:
> > Hmm... where the heck do I find a free description of what a make has to
> > do to be POSIX compliant?
> 
> If you don't know this stuff stone cold...  It will make working on
> this harder.
> 
> Kinda like writing portable code, but not knowing what portable code
> is.  It is relatively hard for us to just say.
> 
> One pragmatic way, is to only use constructs that you see in the
> existing makefiles.

Yup.  Well, the existing makefiles are not SUS compliant, but are pretty
close.  (They use dashes and .PHONY.)  So I'll try to stick to SUS +
dashes + .PHONY.  

This means I am probably going to be writing a small program to
automatically generate Makefile.in, because there will be huge
lists of almost identical targets (which could be collapsed with pattern
rules, but not suffix rules).  This is an issue with any Makefile which
recursively makes subprojects, so I'm thinking of making a fairly generic
script.  (Unfortunately autoconf2.13 + automake is not sufficient, but
what I'm writing could probably be folded into one or the other at
some later time.)

If anyone's interested in seeing the preliminary version of RAM
('recursive automake'), tell me and I'll put it up somewhere once I've
actually written it.  (I wrote a spec so far, but not the actual
program... I haven't decided quite what form to make it in, and I'm only 
98% sure it's worth the bother.)

--Nathanael Nerode

Re: autoconfiscation -- questions about make usage

[Zack Weinberg]

On Wed, Jan 30, 2002 at 02:06:19PM -0500, Nathanael Nerode wrote:
> On Wed, 30 Jan 2002, mike stump wrote:
> > If you don't know this stuff stone cold...  It will make working on
> > this harder.
> > 
> > Kinda like writing portable code, but not knowing what portable code
> > is.  It is relatively hard for us to just say.
> > 
> > One pragmatic way, is to only use constructs that you see in the
> > existing makefiles.
> 
> Yup.  Well, the existing makefiles are not SUS compliant, but are pretty
> close.  (They use dashes and .PHONY.)  So I'll try to stick to SUS +
> dashes + .PHONY.  

But notice that wherever you see .PHONY, there's either a "force"
dependency, or we don't think it's worth worrying about someone
creating a file with that name.  In other words, the makefile needs to
work even if .PHONY is being ignored.

(Just one of the things Mike is referring to when he says you need to
know this stuff subconsciously...)

zw

Re: autoconfiscation -- questions about make usage

[Alexandre Oliva]

On Jan 30, 2002, Nathanael Nerode <neroden@doctormoo.dyndns.org> wrote:

> (They use dashes and .PHONY.)

dashes in macro names are not SUS, but dashes in filenames are,
AFAIK.  If we're really using dashes in macro names, these should
probably be fixed.

As for .PHONY, for make programs that don't understand it, it looks
like a harmless dependency of file .PHONY on other files, so it is
simply ignored.

> This means I am probably going to be writing a small program to
> automatically generate Makefile.in, because there will be huge
> lists of almost identical targets (which could be collapsed with pattern
> rules, but not suffix rules).

Care to explain in advance what kind of targets you're thinking of
generating?  Perhaps we could help save you some work, should someone
think of a way to do it without needing such a program.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: autoconfiscation -- questions about make usage

[Nathanael Nerode]

On 30 Jan 2002, Alexandre Oliva wrote:

> On Jan 30, 2002, Nathanael Nerode <neroden@doctormoo.dyndns.org> wrote:
> > This means I am probably going to be writing a small program to
> > automatically generate Makefile.in, because there will be huge
> > lists of almost identical targets (which could be collapsed with pattern
> > rules, but not suffix rules).
> 
> Care to explain in advance what kind of targets you're thinking of
> generating?  Perhaps we could help save you some work, should someone
> think of a way to do it without needing such a program.

Sorry, I finally got around to this.  Here's more information than you
asked for.

The repetitive targets are entirely due to one thing: causing the
subconfigures to be invoked by the Makefile rather than the top-level
configure. (This is a feature which was requested by someone.  It's also
the easiest way to do things as long as AC_CONFIG_SUBDIR is broken, which
it is in autoconf 2.13)

First of all, the existing all-$(subdir) targets would have a new
dependency configure-$(subdir).

(if expanded, they'd look like this:
all-misc: configure-misc
	cd misc; $(MAKE) all
check-misc: configure-misc
	cd misc; $(MAKE) check
)

And now the new repetitive targets:
(Note that srcdir_abs is a version of srcdir which will be accurate when
in the subdirectory -- has to be constructed by configure)
(subconfigure_args are the arguments which should be passed to
subconfigures -- must be set by configure)

configure-misc: misc/Makefile
misc/Makefile: config.status
	cd misc; ${srcdir_abs}/misc/configure ${subconfigure_args}

This combination will force misc to be reconfigured precisely when the top
level has been reconfigured.  When something else has changed *within* the
misc directory, the Makefile in the misc directory will deal with any
problems.

I think this is a moderately elegant piece of glue code.  It depends on
misc/Makefile being a *real* target, however.

It can probably be converted into a single Makefile entry rather than one
per subdirectory by (ab)use of macros, much like the other
entries in Makefile.in.  I'd rather not do this as it makes the code much
more unreadable, and significantly slower.  (If I had my way, much of the
nonsense in the existing targets would also go away in favor of a more
explicit Makefile.)  

But if I *did* do this, I'd run into a subtler problem: the current
targets handle missing subdirectories by checking inside the
make code and only doing stuff if the subdirectory is present.  The use of
the real target misc/Makefile makes this impossible.  

The 'missing directory' checks can be moved configure-side.  Putting them
configure-side essentially solves this problem -- at
the expense of requiring 'configure' to take the list of subdirectories,
and generate the lists of 'all-subdir' targets, 'check-subdir' targets,
'configure-subdir' targets, 'subdir/Makefile' targets, and so on.  Using
'sed' or large shell loops.

This should, in fact, work without requiring an additional 'stage'.

But it leaves the slow, unreadable shell script fragments in the
Makefile.in, and adds two more (!).  And it's incredibly wasteful to use
the list of subdirectories in the configure to generate several lists of
targets, and then in each target to jump through hoops to get the original
subdirectory name back.  And this ends up moving some logic which 
belongs in the Makefile (such as which targets support 'check') out of the
Makefile into configure.

All of these disgusting things could be avoided:
* trivially with (implicit) pattern rules (as opposed to suffix rules)
* almost trivially with gcc's static pattern rules
* with an appropriate set of new automake rules (I haven't worked out
precisely how to write them, since I don't yet grok automake)
* with a Makefile preprocessor which converted static
pattern rules (with non-wildcard targets) into individual rules

Moving the non-existent-directory checks into configure may (or may
not) be a good idea anyway.  If you think it's a good idea anyway, then
the asterisked items above would still speed up the Makefile and make it
much more readable, although they wouldn't avoid the heavy string-munging
in configure.

--Nathanael Nerode

autoconfiscation -- questions about make usage

[Nathanael Nerode]

All right.  I'm doing a lot of makefile rewriting as part of my
autoconfiscation of the top level directory.  I need to know what GNU make
constructs I'm allowed to use.  Do I need to stick to
lowest-common-denominator make?

It would make things easier if I could define static pattern rules, but if
I can't I can find a way around it.

--Nathanael

Re: autoconfiscation -- questions about make usage

[Joe Buck]

> All right.  I'm doing a lot of makefile rewriting as part of my
> autoconfiscation of the top level directory.  I need to know what GNU make
> constructs I'm allowed to use.  Do I need to stick to
> lowest-common-denominator make?

You don't need to use "least common denominator", but ideally any
Posix-compliant make (e.g. BSD Make) should work.

Re: autoconfiscation -- questions about make usage

[Nathanael Nerode]

On Tue, 29 Jan 2002, Joe Buck wrote:

> 
> > All right.  I'm doing a lot of makefile rewriting as part of my
> > autoconfiscation of the top level directory.  I need to know what GNU make
> > constructs I'm allowed to use.  Do I need to stick to
> > lowest-common-denominator make?
> 
> You don't need to use "least common denominator", but ideally any
> Posix-compliant make (e.g. BSD Make) should work.

Hmm... where the heck do I find a free description of what a make has to
do to be POSIX compliant?

Re: autoconfiscation -- questions about make usage

[Phil Edwards]

On Wed, Jan 30, 2002 at 02:29:39AM -0500, Nathanael Nerode wrote:
> On Tue, 29 Jan 2002, Joe Buck wrote:
> > 
> > You don't need to use "least common denominator", but ideally any
> > Posix-compliant make (e.g. BSD Make) should work.
> 
> Hmm... where the heck do I find a free description of what a make has to
> do to be POSIX compliant?

Don't know about POSIX per se, but the Single Unix Specification is sort
of a follow-on to POSIX.  Their make(1) page is here:

    http://www.opengroup.org/onlinepubs/007908799/xcu/make.html

Unfortunately, even POSIX make is lacking in handy features.  You might
consider writing comments in the makefile.in where some of the more
common GNU make features might be used as replacements, should the SC ever
permit it.  (By "more common" I mean extensions which might also exist in
other make's, like BSD's.)

Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: autoconfiscation -- questions about make usage

[Daniel Jacobowitz]

On Wed, Jan 30, 2002 at 03:14:45AM -0500, Phil Edwards wrote:
> On Wed, Jan 30, 2002 at 02:29:39AM -0500, Nathanael Nerode wrote:
> > On Tue, 29 Jan 2002, Joe Buck wrote:
> > > 
> > > You don't need to use "least common denominator", but ideally any
> > > Posix-compliant make (e.g. BSD Make) should work.
> > 
> > Hmm... where the heck do I find a free description of what a make has to
> > do to be POSIX compliant?
> 
> Don't know about POSIX per se, but the Single Unix Specification is sort
> of a follow-on to POSIX.  Their make(1) page is here:
> 
>     http://www.opengroup.org/onlinepubs/007908799/xcu/make.html
> 
> Unfortunately, even POSIX make is lacking in handy features.  You might
> consider writing comments in the makefile.in where some of the more
> common GNU make features might be used as replacements, should the SC ever
> permit it.  (By "more common" I mean extensions which might also exist in
> other make's, like BSD's.)

I maintain that the best approach here would be to include GNU make in
the source tree.  Someone else (was it Zack?) had a great deal of
simplification this would enable.

I also think we should have auto* stuff in the tree, for maintainer
convenience, but that's a separate argument (and one to pick up after
we've moved to recent versions of those).

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer