On 08/05/2012 10:50 PM, Stefano Lattarini wrote:
> On 08/04/2012 03:28 PM, Stefano Lattarini wrote: >> >> I'm not sure whether you are aware of this, but I've been using Automake-NG >> already on several GNU projects, and the results so far seems very promising. >> >> [SNIP] >> >> I hope I'll be able to add DejaGNU and GNU Smalltalk to the list of such >> projects before the end the GSoC (no promise though). >> <https://github.com/slattarini/smalltalk-am-ng> The relevant changes are all contained in the attached patch. Regards, Stefano _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk 0001-build-support-and-require-Automake-NG.patch (15K) Download Attachment |
On Sat, Aug 18, 2012 at 03:48:28PM +0200, Stefano Lattarini wrote:
Dear Stefano, do you have some bulletin points that automake-ng can do better than plain automake? All I found out is that it targets GNU make directly. And where do the incompabilities come from? E.g. would most of your changes work with the normal automake? holger _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Hi Holger, thanks for the feedback.
On 08/19/2012 01:19 PM, Holger Hans Peter Freyther wrote: > On Sat, Aug 18, 2012 at 03:48:28PM +0200, Stefano Lattarini wrote: > > Dear Stefano, > > do you have some bulletin points that automake-ng can do better than > plain automake? > It depends what do you intend for "better". Let me elaborate. What is important to understand is that Automake-NG has a threefold aim: [1] it wants to improve user experience, by letting the user take more advantage of GNU make features (where possible); [2] it wants to itself take advantage of GNU make features and semantics to improve the robustness and speed of the generated Makefile, and to fix some long-standing limitations and bugs of Automake that are basically impossible to fix using only portable make constructs; an example of this is the "command-line length limits exceeded" problems possible in the 'dist' and 'check' targets; for reference see: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7868> [3] it wants to make the life of Automake's developers easier and more pleasant, by allowing them to freely use of all the available GNU make features and extensions -- which are far more powerful and flexible than the features available in portable make, and allows for clearer and simpler implementation (as well as testing) of Automake. So, Automake-NG will be "better" for you as an user in the areas covered by the [1] and [2] above, while it will just be better for "us" developers in the other areas. Also, keep in mind that Automake-NG is still an experimental project, so it would be premature for GNU Smalltalk to switch to it right away (even though the Smalltalk build system seems to already require GNU make); the use of Automake-NG should be restricted to an experimental branch, proceeding in parallel with the master branch, at least until Automake-NG reaches its first stable release. > All I found out is that it targets GNU make directly. > That is the most important difference at the moment. For more background and future plans/hopes, you might take a look at the README file in the 'ng/master' branch in the Automake official Git repository. (Note to self: maybe it's time I write an "introduction" of sort in the Automake-NG manual to explain the purpose and aims of it, as well as the major differences between it and mainline Automake ...) > And where do the incompabilities come from? > Some of them are necessary to enable the use of desired GNU make features; some of them are part of the deliberate trend of moving knowledge and processing from Automake runtime to GNU make runtime; and some of them are due to API changes that, while simple and easy to adapt to, are either backward-incompatible, or unable to work with portable make -- thus being in both cases unfit to go into mainline Automake. Most of such incompatibilities should be listed and explained in the NG-NEWS file in the 'ng/master' branch of the Automake official Git repository. > E.g. would most of your changes work with the normal automake? > Some yes, some no. If you want, I can separate my patch into a "preparatory cleanup" that still works with mainline Automake (and can thus go in the master branch of the Smalltalk repo), and a further patch on the top of that which ports the build system to Automake-NG (that should go only into the experimental branch I suggested above). Thanks, Stefano _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Il 19/08/2012 14:01, Stefano Lattarini ha scritto:
>> E.g. would most of your changes work with the normal automake? >> > Some yes, some no. If you want, I can separate my patch into a > "preparatory cleanup" that still works with mainline Automake (and > can thus go in the master branch of the Smalltalk repo), and a > further patch on the top of that which ports the build system to > Automake-NG (that should go only into the experimental branch I > suggested above). Yes, please do so. I'm more than happy to apply the first part, and it would help me evaluate the amount of incompatible changes (I'm not sure I liked the "problems" with XYZ_LDFLAGS macros; it reminds me of horrible experiences with early 2.5x versions of Autoconf). Paolo _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Hi Paolo.
On 08/20/2012 09:16 AM, Paolo Bonzini wrote: > Il 19/08/2012 14:01, Stefano Lattarini ha scritto: >>> E.g. would most of your changes work with the normal automake? >>> >> Some yes, some no. If you want, I can separate my patch into a >> "preparatory cleanup" that still works with mainline Automake (and >> can thus go in the master branch of the Smalltalk repo), and a >> further patch on the top of that which ports the build system to >> Automake-NG (that should go only into the experimental branch I >> suggested above). > > Yes, please do so. > > I'm more than happy to apply the first part, and it > would help me evaluate the amount of incompatible changes (I'm not sure > I liked the "problems" with XYZ_LDFLAGS macros; > They are not "problems" IMO; simply, some checks has been tightened when they have been moved from Automake runtime to GNU make runtime. Since this enhanced warnings can be very easily silenced (with the help of the AM_VARTYPOS_WHITELIST special variable) or avoided (renaming an offending 'FOO_LDFLAGS' variable to, say, 'FOO-LDFLAGS'), I don't see any issue here. > it reminds me of horrible experiences with early 2.5x versions of > Autoconf). > > Paolo Regards, Stefano _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Paolo Bonzini-2
After these changes, the Smalltalk build system still works with
mainline Automake (and only with it), but will be much easier to modify to convert it to Automake-NG. -*-*-*- Stefano Lattarini (5): build: use $(AM_CPPFLAGS), not $(INCLUDES) build: prefer pattern rules over suffix rules build: don't use files with non-standard extensions in _SOURCES svnprintf: modernize and improve its build system build: reorganize some stamp files' handling ChangeLog | 92 +++++++++++++++++++++++++++++++++++++++++ doc/Makefile.am | 2 +- libgst/Makefile.am | 31 +++++--------- packages/glib/Makefile.am | 6 ++- packages/gtk/Makefile.am | 1 - packages/i18n/Makefile.am | 2 +- snprintfv/Makefile.am | 19 --------- snprintfv/snprintfv/Makefile.am | 2 - 8 files changed, 109 insertions(+), 46 deletions(-) -- 1.7.12.rc0.129.g61b472e _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
The latter is a long-deprecated and obsolescent alias for the former.
* packages/glib/Makefile.am (INCLUDES): Rename ... (AM_CPPFLAGS): ... like this Signed-off-by: Stefano Lattarini <[hidden email]> --- ChangeLog | 9 +++++++++ packages/glib/Makefile.am | 5 ++++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index ec4a739..293b064 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2012-08-20 Stefano Lattarini <[hidden email]> + + build: use $(AM_CPPFLAGS), not $(INCLUDES) + + The latter is a long-deprecated and obsolescent alias for the former. + + * packages/glib/Makefile.am (INCLUDES): Rename ... + (AM_CPPFLAGS): ... like this + 2012-02-22 Paolo Bonzini <[hidden email]> * kernel/CallinProcess.st: Fix creation of cloned process, reported diff --git a/packages/glib/Makefile.am b/packages/glib/Makefile.am index 4ff4566..b8075f6 100644 --- a/packages/glib/Makefile.am +++ b/packages/glib/Makefile.am @@ -23,7 +23,10 @@ BUILT_SOURCES = libs.def # installed before libgst-gobject has been relinked. .NOTPARALLEL: -INCLUDES = -I$(top_srcdir)/libgst -I$(top_srcdir)/lib-src -I$(top_srcdir)/libltdl +AM_CPPFLAGS = \ + -I$(top_srcdir)/libgst \ + -I$(top_srcdir)/lib-src \ + -I$(top_srcdir)/libltdl AM_CFLAGS = $(GLIB_CFLAGS) $(GTHREAD_CFLAGS) -- 1.7.12.rc0.129.g61b472e _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Stefano Lattarini
They are clearer and more idiomatic. Of course they are unportable to
non-GNU make implementations, but the Smalltalk build system already requires GNU make, so that's not a problem. * libgst/Makefile.am (.gperf.inl): Rewrite ... (%.inl: %.gperf): ... as a pattern rule. * packages/i18n/Makefile.am (.sin.sed): Rewrite ... (%.sed: %.sin): ... as this pattern rule. * doc/Makefile.am (.texi.info): Rewrite ... (%.info: %.texi): ... as this pattern rule. Signed-off-by: Stefano Lattarini <[hidden email]> --- ChangeLog | 15 +++++++++++++++ doc/Makefile.am | 2 +- libgst/Makefile.am | 2 +- packages/i18n/Makefile.am | 2 +- 4 files changed, 18 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index 293b064..733c110 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,20 @@ 2012-08-20 Stefano Lattarini <[hidden email]> + build: prefer pattern rules over suffix rules + + They are clearer and more idiomatic. Of course they are not + portable to non-GNU make implementations, but the Smalltalk build + system already requires GNU make, so that's not a problem. + + * libgst/Makefile.am (.gperf.inl): Rewrite ... + (%.inl: %.gperf): ... as a pattern rule. + * packages/i18n/Makefile.am (.sin.sed): Rewrite ... + (%.sed: %.sin): ... as this pattern rule. + * doc/Makefile.am (.texi.info): Rewrite ... + (%.info: %.texi): ... as this pattern rule. + +2012-08-20 Stefano Lattarini <[hidden email]> + build: use $(AM_CPPFLAGS), not $(INCLUDES) The latter is a long-deprecated and obsolescent alias for the former. diff --git a/doc/Makefile.am b/doc/Makefile.am index a89a38a..ea6c0bf 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -159,7 +159,7 @@ $(srcdir)/classes.texi: $(top_srcdir)/kernel/stamp-classes # In TeX output, having colons in index entries looks pretty, but # this is impossible in info output!!! So we hack by replacing # colons with underscores in the info file. -.texi.info: +%.info: %.texi @cd $(srcdir) && rm -f $@ $@-[0-9] $@-[0-9][0-9] fixed=`pwd`/`echo $< | $(SED) 's/\.texi/-fixed&/' `; \ cd $(srcdir) && \ diff --git a/libgst/Makefile.am b/libgst/Makefile.am index 5a28027..4393388 100644 --- a/libgst/Makefile.am +++ b/libgst/Makefile.am @@ -166,7 +166,7 @@ $(srcdir)/vm.stamp: vm.def # rules for invoking gperf # not fully idiot-proof but only to be run by maintainers -.gperf.inl: +%.inl: %.gperf @opts="$< `$(SED) -ne /.*gperf/!d -e s///p -e q $< | \ $(SED) 's,$$(srcdir),$(srcdir),g'`"; \ echo $(GPERF) $$opts " > $@"; \ diff --git a/packages/i18n/Makefile.am b/packages/i18n/Makefile.am index 2ba4815..dc90582 100644 --- a/packages/i18n/Makefile.am +++ b/packages/i18n/Makefile.am @@ -15,7 +15,7 @@ EXTRA_DIST = ref-add.sin ref-del.sin config.charset noinst_SCRIPTS = ref-add.sed ref-del.sed CLEANFILES = ref-add.sed ref-del.sed charset.alias -.sin.sed: +%.sed: %.sin $(SED) -e '/^#/d' -e 's/@''PACKAGE''@/@PACKAGE@/g' $< > t-$@ mv t-$@ $@ -- 1.7.12.rc0.129.g61b472e _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Stefano Lattarini
While they are still perfectly supported in mainline Automake, they
would make a transition to Automake-NG harder. * packages/glib/Makefile.am (nodist_gst_glib_la_SOURCES): Don't list 'libs.def' here. There's no need to, because it is already generated early (being listed in BUILT_SOURCES), and its role as a prerequisite is already computed automatically by the automatic dependency tracking code. More importantly, Automake-NG does not blindly treat source files with a custom unknown user extension as if they were header files anymore, so the presence of 'libs.def' here would cause spurious errors. * packages/gtk/Makefile.am: Likewise (with 'nodist_gst_gtk_la_SOURCES' in place of 'nodist_gst_glib_la_SOURCES'). Signed-off-by: Stefano Lattarini <[hidden email]> --- ChangeLog | 18 ++++++++++++++++++ packages/glib/Makefile.am | 1 - packages/gtk/Makefile.am | 1 - 3 files changed, 18 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 733c110..426b934 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,23 @@ 2012-08-20 Stefano Lattarini <[hidden email]> + build: don't use files with non-standard extensions in _SOURCES + + While they are still perfectly supported in mainline Automake, they + would make a transition to Automake-NG harder. + + * packages/glib/Makefile.am (nodist_gst_glib_la_SOURCES): Don't list + 'libs.def' here. There's no need to, because it is already generated + early (being listed in BUILT_SOURCES), and its role as a prerequisite + is already computed automatically by the automatic dependency tracking + code. More importantly, Automake-NG does not blindly treat source + files with a custom unknown user extension as if they were header + files anymore, so the presence of 'libs.def' here would cause spurious + errors. + * packages/gtk/Makefile.am: Likewise (with 'nodist_gst_gtk_la_SOURCES' + in place of 'nodist_gst_glib_la_SOURCES'). + +2012-08-20 Stefano Lattarini <[hidden email]> + build: prefer pattern rules over suffix rules They are clearer and more idiomatic. Of course they are not diff --git a/packages/glib/Makefile.am b/packages/glib/Makefile.am index b8075f6..ae340af 100644 --- a/packages/glib/Makefile.am +++ b/packages/glib/Makefile.am @@ -16,7 +16,6 @@ gst_glib_la_LDFLAGS = $(gst_module_ldflags) gst_glib_la_LIBADD = $(ALL_LIBS) libgst-gobject.la ../../lib-src/library.la gst_glib_la_DEPENDENCIES = libgst-gobject.la dist_gst_glib_la_SOURCES = gst-glib.c -nodist_gst_glib_la_SOURCES = libs.def BUILT_SOURCES = libs.def # Work around bug in Automake (or is it Libtool?) The gst-glib library is diff --git a/packages/gtk/Makefile.am b/packages/gtk/Makefile.am index c136f38..1d32719 100644 --- a/packages/gtk/Makefile.am +++ b/packages/gtk/Makefile.am @@ -21,7 +21,6 @@ moduleexec_LTLIBRARIES = gst-gtk.la gst_gtk_la_LDFLAGS = $(gst_module_ldflags) gst_gtk_la_LIBADD = $(ALL_LIBS) ../glib/libgst-gobject.la dist_gst_gtk_la_SOURCES = gst-gtk.c placer.c -nodist_gst_gtk_la_SOURCES = libs.def BUILT_SOURCES = libs.def dist_noinst_HEADERS = placer.h -- 1.7.12.rc0.129.g61b472e _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Stefano Lattarini
* snvprintf/Makefile.am (DIST_SUBDIRS): Don't explicitly define
to $(SUBDIRS), that's the default anyway. (MAINTAINERCLEANFILES): Don't clean the various Autotools-generated files, that goes against the GNU coding standards, which explicitly say "... more generally, 'make maintainer-clean' should not delete anything that needs to exist in order to run 'configure' and then begin to build the program". (aclocaldir): Remove definition; it's not used anyway, since the file 'snprintfv.m4' is not installed. (dist_noinst_DATA): Drop as useless, since the only file listed in there ('snprintfv.m4') is automatically distributed, being 'm4_included'd in the generated aclocal.m4. (nodist_noinst_HEADERS): Drop as useless, since the only file listed in there ('config.h') is automatically generated anyway by ./configure. Also remove some redundant comments and blank lines. * snvprintf/snvprintf/Makefile.am (AWK): Remove, it's never used. (MAINTAINERCLEANFILES): Don't clean the Automake-generated Makefile.in files, that goes against the GNU coding standards. Signed-off-by: Stefano Lattarini <[hidden email]> --- ChangeLog | 24 ++++++++++++++++++++++++ snprintfv/Makefile.am | 19 ------------------- snprintfv/snprintfv/Makefile.am | 2 -- 3 files changed, 24 insertions(+), 21 deletions(-) diff --git a/ChangeLog b/ChangeLog index 426b934..fdeec4b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,29 @@ 2012-08-20 Stefano Lattarini <[hidden email]> + svnprintf: modernize and improve its build system + + * snvprintf/Makefile.am (DIST_SUBDIRS): Don't explicitly define + to $(SUBDIRS), that's the default anyway. + (MAINTAINERCLEANFILES): Don't clean the various Autotools-generated + files, that goes against the GNU coding standards, which explicitly + say "... more generally, 'make maintainer-clean' should not delete + anything that needs to exist in order to run 'configure' and then + begin to build the program". + (aclocaldir): Remove definition; it's not used anyway, since the + file 'snprintfv.m4' is not installed. + (dist_noinst_DATA): Drop as useless, since the only file listed + in there ('snprintfv.m4') is automatically distributed, being + 'm4_included'd in the generated aclocal.m4. + (nodist_noinst_HEADERS): Drop as useless, since the only file + listed in there ('config.h') is automatically generated anyway + by ./configure. + Also remove some redundant comments and blank lines. + * snvprintf/snvprintf/Makefile.am (AWK): Remove, it's never used. + (MAINTAINERCLEANFILES): Don't clean the Automake-generated + Makefile.in files, that goes against the GNU coding standards. + +2012-08-20 Stefano Lattarini <[hidden email]> + build: don't use files with non-standard extensions in _SOURCES While they are still perfectly supported in mainline Automake, they diff --git a/snprintfv/Makefile.am b/snprintfv/Makefile.am index 430ff7a..75c10b1 100644 --- a/snprintfv/Makefile.am +++ b/snprintfv/Makefile.am @@ -24,30 +24,11 @@ ## uses the libopts library from AutoGen, you may include it under ## the same distribution terms used by the libopts library. -## Code: - ACLOCAL_AMFLAGS = -I ../build-aux AUTOMAKE_OPTIONS = gnits -## BEGIN GNU SMALLTALK LOCAL dist-hook: rm -rf $(distdir)/doc $(distdir)/tests SUBDIRS = snprintfv -## SUBDIRS = snprintfv doc tests -## END GNU SMALLTALK LOCAL - -DIST_SUBDIRS = $(SUBDIRS) - -MAINTAINERCLEANFILES = Makefile.in aclocal.m4 configure config.h.in \ - stamp-h.in - -nodist_noinst_HEADERS = config.h - -aclocaldir = $(datadir)/aclocal -dist_noinst_DATA = snprintfv.m4 - dist_noinst_SCRIPTS = gendoc.awk genproto commit - -# Makefile.am ends here - diff --git a/snprintfv/snprintfv/Makefile.am b/snprintfv/snprintfv/Makefile.am index e78596a..aa72113 100644 --- a/snprintfv/snprintfv/Makefile.am +++ b/snprintfv/snprintfv/Makefile.am @@ -29,9 +29,7 @@ AUTOMAKE_OPTIONS = gnits DISTCLEANFILES = compat.h compat.stamp -MAINTAINERCLEANFILES = Makefile.in -AWK = gawk GENPROTO = $(top_srcdir)/genproto GENPROTO_FLAGS = $(top_srcdir)/gendoc.awk GENPROTO_ENVIRONMENT = FORMAT=SNV_GNUC_PRINTF -- 1.7.12.rc0.129.g61b472e _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Stefano Lattarini
This change is a useless but harmless re-organization of some
build rules using stamp files. The real reason for such a change is that it will make transition to Automake-NG easier. * libgst/Makefile.am ($(srcdir)/match.stamp): No need to specify the '$(srcdir)/' explicitly, since the Smalltalk build system is assuming GNU make anyway (it was once necessary to avoid a bug with FreeBSD VPATH handling); so rename this target simply ... (match.stamp): ... like this. Also, depend on 'genbc$(EXEEXT)', rather than calling '$(MAKE)' recursively in the recipe to build it. Not only is this more efficient, it also avoid possible hanging of "make all" in the 'libgist' subdir when Automake-NG is used to bootstrap the Smalltalk build system. ($(srcdir)/prims.stamp): Likewise ... (prims.stamp): ... rename and modify the rule (with the dependency being on 'genprims$(EXEEXT)' this time). ($(srcdir)/vm.stamp): Likewise ... (vm.stamp): ... rename and modify the rule (with the dependency being on 'genvm$(EXEEXT)' this time). (dist-hook, STAMP_FILES): Remove, no more needed. (CLEANFILES): Add all the '*.stamp' files referenced above. Signed-off-by: Stefano Lattarini <[hidden email]> --- ChangeLog | 26 ++++++++++++++++++++++++++ libgst/Makefile.am | 29 ++++++++++------------------- 2 files changed, 36 insertions(+), 19 deletions(-) diff --git a/ChangeLog b/ChangeLog index fdeec4b..af14a82 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,31 @@ 2012-08-20 Stefano Lattarini <[hidden email]> + build: reorganize some stamp files' handling + + This change is a useless but harmless re-organization of some + build rules using stamp files. The real reason for such a change + is that it will make transition to Automake-NG easier. + + * libgst/Makefile.am ($(srcdir)/match.stamp): No need to specify + the '$(srcdir)/' explicitly, since the Smalltalk build system is + assuming GNU make anyway (it was once necessary to avoid a bug + with FreeBSD VPATH handling); so rename this target simply ... + (match.stamp): ... like this. Also, depend on 'genbc$(EXEEXT)', + rather than calling '$(MAKE)' recursively in the recipe to build + it. Not only is this more efficient, it also avoid possible + hanging of "make all" in the 'libgist' subdir when Automake-NG + is used to bootstrap the Smalltalk build system. + ($(srcdir)/prims.stamp): Likewise ... + (prims.stamp): ... rename and modify the rule (with the + dependency being on 'genprims$(EXEEXT)' this time). + ($(srcdir)/vm.stamp): Likewise ... + (vm.stamp): ... rename and modify the rule (with the dependency + being on 'genvm$(EXEEXT)' this time). + (dist-hook, STAMP_FILES): Remove, no more needed. + (CLEANFILES): Add all the '*.stamp' files referenced above. + +2012-08-20 Stefano Lattarini <[hidden email]> + svnprintf: modernize and improve its build system * snvprintf/Makefile.am (DIST_SUBDIRS): Don't explicitly define diff --git a/libgst/Makefile.am b/libgst/Makefile.am index 4393388..6082a35 100644 --- a/libgst/Makefile.am +++ b/libgst/Makefile.am @@ -16,6 +16,7 @@ include_HEADERS = gstpub.h gst.h lib_LTLIBRARIES = libgst.la EXTRA_PROGRAMS = genprims genbc genvm CLEANFILES = genprims$(EXEEXT) genbc$(EXEEXT) genvm$(EXEEXT) \ + prims.stamp match.stamp vm.stamp \ genbc-decl.stamp genbc-impl.stamp genpr-parse.stamp genvm-parse.stamp # definitions for libgst.la @@ -81,7 +82,6 @@ BUILT_SOURCES = prims.inl match.h builtins.inl vm.inl \ genvm-parse.c genvm-scan.c genvm-parse.h dist_noinst_DATA = valgrind.supp prims.def byte.def vm.def builtins.gperf -STAMP_FILES = prims.stamp match.stamp vm.stamp noinst_HEADERS = \ gstpriv.h files.h lex.h str.h re.h \ @@ -109,11 +109,10 @@ noinst_HEADERS = \ # Try to economize in the rebuilds, by avoiding unnecessary # changes to the timestamp of match.h -$(srcdir)/match.h: $(srcdir)/match.stamp +$(srcdir)/match.h: match.stamp @: -$(srcdir)/match.stamp: byte.def byte.c opt.c xlat.c - @$(MAKE) genbc$(EXEEXT) +match.stamp: byte.def byte.c opt.c xlat.c genbc$(EXEEXT) @echo "./genbc$(EXEEXT) $(srcdir)/byte.def $(srcdir)/byte.c $(srcdir)/opt.c $(srcdir)/xlat.c > match.h"; \ ./genbc$(EXEEXT) $(srcdir)/byte.def $(srcdir)/byte.c $(srcdir)/opt.c $(srcdir)/xlat.c > _match.h @if cmp _match.h $(srcdir)/match.h > /dev/null 2>&1; then \ @@ -122,18 +121,17 @@ $(srcdir)/match.stamp: byte.def byte.c opt.c xlat.c else \ mv _match.h $(srcdir)/match.h; \ fi - @echo timestamp > $(srcdir)/match.stamp + @echo timestamp > $@ # rules for invoking genprims # Try to economize in the rebuilds, by avoiding unnecessary # changes to the timestamp of prims.inl -$(srcdir)/prims.inl: $(srcdir)/prims.stamp +$(srcdir)/prims.inl: prims.stamp @: -$(srcdir)/prims.stamp: prims.def - @$(MAKE) genprims$(EXEEXT) +prims.stamp: prims.def genprims$(EXEEXT) @echo "./genprims$(EXEEXT) < $(srcdir)/prims.def > prims.inl"; \ ./genprims$(EXEEXT) < $(srcdir)/prims.def > _prims.inl @if cmp _prims.inl $(srcdir)/prims.inl > /dev/null 2>&1; then \ @@ -142,17 +140,16 @@ $(srcdir)/prims.stamp: prims.def else \ mv _prims.inl $(srcdir)/prims.inl; \ fi - @echo timestamp > $(srcdir)/prims.stamp + @echo timestamp > $@ # rules for invoking genvm # Try to economize in the rebuilds, by avoiding unnecessary # changes to the timestamp of vm.inl -$(srcdir)/vm.inl: $(srcdir)/vm.stamp +$(srcdir)/vm.inl: vm.stamp @: -$(srcdir)/vm.stamp: vm.def - @$(MAKE) genvm$(EXEEXT) +vm.stamp: vm.def genvm$(EXEEXT) @echo "./genvm$(EXEEXT) < $(srcdir)/vm.def | awk '{ /^#/ && gsub(/__oline__/,NR+1); print }' > vm.inl"; \ ./genvm$(EXEEXT) < $(srcdir)/vm.def | awk '{ /^#/ && gsub(/__oline__/,NR+1); print }' > _vm.inl @if cmp _vm.inl $(srcdir)/vm.inl > /dev/null 2>&1; then \ @@ -161,7 +158,7 @@ $(srcdir)/vm.stamp: vm.def else \ mv _vm.inl $(srcdir)/vm.inl; \ fi - @echo timestamp > $(srcdir)/vm.stamp + @echo timestamp > $@ # rules for invoking gperf # not fully idiot-proof but only to be run by maintainers @@ -180,9 +177,3 @@ $(srcdir)/vm.stamp: vm.def done builtins.inl: builtins.gperf - -dist-hook: - for i in $(STAMP_FILES); do \ - echo timestamp > $(distdir)/$$i; \ - done - -- 1.7.12.rc0.129.g61b472e _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Stefano Lattarini
Il 20/08/2012 21:56, Stefano Lattarini ha scritto:
> After these changes, the Smalltalk build system still works with > mainline Automake (and only with it), but will be much easier to > modify to convert it to Automake-NG. Can you send a "patch 6" with the remaining changes? I'm a bit scared of this: * libgst/Makefile.am ($(srcdir)/match.stamp): No need to specify the '$(srcdir)/' explicitly, since the Smalltalk build system is assuming GNU make anyway (it was once necessary to avoid a bug with FreeBSD VPATH handling); so rename this target simply ... (match.stamp): ... like this. Also, depend on 'genbc$(EXEEXT)', rather than calling '$(MAKE)' recursively in the recipe to build it. Not only is this more efficient, it also avoid possible hanging of "make all" in the 'libgist' subdir when Automake-NG is used to bootstrap the Smalltalk build system. Why should it hang "make all"? Isn't it a bug in Automake-NG? Paolo _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Stefano Lattarini
Il 20/08/2012 21:56, Stefano Lattarini ha scritto:
> After these changes, the Smalltalk build system still works with > mainline Automake (and only with it), but will be much easier to > modify to convert it to Automake-NG. > > -*-*-*- > > Stefano Lattarini (5): > build: use $(AM_CPPFLAGS), not $(INCLUDES) > build: prefer pattern rules over suffix rules > build: don't use files with non-standard extensions in _SOURCES > svnprintf: modernize and improve its build system > build: reorganize some stamp files' handling > > ChangeLog | 92 +++++++++++++++++++++++++++++++++++++++++ > doc/Makefile.am | 2 +- > libgst/Makefile.am | 31 +++++--------- > packages/glib/Makefile.am | 6 ++- > packages/gtk/Makefile.am | 1 - > packages/i18n/Makefile.am | 2 +- > snprintfv/Makefile.am | 19 --------- > snprintfv/snprintfv/Makefile.am | 2 - > 8 files changed, 109 insertions(+), 46 deletions(-) > I applied patches 1-4, thanks. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Paolo Bonzini-2
[Adding the Automake-NG list in CC]
On 08/21/2012 08:37 AM, Paolo Bonzini wrote: > Il 20/08/2012 21:56, Stefano Lattarini ha scritto: >> After these changes, the Smalltalk build system still works with >> mainline Automake (and only with it), but will be much easier to >> modify to convert it to Automake-NG. > > Can you send a "patch 6" with the remaining changes? > > I'm a bit scared of this: > > * libgst/Makefile.am ($(srcdir)/match.stamp): No need to specify > the '$(srcdir)/' explicitly, since the Smalltalk build system is > assuming GNU make anyway (it was once necessary to avoid a bug > with FreeBSD VPATH handling); so rename this target simply ... > (match.stamp): ... like this. Also, depend on 'genbc$(EXEEXT)', > rather than calling '$(MAKE)' recursively in the recipe to build > it. Not only is this more efficient, it also avoid possible > hanging of "make all" in the 'libgist' subdir when Automake-NG > is used to bootstrap the Smalltalk build system. > > Why should it hang "make all"? > Automake-NG. This limitation is the price to pay to allow us avoid an extra recursive make invocation per each Makefile using BUILT_SOURCES -- and that's definitely a price worth paying; however, I agree it shouldn't silently cause hanging or fork bombs; we should detect and diagnose the situation. I'll try to cook something up in the next days. > Isn't it a bug in Automake-NG? > It is just a limitation. But it is a bug that the breakage is silent instead of being diagnosed. Thanks, Stefano _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Paolo Bonzini-2
On 08/21/2012 08:37 AM, Paolo Bonzini wrote:
> Il 20/08/2012 21:56, Stefano Lattarini ha scritto: >> After these changes, the Smalltalk build system still works with >> mainline Automake (and only with it), but will be much easier to >> modify to convert it to Automake-NG. > > Can you send a "patch 6" with the remaining changes? > First of all, there still a stray use of '$(INCLUDES)' that I missed to convert in my earlier patches. The patch below takes care of that. Sorry for the noise, Stefano -----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<----- From b33b57b68023c5cc203e154360c1014792aae2c7 Mon Sep 17 00:00:00 2001 Message-Id: <[hidden email]> From: Stefano Lattarini <[hidden email]> Date: Tue, 21 Aug 2012 11:00:47 +0200 Subject: [PATCH] build: once more, use $(AM_CPPFLAGS), not $(INCLUDES) The latter is a long-deprecated and obsolescent alias for the former. * packages/gtk/Makefile.am (INCLUDES): Rename ... (AM_CPPFLAGS): ... like this Signed-off-by: Stefano Lattarini <[hidden email]> --- ChangeLog | 9 +++++++++ packages/gtk/Makefile.am | 6 +++++- 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index af14a82..4ad1f6a 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2012-08-21 Stefano Lattarini <[hidden email]> + + build: once more, use $(AM_CPPFLAGS), not $(INCLUDES) + + The latter is a long-deprecated and obsolescent alias for the former. + + * packages/gtk/Makefile.am (INCLUDES): Rename ... + (AM_CPPFLAGS): ... like this + 2012-08-20 Stefano Lattarini <[hidden email]> build: reorganize some stamp files' handling diff --git a/packages/gtk/Makefile.am b/packages/gtk/Makefile.am index 1d32719..3229e31 100644 --- a/packages/gtk/Makefile.am +++ b/packages/gtk/Makefile.am @@ -29,7 +29,11 @@ testplacer_SOURCES = testplacer.c testplacer_LDADD = $(GLIB_LIBS) $(GTK_LIBS) -INCLUDES = -I$(top_srcdir)/libgst -I$(top_srcdir)/lib-src -I$(top_srcdir)/libltdl -I$(top_srcdir)/packages/glib +AM_CPPFLAGS = \ + -I$(top_srcdir)/libgst \ + -I$(top_srcdir)/lib-src \ + -I$(top_srcdir)/libltdl \ + -I$(top_srcdir)/packages/glib AM_CFLAGS = $(GLIB_CFLAGS) $(GTK_CFLAGS) $(PANGO_CFLAGS) $(ATK_CFLAGS) -- 1.7.12 _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Il 21/08/2012 11:02, Stefano Lattarini ha scritto:
> First of all, there still a stray use of '$(INCLUDES)' that I missed to > convert in my earlier patches. The patch below takes care of that. > > Sorry for the noise, > Stefano > > -----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<----- > > From b33b57b68023c5cc203e154360c1014792aae2c7 Mon Sep 17 00:00:00 2001 > Message-Id: <[hidden email]> > From: Stefano Lattarini <[hidden email]> > Date: Tue, 21 Aug 2012 11:00:47 +0200 > Subject: [PATCH] build: once more, use $(AM_CPPFLAGS), not $(INCLUDES) > > The latter is a long-deprecated and obsolescent alias for the former. > > * packages/gtk/Makefile.am (INCLUDES): Rename ... > (AM_CPPFLAGS): ... like this > > Signed-off-by: Stefano Lattarini <[hidden email]> I had already noticed it when applying the patches (because I first backported them to the 3.2 branch, and then merged stable-3.2 into master). I'll push shortly. No problem, thanks for the fixes. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Stefano Lattarini
On 08/21/2012 11:02 AM, Stefano Lattarini wrote:
> On 08/21/2012 08:37 AM, Paolo Bonzini wrote: >> Il 20/08/2012 21:56, Stefano Lattarini ha scritto: >>> After these changes, the Smalltalk build system still works with >>> mainline Automake (and only with it), but will be much easier to >>> modify to convert it to Automake-NG. >> >> Can you send a "patch 6" with the remaining changes? >> > First of all, there still a stray use of '$(INCLUDES)' that I missed to > convert in my earlier patches. The patch below takes care of that. > > [SNIP] > -----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<----- From 5c4521e51cf21f361d3500e32b6c17c565aca3b1 Mon Sep 17 00:00:00 2001 Message-Id: <[hidden email]> From: Stefano Lattarini <[hidden email]> Date: Tue, 21 Aug 2012 10:13:26 +0200 Subject: [PATCH] build: support and require Automake-NG * configure.ac (AC_PREREQ): Require Autoconf version >= 2.65, since that is the minimal version supported by Automake-NG. (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. * 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". * .gitignore: Ignore all the '.am/' directories everywhere; it's used internally by some Automake-NG generated rules. * build-aux/.gitignore: Ignore the 'am-ng/' directory; it's used by Automake-NG to install makefile fragments used by its generated Makefiles. Signed-off-by: Stefano Lattarini <[hidden email]> --- .gitignore | 1 + ChangeLog | 24 ++++++++++++++++++++++++ Makefile.am | 3 ++- build-aux/.gitignore | 1 + configure.ac | 6 +++++- 5 files changed, 33 insertions(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index 504cfce..a92d716 100644 --- a/.gitignore +++ b/.gitignore @@ -6,6 +6,7 @@ *.lo *.o *.star +.am/ .svn .deps .dirstamp diff --git a/ChangeLog b/ChangeLog index 4ad1f6a..8b8f79f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,29 @@ 2012-08-21 Stefano Lattarini <[hidden email]> + build: support and require Automake-NG + + * configure.ac (AC_PREREQ): Require Autoconf version >= 2.65, + since that is the minimal version supported by Automake-NG. + (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. + * 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". + * .gitignore: Ignore all the '.am/' directories everywhere; it's + used internally by some Automake-NG generated rules. + * build-aux/.gitignore: Ignore the 'am-ng/' directory; it's used by + Automake-NG to install makefile fragments used by its generated + Makefiles. + +2012-08-21 Stefano Lattarini <[hidden email]> + build: once more, use $(AM_CPPFLAGS), not $(INCLUDES) The latter is a long-deprecated and obsolescent alias for the former. diff --git a/Makefile.am b/Makefile.am index 732a72c..8159dd1 100644 --- a/Makefile.am +++ b/Makefile.am @@ -16,7 +16,8 @@ # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. # Automake requirements -AUTOMAKE_OPTIONS = gnu 1.11 dist-xz +AUTOMAKE_OPTIONS = ng gnu 1.12a +AM_DIST_FORMATS = gzip xz ACLOCAL_AMFLAGS = -I build-aux PACKAGE=smalltalk diff --git a/build-aux/.gitignore b/build-aux/.gitignore index d79bca9..df920ab 100644 --- a/build-aux/.gitignore +++ b/build-aux/.gitignore @@ -1,3 +1,4 @@ +am-ng/ compile config.guess config.sub diff --git a/configure.ac b/configure.ac index c040d4c..d509670 100644 --- a/configure.ac +++ b/configure.ac @@ -6,7 +6,7 @@ dnl with this software. dnl Process this file with autoconf to produce a configure script. dnl 2.63 needed by testsuite, actually -AC_PREREQ(2.63) +AC_PREREQ(2.65) AC_INIT([GNU Smalltalk], 3.2.90, [hidden email], smalltalk, [http://smalltalk.gnu.org/]) MAINTAINER="[hidden email]" @@ -24,6 +24,10 @@ GST_PROG_GAWK AM_INIT_AUTOMAKE AC_CANONICAL_HOST +# Avoid spurious failures with Automake-NG. +AC_SUBST([AM_VARTYPOS_WHITELIST], + ['RELOC_LDFLAGS LIBFFI_EXECUTABLE_LDFLAGS']) + if test -d $srcdir/.git; then GIT_REVISION=-`git rev-parse --short HEAD 2>/dev/null || echo git` else -- 1.7.12 _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Il 21/08/2012 11:22, Stefano Lattarini ha scritto:
Cool, let's look at it one by one. > * configure.ac (AC_PREREQ): Require Autoconf version >= 2.65, > since that is the minimal version supported by Automake-NG. This is good. > (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? Also, this is different from all other configuration mechanisms; it would be nicer to have it as an Automake-provided AM_* macro, or a Makefile.am definition. > * 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? And perhaps add support for AM_DIST_FORMATS in mainline Automake? > * .gitignore: Ignore all the '.am/' directories everywhere; it's > used internally by some Automake-NG generated rules. > * build-aux/.gitignore: Ignore the 'am-ng/' directory; it's used by > Automake-NG to install makefile fragments used by its generated > Makefiles. This is not a problem, of course. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
[Adding the Automake and Automake-NG lists in CC]
Reference: <http://lists.gnu.org/archive/html/help-smalltalk/2012-08/msg00032.html> On 08/21/2012 11:28 AM, Paolo Bonzini wrote: > Il 21/08/2012 11:22, Stefano Lattarini ha scritto: > > Cool, let's look at it one by one. > >> * configure.ac (AC_PREREQ): Require Autoconf version >= 2.65, >> since that is the minimal version supported by Automake-NG. > > This is good. > >> (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? > 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. > 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! It's just that, in Automake-NG as in mainline Automake, definitions of make variables can also be specified through AC_SUBST calls, which is very handy in case those definitions must be propagated in all the Makefile.am files of the project -- as is the case here. If you don't mind duplication, you could simply copy the AM_VARTYPOS_WHITELIST = LIBFFI_EXECUTABLE_LDFLAGS RELOC_LDFLAGS definition by hand in all the affected Makefiles. As you prefer. >> * 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? > 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. > 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. >> * .gitignore: Ignore all the '.am/' directories everywhere; it's >> used internally by some Automake-NG generated rules. >> * build-aux/.gitignore: Ignore the 'am-ng/' directory; it's used by >> Automake-NG to install makefile fragments used by its generated >> Makefiles. > > This is not a problem, of course. > > Paolo Thanks, Stefano _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
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 _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Free forum by Nabble | Edit this page |