bug#7689: Fwd: Due for a new release?

[Stefano Lattarini]

reopen 7689 !
tags 7689 -notabug
severity 7689 whishlist
retitle 7689 Disable portability warnings about make portability issues only?
thanks

On Thursday 23 December 2010, Philip Prindeville wrote:
> On 12/22/10 3:24 PM, Stefano Lattarini wrote:
> > tags 7689 notabug
> > close 7689
> > thanks
> >
> > On Monday 20 December 2010, Philip Prindeville wrote:
> >> The odd thing is that even though it complains, it still generates the 
> >> correct Makefile in the first case:
> >>
> >> SYMFILES = $(srcdir)/uni.h $(shell $(CC) $(CFLAGS) -E $(srcdir)/header.c | 
> >> $(AWK) -f $(srcdir)/script.awk)
> >>
> >> Does automake need to be $(shell ...)-aware?
> >>
> > This is not a bug, as Nick has clearly explained here (BTW, thanks
> > Nick for this!):
> >   
> >
> > So I'm closing it.
> >
> > Philip, if you've been confused on this issue by the automake manual,
> > and have specific complaints or suggestions for improvement, feel free
> > to open a new bug report.  Thanks.
> >
> > Regards,
> >Stefano
> 
> No, not confused.  Just seems counter-intuitive that a GNU utility would have
> the default behavior of complaining when you use other GNU utilities... or
> syntax particular to them.
> 
> It might make more sense to have automake assume that it is being used with
> gmake, and then have a specific option to explicitly turn off that behavior.
> 
Well, since one of the primary goals of Automake is generating *portable*
Makefiles (and believe me it goes through considerable pain to do so), its
behaviour is perfectly rational in this regard.

That said, I think that having more granular warnings about make-only
portability issues might make sense; so that a developer interested in
supporting only GNU make could do something like:

  AUTOMAKE_OPTIONS([-Wall -Wno-make-portability])

and then safely use GNU extensions in his Makefile.am, while preserving
all the other portability warnings provided by Automake.

In light of this, I'm re-opening and re-titling this bug (with severity
"whishlist" this time).

Thanks,
   Stefano

bug#7689: Fwd: Due for a new release?

[Stefano Lattarini]

tags 7689 notabug
close 7689
thanks

On Monday 20 December 2010, Philip Prindeville wrote:
> The odd thing is that even though it complains, it still generates the 
> correct Makefile in the first case:
> 
> SYMFILES = $(srcdir)/uni.h $(shell $(CC) $(CFLAGS) -E $(srcdir)/header.c | 
> $(AWK) -f $(srcdir)/script.awk)
> 
> Does automake need to be $(shell ...)-aware?
> 
This is not a bug, as Nick has clearly explained here (BTW, thanks
Nick for this!):
 

So I'm closing it.

Philip, if you've been confused on this issue by the automake manual,
and have specific complaints or suggestions for improvement, feel free
to open a new bug report.  Thanks.

Regards,
  Stefano

bug#7698: aclocal generates too strict a check for name-lister

[Peter Rosin]

Den 2010-12-22 10:06 skrev Ximin Luo:
> On 22/12/10 00:55, Peter Rosin wrote:
>> FWIW, It smells exactly like a bug that was fixed in libtool 2.2.8 related
>> to this NEWS entry:
> 
> I did some more poking around - this bug is in libtool, but not the one you
> mention. The "responsible snippet" I pasted above is from libtool.m4, and it
> exists in both 2.2.6 (what I have) and 2.2.10 (I checked the debian package
> from experimental). I've sent a mail to bug-libt...@gnu.org.

Well, since I do not see any message on bug-libtool (yet), I'll respond here.

Your quoted "responsible snippet" is not really responsible, methinks.

The bug I mentioned was that when cross-compiling and yet expecting to find
a name lister that is not named as cross tools are normally named (i.e.
relying on 'nm' instead of 'pentium4-foo-bar-nm') libtool would go with the
'link' program instead of falling back to 'nm'. In the good old days, before
libtool could use 'link' (not the 'link' you have, another proprietary 'link')
to find symbols, libtool did fall back to 'nm' in setups such as yours,
and that regression was fixed in 2.2.8. This is exactly what seems to be
happening to you, so I can only encourage you to try with a more recent
libtool. Or, if you find it difficult to update libtool, install a
'pentium4-foo-bar-nm' where your current libtool will find it, perhaps as a
symlink to '/usr/bin/nm'.

Cheers,
Peter

bug#7655: conditional _TEXINFOS should be supported

[Stefano Lattarini]

On Thursday 16 December 2010, Ralf Wildenhues wrote:
> Severity: wishlist
> 
> Conditional _TEXINFOS files should be supported, i.e.,
> 
> if COND
> info_TEXINFOS = foo.texi
> foo_TEXINFOS = bar.texi
> nodist_info_TEXINFOS = generated.texi
> endif
> 
> should work to generate and install foo.{info,pdf,...} only if COND,
> but distribute foo.texi and bar.texi always.  Similar with
> generated.texi (except for distribution, of course).
> 
> Cheers,
> Ralf
> 
JFTR: this is basically PR/191 from the older gnats database:
 


Regards,
   Stefano