[Top][All Lists]

[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: Gary V. Vaughan
Subject: Re: [PATCH 09/25] syntax-check: fix violations and re-enable sc_makefile_at_at_check.
Date: Thu, 17 Nov 2011 08:04:34 +0700

Hi Stefano, Eric,

On 17 Nov 2011, at 00:27, Stefano Lattarini wrote:
> On Wednesday 16 November 2011, Eric Blake wrote:
>>> +  - 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:
> This links says nothing about make not accepting macros in targets; it says
> that using macros on the left side of a *macro assignment* is not portable:
>  # Bad, not portable.
>  foo$(var) = bar 
>  # But this should be OK.
>  foo$(var):
>      @echo crating address@hidden

Right, and even when I wrote the dubious comment quoted above in 2003, other
parts of libtool were still using macro expansions in make targets, so I think
the whole thing is probably a red herring.  Libtool has never fully supported
any make that can't deal with macros in targets, and we've never received a
complaint or bug report, which makes me think that if such a make exists, no
one wants to use it with libtool, so we can safely ignore the whole thing.

The NEWS entry I wrote for this commit is purely for future repo archaeology.

>> At least IRIX and HP-UX vendor make fail to handle macros in the target.
> Are you sure?  I'm seeing this in the master branch of automake:
>  $ grep -C1 '^$(.*) *:' lib/am/*.am
>  lib/am/
>  lib/am/$(TEST_SUITE_LOG): $(TEST_LOGS)
>  lib/am/        @$(am__sh_e_setup);                                  
>            \
>  --
>  lib/am/ %?REGEN-ACLOCAL-M4%
>  lib/am/$(ACLOCAL_M4): %MAINTAINER-MODE% $(am__aclocal_m4_deps)
>  lib/am/  $(am__cd) $(srcdir) && $(ACLOCAL) 
>  --
>  lib/am/ Avoid the "deleted header file" problem for the 
> dependencies.
>  lib/am/$(am__aclocal_m4_deps):
>  lib/am/ %?REGEN-ACLOCAL-M4%
>  --
>  lib/am/ an empty target.
>  lib/am/$(am__ELCFILES): elc-stamp
>  lib/am/ Recover from the removal of address@hidden
>  --
>  lib/am/
>  lib/am/ Using $failcom allows "-k" to keep its natural meaning 
> when running a
>  --
>  lib/am/ bombs.
>  lib/am/ Using $failcom allows "-k" to keep its natural meaning 
> when running a
> ... but Ralf Wildnehues used to test automake somewhat regularly on both
> IRIX and HP-UX, and to my knowledge never reported an error related to
> the contructs above.
>>> +
>>> +    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.
> See above.

When my Internet comes back reliably and I can do more than just put mail in
qmail's queue for the next time I have a bit of bandwidth, I'll make sure to
test the HEAD of libtool master on the architectures I have access to, including
both HP/UX and IRIX.

Gary V. Vaughan (gary AT gnu DOT org)

reply via email to

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