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

[Gary V. Vaughan]

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:
>> 
>> https://lists.gnu.org/archive/html/automake-patches/2008-12/msg00027.html
>> 
> 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/check.am-
>  lib/am/check.am:$(TEST_SUITE_LOG): $(TEST_LOGS)
>  lib/am/check.am-        @$(am__sh_e_setup);                                  
>            \
>  --
>  lib/am/configure.am-if %?REGEN-ACLOCAL-M4%
>  lib/am/configure.am:$(ACLOCAL_M4): %MAINTAINER-MODE% $(am__aclocal_m4_deps)
>  lib/am/configure.am-?TOPDIR_P?  $(am__cd) $(srcdir) && $(ACLOCAL) 
> $(ACLOCAL_AMFLAGS)
>  --
>  lib/am/configure.am-## Avoid the "deleted header file" problem for the 
> dependencies.
>  lib/am/configure.am:$(am__aclocal_m4_deps):
>  lib/am/configure.am-endif %?REGEN-ACLOCAL-M4%
>  --
>  lib/am/lisp.am-## an empty target.
>  lib/am/lisp.am:$(am__ELCFILES): elc-stamp
>  lib/am/lisp.am-## Recover from the removal of address@hidden
>  --
>  lib/am/subdirs.am-
>  lib/am/subdirs.am:$(RECURSIVE_TARGETS):
>  lib/am/subdirs.am-## Using $failcom allows "-k" to keep its natural meaning 
> when running a
>  --
>  lib/am/subdirs.am-## bombs.
>  lib/am/subdirs.am:$(RECURSIVE_CLEAN_TARGETS):
>  lib/am/subdirs.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.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)