Re: unesthetic build commands generated by automake

[Ralf Corsepius]

Am Mon, 2003-02-24 um 19.28 schrieb Alexandre Duret-Lutz:
> >>> "Ralf" == Ralf Corsepius <address@hidden> writes:
> 
>  Ralf> Am Mon, 2003-02-24 um 18.18 schrieb Alexandre Duret-Lutz:
>  >> FWIW, Automake doesn't support %-rule.  This is not portable,
>  >> not POSIX, nothing.  You can run `automake -Wportability' to get
>  >> warning about these (BTW, these warnings are likely to be turned
>  >> on by default in 1.8 -- people who know what they do can start
>  >> using `AUTOMAKE_OPTIONS = -Wno-portability' now).
> 
>  Ralf> I don't think this step would be a wise decision unless automake can
>  Ralf> provide a replacement.
> 
> Sorry I don't follow.  A replacement for what?  %-rules?
> Automake never understood these,
IMO, that's the point: Automake never has understood them, has never
cared about them and therefore should not care about them in future
unless automake can provide a substitute ...

>  why should we provide a replacement?

.. to make these Makefiles (more) portable, without rendering future
automakes incompatible to older automakes.

> I agree we should still support those people that know what
> their business and use %-rules anyway, just like we did before
> (i.e., no real support but no complaints).  So if you use
> -Wno-portability, you get the old behavior.  I don't see what's
> unwise.  Automake is there to help creating portable Makefiles.

Well, there are several communities of automake users:
1. Those wanting to implement portable Makefiles.
2. Those using automake as an approach to ease writing Makefiles.

Folks from the 2. community typically will apply custom make-rules and
will not care about portability.

Also keep in mind, that people often apply gnu-make-%-rules to work
around automake-deficiencies.

For instance, I apply gnu-make-%-rules in my Makefile.am to work around
automake not supporting preinstallation of header files and to avoid
having to manually expand dependencies automake can not deal with.

(I could manually expand them, but this would be night-mare to
maintain.)

>  Ralf> Why doesn't automake parse them and rewrite them into a portable form?
> 
> I've tought about this too, but came to the conclusion it was
> impossible.
Well, it might not be possible in all cases of gmake-style
pattern-rules, but it probably is possible in a large subset of them.

>   Consider the following horror:
> 
> %.o: subdir1/%.c subdir2/%.h
Hmm, how does depcomp handle similar dependencies?
[eg. xxx.c: foo/bar.h /usr/include/xyz.h]

> 
> The subdirectories and the number of dependencies prevent
> any conversion to a portable suffix rule.
I am talking about extending automake to accept %-rules in
make-variables automake knows about.

> We can't expand this to normal (i.e. non-suffix) rules either if
> we assume built sources.

Ralf