libtool-patches
[Top][All Lists]
Advanced

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

Re: [PATCH 09/25] syntax-check: fix violations and re-enable sc_makefile


From: Eric Blake
Subject: Re: [PATCH 09/25] syntax-check: fix violations and re-enable sc_makefile_at_at_check.
Date: Wed, 16 Nov 2011 07:58:11 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1

On 11/15/2011 09:22 PM, Gary V. Vaughan wrote:
> Hi Chuck, Eric,
> 
> Thanks both for the review!
> 
> On 15 Nov 2011, at 23:07, Charles Wilson wrote:
>> On 11/15/2011 7:53 AM, Gary V. Vaughan wrote:
>> tests/mdemo/Makefile.am
>>> -## use @LIBLTDL@ because some broken makes do not accept macros in targets
>>> +## use $(LIBLTDL) because some broken makes do not accept macros in targets
>>
>> This comment now makes zero sense. If you are now forcing the following
>> rule:
>>
>> +$(LIBLTDL): $(top_distdir)/libtool \
>>
>> then (a) remove the comment completely, and (b) document somewhere that
>> we now require non-broken make which DOES allow $(macros) in targets.

>  
> +  - At some point we were supporting some undetermined `broken make', as
> +    evidenced by having carried the following code since 2003:
> +
> +      ## use @LIBLTDL@ because some broken makes do not accept macros in
> +      ## targets, we can only do this because our LIBLTDL does not contain
> +      ## $(top_builddir)
> +      @LIBLTDL@: $(top_distdir)/libtool \
> +      ...

By the way, such make implementations (that don't work with $(macros) in
targets) exist:

https://lists.gnu.org/archive/html/automake-patches/2008-12/msg00027.html

At least IRIX and HP-UX vendor make fail to handle macros in the target.


> +
> +    However, we've also had *many* cases of macros in targets for just as
> +    long, so most likely we never fully supported makes allegedly broken
> +    in this way.  As of this release, we explicitly no longer support
> +    make implementations that do not accept macros in targets.

I suppose we can resuscitate make portability if anyone complains loudly
enough.  We may want to also ask on the automake list if this is still a
real limitation, or whether automake has given up on worrying about this
as well.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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