Last patch I'd like to go in 2.60
http://mail.gnu.org/archive/html/autoconf-patches/2003-11/msg00075.html fixes the longstading (dates back to the beginning of the CVS repository) failure to use the third argument of AU_DEFUN. Maybe given the problems with 2.58 it would be good to distribute Automake 1.8 and Autoconf 2.60 together, so that the former can require the latter. All the changes that intervened since 2.59 should be safe, except possibly the shell functions spy. Again, I must thank you for putting up with my (probably, sometimes presumptuous) views, and sorry for being unclear about RFC vs. RFA. Paolo
[Fwd: gnuplot sed error]
Here's it for you, a bug in the missing script.
Paolo
---BeginMessage---
There was an error when I ran make install-strip.
Thanks for gnuplot. The demos are working just fine.
I am running gnuplot on HP-UX B.11.23 U ia64
Dale Holt
Colorado Springs
Making install in docs
/home/dholt/gnu/gnuplot-4.0.0/docs
gmake[2]: Entering directory `/home/dholt/gnu/gnuplot-4.0.0/docs'
../mkinstalldirs /home/dholt/share/gnuplot/4.0
.././install-sh -c -m 644 gnuplot.gih
/home/dholt/share/gnuplot/4.0/gnuplot.gih
/bin/sh /home/dholt/gnu/gnuplot-4.0.0/missing --run makeinfo -I.
./gnuplot.texi --no-split --output=gnuplot.info
/home/dholt/gnu/gnuplot-4.0.0/missing[52]: makeinfo: not found.
WARNING: `makeinfo' is missing on your system. You should only need it if
you modified a `.texi' or `.texinfo' file, or any other file
indirectly affecting the aspect of the manual. The spurious
call might also be the consequence of using a buggy `make' (AIX,
DU, IRIX). You might want to install the `Texinfo' package or
the `GNU make' package. Grab either from any GNU archive site.
sed: unrecognized option `--output=gnuplot.info'
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...
-n, --quiet, --silent
suppress automatic printing of pattern space
-e script, --expression=script
add the script to the commands to be executed
-f script-file, --file=script-file
add the contents of script-file to the commands to be
executed
-i[SUFFIX], --in-place[=SUFFIX]
edit files in place (makes backup if extension supplied)
-l N, --line-length=N
specify the desired line-wrap length for the `l' command
--posix
disable all GNU extensions.
-r, --regexp-extended
use extended regular expressions in the script.
-s, --separate
consider files as separate rather than as a single
continuous
long stream.
-u, --unbuffered
load minimal amounts of data from the input files and flush
the output buffers more often
--help display this help and exit
--version output version information and exit
If no -e, --expression, -f, or --file option is given, then the first
non-option argument is taken as the sed script to interpret. All
remaining arguments are names of input files; if no input files are
specified, then the standard input is read.
E-mail bug reports to: [EMAIL PROTECTED] .
Be sure to include the word ``sed'' somewhere in the ``Subject:'' field.
usage: touch [-amc] [-t [[CC]YY]MMDDhhmm[.SS] | -r ref_file] file ...
../mkinstalldirs /home/dholt/info
.././install-sh -c -m 644 gnuplot.info /home/dholt/info/gnuplot.info
.././install-sh: gnuplot.info does not exist.
gmake[2]: *** [install-info] Error 1
gmake[2]: Leaving directory `/home/dholt/gnu/gnuplot-4.0.0/docs'
gmake[1]: *** [install-recursive] Error 1
gmake[1]: Leaving directory `/home/dholt/gnu/gnuplot-4.0.0'
gmake: *** [install-strip] Error 2
---End Message---
Re: Workarounds for automake does not support info_TEXINFOS being defined conditionally
Ralf Wildenhues wrote: Hello Brooks, * Brooks Moses wrote on Tue, Nov 06, 2007 at 11:19:21PM CET: This resulted in the error quoted in the subject line, automake does not support info_TEXINFOS being defined conditionally, followed by an Internal Error. Hmm, something got stuck there: http://thread.gmane.org/gmane.comp.sysutils.automake.patches/2731/focus=2757 Paolo, do you have time to look at this? Not soonish, but I will. On the other hand, did you look into improving portability of my patch for faster autotest? :-) Paolo
Re: profile-directed optimization
Bruno Haible wrote: Paolo Bonzini wrote: But the compiler does not know that fstrcmp is called millions of time and that this piece of code needs to be optimized for speed rather than for space. If doing profile-directed optimization, it does know. However, it is impractical: I never used profile-directed optimization with GCC so far, because the steps to put it in place are prohibitive. In a just-in-time compiler, such as in Java or C# virtual machines, it can be implemented transparently. But in a C compiler, it requires the following steps (taken from the GCC manual): * Compile the source files with `-fprofile-arcs' plus optimization and code generation options. * Link your object files with `-lgcov' or `-fprofile-arcs' (the latter implies the former). * Run the program on a representative workload to generate the arc profile information. * Compile the source files again with the same optimization and code generation options plus `-fbranch-probabilities' .PHONY: profile profile: make clean make CFLAGS=$(CFLAGS) -fprofile-generate make check make mostlyclean make CFLAGS=$(CFLAGS) -fprofile-use CLEANFILES = *.gcda *.gcno Paolo
Re: Define a complete rule via autoconf (quoting issue, AC_SUBST)
I get errors running ./configure. I guess, this is, because of a problem with the quotation. Doing a simple: AC_SUBST([DESKTOP_DATA_RULE], [ target: requirements @list=... ]) DESKTOP_DATA_RULE=AS_ESCAPE([ ... ]) AC_SUBST([DESKTOP_DATA_RULE]) should work. Paolo
Re: [PATCH] maint.mk (null_AM_MAKEFLAGS, built_programs): remove unused definitions
On 12/13/2009 10:31 AM, Jim Meyering wrote: -# Use this to make sure we don't run these programs when building -# from a virgin tgz file, below. -null_AM_MAKEFLAGS = \ - ACLOCAL=false \ - AUTOCONF=false \ - AUTOMAKE=false \ - AUTOHEADER=false \ - MAKEINFO=false This rule could actually be moved to Automake's distcheck target. Paolo
Re: [PATCH 0/2] Re: ifdef expessions in Makefile.am
On 12/22/2009 09:38 AM, Joakim Tjernlund wrote: bonz...@gnu.org wrote on 22/12/2009 09:16:59: From: Paolo Bonzinibonz...@gnu.org Here is where I was at. After that it was not immediate how to use a tag-dependent cache variable. Strictly speaking however using a cache variable is not needed to make the PIC test overridable. The patch is quite risky though. Paolo Paolo Bonzini (2): split -Wl test extract static flag detection hmm, looking into the patch I don't see how this lets me replace -fPIC with -fpic. Maybe I am missing something? It is not complete, hence here is where I was at. Paolo
[RFC] AM_ARG_ENABLE
While looking around at the most common shell idioms in otherwise simple configure.ac files, I found a very common one: AC_ARG_ENABLE([something], [--enable-somethingxyz],, [enable_something=no]) AM_CONDITIONAL([SOMETHING, [test $enable_something != no]) What would you think about one or two wrapper macros in Automake that would simplify the above to AM_ARG_ENABLE([something], [xyz]) # if default is NO AM_ARG_DISABLE([something], [xyz]) # if default is YES ? Paolo
Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?
On 11/21/2011 09:56 PM, Stefano Lattarini wrote: Here is my tentative plan to act on the proposal: 1. We start requiring GNU make in an experimental automake 2.0 development line (which might, and will, break whathever backward-compatibility gets in its way). 2. Concurrently, we continue to support the more portable (and tested, and used-in-the-real-world) 1.x line, with bugfixes at least (and probably also with addition of new not-too-big features). 3. We publicize this move in the automake (1.x) web pages, documentation, etc, inviting users and developers to try out the new automake 2.0 pre-alpha, and to send cricisims, suggestions, praise and ranting to the automake lists. 4. Time and user responses decide wether automake 2.0 will succeed or die out. WDYT? It seems very hard to be successful and break backwards-compatibility. When we introduced shell functions into Autoconf, and in general updated Autoconf/M4sh/libtool for relatively new shells (new = newer than Ultrix), it was successful exactly because no one noticed! Paolo
Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?
On 11/22/2011 04:35 PM, Stefano Lattarini wrote: 1. Automake 2 turns out to be a failure, it gets abandoned, and Automake 1 becomes again the center of all our developement efforts. No problem for you, since you're still using this older automake. 2. Automake 2 is a success, and we drop support for Automake 1. At this point, it shouldn't be too big a pain for you to convert to the new automake (a good documentation about incompatibilities between, and/or transition from, automake 1 and 2 should exist at this point). Also, assuming that many other packages are using automake 2 by now, and thus requiring GNU make, it should be much more acceptable for the NTP build system to do the same. A half transition happens, which turns out to be a nightmare until Automake 2 adoption actually becomes common. This is exactly what happen between Automake 1.5 and Automake 1.8, each of which introduced many backwards-incompatible features, and between Autoconf 2.50 and some time later. Paolo
Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?
On 11/24/2011 04:51 PM, Richard Stallman wrote: I agree the reason becomes less compelling as more capable systems become more commonplace, but I do not agree ancient RISC boxes are no longer an interesting target for current NTP builds. The machine I use (and many of us, too) has a MIPS-like chip, the Loongson. I don't think portability has anything to do with age or family of the processor, but more with the operating system. Ancient RISC boxes were running only very small parts of the GNU userspace. Instead, modern ARM/MIPS/SPARC/PowerPC machines are often GNU/Linux or Busybox/Linux (and if the latter, they are cross-compiled with a GNU toolchain). Paolo
Re: [PATCH] build: support and require Automake-NG
Il 21/08/2012 12:10, Stefano Lattarini ha scritto: (AC_SUBST): Define AM_VARTYPOS_WHITELIST to LIBFFI_EXECUTABLE_LDFLAGS RELOC_LDFLAGS. This is required because Automake-NG is stricter than mainline Automake in its make runtime checks on possible typos in variables like 'foo_SOURCES' and 'bar_LDADD', and that was causing a spurious failure in the GNU Smalltalk build system. Can Automake-NG instead whitelist all-uppercase variables? I'd rather not add extra special cases unless that proves to be actually necessary. And I believe that is not the case here, since the white listing is obtained with just a simple one-liner. If you really don't like the whitelisting, another viable solution would be to rename the RELOC_LDFLAGS variable to, say, RELOC-LDFLAGS, or even LDFLAGS.RELOC; and similarly for the other variable. This is the solution I'd personally prefer; in the I sent patch I opted for the whitelisting just because that entailed less code churn. The point is not the whitelisting; it is really that zero code churn is still the best choice... This smells too much of Autoconf 2.50... I was there and it was not pretty. ;) Another choice is to find AC_SUBSTed variables that end with LDFLAGS, CPPFLAGS, CFLAGS, etc., and whitelist them automatically. It can be done in m4, from Automake-NG's macros. Also, this is different from all other configuration mechanisms; it would be nicer to have it as an Automake-provided AM_* macro, Nope, because the whitelisting must be allowed to be Makefile-specific. or a Makefile.am definition. I agree. And in fact this is exactly the mechanism provided by Automake-NG! Doh, obvious when you point it out. :) * Makefile.am (AUTOMAKE_OPTIONS): Add the 'ng' option, to ensure that mainstream Automake is not used by mistake when bootstrapping. Also, bump the required Automake version from '1.11.1' to '1.12a', which is the latest (and still development-only) version of Automake-NG at the moment of writing. Drop the 'dist-xz' option, that is not supported anymore. The same effect is now obtained ... (AM_DIST_FORMATS): ... defining this to gzip xz. Can you instead provide the backwards-compatible format with a deprecation period? No, sorry, that would complicate the Automake-NG code for too little gain. Automake-NG is actually about maintainer convenience as much as it is about user convenience, so such backward-incompatibilites and little porting efforts are to be expected when switching from mainline Automake to Automake-NG. That's fine, indeed if you add support in mainline Automake the deprecation period would end with the merge of Automake-NG. And perhaps add support for AM_DIST_FORMATS in mainline Automake? This should be easily doable for 1.13, or even 1.12.4. And it might help some projects simplifying their transition to Automake-NG. So why not? I'll try to cook up a patch in the next days. Nice. Paolo
Re: Automake vs. Automake-NG
Il 21/08/2012 14:44, Stefano Lattarini ha scritto: But there is an important difference: Automake-NG is *not* the next version of Automake, it is the Next Generation: it's not meant to be merged into the Automake code base, nor to supersede Automake, because the two projects have different mission statement: - Automake: allow the user to write Makefiles portable to different systems *and* make implementation, and help him to *avoid* using GNU make specific features would hurt portability, - Automake-NG: allow the user to write Makefiles portable to different systems *but* tailored for modern GNU make, and allow them to take *full advantage* of GNU make features whenever possible (which is less than we'd like, due to the code base and design inherited from mainline Automake). Automake-NG might finally supersede Automake when *and if* the great majority of developers using the the Autotools agree that porting to non-GNU make is not worth anymore; but that will not mean that Automake has been merged into Automake-NG, merely that a change in portability requirements have made it obsolete. That's very important to understand. Understood. On the other hand, Automake-NG should strive as much as possible for backwards-compatibility, so that the obsolescence of Automake comes naturally, and requires as little manual intervention as possible. If one day Automake-NG 0.99 happens to become Automake 2.0, people should not notice. For this reason, as much deprecation as possible should occur in both code bases. Looking at the GNU Smalltalk patches you sent: * using INCLUDES instead of AM_CPPFLAGS could be deprecated loudly in Automake 1.13 * pattern rules should be advertised over suffix rules in Automake-NG, but suffix rules should be accepted * files with non-standard extensions in _SOURCES should be warned about in Automake 1.13 This way, people will slowly convert their code bases to the style preferred for Automake-NG. If the only point that remains is the variable typo detection, that's fine. But all semantic changes should be suggested by (non-NG) Automake for developer to even consider taking Automake-NG seriously, IMHO. I apologize for the useless complaint if you are already doing this; please let me explain my worries. The lack of a clear upgrading path (and bugs in autoupdate, which took a while to get right) was what caused problems in Autoconf 2.50-2.53, compounded by the lack of awareness about Autoconf/m4 best practices. Now the latter has not changed much; try-and-see-debugging is still in wide use for Autotools (and that is the reason for so many Autotools-related flamewars). But (non-NG) Automake is Perl, not m4. It can provide good error messages and a clear upgrading path. Please _do_ provide it. Another choice is to find AC_SUBSTed variables that end with LDFLAGS, CPPFLAGS, CFLAGS, etc., and whitelist them automatically. It can be done in m4, from Automake-NG's macros. I'm still not sold on this. What if a user have foobar in bin_PROGRAMS, and then do something like this in its configure.ac: if something; then AC_SUBST([foobar_LDFLAGS], [-lzap]) else AC_SUBST([foobaz_LDFLAGS], [-lmu]) fi I think a warning about no program or library named 'foobaz' is still warranted here. Yeah, and that's why I initially proposed whitelisting all-uppercase variables. It's a convention, but it's a common convention. Programs are rarely if-ever all-uppercase. Libraries never are due to the _a or _la suffix. Hope I've clarified the situation a bit. Me too. :) Paolo
Re: Automake vs. Automake-NG
Il 21/08/2012 16:32, Stefano Lattarini ha scritto: Bottom line is: we want to make it clear that Automake-NG is something different from Automake -- albeit mostly compatible, deliberately, and with very, very similar design and API; and that a transition between the two won't be seamless -- albeit it is expected to be simple and to involve only little churn. Ok. * using INCLUDES instead of AM_CPPFLAGS could be deprecated loudly in Automake 1.13 This is a good idea. Want to attempt a patch? Otherwise, I will write it myself in the next days. I doubt I have time, unfortunately. :( * pattern rules should be advertised over suffix rules in Automake-NG, but suffix rules should be accepted They are! It's actually simpler to accept them rather than to reject them, since doing the latter would entail more Automake-runtime processing, which we want to avoid. The only important difference is that you'll have to declare '.SUFFIXES:' yourself, as Automake-NG do not do it automatically for you anymore (a change which I now see is not listed in the NG-NEWS file; will fix shortly). Ok. So the question I'd like you to ask yourself are: * Why does it make sense to request manual declaration of '.SUFFIXES:'? * Does it make sense to do so in Automake, too? * Even if not, could a missing '.SUFFIXES:' hide bugs? Would you consider adding a warning for missing .SUFFIXES in Automake, too? This needs to be done for each NG-NEWS items. It could improve the existing users of Automake, and reduce the size of NG-NEWS. Both of which are good things! This way, people will slowly convert their code bases to the style preferred for Automake-NG. If the only point that remains is the variable typo detection, that's fine. But all semantic changes should be suggested by (non-NG) Automake for developer to even consider taking Automake-NG seriously, IMHO. I disagree. After all, people are taking CMake seriously, and that is hardly compatible with Automake. But CMake is not almost the same as Automake, Automake-NG is. Automake-NG is not Automake 2.0, but Automake 2.0 _could_ have the same user interface as Automake-NG. What I'm asking is, please consider a deprecation path in Automake for _every_ _single_ difference between it and Automake-NG. If you rewrote Automake in m4 (only partly kidding), I wouldn't have had these objections. But changing the name doesn't change the perception. I apologize for the useless complaint if you are already doing this; Please don't. I find this exchange very useful and informative for my own understanding of the status and direction of Automake-NG. please let me explain my worries. The lack of a clear upgrading path (and bugs in autoupdate, which took a while to get right) was what caused problems in Autoconf 2.50-2.53, compounded by the lack of awareness about Autoconf/m4 best practices. The difference here is that people *should* understand that Automake-NG is not meant as an Automake 2.0, but as a new projects with different aims, and thus different idioms, usages, strengths and weaknesses. People won't. :) This is the point I want to drive home, to avoid another transition debacle like the Autoconf one. Here's an honest question: if Autoconf 2.50 has been called Autoconf-NG 3.0 alpha, and finally graduated to Autoconf-NG 3.0 with what we know as Autoconf 2.60, do you think the transition would have been less painful (I really hope the answer is yes, of course). My answer is that the two cases are different. On one hand, there was no obstacle between a possible graduation of Autoconf-NG 2.5x to Autoconf, like the GNU Make dependency could be for Automake-NG. On the other hand, it would have been nigh impossible to provide the smooth deprecation path that I'm suggesting. All I'm saying is, do not release Automake-NG for public use until Automake can warn of all incompatible uses, or almost all. It can provide good error messages and a clear upgrading path. Please _do_ provide it. I hope to finally do that, but it will be in a form of a how-to and a set of recipes rather than an attempt to shoehorn Automake-NG semantics back to Automake. The latter sounds too slow and too dangerious. You have to evaluate each case separately of course, but a single project has already shown several cases where Automake _could_ be improved this way. Paolo
Re: Automake vs. Automake-NG
Il 21/08/2012 16:53, Diego Elio Pettenò ha scritto: do you think the transition would have been less painful (I really hope the answer is yes, of course). From a distribution point of view... it wouldn't have been any less painful. It would have meant we'd have even more packages using autoconf-2.1 than we still have right now Exactly. The -NG moniker would have made no sense. What could have made sense would have been a mapping like 2.50 2.90 2.51 2.91 2.52 2.92 2.53 2.93 2.x, x = 54 3.(x-54) This would have made it clear that the transition was not expected to be too smooth. Note that following each version was a lot of work, but 2.13-2.50 and 2.13-2.54 weren't that different (in fact 2.13-2.54 was probably easier due to less bugs). Another thing that was missing was the author's reaching out to convert other projects, which is what you've been doing (and it's been very welcome). Did you try sed and grep already? Paolo
Re: Automake vs. Automake-NG
Il 21/08/2012 17:42, Stefano Lattarini ha scritto: Not sed, no (maybe you can try it to see how the conversion goes from someone not involved in Automake-NG as I am?). But grep, coreutils, m4 (1.4.x branch), bison, dejagnu, parted and autoconf has already been successfully converted: https://github.com/slattarini/coreutils-am-ng https://github.com/slattarini/grep-am-ng [ ... and so on, you got the gist ... ] Splitting the patches like you did for GNU Smalltalk would be great, so we can get the early part merged as soon as possible. Paolo
Re: Automake vs. Automake-NG
Ok. So the question I'd like you to ask yourself are: * Why does it make sense to request manual declaration of 'SUFFIXES'? * Does it make sense to do so in Automake, too? And another question: * Alternatively, could Automake-NG suggest converting suffix rules to pattern rules so that the extra SUFFIXES entries are not necessary anymore? Or even do that automatically in the Makefile.am - Makefile.in conversion? This needs to be done for each NG-NEWS items. It could improve the existing users of Automake, and reduce the size of NG-NEWS. Both of which are good things! And I've done that already where possible and reasonable. For example, the 'silent-rules' option is now active by default, and the tags-related rules have been reworked and improved. I might consider other similar backports as well in the future. Cool, please do. But in several areas, similar changes would risk to cause serious bugs and incompatibilities which, while IMHO acceptable in a young and still experimental software like Automake-NG, would not be acceptable in an Automake release. Understood. It has to be done carefully. But CMake is not almost the same as Automake, Automake-NG is. Automake-NG is not Automake 2.0, but Automake 2.0 _could_ have the same user interface as Automake-NG. What I'm asking is, please consider a deprecation path in Automake for _every_ _single_ difference between it and Automake-NG. Not doable, sorry. Consider != provide. :) You can use your judgement and creativity. If you rewrote Automake in m4 (only partly kidding), I wouldn't have had these objections. But changing the name doesn't change the perception. Maybe we just need good PR and advertisment in this. The python developers has managed to make a 3.0 release incompatible with the 2.x series, because they've been very clear and vocal about the breakage, and have been for a long time. We might need to learn from them here, and maybe we'll succeed. Any suggestion? Yes, that's correct. PR and advertisement is what lacked in the early Autoconf 2.5x releases. All I'm saying is, do not release Automake-NG for public use until Automake can warn of all incompatible uses, or almost all. As I said, I don't believe this would be actually doable. Looking at GNU Smalltalk, I see: * warn for INCLUDES (vs. AM_CPPFLAGS) * warn for unknown *_XYZFLAGS variables (btw, why doesn't CAIRO_CFLAGS raise a warning)? * warn for treating _SOURCES entries with a custom unknown user extension as if they were header files as possible action items for Automake. And: * warn for suffix rules or otherwise do something about them * fix BUILD_SOURCES fork bomb, perhaps warn about it in advance (though I'm not sure I understood the root cause here) for Automake-NG. You have to evaluate each case separately of course, but a single project has already shown several cases where Automake _could_ be improved this way. Are you referring to the Smalltalk port? If yes, I'm not seeing your point honestly. Care to elaborate? See above. Paolo
Re: Automake vs. Automake-NG
Il 21/08/2012 18:01, Paolo Bonzini ha scritto: Ok. So the question I'd like you to ask yourself are: * Why does it make sense to request manual declaration of 'SUFFIXES'? * Does it make sense to do so in Automake, too? And another question: * Alternatively, could Automake-NG suggest converting suffix rules to pattern rules so that the extra SUFFIXES entries are not necessary anymore? Or even do that automatically in the Makefile.am - Makefile.in conversion? This needs to be done for each NG-NEWS items. It could improve the existing users of Automake, and reduce the size of NG-NEWS. Both of which are good things! And I've done that already where possible and reasonable. For example, the 'silent-rules' option is now active by default, and the tags-related rules have been reworked and improved. I might consider other similar backports as well in the future. Cool, please do. But in several areas, similar changes would risk to cause serious bugs and incompatibilities which, while IMHO acceptable in a young and still experimental software like Automake-NG, would not be acceptable in an Automake release. Understood. It has to be done carefully. But CMake is not almost the same as Automake, Automake-NG is. Automake-NG is not Automake 2.0, but Automake 2.0 _could_ have the same user interface as Automake-NG. What I'm asking is, please consider a deprecation path in Automake for _every_ _single_ difference between it and Automake-NG. Not doable, sorry. Consider != provide. :) You can use your judgement and creativity. If you rewrote Automake in m4 (only partly kidding), I wouldn't have had these objections. But changing the name doesn't change the perception. Maybe we just need good PR and advertisment in this. The python developers has managed to make a 3.0 release incompatible with the 2.x series, because they've been very clear and vocal about the breakage, and have been for a long time. We might need to learn from them here, and maybe we'll succeed. Any suggestion? Yes, that's correct. PR and advertisement is what lacked in the early Autoconf 2.5x releases. All I'm saying is, do not release Automake-NG for public use until Automake can warn of all incompatible uses, or almost all. As I said, I don't believe this would be actually doable. Looking at GNU Smalltalk, I see: * warn for INCLUDES (vs. AM_CPPFLAGS) * warn for unknown *_XYZFLAGS variables (btw, why doesn't CAIRO_CFLAGS raise a warning)? * warn for treating _SOURCES entries with a custom unknown user extension as if they were header files Ah, and * add support for AM_DIST_FORMATS. Paolo as possible action items for Automake. And: * warn for suffix rules or otherwise do something about them * fix BUILD_SOURCES fork bomb, perhaps warn about it in advance (though I'm not sure I understood the root cause here) for Automake-NG. You have to evaluate each case separately of course, but a single project has already shown several cases where Automake _could_ be improved this way. Are you referring to the Smalltalk port? If yes, I'm not seeing your point honestly. Care to elaborate? See above. Paolo
Re: Automake vs. Automake-NG
Il 21/08/2012 18:30, Ralf Corsepius ha scritto: Yes, that's correct. PR and advertisement is what lacked in the early Autoconf 2.5x releases. Really? That's not how I recall the situation. I recall people turning away from autoconf in disgust because of the numerous incompatiblities and the often tremendous effort porting would have required. Yes, that's correct. Still, in the end the reason was bad planning: 2.50-2.53 were buggy and introduced backwards-incompatibilities with respect to earlier 2.5x versions. There was no advertisement of the actual state, so you had to figure out that 2.54 and 2.59 were the really stable ones. There was also no proactive effort of the maintainers to push changes to other projects, etc. In all fairness, it's very difficult to do such a transition for a build system. But it's still a lesson to learn, and you _can_ do better with Automake-NG. Instead of jumping the upstream autoconf train, they waited for the things to settle/stabilize (some projects are still waiting today) while others started to look out for alternatives (cmake, scons) - Many switched away. Yes, that's also what I recall. Paolo
Re: Automake vs. Automake-NG
Il 21/08/2012 19:14, Stefano Lattarini ha scritto: * warn for unknown *_XYZFLAGS variables I'm still unconvinced it would be a good idea to introduce this incompatibility in Automake just for the sake of simplifying transition to Automake-NG, sorry. * warn for treating _SOURCES entries with a custom unknown user extension as if they were header files Ditto. Uhm, either they are good warnings for both, or pointless incompatibilities for both... You had almost convinced me of the former! :P Paolo
Re: Automake vs. Automake-NG
On Tue, Aug 21, 2012 at 9:10 PM, Stefano Lattarini stefano.lattar...@gmail.com wrote: On 08/21/2012 08:51 PM, Paolo Bonzini wrote: Il 21/08/2012 19:14, Stefano Lattarini ha scritto: * warn for unknown *_XYZFLAGS variables I'm still unconvinced it would be a good idea to introduce this incompatibility in Automake just for the sake of simplifying transition to Automake-NG, sorry. * warn for treating _SOURCES entries with a custom unknown user extension as if they were header files Ditto. Uhm, either they are good warnings for both, or pointless incompatibilities for both... You had almost convinced me of the former! :P No, I mean, we might make the warnings stricter for mainline Automake too, but that would cause extra headaches and incompatibilities. Not much serious (so that they are OK tackle for someone ready to jump on the NG wagon), but noisy and annoying enough to make them unpalatable as an addition to mainline Automake. Yes, I understood. But if they are noisy and annoying, they are _wrong_ to have in Automake-NG, no matter how it lets you simplify things. On the other hand, you almost convinced me that they are _good_ warnings, and in general cryptic behavior is one of the common criticisms of Autotools; so we need more warnings, not less. By implementing the warnings in mainline (1.13) you could hear user's opinions even if they do not jump on NG, and perhaps help people find a couple of bugs. If you get too many complaints, you can either make them opt-in (-Wsomething) and review your NG plans, or refine the warnings. Paolo
Re: Automake vs. Automake-NG
Il 21/08/2012 20:58, Bob Friesenhahn ha scritto: Because all of us have forgotten to drop the 'CC:' to that list (where the discussion originated from) at a proper time :-( If it had been held only on the automake list then there would be less harm to the free software world Which harm are you referring to? Honest question. The fact that me and Paolo disagree (politely!) on some issues should not be taken as some sort of sign that the community is split or quarrelsome. In fact, I highly value his input, and his opinion as well (even where it differs from mine). The discussion is good as long as it is constrained to the right place. The harm comes from consuming so much time from so many people due to duplicated email messages. I am not on the help-smalltalk list. I assume that the list moderator is annoyed by the many messages which arrive and now require moderation. No, I am not. I assume uninterested parties will just kill the thread. Paolo
typo whitelisting, and Automake-NG vs. GNU make runtime
So I took a closer look at the whitelisting problem that was reported
in GNU Smalltalk.
The piece of code that was removed in Automake-NG is:
foreach my $primary ('SOURCES', 'LIBADD', 'LDADD', 'LDFLAGS', 'DEPENDENCIES')
{
foreach my $var (variables $primary)
{
my $varname = $var-name;
# A configure variable is always legitimate.
next if exists $configure_vars{$varname};
for my $cond ($var-conditions-conds)
{
$varname =~
/^(?:EXTRA_)?(?:nobase_)?(?:dist_|nodist_)?(.*)_[[:alnum:]]+$/;
msg_var ('syntax', $var, variable '$varname' is defined but no
. program or\nlibrary has '$1' as canonical name
. (possible typo))
unless $var-rdef ($cond)-seen;
}
}
Note the
# A configure variable is always legitimate.
next if exists $configure_vars{$varname};
part in particular. Going back to the commit that introduced it, in
54ad2a6, the comment was even more expressive:
# Note that a configure variable is always legitimate.
# It is natural to name such variables after the
# primary, so we explicitly allow it.
Now this suggests that indeed the new behavior of Automake-NG _would_ be
naughty and annoying (quoting from Stefano). Indeed there are cases
where the new behavior would catch bugs, but are they enough overall?
Generalizing the above, the point is that there _is_ a loss of information
going from Automake runtime to GNU Make runtime. Therefore, I don't see
the point in moving the check from Automake runtime to GNU make runtime.
The tasks of Automake are multiple:
1) gather information from configure.ac and merge it with Makefile.am
files (options, subst-ed variables, etc.)
2) resolve conditionals
3) gather primaries, and select the appropriate snippets into the rules
section of Makefile.in (roughly speaking)
4) apply transformations to the snippets
5) do semantic checks
For each of this, the amount of code that can be moved to GNU make runtime
is different. For (1) it is obviously zero, and for (3) I suppose it is
close to zero as well. (2) could probably be simplified somehow, with
hardly any effect on the cost of actually building with GNU make.
(4) can be simplified a lot, with some extra cost imposed on GNU make,
but it should really be bearable. In fact, simplifying this complex, and
little known, part of Automake is the main benefit I see in requiring
Automake-NG.
For (5), it _may_ be possible (using things like .VARIABLES) to move the
checks to GNU make. But I don't really see the point. You want errors
to be diagnosed as soon as possible, and as precisely as possible.
Regarding quality, Perl can do the task better than Make, just like it can
do it better than M4. And Automake can also do it better than the generated
Makefiles, because it has more information coming from tasks (1) and (2) in
the list above.
Regarding early diagnosis, I want sh bootstrap.sh to find all problems in
my build system, *before* I embark into the expensive ./configure make.
One of the reasons why the C compiler tries to warn about implicitly-defined
functions, even though C89 does not require that, is that it diagnoses typos
well before the final link.
Thoughts?
Paolo
Re: [PATCH] {master} compile: remove support for $(INCLUDES) (was: Re: Automake vs. Automake-NG)
On Wed, Aug 22, 2012 at 5:12 PM, Stefano Lattarini stefano.lattar...@gmail.com wrote: On 08/21/2012 06:03 PM, Paolo Bonzini wrote: Looking at GNU Smalltalk, I see: * warn for INCLUDES (vs. AM_CPPFLAGS) Turns out this has already been done for ages (at least since 2003). I'll just remove support for it in Automake 1.13. See the patch below. OK? What about first making the warning visible always, not just with -Wobsolete? And add to the message that support will be removed in 1.14. Paolo
Re: [PATCH] {master} compile: remove support for $(INCLUDES)
Il 22/08/2012 23:52, Stefano Lattarini ha scritto: I'd much rather a mandatory noisy warning period before a feature is completely removed. This would require a new category of warnings that are are unconditionally show, regardless of strictness or any -Wnone option. As usual, patches welcome. I think -Wnone should still suppress this warning. Paolo
Re: [Automake-NG] typo whitelisting, and Automake-NG vs. GNU make runtime
Il 23/08/2012 10:36, Stefano Lattarini ha scritto: On 08/22/2012 12:32 PM, Paolo Bonzini wrote: How would you diagnose a typo in here at Automake runtime? bin_PROGRAMS = $(call user-func,args) bin_PROGRAMS += $(if $(ON-CYGWIN),baz) ifdef ON-CYGWIN # Oops, this was meant to be baz_LDFLAGS! bar_LDFLAGS = -lextra endif It's true that this currently (and sadly) wouldn't work anyway, but that is due to the limitations inherited by mainline Automake, not to some fundamental impossibility; so I'd like to be able to make it work in the future (the same way we made TEST_EXTENSIONS completely processed at make runtime). So we need to be prepared to the fact that a lot of information will no longer be available at automake runtime. I think a user that wants to do this should be prepared to lose the warnings. I.e. the more dynamic your Makefile.am is, the less checking can be done at Automake time. But I don't see a particularly pressing reason to move the checks to make, where they will be expensive for all users instead of just the developers. But it seems that your goals are a bit different from what I had understood so far. The tasks of Automake are multiple: 1) gather information from configure.ac and merge it with Makefile.am files (options, subst-ed variables, etc.) And this ability should be preserved in Automake-NG. 2) resolve conditionals Ideally, once Automake-NG is powerful enough, Automake-time conditional would disappear -- you should be able to use GNU make builtins like '$(if ...)', 'ifeq' and 'ifdef' instead. That will be quite difficult to do (something for Automake-NG 2.0 probably), but is worth keeping in mind that we are working towards that goal, and acting accordingly from right now. This, or if/endif could just be rewritten to GNU make syntax. 4) apply transformations to the snippets This too will disappear eventually, to be replaced with proper use of $(eval) and user-defined functions. To get the gist of it, take a look at the implementation of the parallel-tests harness in Automake-NG, in the file 'lib/am/parallel-tests.mk': that file is included *verbatim* in the generated Makefile.in (well, almost: '##' comments still have to be stripped of course). 5) do semantic checks Some of them (e.g., those involving only configure.ac) will be kept at automake runtime; a lot will be moved at make runtime; some (I hope very few) will just have to be dropped. An unavoidable price to pay IMO. This is where I disagree, because moving things to make runtime makes the execution more expensive for everyone except developers. For each of this, the amount of code that can be moved to GNU make runtime is different. For (1) it is obviously zero, Yep. and for (3) I suppose it is close to zero as well. Disagree. I actually want it to be 100% eventually :-) You're right, you can actually derive everything from .VARIABLES. Still, a limited amount of parsing can help with better diagnostics. (4) can be simplified a lot, with some extra cost imposed on GNU make, but it should really be bearable. In fact, simplifying this complex, and little known, part of Automake is the main benefit I see in requiring Automake-NG. I agree this is the best starting point, and the simplest part to tackle (and most of my changes have in fact worked in that direction). But I assure you this part of the Automake code base is actually one of the simplest ans clearest ones! Yes, the Perl bits are clean but the .am syntax is daunting. For (5), it _may_ be possible (using things like .VARIABLES) to move the checks to GNU make. But I don't really see the point. This I should have explained above already. You want errors to be diagnosed as soon as possible, and as precisely as possible. Yes -- as long as that is possible and doesn't impede further developments. Regarding quality, Perl can do the task better than Make, But I envision a day when Automake-NG will be no more than a few hundred lines of perl, mostly dedicated at tracing stuff in 'configure.ac', and setting up few variable definitions accordingly. No more incomplete, messy, half-unspecified parsing and tweaking of a subset of make syntax there! Let GNU make parse GNU make input -- it's the only sane way ahead. So basically you want a version of Quagmire that supports configure.ac. Are you sure it isn't simpler to start from scratch? Serious question... Paolo
Re: [PATCH] build: use AC_CONFIG_HEADERS, not AM_CONFIG_HEADER
Il 29/12/2012 17:32, Stefano Lattarini ha scritto: * configure.ac: Here. The latter has been removed in Automake 1.13. Is there any reason for this, apart from randomly breaking perfectly-working packages? The right way to do this is to rely on the autoupdate machinery. Paolo Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com Copyright-paperwork-exempt: yes --- ChangeLog| 5 + configure.ac | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 83109e7..133b56a 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2012-12-29 Stefano Lattarini stefano.lattar...@gnu.org (tiny change) + + build: use AC_CONFIG_HEADERS, not AM_CONFIG_HEADER + * configure.ac: Here. The latter has been removed in Automake 1.13. + 2012-12-21 Paolo Bonzini bonz...@gnu.org * configure.ac: Bump version number. Replace COPYRIGHT_YEAR. diff --git a/configure.ac b/configure.ac index 9d33ec9..c89f368 100644 --- a/configure.ac +++ b/configure.ac @@ -2,7 +2,7 @@ dnl Process this file with -*- autoconf -*- to produce a configure script. AC_INIT([GNU sed], 4.2.2, bug-...@gnu.org, sed) AC_CONFIG_AUX_DIR(build-aux) AC_CONFIG_SRCDIR([sed/sed.c]) -AM_CONFIG_HEADER(config.h:config_h.in) +AC_CONFIG_HEADERS(config.h:config_h.in) AC_PREREQ(2.60) AM_INIT_AUTOMAKE
Re: [PATCH] build: use AC_CONFIG_HEADERS, not AM_CONFIG_HEADER
Il 29/12/2012 21:43, Stefano Lattarini ha scritto: On 12/29/2012 08:46 PM, Paolo Bonzini wrote: Il 29/12/2012 17:32, Stefano Lattarini ha scritto: * configure.ac: Here. The latter has been removed in Automake 1.13. Is there any reason for this, Avoiding to keep too much cruft around the codebase, and smoothing possible future transitions to Automake-NG. Two lines of code are not cruft. It's only cruft if it happens _outside_ the definition of AM_CONFIG_HEADER itself. apart from randomly breaking perfectly-working packages? The right way to do this is to rely on the autoupdate machinery. I thought I had deprecated this macro in the 1.12.x series already, with proper warnings. Wasn't that the case? Deprecating is different from letting autoupdate convert it automatically. If not, I apologize for the inconvenience; while it's worth noting that the AM_CONFIG_HEADER macro has been clearly deprecated in the manual for a long time, I understand that that kind of deprecation can be easily missed, and a runtime warning is much more helpful and user-friendly. Note that this sort of random breakage (or at least, this is how it is perceived by users) is the main reason for hatred of Autotools. It used to be (around Autoconf 2.50-2.53, and Automake 1.4-1.6) that a medium-sized project took a day to upgrade. Things have been much much smoother for the past 5-8 years, yet the memories remain. Please do not bring that time back. Paolo
Re: [Help-smalltalk] [PATCH] build: drop useless AC_SUBST of 'INCLUDES'
Il 11/01/2013 11:28, Stefano Lattarini ha scritto: * snprintfv/configure.ac: Here. Not only that substitution was useless, but it was causing runtime warnings with Automake 1.13, and, since support for $(INCLUDES) is bound to disappear in Automake 1.14 (in favour of $(AM_CPPFLAGS)), it will start causing runtime errors with that new Automake version. I'm sick of these backwards-incompatible changes. There's tons of non-GNU packages that you won't be able to update, not to mention blocking enterprise distributions from shipping newer versions of the autotools. Do you really want to reopen the wounds of Autoconf 2.50? Paolo Copyright-paperwork-exempt: yes Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
Re: autotest, automake non-recursive makes
Il 26/09/2013 18:16, Diab Jerius ha scritto:
# The `:;' works around a Bash 3.2 bug when the output is not writable.
%D%/package.m4: $(top_srcdir)/configure.ac
:;{ \
echo '# Signature of the current package.' \
echo 'm4_define([AT_PACKAGE_NAME],' \
echo ' [$(PACKAGE_NAME)])' \
echo 'm4_define([AT_PACKAGE_TARNAME],' \
echo ' [$(PACKAGE_TARNAME)])' \
echo 'm4_define([AT_PACKAGE_VERSION],' \
echo ' [$(PACKAGE_VERSION)])' \
echo 'm4_define([AT_PACKAGE_STRING],' \
echo ' [$(PACKAGE_STRING)])' \
echo 'm4_define([AT_PACKAGE_BUGREPORT],' \
echo ' [$(PACKAGE_BUGREPORT)])'; \
echo 'm4_define([AT_PACKAGE_URL],' \
echo ' [$(PACKAGE_URL)])'; \
} $@
EXTRA_DIST += %D%/testsuite.at %D%/package.m4 %D%/$(TESTSUITE)
DISTCLEANFILES += %D%/atconfig %D%/testsuite.log
TESTSUITE = testsuite
check-local: %D%/atconfig %D%/$(TESTSUITE)
cd %D%; \
if test -f '$(TESTSUITE)' ; then d=; else d='$(abs_top_srcdir)/%D%/' ; fi
;\
$(SHELL) $$d'$(TESTSUITE)' AUTOTEST_PATH='$(abs_builddir)/%D%'
$(TESTSUITEFLAGS)
installcheck-local: %D%/atconfig %D%/$(TESTSUITE)
cd %D%; \
if test -f '$(TESTSUITE)' ; then d=; else d='$(abs_top_srcdir)/%D%/' ; fi
;\
$(SHELL) $$d'$(TESTSUITE)' AUTOTEST_PATH='$(abs_builddir)/%D%'
$(TESTSUITEFLAGS)
clean-local:
test ! -f '%D%/$(TESTSUITE)' || $(SHELL) '%D%/$(TESTSUITE)' --clean
AUTOM4TE = $(SHELL) $(top_srcdir)/build-aux/missing --run autom4te
AUTOTEST = $(AUTOM4TE) --language=autotest
%D%/$(TESTSUITE): %D%/testsuite.at %D%/package.m4
$(AUTOTEST) -I '$(srcdir)' -I '%D%' -o $@.tmp $@.at
mv $@.tmp $@
We were doing something similar in msitools (https://wiki.gnome.org/msitools).
The main differences are:
(1) Generating package.m4 from configure, like
AC_CONFIG_FILES([tests/package.m4.tmp:tests/package.m4.in],
[$srcdir/build-aux/move-if-change tests/package.m4.tmp
$srcdir/tests/package.m4
cp $srcdir/tests/package.m4 tests/package.m4.tmp])
$ cat tests/package.m4.in
# Signature of the current package.
m4_define([AT_PACKAGE_NAME], [@PACKAGE_NAME@])
m4_define([AT_PACKAGE_TARNAME], [@PACKAGE_TARNAME@])
m4_define([AT_PACKAGE_VERSION], [@PACKAGE_VERSION@])
m4_define([AT_PACKAGE_STRING], [@PACKAGE_STRING@])
m4_define([AT_PACKAGE_BUGREPORT], [@PACKAGE_BUGREPORT@])
m4_define([AT_PACKAGE_URL], [@PACKAGE_URL@])
(2) check-local and installcheck-local are simpler:
check-local: $(srcdir)/tests/testsuite atconfig atlocal
$(SHELL) $(srcdir)/tests/testsuite AUTOTEST_PATH=. $(TESTSUITEFLAGS)
installcheck-local: $(srcdir)/tests/testsuite atconfig atlocal
$(SHELL) $(srcdir)/tests/testsuite AUTOTEST_PATH=$(bindir)
$(TESTSUITEFLAGS)
(Your check-local seems ok, installcheck-local seems the same as check-local
so it doesn't look right to me).
(3) clean-local is simply using -:
clean-local:
-$(SHELL) $(srcdir)/tests/testsuite --clean
Paolo
Re: Want make check to test shared, static lib
Il 20/11/2013 09:47, Torbjorn Granlund ha scritto: Christian Rössel christian.roes...@gmx.de writes: assuming that you are using libtool, just configure twice, with --enable-static --disable-shared' and '--disable-static --enable-shared' respectively. Maybe this is not the solution you are looking for, but it is an easy workaround that is trivial to automate; and you don't have to touch any Makefile.am. We do just that for our (automated) own testing. We cannot tell end users to do that. (Or, we sure can, but they won't do it, realistically.) Compile the tests twice, add --tag disable-shared to the linker flags of the second copy. Something like check_TESTS = test-add test-add-static \ test-sub test-sub-static ... test_add_static_LDFLAGS = $(LDFLAGS) --tag disable-shared test_add_static_LDADD = ../path/to/lib.la test_sub_static_LDFLAGS = $(LDFLAGS) --tag disable-shared test_sub_static_LDADD = ../path/to/lib.la ... Paolo
Re: [Automake-NG] Automake vs. Automake-NG
Il 21/08/2012 14:44, Stefano Lattarini ha scritto: But there is an important difference: Automake-NG is *not* the next version of Automake, it is the Next Generation: it's not meant to be merged into the Automake code base, nor to supersede Automake, because the two projects have different mission statement: - Automake: allow the user to write Makefiles portable to different systems *and* make implementation, and help him to *avoid* using GNU make specific features would hurt portability, - Automake-NG: allow the user to write Makefiles portable to different systems *but* tailored for modern GNU make, and allow them to take *full advantage* of GNU make features whenever possible (which is less than we'd like, due to the code base and design inherited from mainline Automake). Automake-NG might finally supersede Automake when *and if* the great majority of developers using the the Autotools agree that porting to non-GNU make is not worth anymore; but that will not mean that Automake has been merged into Automake-NG, merely that a change in portability requirements have made it obsolete. That's very important to understand. Understood. On the other hand, Automake-NG should strive as much as possible for backwards-compatibility, so that the obsolescence of Automake comes naturally, and requires as little manual intervention as possible. If one day Automake-NG 0.99 happens to become Automake 2.0, people should not notice. For this reason, as much deprecation as possible should occur in both code bases. Looking at the GNU Smalltalk patches you sent: * using INCLUDES instead of AM_CPPFLAGS could be deprecated loudly in Automake 1.13 * pattern rules should be advertised over suffix rules in Automake-NG, but suffix rules should be accepted * files with non-standard extensions in _SOURCES should be warned about in Automake 1.13 This way, people will slowly convert their code bases to the style preferred for Automake-NG. If the only point that remains is the variable typo detection, that's fine. But all semantic changes should be suggested by (non-NG) Automake for developer to even consider taking Automake-NG seriously, IMHO. I apologize for the useless complaint if you are already doing this; please let me explain my worries. The lack of a clear upgrading path (and bugs in autoupdate, which took a while to get right) was what caused problems in Autoconf 2.50-2.53, compounded by the lack of awareness about Autoconf/m4 best practices. Now the latter has not changed much; try-and-see-debugging is still in wide use for Autotools (and that is the reason for so many Autotools-related flamewars). But (non-NG) Automake is Perl, not m4. It can provide good error messages and a clear upgrading path. Please _do_ provide it. Another choice is to find AC_SUBSTed variables that end with LDFLAGS, CPPFLAGS, CFLAGS, etc., and whitelist them automatically. It can be done in m4, from Automake-NG's macros. I'm still not sold on this. What if a user have foobar in bin_PROGRAMS, and then do something like this in its configure.ac: if something; then AC_SUBST([foobar_LDFLAGS], [-lzap]) else AC_SUBST([foobaz_LDFLAGS], [-lmu]) fi I think a warning about no program or library named 'foobaz' is still warranted here. Yeah, and that's why I initially proposed whitelisting all-uppercase variables. It's a convention, but it's a common convention. Programs are rarely if-ever all-uppercase. Libraries never are due to the _a or _la suffix. Hope I've clarified the situation a bit. Me too. :) Paolo
Re: [Automake-NG] Automake vs. Automake-NG
Il 21/08/2012 16:32, Stefano Lattarini ha scritto: Bottom line is: we want to make it clear that Automake-NG is something different from Automake -- albeit mostly compatible, deliberately, and with very, very similar design and API; and that a transition between the two won't be seamless -- albeit it is expected to be simple and to involve only little churn. Ok. * using INCLUDES instead of AM_CPPFLAGS could be deprecated loudly in Automake 1.13 This is a good idea. Want to attempt a patch? Otherwise, I will write it myself in the next days. I doubt I have time, unfortunately. :( * pattern rules should be advertised over suffix rules in Automake-NG, but suffix rules should be accepted They are! It's actually simpler to accept them rather than to reject them, since doing the latter would entail more Automake-runtime processing, which we want to avoid. The only important difference is that you'll have to declare '.SUFFIXES:' yourself, as Automake-NG do not do it automatically for you anymore (a change which I now see is not listed in the NG-NEWS file; will fix shortly). Ok. So the question I'd like you to ask yourself are: * Why does it make sense to request manual declaration of '.SUFFIXES:'? * Does it make sense to do so in Automake, too? * Even if not, could a missing '.SUFFIXES:' hide bugs? Would you consider adding a warning for missing .SUFFIXES in Automake, too? This needs to be done for each NG-NEWS items. It could improve the existing users of Automake, and reduce the size of NG-NEWS. Both of which are good things! This way, people will slowly convert their code bases to the style preferred for Automake-NG. If the only point that remains is the variable typo detection, that's fine. But all semantic changes should be suggested by (non-NG) Automake for developer to even consider taking Automake-NG seriously, IMHO. I disagree. After all, people are taking CMake seriously, and that is hardly compatible with Automake. But CMake is not almost the same as Automake, Automake-NG is. Automake-NG is not Automake 2.0, but Automake 2.0 _could_ have the same user interface as Automake-NG. What I'm asking is, please consider a deprecation path in Automake for _every_ _single_ difference between it and Automake-NG. If you rewrote Automake in m4 (only partly kidding), I wouldn't have had these objections. But changing the name doesn't change the perception. I apologize for the useless complaint if you are already doing this; Please don't. I find this exchange very useful and informative for my own understanding of the status and direction of Automake-NG. please let me explain my worries. The lack of a clear upgrading path (and bugs in autoupdate, which took a while to get right) was what caused problems in Autoconf 2.50-2.53, compounded by the lack of awareness about Autoconf/m4 best practices. The difference here is that people *should* understand that Automake-NG is not meant as an Automake 2.0, but as a new projects with different aims, and thus different idioms, usages, strengths and weaknesses. People won't. :) This is the point I want to drive home, to avoid another transition debacle like the Autoconf one. Here's an honest question: if Autoconf 2.50 has been called Autoconf-NG 3.0 alpha, and finally graduated to Autoconf-NG 3.0 with what we know as Autoconf 2.60, do you think the transition would have been less painful (I really hope the answer is yes, of course). My answer is that the two cases are different. On one hand, there was no obstacle between a possible graduation of Autoconf-NG 2.5x to Autoconf, like the GNU Make dependency could be for Automake-NG. On the other hand, it would have been nigh impossible to provide the smooth deprecation path that I'm suggesting. All I'm saying is, do not release Automake-NG for public use until Automake can warn of all incompatible uses, or almost all. It can provide good error messages and a clear upgrading path. Please _do_ provide it. I hope to finally do that, but it will be in a form of a how-to and a set of recipes rather than an attempt to shoehorn Automake-NG semantics back to Automake. The latter sounds too slow and too dangerious. You have to evaluate each case separately of course, but a single project has already shown several cases where Automake _could_ be improved this way. Paolo
Re: [Automake-NG] [PATCH 6/7] [ng] dist: new API to specify formats of distribution tarballs
Il 12/08/2012 23:20, Stefano Lattarini ha scritto:
The API to specify the formats of distribution tarballs has been changed
completely, in a BACKWARD-INCOMPATIBLE way.
Instead of using the various 'dist-*' automake options, the developer is
now expected to specify the default formats of its distribution tarballs
with the special variable AM_DIST_FORMATS; for example, where once would
have been:
AM_INIT_AUTOMAKE([dist-bzip2 dist-zip])
now it must be:
AM_DIST_FORMATS = gzip bzip2 zip
and similarly, where once would have been:
AUTOMAKE_OPTIONS = no-dist-gzip dist-bzip2 dist-xz
now is it simply:
AM_DIST_FORMATS = bzip2 xz
Nice, but I'm not sure why this couldn't have a backwards-compatible
replacement.
ifeq ($(origin AM_DIST_FORMATS),undefined)
AM_DIST_FORMATS := \
$(patsubst dist-%, %, $(filter dist-%, $(AUTOMAKE_OPTIONS)) \
$(if $(filter no-dist-gzip, $(AUTOMAKE_OPTIONS)),,gzip)
endif
This requires Automake-NG to merge AM_INIT_AUTOMAKE's arguments into the
Makefile.in's AUTOMAKE_OPTIONS, which is only goodness.
Paolo
Similarly, The various 'dist-*' targets (dist-gzip, dist-xz, dist-lzip,
dist-bzip2 and dist-gz) has been removed. If the user wants to generate
tarballs for formats not specified by the default AM_DIST_FORMATS, he can
simply override that variable dynamically:
# Will generate a '.zip' archive and a '.tar.xz' archive, and not
# further ones.
make dist AM_DIST_FORMATS='zip xz'
This change is of course is totally backward incompatible, but the
enhanced flexibility and simplicity is worth it. Not to mention that
the transition from the mainline Automake API to the new Automake-NG
one is trivial.
* NG-NEWS: Update.
* ng/automake-ng.texi: Likewise.
* configure.ac (AM_INIT_AUTOMAKE): Drop the 'dist-xz' option. While
at it, drop the 'color-tests' option (now on by default, even in
coming-soon Automake 1.13) and add the 'ng' option (mostly for some
showing-off :-).
* t/ax/am-test-lib.sh: Also unset 'AM_DIST_FORMATS'.
* Makefile.am (AM_DIST_FORMATS): New, containing 'gzip' ad 'xz' (so
that we distribute the same formats we did before).
* lib/am/distcheck.mk (AM_DIST_FORMATS): New, defaulting to 'gzip'.
(am.dist.bad-targets): New, list invalid entries of $(AM_DIST_FORMATS).
Error out with a suitable message if that variable is non-empty.
Rename all the 'dist-*' targets, once public, to '.am/dist-*' (which
are private). Adjust their rules.
(am.dist.all-targets): Adjust to said 'dist-*' = '.am/dist-*'
renaming.
(am.dist.default-targets): New, defined from $(AM_DIST_FORMATS).
(dist, dist-all): Rewritten to rely on dependencies rather than on
recursive make invocation (the new API allows us to do so easily).
Other minor related adjustments.
(distcheck): Use $(AM_DIST_FORMATS) instead of $(am.dist.formats)
in the recipe.
* automake.in (handle_dist): Drop analysis of the various 'dist-*'
options, and of the 'no-dist-gzip' one; don't define the internal
make variable 'am.dist.formats'.
* lib/Automake/Options.pm (_is_valid_easy_option): Recognize the
various 'dist-*' options and the 'no-dist-gzip' one no more.
(_process_option_list): Explicitly reject them (to give better
diagnostic).
* t/dist-obsolete-opts.sh: New, check such diagnostic.
* t/dist-obsolete.sh: Remove as obsolete.
* t/repeated-options.sh: Minor adjustments to avoid spurious
failures.
* t/dist-formats.tap: Adjust heavily (almost a complete rewrite).
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
Makefile.am | 3 +
NG-NEWS | 48 +++-
automake.in | 22 --
configure.ac | 3 +-
doc/automake-ng.texi | 109 ---
lib/Automake/Options.pm | 22 +-
lib/am/distcheck.mk | 34 +--
t/ax/am-test-lib.sh | 2 +
t/dist-formats.tap| 392
++
t/{dist-obsolete.sh = dist-obsolete-opts.sh} | 15 +-
t/repeated-options.sh | 25 +-
11 files changed, 229 insertions(+), 446 deletions(-)
rename t/{dist-obsolete.sh = dist-obsolete-opts.sh} (64%)
diff --git a/Makefile.am b/Makefile.am
index db3dea7..9455f0f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -27,6 +27,9 @@ EXTRA_DIST =
## Top level. ##
## ##
+# Distribution formats.
+AM_DIST_FORMATS = gzip xz
+
# We want a handful of substitutions to be fully-expanded by make;
# then use config.status to substitute the remainder where a single
# expansion is sufficient. We use a funny notation here to avoid
diff --git a/NG-NEWS b/NG-NEWS
index 8f3cf72..129da68 100644
--- a/NG-NEWS
+++ b/NG-NEWS
@@ -212,24 +212,54 @@ Distribution
EXTRA_DIST = $(wildcard doc/*.txt $(srcdir)/doc/*.txt) # Better.
-*
Re: [Automake-NG] Automake vs. Automake-NG
Il 21/08/2012 19:14, Stefano Lattarini ha scritto: * warn for unknown *_XYZFLAGS variables I'm still unconvinced it would be a good idea to introduce this incompatibility in Automake just for the sake of simplifying transition to Automake-NG, sorry. * warn for treating _SOURCES entries with a custom unknown user extension as if they were header files Ditto. Uhm, either they are good warnings for both, or pointless incompatibilities for both... You had almost convinced me of the former! :P Paolo
Re: [Automake-NG] Automake vs. Automake-NG
Il 21/08/2012 20:58, Bob Friesenhahn ha scritto: Because all of us have forgotten to drop the 'CC:' to that list (where the discussion originated from) at a proper time :-( If it had been held only on the automake list then there would be less harm to the free software world Which harm are you referring to? Honest question. The fact that me and Paolo disagree (politely!) on some issues should not be taken as some sort of sign that the community is split or quarrelsome. In fact, I highly value his input, and his opinion as well (even where it differs from mine). The discussion is good as long as it is constrained to the right place. The harm comes from consuming so much time from so many people due to duplicated email messages. I am not on the help-smalltalk list. I assume that the list moderator is annoyed by the many messages which arrive and now require moderation. No, I am not. I assume uninterested parties will just kill the thread. Paolo
[Automake-NG] [PATCH 1/3] var: add VAR_COMPUTED source
We want AUTOMAKE_OPTIONS in Makefile.in to be the combination of
configure.ac and Makefile.am options. Define a new variable owner
for this, because we need to override the Makefile.am value
unconditionally and never emit warnings.
* lib/Automake/VarDef.pm (VAR_COMPUTED): New.
(dump): Print it.
* lib/Automake/Variable.pm (define): Check that VAR_COMPUTED variables
were not conditionally defined, and always allow them to override
previous definitions.
---
lib/Automake/VarDef.pm | 18 --
lib/Automake/Variable.pm | 12 +++-
2 file modificati, 23 inserzioni(+), 7 rimozioni(-)
diff --git a/lib/Automake/VarDef.pm b/lib/Automake/VarDef.pm
index 6bb9fa6..7d2a321 100644
--- a/lib/Automake/VarDef.pm
+++ b/lib/Automake/VarDef.pm
@@ -24,7 +24,7 @@ use Automake::ItemDef;
require Exporter;
use vars '@ISA', '@EXPORT';
@ISA = qw/Automake::ItemDef Exporter/;
-@EXPORT = qw (VAR_AUTOMAKE VAR_CONFIGURE VAR_MAKEFILE);
+@EXPORT = qw (VAR_AUTOMAKE VAR_CONFIGURE VAR_MAKEFILE VAR_COMPUTED);
=head1 NAME
@@ -75,11 +75,12 @@ This class gathers data related to one Makefile-variable
definition.
=over 4
-=item CVAR_AUTOMAKE, CVAR_CONFIGURE, CVAR_MAKEFILE
+=item CVAR_AUTOMAKE, CVAR_CONFIGURE, CVAR_MAKEFILE, CVAR_COMPUTED
Possible owners for variables. A variable can be defined
-by Automake, in Fconfigure.ac (using CAC_SUBST), or in
-the user's FMakefile.am.
+by Automake (this is also the case for CVAR_COMPUTED, which
+has highest priority), in Fconfigure.ac (using CAC_SUBST),
+or in the user's FMakefile.am.
=cut
@@ -88,6 +89,7 @@ the user's FMakefile.am.
use constant VAR_AUTOMAKE = 0; # Variable defined by Automake.
use constant VAR_CONFIGURE = 1;# Variable defined in configure.ac.
use constant VAR_MAKEFILE = 2; # Variable defined in Makefile.am.
+use constant VAR_COMPUTED = 3; # Variable computed by Automake.
=back
@@ -114,8 +116,8 @@ C$type should be C'' for definitions made with C=,
and C':'
for those made with C:=.
C$owner specifies who owns the variables, it can be one of
-CVAR_AUTOMAKE, CVAR_CONFIGURE, or CVAR_MAKEFILE (see these
-definitions).
+CVAR_AUTOMAKE, CVAR_CONFIGURE, CVAR_MAKEFILE, or
+CVAR_COMPUTED (see these definitions).
=cut
@@ -279,6 +281,10 @@ sub dump ($)
{
$owner = 'Makefile';
}
+ elsif ($owner == VAR_COMPUTED)
+{
+ $owner = 'Automake (computed variable)';
+}
else
{
prog_error (unexpected owner);
diff --git a/lib/Automake/Variable.pm b/lib/Automake/Variable.pm
index 50a4dad..dbda0a0 100644
--- a/lib/Automake/Variable.pm
+++ b/lib/Automake/Variable.pm
@@ -782,6 +782,13 @@ sub define ($$$)
}
}
+ # Additional checks for computed variables
+ if ($owner == VAR_COMPUTED ! $new_var)
+{
+ # A computed variable must be unconditional.
+ $self-check_defined_unconditionally;
+}
+
# Differentiate assignment types.
# 1. append (+=) to a variable defined for current condition
@@ -849,10 +856,13 @@ sub define ($$$)
# There must be no previous value unless the user is redefining
# an Automake variable or an AC_SUBST variable for an existing
# condition.
+ # Computed variables (currently only AUTOMAKE_OPTIONS) can always
+ # override user definitions.
_check_ambiguous_condition ($self, $cond, $where)
unless (!$new_var
(($def-owner == VAR_AUTOMAKE $owner != VAR_AUTOMAKE)
- || $def-owner == VAR_CONFIGURE));
+ || $def-owner == VAR_CONFIGURE
+ || $owner == VAR_COMPUTED));
# Never decrease an owner.
$owner = $def-owner
--
1.7.11.2
Re: [Automake-NG] [PATCH v2 2/2] dist: add back support for obsolete dist-* options
Il 22/08/2012 13:47, Stefano Lattarini ha scritto:
Hi Paolo.
Since I still have some gripes with the preparatory [PATCH 1/2], I'm
thinking about reworking this patch to make is independent from that.
Find my ideas below. Do you think they would be a good move? If
yes, would you mind re-working you patch accordingly?
I prefer to wait for 1/2 to be sorted out.
On 08/22/2012 12:44 PM, Paolo Bonzini wrote:
The old API for dist formats can be supported easily, by parsing the
AUTOMAKE_OPTIONS and generating AM_DIST_FORMATS from it, if not defined
otherwise.
* NG-NEWS: Document that the old distribution format API is obsolete
but available.
* lib/Automake/Options.pm: Degrade error to warning.
* lib/am/distcheck.mk: Generate AM_DIST_FORMATS from AUTOMAKE_OPTIONS
* t/dist-obsolete-opts.sh: Add backwards-compatibility tests.
---
NG-NEWS | 2 +-
lib/Automake/Options.pm | 8
lib/am/distcheck.mk | 4 +++-
t/dist-obsolete-opts.sh | 24 +++-
4 file modificati, 23 inserzioni(+), 15 rimozioni(-)
diff --git a/NG-NEWS b/NG-NEWS
index 129da68..8ee1aae 100644
--- a/NG-NEWS
+++ b/NG-NEWS
@@ -228,7 +228,7 @@ Distribution
have been removed; and with them the targets 'dist-shar' and 'dist-tarZ'.
* The API to specify the formats of distribution tarballs has been changed
- completely.
+ completely; the old API is still available, but gives warnings.
Instead of using the various 'dist-*' automake options, the developer is
now expected to specify the default formats of its distribution tarballs
diff --git a/lib/Automake/Options.pm b/lib/Automake/Options.pm
index 8dd8176..abf488c 100644
--- a/lib/Automake/Options.pm
+++ b/lib/Automake/Options.pm
@@ -322,11 +322,11 @@ sub _process_option_list (\%@)
{
error $where, support for Cygnus-style trees has been removed;
}
- elsif (/^(?:no-)?dist-.*/)
+ elsif ($_ eq 'no-dist-gzip' || /^dist-.*/)
{
- error ($where,
- '$_' option and the like are no more supported;\n .
- use AM_DIST_FORMATS in top-level Makefile.am instead);
+ msg ('obsolete', $where,
+ '$_' option and the like are obsolete; use\n .
+ AM_DIST_FORMATS in top-level Makefile.am instead);
}
Since we are still processing these options explicitly, we can easily know
which dist formats the user is requesting. So, instead of having to recover
them from the 'dist-*' options at make runtime, we could register them right
away in an internal make variable, say '$(am.dist.formats-from-opts)';
and then, at make runtime, default AM_DIST_FORMATS to that. Something like
this:
I wanted to minimize the Automake changes.
I'm a bit confused as to where to draw the line between Automake and GNU
make...
Paolo
diff --git a/lib/am/distcheck.mk b/lib/am/distcheck.mk
index 421b15b..cbde58b 100644
--- a/lib/am/distcheck.mk
+++ b/lib/am/distcheck.mk
@@ -69,7 +69,9 @@ am.dist.extract-cmd.zip = \
# This is namespace-safe, so it's OK to accept values from
# the environment.
-AM_DIST_FORMATS ?= gzip
+AM_DIST_FORMATS ?= \
+ $(patsubst dist-%, %, $(filter dist-%, $(am.automake-options))) \
+ $(if $(filter no-dist-gzip, $(am.automake-options)),,gzip)
... here we could simply do:
AM_DIST_FORMATS ?= $(am.dist.formats-from-opts)
How does that sound?
-*-*-*-
Now, to some style/minor nits ...
am.dist.bad-targets := \
$(filter-out $(am.dist.all-formats),$(AM_DIST_FORMATS))
diff --git a/t/dist-obsolete-opts.sh b/t/dist-obsolete-opts.sh
index 06bea8d..018fc1c 100644
--- a/t/dist-obsolete-opts.sh
+++ b/t/dist-obsolete-opts.sh
@@ -22,9 +22,9 @@ $ACLOCAL
for fmt in gzip bzip2 xz lzip zip tarZ lzma shar; do
echo AUTOMAKE_OPTIONS = dist-$fmt Makefile.am
- AUTOMAKE_fails -Wnone -Wno-error
- grep ^Makefile\\.am:1:.* 'dist-$fmt' option.* no more supported stderr
- grep ^Makefile\\.am:1:.* use AM_DIST_FORMATS .*instead stderr
+ $AUTOMAKE -Wobsolete -Wno-error 2stderr
+ grep ^Makefile\\.am:1:.* 'dist-$fmt' option.* obsolete stderr
+ grep ^Makefile\\.am:1:.* AM_DIST_FORMATS .*instead stderr
Here is the usual idiomatic way to check for warnings:
AUTOMAKE_fails -Wnone -Wobsolete
grep ^Makefile\\.am:1:.* 'dist-$fmt' option.* obsolete stderr
grep ^Makefile\\.am:1:.* AM_DIST_FORMATS .*instead stderr
$AUTOMAKE -Wno-obsolete
done
rm -rf autom4te*.cache
@@ -33,12 +33,18 @@ cat configure.ac 'END'
AC_INIT([foo], [1.0])
AM_INIT_AUTOMAKE([no-dist-gzip dist-xz])
AC_CONFIG_FILES([Makefile])
+AC_OUTPUT
END
-: Makefile.am
+: foo
+echo EXTRA_DIST = foo Makefile.am
$ACLOCAL
-AUTOMAKE_fails -Wnone -Wno-error
-grep ^configure\\.ac:2:.* 'no-dist-gzip' option.* no more supported stderr
-grep ^configure\\.ac:2:.* 'dist-xz' option.* no more supported stderr
-grep ^configure\\.ac:2:.*use AM_DIST_FORMATS
Re: [Automake-NG] [PATCH] {master} compile: remove support for $(INCLUDES) (was: Re: Automake vs. Automake-NG)
On Wed, Aug 22, 2012 at 5:12 PM, Stefano Lattarini stefano.lattar...@gmail.com wrote: On 08/21/2012 06:03 PM, Paolo Bonzini wrote: Looking at GNU Smalltalk, I see: * warn for INCLUDES (vs. AM_CPPFLAGS) Turns out this has already been done for ages (at least since 2003). I'll just remove support for it in Automake 1.13. See the patch below. OK? What about first making the warning visible always, not just with -Wobsolete? And add to the message that support will be removed in 1.14. Paolo
Re: [Automake-NG] [PATCH] {master} compile: remove support for $(INCLUDES)
Il 22/08/2012 23:52, Stefano Lattarini ha scritto: I'd much rather a mandatory noisy warning period before a feature is completely removed. This would require a new category of warnings that are are unconditionally show, regardless of strictness or any -Wnone option. As usual, patches welcome. I think -Wnone should still suppress this warning. Paolo
Re: [Automake-NG] typo whitelisting, and Automake-NG vs. GNU make runtime
Il 23/08/2012 10:36, Stefano Lattarini ha scritto: On 08/22/2012 12:32 PM, Paolo Bonzini wrote: How would you diagnose a typo in here at Automake runtime? bin_PROGRAMS = $(call user-func,args) bin_PROGRAMS += $(if $(ON-CYGWIN),baz) ifdef ON-CYGWIN # Oops, this was meant to be baz_LDFLAGS! bar_LDFLAGS = -lextra endif It's true that this currently (and sadly) wouldn't work anyway, but that is due to the limitations inherited by mainline Automake, not to some fundamental impossibility; so I'd like to be able to make it work in the future (the same way we made TEST_EXTENSIONS completely processed at make runtime). So we need to be prepared to the fact that a lot of information will no longer be available at automake runtime. I think a user that wants to do this should be prepared to lose the warnings. I.e. the more dynamic your Makefile.am is, the less checking can be done at Automake time. But I don't see a particularly pressing reason to move the checks to make, where they will be expensive for all users instead of just the developers. But it seems that your goals are a bit different from what I had understood so far. The tasks of Automake are multiple: 1) gather information from configure.ac and merge it with Makefile.am files (options, subst-ed variables, etc.) And this ability should be preserved in Automake-NG. 2) resolve conditionals Ideally, once Automake-NG is powerful enough, Automake-time conditional would disappear -- you should be able to use GNU make builtins like '$(if ...)', 'ifeq' and 'ifdef' instead. That will be quite difficult to do (something for Automake-NG 2.0 probably), but is worth keeping in mind that we are working towards that goal, and acting accordingly from right now. This, or if/endif could just be rewritten to GNU make syntax. 4) apply transformations to the snippets This too will disappear eventually, to be replaced with proper use of $(eval) and user-defined functions. To get the gist of it, take a look at the implementation of the parallel-tests harness in Automake-NG, in the file 'lib/am/parallel-tests.mk': that file is included *verbatim* in the generated Makefile.in (well, almost: '##' comments still have to be stripped of course). 5) do semantic checks Some of them (e.g., those involving only configure.ac) will be kept at automake runtime; a lot will be moved at make runtime; some (I hope very few) will just have to be dropped. An unavoidable price to pay IMO. This is where I disagree, because moving things to make runtime makes the execution more expensive for everyone except developers. For each of this, the amount of code that can be moved to GNU make runtime is different. For (1) it is obviously zero, Yep. and for (3) I suppose it is close to zero as well. Disagree. I actually want it to be 100% eventually :-) You're right, you can actually derive everything from .VARIABLES. Still, a limited amount of parsing can help with better diagnostics. (4) can be simplified a lot, with some extra cost imposed on GNU make, but it should really be bearable. In fact, simplifying this complex, and little known, part of Automake is the main benefit I see in requiring Automake-NG. I agree this is the best starting point, and the simplest part to tackle (and most of my changes have in fact worked in that direction). But I assure you this part of the Automake code base is actually one of the simplest ans clearest ones! Yes, the Perl bits are clean but the .am syntax is daunting. For (5), it _may_ be possible (using things like .VARIABLES) to move the checks to GNU make. But I don't really see the point. This I should have explained above already. You want errors to be diagnosed as soon as possible, and as precisely as possible. Yes -- as long as that is possible and doesn't impede further developments. Regarding quality, Perl can do the task better than Make, But I envision a day when Automake-NG will be no more than a few hundred lines of perl, mostly dedicated at tracing stuff in 'configure.ac', and setting up few variable definitions accordingly. No more incomplete, messy, half-unspecified parsing and tweaking of a subset of make syntax there! Let GNU make parse GNU make input -- it's the only sane way ahead. So basically you want a version of Quagmire that supports configure.ac. Are you sure it isn't simpler to start from scratch? Serious question... Paolo
bug#9026: [PATCH] aclocal: handle ACLOCAL_PATH environment variable
On Mon, Sep 19, 2011 at 18:39, Stefano Lattarini stefano.lattar...@gmail.com wrote: Just to be sure, you are not including http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00091.html are you? No, not yet at least. Because, if I'm not reading it wrong (which I might be doing in fact, since I've only taken a perfunctory look at it so far), it introduces an incompatibility between the system acdirs added with ACLOCAL_PATH (which can be used to override automake macros) and those added with dirlist (which on the contrary cannot be used to do so). Yes (and that's on purpose: ACLOCAL_PATH is typically used by a user which has newer versions of libraries installed, so they need their directories to override everything). Unfortunately, I do not have time right now to look at autotools. :( Paolo
bug#9026: [PATCH] aclocal: handle ACLOCAL_PATH environment variable
On 09/20/2011 02:09 PM, Stefano Lattarini wrote: Yeah, I think the problem is that in the normal search path (from `aclocal -I /foo -I /bar'): 1. `/foo' 2. `/bar' 3. ACDIR-APIVERSION 4. ACDIR The directories from dirlist and ACLOCAL_PATH should go after (3), rather than after (4). But this is what they currently do (see test `aclocal-path-precedence.test'). Interesting, that's not what is in (automake.info)Macro Search Path. Paolo
bug#13351: [IMPORTANT] Dropping support for split '.info' files in mainline Automake
Il 03/01/2013 21:53, Stefano Lattarini ha scritto: Severity: wishlist [This is posted also to the automake and texinfo lists to ensure a wider audience. Discussion should continue exclusively on the bug-automake list, to avoid a cross-posting flood] Automake-generated have for a long time supported split info files: http://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Tag-and-Split-Files When I asked the rationale for this feature: http://lists.gnu.org/archive/html/texinfo-devel/2012-08/msg00015.html Karl Berry confirmed that the reason for its existence was indeed efficiency, especially memory size: http://lists.gnu.org/archive/html/texinfo-devel/2012-08/msg00024.html He also added that The Elisp manual is one of the largest ones around. Looks like it would be maybe 3.5mb as one file. Not in any way big by modern standards. OTOH, it appears that the use of split info files (at least in the way Automake-generated rules have been handling them for a long time) can cause real problems in some (admittedly quite corner-case) situations: http://thread.gmane.org/gmane.comp.parsers.bison.bugs/3963 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12320 So I believe we could follow suit with Automake-NG (see commit dd603e21, http://lists.gnu.org/archive/html/automake-ng/2012-08/msg00147.html) and have Automake-generated makefiles pass the '--no-split' option unconditionally to makeinfo invocations (starting from Automake 1.14). This would allow some nice simplifications in our Texinfo recipe (exemplified by the Automake-NG patch referenced above), and offer an automatic fix for bug#12320. Another *very* good aspect of such a change is that it would be 100% transparent to the Automake users. Thoughts, opinions, objections? *This* is a change I support. Paolo
Re: support cross multilibs
I'd appreciate it if this could go on the 1.9.x branch as well as mainline. I think Alexandre doesn't plan another 1.9.x release. Distro makers might take the patch, though. I support Geoff's request. Paolo
[PATCH] conditional info_TEXINFOS, updated
Ok, here's the patch I sent a month ago together with new
testcases.
I also found a little opportunity for refactoring.
Paolo
2007-03-12 Paolo Bonzini [EMAIL PROTECTED]
* automake.in (output_texinfo_build_rules): Add COND parameter.
Emit INFO_DEPS and TEXINFOS.
(handle_texinfo_helper): Remove references to dead variable
info_deps_list. Collect conditions for info_texinfos files and
pass it to output_texinfo_build_rules. Don't emit TEXINFOS.
(append_pretty_variable): New.
(push_dist_common): Use it.
* automake.in (output_texinfo_build_rules): Add COND parameter.
* lib/am/texibuild.am (INFODEPS): Don't emit it.
* tests/Makefile.am (TESTS): Add condinfo.test.
* tests/condinfo.test: New test.
Index: NEWS
===
RCS file: /sources/automake/automake/NEWS,v
retrieving revision 1.323
diff -u -p -r1.323 NEWS
--- NEWS10 Jan 2007 17:57:24 - 1.323
+++ NEWS12 Mar 2007 17:35:09 -
@@ -16,6 +16,11 @@ New in 1.10a:
(and its time stamps) if the contents did not change.
+Bugs fixed in 1.10.1:
+
+* Automake is now able to handle conditional info_TEXINFOS.
+
+
New in 1.10:
* Version requirements:
Index: automake.in
===
RCS file: /sources/automake/automake/automake.in,v
retrieving revision 1.1641
diff -u -p -r1.1641 automake.in
--- automake.in 16 Oct 2006 05:24:17 - 1.1641
+++ automake.in 12 Mar 2007 17:35:10 -
@@ -7,7 +7,7 @@ eval 'case $# in 0) exec @PERL@ -S $0;
# automake - create Makefile.in from Makefile.am
# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
-# 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
+# 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -2960,15 +2960,16 @@ sub scan_texinfo_file ($)
# ($DIRSTAMP, @CLEAN_FILES)
-# output_texinfo_build_rules ($SOURCE, $DEST, $INSRC, @DEPENDENCIES)
-# --
+# output_texinfo_build_rules ($SOURCE, $DEST, $INSRC, $COND, @DEPENDENCIES)
+# -
# SOURCE - the source Texinfo file
# DEST - the destination Info file
-# INSRC - wether DEST should be built in the source tree
+# INSRC - whether DEST should be built in the source tree
+# COND - the condition under which DEST should be built
# DEPENDENCIES - known dependencies
-sub output_texinfo_build_rules ($$$@)
+sub output_texinfo_build_rules (@)
{
- my ($source, $dest, $insrc, @deps) = @_;
+ my ($source, $dest, $insrc, $cond, @deps) = @_;
# Split `a.texi' into `a' and `.texi'.
my ($spfx, $ssfx) = ($source =~ /^(.*?)(\.[^.]*)?$/);
@@ -3029,6 +3030,13 @@ sub output_texinfo_build_rules ($$$@)
my $dipfx = ($insrc ? '$(srcdir)/' : '') . $dpfx;
+ append_pretty_variable ('INFO_DEPS', $cond, INTERNAL, $dipfx$dsfx);
+
+ # This next line isn't strictly needed now -- the places that look here
+ # could easily be changed to look in info_TEXINFOS. But this is
+ # probably better, in case html_TEXINFOS is ever supported.
+ append_pretty_variable ('TEXINFOS', $cond, INTERNAL, $source);
+
$output_rules .= file_contents ('texibuild',
new Automake::Location,
DEPS = @deps,
@@ -3058,7 +3066,7 @@ sub output_texinfo_build_rules ($$$@)
sub handle_texinfo_helper ($)
{
my ($info_texinfos) = @_;
- my (@infobase, @info_deps_list, @texi_deps);
+ my (@infobase, @texi_deps);
my %versions;
my $done = 0;
my @texi_cleans;
@@ -3072,6 +3080,19 @@ sub handle_texinfo_helper ($)
@f = map { s|[^A-Za-z_0-9*\[\]\-]|\\$|g; s|\*|[^/]*|g; $_; } @f;
my $user_cleaned_files = '^(?:' . join ('|', @f) . ')$';
+ my %info_texinfos_conds;
+
+ append_pretty_variable ('INFO_DEPS', TRUE, INTERNAL, '');
+ append_pretty_variable ('TEXINFOS', TRUE, INTERNAL, '');
+
+ $info_texinfos-traverse_recursively
+(sub {
+ my ($var, $val, $cond, $full_cond) = @_;
+ $info_texinfos_conds{$val} = $full_cond;
+},
+undef,
+inner_expand = 1);
+
foreach my $texi
($info_texinfos-value_as_list_recursive (inner_expand = 1))
{
@@ -3219,11 +3240,10 @@ sub handle_texinfo_helper ($)
}
my ($dirstamp, @cfiles) =
- output_texinfo_build_rules ($texi, $out_file, $insrc, @texi_deps);
+ output_texinfo_build_rules ($texi, $out_file, $insrc,
+ $info_texinfos_conds{$texi}, @texi_deps);
push (@texi_cleans, @cfiles);
- push (@info_deps_list, $out_file);
-
# If a vers*.texi file is needed, emit the rule.
if ($vtexi)
{
@@ -3241,8 +3261,8 @@ sub
Re: [PATCH] conditional info_TEXINFOS, updated
PING... (or just give me commit access so I can do it myself). http://permalink.gmane.org/gmane.comp.sysutils.automake.patches/2731 Paolo
Re: [trunk][patch] fix --enable-shared=some_libraries
Ok for trunk and 4.3, but please also handle enable_static in the same way. The patch is preapproved with this change, but please repost it so that it can also go in Automake (I'm CCing Ralf and automake-patches@gnu.org for this). Paolo
[PATCH] aclocal: handle ACLOCAL_PATH environment variable
Hi all, this patch provides a fourth scheme of adding directories to
the search path. It is a simple colon-separated list of directories
(without globbing).
It is useful when you're using a global installation of Automake but
you want to add directories from your account as well to the search
path. It is also useful for people who do not like for some reason
to touch files in /usr/share (which, unlike /etc, are usually not
meant for user customization).
The test suites leaves the user's ACLOCAL_PATH in place, for consistency
with the treatment of ${prefix}/share/aclocal/dirlist in tests/defs.in.
By the way, this line:
aclocaldir='@prefix@/share/aclocal'
should probably use datadir, no?
Ok to apply? (I have copyright assignment in place but I'm not sure if I
have access to the repository---probably not).
* NEWS: Document new behavior.
* aclocal.in (parse_arguments): Parse ACLOCAL_PATH as
a colon-separated list of directories to be included in
the search path.
* doc/automake.texi (Macro Search Path): Document new
behavior.
* tests/acloca24.test: New testcase.
* tests/Makefile.am (TESTS): Add it.
* tests/Makefile.in: Regenerate.
---
NEWS|5
aclocal.in | 11 -
doc/automake.texi | 10
tests/Makefile.am |1 +
tests/Makefile.in |1 +
tests/acloca24.test | 60 +++
6 files changed, 87 insertions(+), 1 deletions(-)
create mode 100755 tests/acloca24.test
diff --git a/NEWS b/NEWS
index c64ec14..7567ca6 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,10 @@
New in 1.11a:
+* Changes to aclocal:
+
+ - aclocal now interprets the `ACLOCAL_PATH' environment variable as a
+colon-separated list of additional directories to search.
+
* Changes to automake:
- automake now generates silenced rules for texinfo outputs.
diff --git a/aclocal.in b/aclocal.in
index 4c81a47..bc8cd25 100644
--- a/aclocal.in
+++ b/aclocal.in
@@ -1025,7 +1025,7 @@ sub parse_arguments ()
}
else
{
- # Finally, adds any directory listed in the `dirlist' file.
+ # Add any directory listed in the `dirlist' file.
if (open (DIRLIST, $system_includes[0]/dirlist))
{
while (DIRLIST)
@@ -1043,6 +1043,15 @@ sub parse_arguments ()
close (DIRLIST);
}
}
+ # Add any directory listed in the `ACLOCAL_PATH' environment
+ # variable.
+ if (defined $ENV{ACLOCAL_PATH})
+{
+ foreach my $dir (split /:/, $ENV{ACLOCAL_PATH})
+{
+ push (@system_includes, $dir) if $dir ne '' -d $dir;
+}
+}
}
diff --git a/doc/automake.texi b/doc/automake.texi
index 7214e49..92fb0ab 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -3361,6 +3361,16 @@ Macro Search Path
copy of Automake in your account and want @command{aclocal} to look for
macros installed at other places on the system.
+...@subsubheading Modifying the Macro Search Path: @file{ACLOCAL_PATH}
+...@cindex @env{ACLOCAL_PATH}
+
+The fourth and last mechanism to customize the macro search path is
+also the simplest. Any directory included in the colon-separated
+environment variable @env{ACLOCAL_PATH} is added to the search path.
+
+Conversely to @file{dirlist}, @env{ACLOCAL_PATH} is useful if you are
+using a global copy of Automake and want @command{aclocal} to look for
+macros somewhere under your home directory.
@node Extending aclocal
@subsection Writing your own aclocal macros
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 6673293..8bddb03 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -77,6 +77,7 @@ acloca20.test \
acloca21.test \
acloca22.test \
acloca23.test \
+acloca24.test \
acoutnoq.test \
acoutpt.test \
acoutpt2.test \
diff --git a/tests/Makefile.in b/tests/Makefile.in
index 3bc699f..798c4fe 100644
--- a/tests/Makefile.in
+++ b/tests/Makefile.in
@@ -317,6 +317,7 @@ acloca20.test \
acloca21.test \
acloca22.test \
acloca23.test \
+acloca24.test \
acoutnoq.test \
acoutpt.test \
acoutpt2.test \
diff --git a/tests/acloca24.test b/tests/acloca24.test
new file mode 100755
index 000..a99be3d
--- /dev/null
+++ b/tests/acloca24.test
@@ -0,0 +1,60 @@
+#! /bin/sh
+# Copyright (C) 2002, 2003, 2004, 2010 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+# Check
Re: [PATCH] aclocal: handle ACLOCAL_PATH environment variable
On 11/03/2010 04:24 PM, Stefano Lattarini wrote:
+ # Add any directory listed in the `ACLOCAL_PATH' environment
+ # variable.
+ if (defined $ENV{ACLOCAL_PATH})
+{
+ foreach my $dir (split /:/, $ENV{ACLOCAL_PATH})
Shouldn't we use `...@path_separator@' here instead of `:', for better
portability to windows?
Yes, I think so.
+{
+ push (@system_includes, $dir) if $dir ne '' -d $dir;
Hmmm... IMHO the right place where to add directories from `ACLOCAL_PATH'
is `...@user_includes', not `...@system_includes'. Also, the testcase should
verify that extra directories from `-I' command line options take
precedence over the ones from `ACLOCAL_PATH', and that these latter
ones take precedence over the extra directories from system includes.
This is true (and, I think, handled by pushing at the end of
@system_includes).
On the other hand, I considered @user_includes as per-package includes
and @system_includes as installation-wide includes (albeit per
account), which means ACLOCAL_PATH would count as a system include
directory.
I've attached two tentative testcases checking for the behaviour I'd
like to see from ACLOCAL_PATH.
But as an afterthought, I see that installing third party macros in
directories provided by `ACLOCAL_PATH' when the `--install' option
is used is probably a bad idea. Any idea about what the best way to
address this would be?
Keep it into @system_includes? :)
Paolo
[PATCH 0/3] Add ACLOCAL_PATH to aclocal
This series is v2 of the patch to add a per-user search path to aclocal. v2 includes Stefano's testcases, and implements his suggestions about search path ordering. However, careful analysis of what happens during the automake build showed that the resulting order is a bit more tricky than what Stefano likely anticipated. Patch 1 presents what would happen (basically, ACLOCAL_PATH would be sandwiched between the versioned and unversioned system directories). While understandable, this is complicated and also makes testing with --acdir not fully representative of what would happen after automake has been installed. For this reason, patch 2 simplifies the rules by letting ACLOCAL_PATH override the versioned system directory as well. This patch can be omitted if you decide that the more complex ordering is actually preferrable. Finally, patch 3 renames the concepts of user and system directories to local and global, as discussed in the v1 thread as well. Paolo Bonzini (3): aclocal: handle ACLOCAL_PATH environment variable aclocal: remove @automake_includes aclocal: rename search path variables ChangeLog | 41 +++ NEWS|6 +++ aclocal.in | 88 +++--- doc/automake.texi | 13 +++ tests/Makefile.am |2 + tests/Makefile.in |2 + tests/acloca24.test | 56 tests/acloca25.test | 67 ++ tests/aclocal.in| 14 ++-- 9 files changed, 251 insertions(+), 38 deletions(-) create mode 100755 tests/acloca24.test create mode 100755 tests/acloca25.test -- 1.7.3.2
[PATCH 1/3] aclocal: handle ACLOCAL_PATH environment variable
This updated patch passes the tests suggested by Stefano. Considering
that Automake will rarely if ever be invoked from outside, MSYS, I stuck
with the colon as the sole separator for ACLOCAL_PATH.
The test suites leaves the user's ACLOCAL_PATH in place, for consistency
with the treatment of ${prefix}/share/aclocal/dirlist in tests/defs.in,
but overrides it in the two dedicated tests.
I needed to tweak the tests/aclocal.in script to avoid passing the
srcdir to -I (which happens if building in srcdir). Otherwise, the
assumptions of the precedence tests in acloca25.test are not respected.
* NEWS: Document new behavior.
* aclocal.in (parse_arguments): Parse ACLOCAL_PATH as a colon-separated
list of directories to be included in the search path.
* doc/automake.texi (Macro Search Path): Document new behavior and
the precedence rules for various elements of the search path.
* tests/Makefile.am (TESTS): Add new testcases.
* tests/acloca24.test: New testcase.
* tests/acloca25.test: New testcase.
* tests/aclocal.in: Special-case in-srcdir build, so that -I is not used
if it brings in unwanted m4 files.
---
ChangeLog | 14 ++
NEWS|6
aclocal.in | 22 ---
doc/automake.texi | 15 ++
tests/Makefile.am |2 +
tests/Makefile.in |2 +
tests/acloca24.test | 56 +++
tests/acloca25.test | 72 +++
tests/aclocal.in| 14 +++---
9 files changed, 195 insertions(+), 8 deletions(-)
create mode 100755 tests/acloca24.test
create mode 100755 tests/acloca25.test
diff --git a/ChangeLog b/ChangeLog
index 5fff04a..fa43c14 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2010-11-09 Paolo Bonzini bonz...@gnu.org
+
+ aclocal: handle ACLOCAL_PATH environment variable.
+ * NEWS: Document new behavior.
+ * aclocal.in (parse_arguments): Parse ACLOCAL_PATH as a colon-separated
+ list of directories to be included in the search path.
+ * doc/automake.texi (Macro Search Path): Document new behavior and
+ the precedence rules for various elements of the search path.
+ * tests/Makefile.am (TESTS): Add new testcases.
+ * tests/acloca24.test: New testcase.
+ * tests/acloca25.test: New testcase.
+ * tests/aclocal.in: Special-case in-srcdir build, so that -I is not used
+ if it brings in unwanted m4 files.
+
2010-11-01 Ralf Wildenhues ralf.wildenh...@gmx.de
Add FAQ entry for bug reporting instructions.
diff --git a/NEWS b/NEWS
index c64ec14..9dd7860 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,11 @@
New in 1.11a:
+* Changes to aclocal:
+
+ - aclocal now interprets the `ACLOCAL_PATH' environment variable as a
+colon-separated list of additional directories to search after
+${prefix}/share/aclocal-VERSION and before ${prefix}/share/aclocal.
+
* Changes to automake:
- automake now generates silenced rules for texinfo outputs.
diff --git a/aclocal.in b/aclocal.in
index 4c81a47..942d8e3 100644
--- a/aclocal.in
+++ b/aclocal.in
@@ -53,9 +53,10 @@ $perl_threads = 0;
# Include paths for searching macros. We search macros in this order:
# user-supplied directories first, then the directory containing the
# automake macros, and finally the system-wide directories for
-# third-party macro. @user_includes can be augmented with -I.
-# @system_includes can be augmented with the `dirlist' file. Also
-# --acdir will reset both @automake_includes and @system_includes.
+# third-party macros. @user_includes can be augmented with -I.
+# @system_includes can be augmented with the `dirlist' file or
+# ACLOCAL_PATH. Also --acdir will reset both @automake_includes
+# and @system_includes.
my @user_includes = ();
my @automake_includes = (@datadir@/aclocal-$APIVERSION);
my @system_includes = ('@datadir@/aclocal');
@@ -1025,7 +1026,7 @@ sub parse_arguments ()
}
else
{
- # Finally, adds any directory listed in the `dirlist' file.
+ # Add any directory listed in the `dirlist' file.
if (open (DIRLIST, $system_includes[0]/dirlist))
{
while (DIRLIST)
@@ -1043,6 +1044,19 @@ sub parse_arguments ()
close (DIRLIST);
}
}
+ # Add any directory listed in the `ACLOCAL_PATH' environment
+ # variable.
+ if (defined $ENV{ACLOCAL_PATH})
+{
+ # Directories in ACLOCAL_PATH should take precedence over system
+ # directories, so we use unshift. However, directories that
+ # come first in ACLOCAL_PATH take precedence over directories
+ # coming later, which is why the result of split is reversed.
+ foreach my $dir (reverse split /:/, $ENV{ACLOCAL_PATH})
+{
+ unshift (@system_includes, $dir) if $dir ne '' -d $dir;
+}
+}
}
diff --git a/doc/automake.texi b/doc/automake.texi
index 7214e49..9c548fd
[PATCH 2/3] aclocal: remove @automake_includes
This patch simplifies the overly complicated rules for ACLOCAL_PATH
vs. @automake_includes and @system_includes, by stating that
ACLOCAL_PATH will override even @automake_includes. The simplest
way to achieve this is to remove @automake_includes altogether.
There are two small visible differences here with respect to 1.11:
- --acdir ${datadir}/prefix/aclocal-VERSION will treat files
in acdir as FT_AUTOMAKE, and special case them with respect to the
serial number. This option makes no sense, but I like the new
semantics better.
- if ${datadir}/prefix/aclocal-VERSION does not exist, aclocal
will not warn about it. This shouldn't happen anyway, so I think we
can live with this.
The third difference is of course in the semantics of ACLOCAL_PATH.
* NEWS: Adapt to change in ACLOCAL_PATH semantics.
* aclocal.in (default_automake_dir): New.
(scan_file): Use it to distinguish FT_AUTOMAKE from FT_SYSTEM.
(automake_includes): Remove.
(scan_m4_files): Do not scan it.
(have_ac_dir): New.
(parse_arguments): Set it for --acdir instead of automake_includes, use it
to determine whether to filter absent directories out of @system_includes.
Allow 1 directory in @system_includes for --print-ac-dir.
* doc/automake.texi: Adapt to changes in ACLOCAL_PATH semantics.
* tests/acloca25.test: Likewise.
---
ChangeLog | 15 +++
NEWS|4 ++--
aclocal.in | 36 +---
doc/automake.texi |6 ++
tests/acloca25.test |7 +--
5 files changed, 41 insertions(+), 27 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index fa43c14..ede73dc 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,20 @@
2010-11-09 Paolo Bonzini bonz...@gnu.org
+ aclocal: remove @automake_includes.
+ * NEWS: Adapt to changes in ACLOCAL_PATH semantics.
+ * aclocal.in (default_automake_dir): New.
+ (scan_file): Use it to distinguish FT_AUTOMAKE from FT_SYSTEM.
+ (automake_includes): Remove.
+ (scan_m4_files): Do not scan it.
+ (have_ac_dir): New.
+ (parse_arguments): Set it for --acdir instead of automake_includes, use
it
+ to determine whether to filter absent directories out of
@system_includes.
+ Allow 1 directory in @system_includes for --print-ac-dir.
+ * doc/automake.texi: Adapt to changes in ACLOCAL_PATH semantics.
+ * tests/acloca25.test: Likewise.
+
+2010-11-09 Paolo Bonzini bonz...@gnu.org
+
aclocal: handle ACLOCAL_PATH environment variable.
* NEWS: Document new behavior.
* aclocal.in (parse_arguments): Parse ACLOCAL_PATH as a colon-separated
diff --git a/NEWS b/NEWS
index 9dd7860..eb732d9 100644
--- a/NEWS
+++ b/NEWS
@@ -3,8 +3,8 @@ New in 1.11a:
* Changes to aclocal:
- aclocal now interprets the `ACLOCAL_PATH' environment variable as a
-colon-separated list of additional directories to search after
-${prefix}/share/aclocal-VERSION and before ${prefix}/share/aclocal.
+colon-separated list of additional directories to search before
+${prefix}/share/aclocal-VERSION and ${prefix}/share/aclocal.
* Changes to automake:
diff --git a/aclocal.in b/aclocal.in
index 942d8e3..1d73f49 100644
--- a/aclocal.in
+++ b/aclocal.in
@@ -50,16 +50,20 @@ use Cwd;
# We do not operate in threaded mode.
$perl_threads = 0;
+# This directory is treated specially with respect to serial numbers.
+my $default_automake_dir = @datadir@/aclocal-$APIVERSION;
+
# Include paths for searching macros. We search macros in this order:
# user-supplied directories first, then the directory containing the
# automake macros, and finally the system-wide directories for
# third-party macros. @user_includes can be augmented with -I.
# @system_includes can be augmented with the `dirlist' file or
-# ACLOCAL_PATH. Also --acdir will reset both @automake_includes
-# and @system_includes.
+# ACLOCAL_PATH.
my @user_includes = ();
-my @automake_includes = (@datadir@/aclocal-$APIVERSION);
-my @system_includes = ('@datadir@/aclocal');
+my @system_includes = ($default_automake_dir, '@datadir@/aclocal');
+
+# Whether --acdir was passed.
+my $have_acdir = 0;
# Whether we should copy M4 file in $user_includes[0].
my $install = 0;
@@ -346,7 +350,6 @@ sub scan_m4_files ()
# Finally, scan all files in our search paths.
scan_m4_dirs (FT_USER, @user_includes);
- scan_m4_dirs (FT_AUTOMAKE, @automake_includes);
scan_m4_dirs (FT_SYSTEM, @system_includes);
# Construct a new function that does the searching. We use a
@@ -464,8 +467,8 @@ my $underquoted_manual_once = 0;
#
# Scan a single M4 file ($FILE), and all files it includes.
# Return the list of included files.
-# $TYPE is one of FT_USER, FT_AUTOMAKE, or FT_SYSTEM, depending
-# on where the file comes from.
+# $TYPE is one of FT_USER or FT_SYSTEM, depending on where
+# the file comes from.
# $WHERE is the location to use in the diagnostic if the file
# does not exist
[PATCH 3/3] aclocal: rename search path variables
As suggested in the v1 thread, this renames references to user/system
includes to local and global. The source now refers to system
directories as a subset of the global directories (together with
ACLOCAL_PATH-supplied and dirlist-supplied directories).
* aclocal.in (user_includes): Rename to...
(local_includes): ... this.
(system_includes): Rename to...
(global_includes): ... this.
(FT_USER): Rename to...
(FT_LOCAL): ... this.
(FT_SYSTEM): Rename to...
(FT_GLOBAL): ... this.
---
ChangeLog | 12
aclocal.in | 50 +-
2 files changed, 37 insertions(+), 25 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index ede73dc..b3ec1fb 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,17 @@
2010-11-09 Paolo Bonzini bonz...@gnu.org
+ aclocal: rename search path variables.
+ * aclocal.in (user_includes): Rename to...
+ (local_includes): ... this.
+ (system_includes): Rename to...
+ (global_includes): ... this.
+ (FT_USER): Rename to...
+ (FT_LOCAL): ... this.
+ (FT_SYSTEM): Rename to...
+ (FT_GLOBAL): ... this.
+
+2010-11-09 Paolo Bonzini bonz...@gnu.org
+
aclocal: remove @automake_includes.
* NEWS: Adapt to changes in ACLOCAL_PATH semantics.
* aclocal.in (default_automake_dir): New.
diff --git a/aclocal.in b/aclocal.in
index 1d73f49..895f56b 100644
--- a/aclocal.in
+++ b/aclocal.in
@@ -56,16 +56,16 @@ my $default_automake_dir = @datadir@/aclocal-$APIVERSION;
# Include paths for searching macros. We search macros in this order:
# user-supplied directories first, then the directory containing the
# automake macros, and finally the system-wide directories for
-# third-party macros. @user_includes can be augmented with -I.
-# @system_includes can be augmented with the `dirlist' file or
+# third-party macros. @local_includes can be augmented with -I.
+# @global_includes can be augmented with the `dirlist' file or
# ACLOCAL_PATH.
-my @user_includes = ();
-my @system_includes = ($default_automake_dir, '@datadir@/aclocal');
+my @local_includes = ();
+my @global_includes = ($default_automake_dir, '@datadir@/aclocal');
# Whether --acdir was passed.
my $have_acdir = 0;
-# Whether we should copy M4 file in $user_includes[0].
+# Whether we should copy M4 file in $local_includes[0].
my $install = 0;
# --diff
@@ -109,9 +109,9 @@ my %file_contents = ();
# Map file names to file types.
my %file_type = ();
-use constant FT_USER = 1;
+use constant FT_LOCAL = 1;
use constant FT_AUTOMAKE = 2;
-use constant FT_SYSTEM = 3;
+use constant FT_GLOBAL = 3;
# Map file names to included files (transitively closed).
my %file_includes = ();
@@ -340,17 +340,17 @@ sub scan_m4_files ()
{
# First, scan configure.ac. It may contain macro definitions,
# or may include other files that define macros.
- scan_file (FT_USER, $configure_ac, 'aclocal');
+ scan_file (FT_LOCAL, $configure_ac, 'aclocal');
# Then, scan acinclude.m4 if it exists.
if (-f 'acinclude.m4')
{
- scan_file (FT_USER, 'acinclude.m4', 'aclocal');
+ scan_file (FT_LOCAL, 'acinclude.m4', 'aclocal');
}
# Finally, scan all files in our search paths.
- scan_m4_dirs (FT_USER, @user_includes);
- scan_m4_dirs (FT_SYSTEM, @system_includes);
+ scan_m4_dirs (FT_LOCAL, @local_includes);
+ scan_m4_dirs (FT_GLOBAL, @global_includes);
# Construct a new function that does the searching. We use a
# function (instead of just evaluating $search in the loop) so that
@@ -467,7 +467,7 @@ my $underquoted_manual_once = 0;
#
# Scan a single M4 file ($FILE), and all files it includes.
# Return the list of included files.
-# $TYPE is one of FT_USER or FT_SYSTEM, depending on where
+# $TYPE is one of FT_LOCAL or FT_GLOBAL, depending on where
# the file comes from.
# $WHERE is the location to use in the diagnostic if the file
# does not exist.
@@ -484,7 +484,7 @@ sub scan_file ($$$)
unshift @file_order, $file;
$type = FT_AUTOMAKE
-if $type == FT_SYSTEM $default_automake_dir eq dirname $file;
+if $type == FT_GLOBAL $default_automake_dir eq dirname $file;
$file_type{$file} = $type;
@@ -761,10 +761,10 @@ sub write_aclocal ($@)
# If the file to add looks like outside the project, copy it
# to the output. The regex catches filenames starting with
# things like `/', `\', or `c:\'.
- if ($file_type{$file} != FT_USER
+ if ($file_type{$file} != FT_LOCAL
|| $file =~ m,^(?:\w:)?[\\/],)
{
- if (!$install || $file_type{$file} != FT_SYSTEM)
+ if (!$install || $file_type{$file} != FT_GLOBAL)
{
# Copy the file into aclocal.m4.
$output .= $file_contents{$file} . \n;
@@ -775,7 +775,7 @@ sub write_aclocal ($@)
my $dest;
for my $ifile (@{$file_includes{$file}}, $file)
{
- $dest
Re: [PATCH 2/3] aclocal: remove @automake_includes
On 11/14/2010 05:46 PM, Ralf Wildenhues wrote: Hi Paolo, * Paolo Bonzini wrote on Tue, Nov 09, 2010 at 08:14:39PM CET: This patch simplifies the overly complicated rules for ACLOCAL_PATH vs. @automake_includes and @system_includes, by stating that ACLOCAL_PATH will override even @automake_includes. The simplest way to achieve this is to remove @automake_includes altogether. I've read the previous discussion about this now, but I'm still not sure I understand the rationale for this change. Is it because you want to actually be able to override the $(datadir)/aclocal-$VERSION files with this variable? If so, why? I don't really need to override the files, it's just to simplify the semantics and make ACLOCAL_PATH between -I and the system variables. If the only reason is that --acdir doesn't accurately reflect what would happen after 'make install', maybe we can instead fix --acdir? That's not a problem, during the testsuite it is safer to operate as if $(datadir)/aclocal is empty, and --acdir achieves that. So I think --acdir is fine. If you would prefer to fix --acdir, it would be in theory possible to make --acdir change @automake_includes and empty @system_includes instead. However, before going on, I might be missing something. Google code search shows a relatively large amount of strange uses of --acdir, even in projects using relatively recent Autoconf (like 1.9.x). I'm not sure how they work; for example: acdir = m4 @ma...@aclocal-files: configure.in @MAINT@ echo 'acfiles = \' $...@-tmp @MAINT@ find $(acdir) -type f -name '*.m4' -print \ @MAINT@ | sed 's!^!$(top_srcdir)/!' \ @MAINT@ | tr '\012' ' ' \ @MAINT@$...@-tmp @MAINT@ echo $...@-tmp @MAINT@ mv $...@-tmp $@ @ma...@include aclocal-files @ma...@# Override default rule to use --acdir option @ma...@$(srcdir)/aclocal.m4: configure.in $(acfiles) @MAINT@ cd $(srcdir) aclocal --acdir=$(acdir) How can this work, wouldn't it miss all the internal Automake macros? I'm not sure if you stated whether the testsuite passes for you with this patch series. Yes, it works. Paolo
Re: [PATCH] aclocal: handle ACLOCAL_PATH environment variable
On 09/19/2011 06:05 PM, Stefano Lattarini wrote: I'll push the attached patch in 72 hours if there is no review by then. Paolo, since it's you who have written the previous version of this patch, from which I've drawn heavily, are you ok to be listed as the main author in the ChangeLog entry, and in the Author field of the git commit? I don't care either way. :) Thanks for shepherding the patch! Paolo
Re: [PATCH] aclocal: handle ACLOCAL_PATH environment variable
On 09/19/2011 06:05 PM, Stefano Lattarini wrote: Resurrecting the old thread Add ACLOCAL_PATH to aclocal; references: http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00089.html http://thread.gmane.org/gmane.comp.sysutils.automake.patches/4972 I really want the ACLOCAL_PATH feature to end up in 1.11.2, which I hope we will be able to release in a few weeks. The test cases I've added should IMHO ough to show that the new feature is solid enough and interacts nicely with the pre-existing aclocal features. The documentation could probably be improved, but that can easily be done at a later moment. I'll push the attached patch in 72 hours if there is no review by then. Paolo, since it's you who have written the previous version of this patch, from which I've drawn heavily, are you ok to be listed as the main author in the ChangeLog entry, and in the Author field of the git commit? Just to be sure, you are not including http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00091.html are you? If so, why not? Paolo
Re: [PATCH] aclocal: handle ACLOCAL_PATH environment variable
On 09/20/2011 12:51 PM, Stefano Lattarini wrote: Yes (and that's on purpose: ACLOCAL_PATH is typically used by a user which has newer versions of libraries installed, so they need their directories to override everything). Yes, this might be desirable. But then, for consistency sake, shouldn't we allow the .m4 files in the default system acdir and in the directories added through a `dirlist' file to override the automake macros as well? Yeah, I think the problem is that in the normal search path (from `aclocal -I /foo -I /bar'): 1. `/foo' 2. `/bar' 3. ACDIR-APIVERSION 4. ACDIR The directories from dirlist and ACLOCAL_PATH should go after (3), rather than after (4). Perhaps even after (2). I'm not sure about this, it has its pros and cons... Anyway, if we decide to go down this road, we should wait for 1.12, as the introduction of such a backward-incompatibility, albeit limited, is inappropriate for a minor release such as 1.11.2. You could certainly push your patch now and modify the behavior of both dirlist and ACLOCAL_PATH in 1.12. I doubt there are many dirlist users anyway, so the probability of regressions should be quite low. Paolo
Re: [PATCH] aclocal: handle ACLOCAL_PATH environment variable
On 09/20/2011 02:09 PM, Stefano Lattarini wrote: Yeah, I think the problem is that in the normal search path (from `aclocal -I /foo -I /bar'): 1. `/foo' 2. `/bar' 3. ACDIR-APIVERSION 4. ACDIR The directories from dirlist and ACLOCAL_PATH should go after (3), rather than after (4). But this is what they currently do (see test `aclocal-path-precedence.test'). Interesting, that's not what is in (automake.info)Macro Search Path. Paolo
Re: [PATCHES] Better error messages if obsolete macros are used
Il 30/12/2012 11:23, Stefano Lattarini ha scritto: +AC_DEFUN([AM_CONFIG_HEADER], +[AC_FATAL(['$0': this macro is obsolete. +You should use the 'AC][_CONFIG_HEADERS' macro instead.])]) + What's the point in doing this instead of m4_defun([AM_CONFIG_HEADER], [AC_CONFIG_HEADERS]) or something like that? Your patch is even longer than keeping backwards-compatibility... Paolo
Re: [PATCHES] Better error messages if obsolete macros are used
Il 31/12/2012 10:05, Stefano Lattarini ha scritto: On 12/30/2012 07:08 PM, Paolo Bonzini wrote: Il 30/12/2012 11:23, Stefano Lattarini ha scritto: +AC_DEFUN([AM_CONFIG_HEADER], +[AC_FATAL(['$0': this macro is obsolete. +You should use the 'AC][_CONFIG_HEADERS' macro instead.])]) + What's the point in doing this instead of m4_defun([AM_CONFIG_HEADER], [AC_CONFIG_HEADERS]) or something like that? Issuing a fatal error will force users to upgrade to AC_CONFIG_HEADERS, thus allowing us to remove AM_CONFIG_HEADER altogether in future Automake versions (probably 1.15). 4, or maybe 1.15). Again: it does not do any harm. Move it to m4/obsolete.m4, and nobody will ever care about it again (including deleting it). Paolo
Re: [PATCHES] Better error messages if obsolete macros are used
Il 31/12/2012 11:32, Stefano Lattarini ha scritto: It is indeed possible that the real reason that pushed me to remove AM_CONFIG_HEADER was the fact that I got caught in a cleanup frenzy when I was removing other (real) cruft. You are starting to partly convince me of that. These patches are at least a little better, so I'll just let your subconscious finish the task of convincing you. (Also because almost nobody is using autoupdate anymore I believe, so a first step using AU_DEFUN would not provide much benefit). That said, I still believe that old cruft, even if completely harmless as in this case, should be removed eventually (and that macro has been cruft for almost 10 yars now). The real issue with the removal is that it is has been too abrupt, with no transition from doc deprecation to runtime warnings to error message to complete removal (despite the fact we had all the time to implement this transition, and not doing so has been 100% my fault). These patches tries to remedy this situation. Yeah, I agree entirely here. Paolo
[PATCH] automake: do not require ltmain.sh for out-of-tree libtool
If Automake does not see LT_SUPPORTED_TAG, it assumes an old libtool
that does not know about AC_REQUIRE_AUX_FILE. However, if the program
does not use Libtool's configure.ac macros this check gets a
false positive. Do not require ltmain.sh if no Libtool macro is
found in configure.ac.
Libtools that are not stone-age are already covered by LT_SUPPORTED_TAG
and _LT_AC_TAGCONFIG, but add AC_PROG_LIBTOOL just in case for Libtool
up to 1.4.
2016-10-31 Paolo Bonzini <bonz...@gnu.org>
* bin/automake.in ($libtool_bundled): New.
(handle_libtool): Do not require libtool files if libtool is
not being bundled.
(scan_autoconf_traces): Set $libtool_bundled. Trace
AC_PROG_LIBTOOL too.
Signed-off-by: Paolo Bonzini <bonz...@gnu.org>
---
If the patch is accepted I will send an Autoconf patch to
preselect AC_PROG_LIBTOOL.
Since this is a bug, it would be nice to add it at least to
the 1.16 branch.
bin/automake.in | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/bin/automake.in b/bin/automake.in
index 3abee49..cb2a480 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -274,6 +274,8 @@ my @extra_recursive_targets = ();
# Lists of tags supported by Libtool.
my %libtool_tags = ();
+# 1 if Libtool is being bundled, so ltmain.sh is required.
+my $libtool_bundled = 0;
# 1 if Libtool uses LT_SUPPORTED_TAG. If it does, then it also
# uses AC_REQUIRE_AUX_FILE.
my $libtool_new_api = 0;
@@ -2304,7 +2306,7 @@ sub handle_libtool ()
# (Starting with Libtool 2.0 we do not have to bother. These
# requirements are done with AC_REQUIRE_AUX_FILE.)
require_conf_file_with_macro (TRUE, 'LIBTOOL', FOREIGN, @libtool_files)
-if $relative_dir eq '.' && ! $libtool_new_api;
+if $relative_dir eq '.' && $libtool_bundled && ! $libtool_new_api;
my @libtool_rms;
foreach my $item (sort keys %libtool_clean_directories)
@@ -4952,6 +4954,7 @@ sub scan_autoconf_traces
_AM_COND_IF => 1,
_AM_COND_ELSE => 1,
_AM_COND_ENDIF => 1,
+ AC_PROG_LIBTOOL => 0,
LT_SUPPORTED_TAG => 1,
_LT_AC_TAGCONFIG => 0,
m4_include => 1,
@@ -5185,10 +5188,16 @@ sub scan_autoconf_traces
if $mtime > $configure_deps_greatest_timestamp;
}
}
+ elsif ($macro eq 'AC_PROG_LIBTOOL')
+ {
+ # Detect bundling of really old Libtool that does not support tags.
+ $libtool_bundled = 1;
+ }
elsif ($macro eq 'LT_SUPPORTED_TAG')
{
$libtool_tags{$args[1]} = 1;
$libtool_new_api = 1;
+ $libtool_bundled = 1;
}
elsif ($macro eq '_LT_AC_TAGCONFIG')
{
@@ -5201,6 +5210,7 @@ sub scan_autoconf_traces
# Hardcode the tags supported by Libtool 1.5.
%libtool_tags = (CC => 1, CXX => 1, GCJ => 1, F77 => 1);
}
+ $libtool_bundled = 1;
}
}
--
2.7.4
Re: [PATCH] automake: do not require ltmain.sh for out-of-tree libtool
On 17/10/2017 13:45, Mathieu Lirzin wrote: >>> 1 file changed, 11 insertions(+), 1 deletion(-) > I haven't tested this, and I am not a Libtool expert so I trust your > analysis. > > What do you think of adding a test ensuring that ltmain.sh is not > required when no Libtool macro is found? > > I have attached a updated patch with trivial formatting and comment > changes. > I am not sure when I will have time (it's been a year ;)) but yes, that's a good idea. Paolo
Re: [PATCH] automake: do not require ltmain.sh for out-of-tree libtool
On 31/10/2016 13:30, Paolo Bonzini wrote:
> If Automake does not see LT_SUPPORTED_TAG, it assumes an old libtool
> that does not know about AC_REQUIRE_AUX_FILE. However, if the program
> does not use Libtool's configure.ac macros this check gets a
> false positive. Do not require ltmain.sh if no Libtool macro is
> found in configure.ac.
>
> Libtools that are not stone-age are already covered by LT_SUPPORTED_TAG
> and _LT_AC_TAGCONFIG, but add AC_PROG_LIBTOOL just in case for Libtool
> up to 1.4.
This patch was never applied.
Paolo
> 2016-10-31 Paolo Bonzini <bonz...@gnu.org>
>
> * bin/automake.in ($libtool_bundled): New.
> (handle_libtool): Do not require libtool files if libtool is
> not being bundled.
> (scan_autoconf_traces): Set $libtool_bundled. Trace
> AC_PROG_LIBTOOL too.
>
> Signed-off-by: Paolo Bonzini <bonz...@gnu.org>
> ---
> If the patch is accepted I will send an Autoconf patch to
> preselect AC_PROG_LIBTOOL.
>
> Since this is a bug, it would be nice to add it at least to
> the 1.16 branch.
>
> bin/automake.in | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/bin/automake.in b/bin/automake.in
> index 3abee49..cb2a480 100644
> --- a/bin/automake.in
> +++ b/bin/automake.in
> @@ -274,6 +274,8 @@ my @extra_recursive_targets = ();
>
> # Lists of tags supported by Libtool.
> my %libtool_tags = ();
> +# 1 if Libtool is being bundled, so ltmain.sh is required.
> +my $libtool_bundled = 0;
> # 1 if Libtool uses LT_SUPPORTED_TAG. If it does, then it also
> # uses AC_REQUIRE_AUX_FILE.
> my $libtool_new_api = 0;
> @@ -2304,7 +2306,7 @@ sub handle_libtool ()
># (Starting with Libtool 2.0 we do not have to bother. These
># requirements are done with AC_REQUIRE_AUX_FILE.)
>require_conf_file_with_macro (TRUE, 'LIBTOOL', FOREIGN, @libtool_files)
> -if $relative_dir eq '.' && ! $libtool_new_api;
> +if $relative_dir eq '.' && $libtool_bundled && ! $libtool_new_api;
>
>my @libtool_rms;
>foreach my $item (sort keys %libtool_clean_directories)
> @@ -4952,6 +4954,7 @@ sub scan_autoconf_traces
> _AM_COND_IF => 1,
> _AM_COND_ELSE => 1,
> _AM_COND_ENDIF => 1,
> + AC_PROG_LIBTOOL => 0,
> LT_SUPPORTED_TAG => 1,
> _LT_AC_TAGCONFIG => 0,
> m4_include => 1,
> @@ -5185,10 +5188,16 @@ sub scan_autoconf_traces
> if $mtime > $configure_deps_greatest_timestamp;
> }
> }
> + elsif ($macro eq 'AC_PROG_LIBTOOL')
> + {
> + # Detect bundling of really old Libtool that does not support tags.
> + $libtool_bundled = 1;
> + }
>elsif ($macro eq 'LT_SUPPORTED_TAG')
> {
> $libtool_tags{$args[1]} = 1;
> $libtool_new_api = 1;
> + $libtool_bundled = 1;
> }
>elsif ($macro eq '_LT_AC_TAGCONFIG')
> {
> @@ -5201,6 +5210,7 @@ sub scan_autoconf_traces
> # Hardcode the tags supported by Libtool 1.5.
> %libtool_tags = (CC => 1, CXX => 1, GCJ => 1, F77 => 1);
> }
> + $libtool_bundled = 1;
> }
> }
>
>
