[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:
>>
>> 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)