Re: [PATCH] getopt: sync from Automake repository
On 01/18/2012 07:09 PM, Stefano Lattarini wrote: * lib/Autom4te/Getopt.am: The master copy of this file has been moved to the Automake repository (see Automake commit 'v1.11-662-g52246cc' 2012-01-18, cmdline parsing: move into a dedicated perl module). So we now we sync it from there, by listing it ... * cfg.mk (autom4te_files): ... in this variable. --- cfg.mk |1 + lib/Autom4te/Getopt.pm |3 +-- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cfg.mk b/cfg.mk index f14737e..6eb2fa4 100644 --- a/cfg.mk +++ b/cfg.mk @@ -82,6 +82,7 @@ autom4te_files = \ Autom4te/Configure_ac.pm \ Autom4te/Channels.pm \ Autom4te/FileUtils.pm \ + Autom4te/Getopt.pm \ Autom4te/Struct.pm \ Autom4te/XFile.pm diff --git a/lib/Autom4te/Getopt.pm b/lib/Autom4te/Getopt.pm index 77f21db..f3fdf68 100644 --- a/lib/Autom4te/Getopt.pm +++ b/lib/Autom4te/Getopt.pm @@ -26,7 +26,7 @@ Autom4te::Getopt - GCS conforming parser for command line options =head1 DESCRIPTION Export a function Cparse_options, performing parsing of command -line options in conformance to the GNU Conding standards. +line options in conformance to the GNU Coding standards. =cut @@ -85,7 +85,6 @@ sub parse_options (%) . Try `$0 --help' for more information.); } } - } =back Ping? Regards, Stefano
Re: [PATCH] build: fix automake error due to missing ChangeLog
On 01/20/2012 10:05 AM, Stefano Lattarini wrote: Apparently, Automake does not accept the '$(srcdir)/ChangeLog' target in Makefile.am as a declaration that ChangeLog is automatically generated (and thus does not need to exist at automake time). One has to use a *literal* 'ChangeLog' target. Problem introduced in commit v2.68-118-g6ed5195 of 2012-01-17, maint: generate ChangeLog from git log. * Makefile.ma ($(srcdir)/ChangeLog): Renamed ... (ChangeLog): ... to this. --- I will push this shortly if there is no objection (as I think that having a suboptimal patch is better than having broken bootstrap on master). ACK, since it improves the build situation. But what does this mean for VPATH development? -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] build: fix automake error due to missing ChangeLog
On 01/20/2012 06:14 PM, Eric Blake wrote: On 01/20/2012 10:05 AM, Stefano Lattarini wrote: Apparently, Automake does not accept the '$(srcdir)/ChangeLog' target in Makefile.am as a declaration that ChangeLog is automatically generated (and thus does not need to exist at automake time). One has to use a *literal* 'ChangeLog' target. Problem introduced in commit v2.68-118-g6ed5195 of 2012-01-17, maint: generate ChangeLog from git log. * Makefile.ma ($(srcdir)/ChangeLog): Renamed ... (ChangeLog): ... to this. --- I will push this shortly if there is no objection (as I think that having a suboptimal patch is better than having broken bootstrap on master). ACK, since it improves the build situation. But what does this mean for VPATH development? Well, let's see: - In a git checkout, make ChangeLog creates a stub dummy ChangeLog anyway *even for in-tree builds*; it will do the same for VPATH builds. This is not a problem anyway, since the real ChangeLog gets rebuilt unconditionally by a dist-hook when the distribution tarball is created. - In a distribution tarball, make ChangeLog should be a no-op, since a ChangeLog file already comes with the distribution. However, with FreeBSD (but *not* NetBSD) make, due to a well-known bug, in a VPATH build make ChangeLog will uselessly rebuild the stub ChangeLog in the builddir (without overriding the one in the srcdir). Which means that FreeBSD cannot bue used to make a new tarball from an extracted tarball using a VPATH setup -- hardly a significant loss IMO. Anyway, patch pushed now. Thanks, Stefano
Re: [PATCH] getopt: sync from Automake repository
On 01/20/2012 05:51 PM, Eric Blake wrote: On 01/18/2012 11:09 AM, Stefano Lattarini wrote: * lib/Autom4te/Getopt.am: The master copy of this file has been moved to the Automake repository (see Automake commit 'v1.11-662-g52246cc' 2012-01-18, cmdline parsing: move into a dedicated perl module). So we now we sync it from there, by listing it ... * cfg.mk (autom4te_files): ... in this variable. --- cfg.mk |1 + lib/Autom4te/Getopt.pm |3 +-- 2 files changed, 2 insertions(+), 2 deletions(-) ACK. Patch pushed. Thanks, Stefano
configure test involving plugin
glib has a configure test to check whether RTLD_GLOBAL is broken on OSF1. This involves building a plugin using libtool and then essentially AC_RUN_IFELSE on a piece of code which loads said plugin. This is all fine, and works. I was just wondering if there was a way of doing this without invoking libtool, as configure should know everything libtool does as it created libtool. (a bit of a theoretical question...) Cheers, Patrick ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Dealing with compilers that pretend to be GCC
On 20/01/2012 11:19, Peter Rosin wrote: Dave Korn skrev 2012-01-20 01:15: *snip* That could be tricky because I guess you won't be able to use libtool at configure time. *snip* It's possible to use libtool at configure time, but you need to invoke LT_OUTPUT before you do so. Or is there a reason for that not to work in this case? Not as far as I know, I just wasn't aware that you could generate the output script early. cheers, DaveK
Re: bug#10555: automake: wrong use of F77FLAGS instead of FFLAGS?
On 01/19/2012 02:45 PM, Stefano Lattarini wrote: [SNIP] So, to all autoconfers: do you happen to know any reason for which Automake should use F77FLAGS? If not, I'll assume that is due to a typo or clerical mistake, and fix it (in 48 hours or so). The attached patch should take care of this. I'll push it tomorrow if there is no objection. Thanks, Stefano From c515aac8817b20a8f0a6ed8969f1f1d0b37c3802 Mon Sep 17 00:00:00 2001 Message-Id: c515aac8817b20a8f0a6ed8969f1f1d0b37c3802.1327089175.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Fri, 20 Jan 2012 20:52:02 +0100 Subject: [PATCH] fixlet: flags for Fortran77 compiler are in FFLAGS, not F77FLAGS This change fixes automake bug#10555. * lib/Automake/Variable.pm (%_ac_macro_for_var): The code generated by AC_PROG_F77 uses FFLAGS, not F77FLAGS, as the variable where to look for switches for the Fortran 77 compiler: adjust accordingly. --- lib/Automake/Variable.pm |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/Automake/Variable.pm b/lib/Automake/Variable.pm index 686847d..8f712bd 100644 --- a/lib/Automake/Variable.pm +++ b/lib/Automake/Variable.pm @@ -181,7 +181,7 @@ my %_ac_macro_for_var = CXX = 'AC_PROG_CXX', CXXFLAGS = 'AC_PROG_CXX', F77 = 'AC_PROG_F77', - F77FLAGS = 'AC_PROG_F77', + FFLAGS = 'AC_PROG_F77', FC = 'AC_PROG_FC', FCFLAGS = 'AC_PROG_FC', OBJC = 'AC_PROG_OBJC', -- 1.7.7.3 ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Dealing with compilers that pretend to be GCC
Dave Korn skrev 2012-01-20 01:15: *snip* That could be tricky because I guess you won't be able to use libtool at configure time. *snip* It's possible to use libtool at configure time, but you need to invoke LT_OUTPUT before you do so. Or is there a reason for that not to work in this case? Cheers, Peter
