automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last part of PR/347: warn about $(foo bar).


From: Ralf Corsepius
Subject: Re: Last part of PR/347: warn about $(foo bar).
Date: 22 Aug 2002 10:05:30 +0200

Am Don, 2002-08-22 um 08.39 schrieb Alexandre Duret-Lutz:
> Hi Ralf,
> 
> Thanks for your comments.
> 
> >>> "Ralf" == Ralf Corsepius <address@hidden> writes:
> 
> [...]
> 
>  Ralf> AFAIU, you disable a lot of useful features for people who 
> intentionally
>  Ralf> use automake for gnumake-Makefiles files .
> 
>  Ralf> Furthermore I am concerned about you wanting to parse and warn about
>  Ralf> variables which are not subject to automake's activities.
> 
> The point is to help people writing portable Makefiles.
> Portable Makefiles are one of the goals of Automake.
I know, but ...

many people (including me) are using automake as a means to ease
Makefile writing, and sometimes resort to gnumake features to work
around deficiencies of automake, because a package already requires
gnumake (VPATH builds). 

So my primary reason to use automake is "ease of Makefile writing" with
portability being a "nice-to-have", secondary feature.

Example: I am using gmake's pattern substitutions to implement header
preinstallation.

preincludedir = @somewhere@

include_HEADERS = ... long list of files ...

$(preincludedir)/%.h: %.h
        $(INSTALL_DATA) $< $@

all-local: $(include_HEADERS:$(preincludedir)/%.h=%.h)

If automake provided a different means to implement this, I'd use it,
but .. we already require gnumake, ... so I used this gnumake feature.
.. now you want me to change ~1000 Makefile.ams, having to manually
expand and duplicate 100s of file names ... I'd have to write a tool (a
Makefile.am parser) do this and to keep the sources maintainable.

>  Ralf> To conclude, I am opposed to this, without having an option to disable
>  Ralf> this feature.
> 
> This is a warning, not an error.  
I my case this warning would be inacceptable because it would affect
~1000 Makefile.ams.

> You can enable it with -Wportability
> and disable it with -Wno-portability (either can be set in AUTOMAKE_OPTIONS
> as one of the test case shows).  Is this enough?
Yes, this is what I had in mind. IMO, -Wno-portability should be the
default (at least for 1.7), because this is closer to the current
behavior and people would feel pee'd if their long term Makefile.am
suddenly stop working. Making it the default for 1.8 might be worth it,
but I am not sure. May-be having a --pedanic mode instead would be
better.

Ralf






reply via email to

[Prev in Thread] Current Thread [Next in Thread]