Re: [RFC] improve autotest syntax checks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Wildenhues on 3/7/2008 11:30 AM:
| Hello Eric,
|
| This patch series is OK, but please look at the nits below.
| Thanks for your good work on this!
I'm committing the first two in the series as is, since there were no
nits. As for the remaining two, here is the revised version for another
round of reviews. Rather than adding a cleanup parameter to
m4_init/AS_INIT, I made m4_wrap guarantee FIFO behavior and added
m4_wrap_lifo, then used these calls in the proper order. I tested with
both M4 1.4.10b (where m4wrap is LIFO) and the M4 argv_ref branch (will
become M4 1.4.11 or maybe 1.5, where m4wrap is FIFO).
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkfWh60ACgkQ84KuGfSFAYD3/QCgmrvxEBVs6SpmreqK93sirkhK
bxIAmwS8ltaTOAwOhxr4UIMjJ6PnlTEQ
=QYBZ
-END PGP SIGNATURE-
From aaf35d7985a94338621fe3577003a8c379162252 Mon Sep 17 00:00:00 2001
From: Eric Blake [EMAIL PROTECTED]
Date: Tue, 11 Mar 2008 07:11:44 -0600
Subject: [PATCH] Tweak m4_wrap to force FIFO or LIFO semantics.
* lib/m4sugar/m4sugar.m4 (m4_wrap): Override M4 implementation.
(m4_wrap_lifo, _m4_wrap): New macros.
* lib/m4sugar/m4sh.m4 (AS_INIT): Combine all cleanup into known
order, prior to m4sugar's.
(_AS_DETECT_BETTER_SHELL): Use cleanup parameter, rather than
m4_wrap.
* lib/autotest/general.m4 (AT_INIT): Combine all cleanup into
known order, prior to m4sh's.
* doc/autoconf.texi (Diagnostic Macros) m4_fatal: Document
argument.
(Redefined M4 Macros) m4_wrap: Rewrite documentation to match
new behavior.
* tests/m4sh.at (AS_INIT cleanup): New test.
* NEWS: Document the change.
Signed-off-by: Eric Blake [EMAIL PROTECTED]
---
ChangeLog | 18 ++
NEWS|6 +-
doc/autoconf.texi | 34 --
lib/autotest/general.m4 |3 ++-
lib/m4sugar/m4sh.m4 | 10 ++
lib/m4sugar/m4sugar.m4 | 26 +-
tests/m4sh.at | 35 +--
7 files changed, 101 insertions(+), 31 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 4576d29..94168a0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,21 @@
+2008-03-11 Eric Blake [EMAIL PROTECTED]
+
+ Tweak m4_wrap to force FIFO or LIFO semantics.
+ * lib/m4sugar/m4sugar.m4 (m4_wrap): Override M4 implementation.
+ (m4_wrap_lifo, _m4_wrap): New macros.
+ * lib/m4sugar/m4sh.m4 (AS_INIT): Combine all cleanup into known
+ order, prior to m4sugar's.
+ (_AS_DETECT_BETTER_SHELL): Use cleanup parameter, rather than
+ m4_wrap.
+ * lib/autotest/general.m4 (AT_INIT): Combine all cleanup into
+ known order, prior to m4sh's.
+ * doc/autoconf.texi (Diagnostic Macros) m4_fatal: Document
+ argument.
+ (Redefined M4 Macros) m4_wrap: Rewrite documentation to match
+ new behavior.
+ * tests/m4sh.at (AS_INIT cleanup): New test.
+ * NEWS: Document the change.
+
2008-03-10 Eric Blake [EMAIL PROTECTED]
Encode nested autotest data.
diff --git a/NEWS b/NEWS
index d6e3b3b..79d72f1 100644
--- a/NEWS
+++ b/NEWS
@@ -111,6 +111,10 @@ GNU Autoconf NEWS - User visible changes.
m4_cmp m4_list_cmp m4_join m4_map m4_map_sep m4_sign
m4_text_box m4_text_wrap m4_version_compare
+ - The m4_wrap macro used to have unspecified order, but now
+ guarantees FIFO order. m4_wrap_lifo was added to guarantee LIFO
+ order.
+
- Packages using the undocumented m4sugar macro m4_PACKAGE_VERSION
should consider using the new AC_AUTOCONF_VERSION instead.
@@ -139,7 +143,7 @@ GNU Autoconf NEWS - User visible changes.
** The following m4sugar macros are new:
m4_append_uniq_w m4_apply m4_combine m4_cond m4_count
m4_dquote_elt m4_echo m4_expand m4_ignore m4_make_list m4_max
- m4_min m4_newline m4_shift2 m4_shift3 m4_unquote
+ m4_min m4_newline m4_shift2 m4_shift3 m4_unquote m4_wrap_lifo
** Warnings are now generated by default when an installer invokes
'configure' with an unknown --enable-* or --with-* option.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 4e24e31..3cdad19 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -10336,29 +10336,19 @@ diversion stack.
@end defmac
@defmac m4_wrap (@var{text})
[EMAIL PROTECTED] m4_wrap_lifo (@var{text})
@msindex{wrap}
-This macro corresponds to @code{m4wrap}.
[EMAIL PROTECTED]
+These macros correspond to @code{m4wrap}. Posix requires arguments of
+multiple wrap calls to be reprocessed at @acronym{EOF} in the same order
+as the original calls (first-in, first-out). @acronym{GNU} M4 versions
+through 1.4.10, however, reprocess them in reverse order
Re: [RFC] improve autotest syntax checks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Wildenhues on 3/11/2008 2:28 PM:
|
| Helper macro for m4_wrap and m4_wrap_lifo. It allows to nest calls
| to m4_wrap within wrapped text.
|
| Should this feature (the nesting) be documented in the manual?
Applied, with the following mention in the manual (and the testsuite
augmented to test nested m4_wrap):
| Unlike the @acronym{GNU} M4 builtin, these macros only recognize one
| argument, and avoid token pasting between consecutive invocations. On
| the other hand, nested calls to @code{m4_wrap} from within wrapped text
| work just as in the builtin.
Although on reflection, this is a slight mis-statement, because:
m4_builtin([m4wrap], [m4_define([foo],[$1])foo([bar])])
behaves differently than
m4_wrap([m4_define([foo],[$1])foo([bar])])
The problem is that m4wrap stores the $1 literally, leaving it for the
definition of foo, but _m4_wrap_text is m4_define'd to contain a $1 then
expanded later, meaning the $1 is expanded as an (empty) argument and foo
is defined to the empty string. However, the M4 manual suffers from the
same bug, so I'll have to think of a way to patch it later and fix it in
both projects.
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkfXLMYACgkQ84KuGfSFAYAYxwCeMJLdh81MBJtNXaknHqzaFcsw
J+0AoNQjPjeTqtGVbOUE1l7i8ZqhIxCv
=v+t4
-END PGP SIGNATURE-
Re: [RFC] improve autotest syntax checks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 3/11/2008 7:07 PM: | The problem is that m4wrap stores the $1 literally, leaving it for the | definition of foo, but _m4_wrap_text is m4_define'd to contain a $1 then | expanded later, meaning the $1 is expanded as an (empty) argument and foo | is defined to the empty string. However, the M4 manual suffers from the | same bug, so I'll have to think of a way to patch it later and fix it in | both projects. Like so. Applying. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfXPRMACgkQ84KuGfSFAYAyXwCg1KSlfYlCTJTZyPMX+b6WcH1H uJcAn3d44SB/KZmwiBrcI4ZdGklBenXp =s8qj -END PGP SIGNATURE- From 3c108e5e9d4eeff6faebc3107dfd11e3b238227e Mon Sep 17 00:00:00 2001 From: Eric Blake [EMAIL PROTECTED] Date: Tue, 11 Mar 2008 20:05:49 -0600 Subject: [PATCH] Fix yesterday's regression in m4_wrap([$1]). * lib/m4sugar/m4sugar.m4 (_m4_wrap): Don't directly invoke wrapped text, since it may contain text that looks like parameters. * tests/m4sh.at (AS@[EMAIL PROTECTED] cleanup): Enhance test. Signed-off-by: Eric Blake [EMAIL PROTECTED] --- ChangeLog |7 +++ lib/m4sugar/m4sugar.m4 |5 +++-- tests/m4sh.at |4 +++- 3 files changed, 13 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index c6cc1e7..2892f57 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2008-03-12 Eric Blake [EMAIL PROTECTED] + + Fix yesterday's regression in m4_wrap([$1]). + * lib/m4sugar/m4sugar.m4 (_m4_wrap): Don't directly invoke wrapped + text, since it may contain text that looks like parameters. + * tests/m4sh.at (AS@[EMAIL PROTECTED] cleanup): Enhance test. + 2008-03-11 Eric Blake [EMAIL PROTECTED] Improve error messages for common testsuite bugs. diff --git a/lib/m4sugar/m4sugar.m4 b/lib/m4sugar/m4sugar.m4 index 9fc7227..e755f98 100644 --- a/lib/m4sugar/m4sugar.m4 +++ b/lib/m4sugar/m4sugar.m4 @@ -611,11 +611,12 @@ m4_define([m4_undefine], # --- # Helper macro for m4_wrap and m4_wrap_lifo. Allows nested calls to # m4_wrap within wrapped text. +# Skip m4_defn and m4_popdef for speed. m4_define([_m4_wrap], [m4_ifdef([$0_text], [m4_define([$0_text], [$1]m4_builtin([defn], [$0_text])[$2])], - [m4_builtin([m4wrap], [$0_text(m4_builtin([popdef], - [$0_text]))])m4_define([$0_text], [$1$2])])]) + [m4_builtin([m4wrap], [m4_unquote(m4_builtin([defn], + [$0_text])m4_builtin([popdef], [$0_text]))])m4_define([$0_text], [$1$2])])]) # m4_wrap(TEXT) # - diff --git a/tests/m4sh.at b/tests/m4sh.at index dc50942..726a23e 100644 --- a/tests/m4sh.at +++ b/tests/m4sh.at @@ -776,8 +776,10 @@ AS_INIT dnl Registered after AS_INIT's cleanups, thus goes to KILL diversion m4_wrap([echo cleanup 2 dnl However, nested wraps and diversions can still be used +dnl Also, test wrapping text that looks like parameter reference m4_wrap([echo cleanup 3 -m4_divert_text([M4SH-INIT], [echo prep 4 +m4_divert_text([M4SH-INIT], [m4_define([foo], [$1])dnl +echo prep foo([4]) ])])]) dnl Registered before AS_INIT's cleanups m4_wrap_lifo([echo cleanup 5 -- 1.5.4
Re: AC_SEARCH_LIBS and the LIBS variable - cross platform?
Brian Dessent wrote: command as just a series of filenames since it does not have any notion of -l or -L. But do note the following from the docs above about Er, that's not quite right. It does have /LIBPATH which I guess is more or less an analogue for -L: http://msdn2.microsoft.com/en-us/library/1xhzskbe.aspx. So you could use that instead of having to mess with the environment if you want to keep things more consistent between the two. Brian ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: seeking advice for a modular build system
Ah, ok, I think I figured out what you mean. I wasn't clear with my initial description. What I want to enable and disable with flags is not which libraries are used for the building (i.e. --with) but which Pure Data libraries get built. Basically, the Pure Data project has about 30ish different libraries, each with its own dependencies, named things like 'gem', 'pdp', 'zexy', etc. I want to be able to do this: ./configure --disable-pdp Then it will build all of the Pure Data libs except 'pdp'. Also, 'pdp' depends on a lot of other libraries, so it should enable/ disable 'pdp' based on which libraries are present in the system. Does that make sense? I don't think it's a common arrangement, but not so unusual. .hc On Mar 11, 2008, at 8:59 AM, Robert Boehne wrote: There are probably too many to name, but what I played with most recently was FreeTDS on SourceForge which does most of these things. Hans-Christoph Steiner wrote: Do you know of an example of the automake/libtool stuff that you are thinking of? .hc On Mar 10, 2008, at 4:29 PM, [EMAIL PROTECTED] wrote: This shouldn't be much trouble. To enable or disable libraries on the command line you would probably use an Automake conditional, and AC_ARG_WITH to turn it on or off. Automake Libtool together will create generic LDFLAGS as well as library-specific ones automatically. -- Original message -- From: Hans-Christoph Steiner [EMAIL PROTECTED] Hey all, I am starting the process of creating an autotools build system for Pd-extended, a large distro of a program called Pure Data and many libraries. Pure Data is a realtime visual programming language for sound, video, etc. Over the years, there have been quite a few libraries written for it. Currently, I have a big hacked Makefile that builds all of the libraries. I would like to replace this with an autotools system. One thing that I would love to have is flags to ./configure to enable/ disable the inclusion of different libraries. The libraries are currently in subdirs named with the library name. I am wondering how to best to that with autotools. Another thing, each of the libraries are made up of one .so/.dylib/.dll for each objectclass. I am wondering what the best method for having separate CFLAGS and LDFLAGS for each library. I want to do that in case different libraries depend on different versions of the same lib. Perhaps I need some kind of recursive ./ configure system. Thanks in advance! .hc --- - ¡El pueblo unido jamás será vencido! ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf - --- [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf All information should be free. - the hacker ethic ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: seeking advice for a modular build system
There are probably too many to name, but what I played with most recently was FreeTDS on SourceForge which does most of these things. Hans-Christoph Steiner wrote: Do you know of an example of the automake/libtool stuff that you are thinking of? .hc On Mar 10, 2008, at 4:29 PM, [EMAIL PROTECTED] wrote: This shouldn't be much trouble. To enable or disable libraries on the command line you would probably use an Automake conditional, and AC_ARG_WITH to turn it on or off. Automake Libtool together will create generic LDFLAGS as well as library-specific ones automatically. -- Original message -- From: Hans-Christoph Steiner [EMAIL PROTECTED] Hey all, I am starting the process of creating an autotools build system for Pd-extended, a large distro of a program called Pure Data and many libraries. Pure Data is a realtime visual programming language for sound, video, etc. Over the years, there have been quite a few libraries written for it. Currently, I have a big hacked Makefile that builds all of the libraries. I would like to replace this with an autotools system. One thing that I would love to have is flags to ./configure to enable/ disable the inclusion of different libraries. The libraries are currently in subdirs named with the library name. I am wondering how to best to that with autotools. Another thing, each of the libraries are made up of one .so/.dylib/.dll for each objectclass. I am wondering what the best method for having separate CFLAGS and LDFLAGS for each library. I want to do that in case different libraries depend on different versions of the same lib. Perhaps I need some kind of recursive ./ configure system. Thanks in advance! .hc ¡El pueblo unido jamás será vencido! ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: FreeBSD /bin/sh with SHELL=.../zsh breaking autoconf ./configure?
On Tue, 11 Mar 2008 08:03:55 +0100 Ralf Wildenhues [EMAIL PROTECTED] wrote:
* Mike Meyer wrote on Tue, Mar 11, 2008 at 01:58:52AM CET:
On Tue, 11 Mar 2008 01:15:11 +0100 Ralf Wildenhues [EMAIL PROTECTED]
wrote:
* Mike Meyer wrote on Sun, Mar 09, 2008 at 02:56:50AM CET:
The configure script otherwise seems to run fine, creates the
Makefile, and exits without any other errors. Likewise, there are no
errors in config.log, nor any mention of as_func or shell
functions. However, the Makefile is pretty horribly broken.[...]
Can you send a unidiff of the broken case and a working case (/bin/sh)
for the config.status file and the Makefile which causes make to bail?
Attached.
Also, which zsh version is this?
zsh 4.3.2 (amd64-portbld-freebsd6.2)
Thanks. This patch ports Python's makesetup to be usable with zsh, and
results in a Makefile identical to one created with bash. I have not
checked whether other shell scripts in the Python package need similar
treatment. Please report this to the Python folks (best if you also
mention the CONFIG_SHELL workaround I wrote in the previous mail).
This isn't a python specific issue; it occurs with other autoconf
generated configure scripts as well. Python was just the first one I
noticed.
mike
Cheers,
Ralf
* Modules/makesetup: Port to zsh, taken from Autoconf.
--- Python-2.5.2/Modules/makesetup.orig 2008-03-11 07:59:23.0
+0100
+++ Python-2.5.2/Modules/makesetup2008-03-11 07:58:53.0 +0100
@@ -39,6 +39,16 @@
# - for each variable definition found in Setup, insert the definition
# before the comment 'Definitions added by makesetup'
+# zsh workaround
+if test -n ${ZSH_VERSION+set} (emulate sh) /dev/null 21; then
+ emulate sh
+ NULLCMD=:
+ # Zsh 3.x and 4.x performs word splitting on ${1+$@}, which
+ # is contrary to our usage. Disable this feature.
+ alias -g '${1+$@}'='$@'
+ setopt NO_GLOB_SUBST
+fi
+
# Loop over command line options
usage='
usage: makesetup [-s srcdir] [-l libdir] [-c config.c.in] [-m Makefile.pre]
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: Checking versions and defining macros
Ralf Wildenhues wrote: Hello Jason, let's please limit replies to the autoconf list, thanks. Sorry, I wanted to check for various solutions for all the packages, not just autoconf. * Jason Curl wrote on Wed, Mar 05, 2008 at 06:47:04AM CET: To achieve my goals, I've borrowed some of the internals of the auto* tools (and libtool). I'd like to somehow check the version of the autotools during autoreconf time and include macros specific to a particular version. If I see a version that I haven't tested with, then I'd like to print a warning that something needs to be looked at (i.e. update my macros). This will allow me especially to upgrade to libtool-2.2 and play with it, while knowing it will always work with 1.5.24. A summary of what I've had to hack: AC_CHECK_LIB: borrowed from here for the Solaris networking features AC_CHECK_DECL: Disable printing, to encapsulate in my own scripts AC_PROG_LD: Would die if it couldn't find LD, rather than allow my configure.ac to provide an alternate Not sure what your question is. Autoconf minimum version can be required with AC_PREREQ, its exact version is m4_defn([m4_PACKAGE_VERSION]). Automake minimum version can be required with AM_INIT_AUTOMAKE. Libtool minimum version can be required with LT_PREREQ (starting from 2.2). To rule out earlier versions, you can see whether LT_PREREQ is defined: m4_ifdef([LT_PREREQ], [...]). If I have autoconf 2.59, I would like to use macro A. But if I have autoconf 2.61, then I'd like to use macro B instead. Ideally, they would be the same name, but might have slightly different definitions, especially if I start to use the internals. I would do this, because I've had to modify and borrow implementations from libtool 1.5.24. As autotools don't guarantee internal APIs as being stable, I would warn when autotools are too new, or use a different implementation. There are two development environments I use. One is older than the other and when I start using internal APIs, they may become incompatible, unless I can include macro A for version A of autotools and macro B for version B of autotools. I hope I make more sense this time. Thanks, Jason. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Checking g77 or gfortan calling convention for c++
Hello Klaas, * Klaas Vantournhout wrote on Sat, Mar 08, 2008 at 10:55:10PM CET: I need to use complex functions from a fortran library in a c/c++ code. First off, do you know cfortran.h? While it's not in the Autoconf spirit of using tests to find out about unknown systems, AFAIK it's quite comprehensive. I don't know whether it covers C++, though. As I have seen there are two calling conventions for complex functions. [...] I am wondering if it is possible for autoconf to check the above calling convention of a library. I see two possibilities: First, try matching declarations: compile a code snippet that includes the library header, then re-declare the function using each way in turn. The matching one will not trigger a conflicting declaration error. Second, you can try to link a small program using one or the other convention against the library. Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Checking g77 or gfortan calling convention for c++
On 11-Mar-2008, Ralf Wildenhues wrote: | I see two possibilities: First, try matching declarations: compile a | code snippet that includes the library header, then re-declare the | function using each way in turn. The matching one will not trigger a | conflicting declaration error. Typically there are no header files providing C/C++ declarations for Fortran functions. | Second, you can try to link a small program using one or the other | convention against the library. Linking is not enough. I think you'd have to run a program and see if it works by checking to see that the correct result is returned from the function. The test program may also crash when run if the calling conventions are mixed. jwe ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
