automake
[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: Stefano Lattarini
Subject: Re: [PATCH 09/25] syntax-check: fix violations and re-enable sc_makefile_at_at_check.
Date: Wed, 16 Nov 2011 18:27:04 +0100
User-agent: KMail/1.13.7 (Linux/2.6.30-2-686; KDE/4.6.5; i686; ; )

[adding automake list in CC]

Hi Eric.

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

> 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.

Regards,
  Stefano



reply via email to

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