[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: 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:
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.
      @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/$(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 
  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/ 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.


reply via email to

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