Re: My "forks" of GNU projects to test Automake-NG

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: My "forks" of GNU projects to test Automake-NG

Stefano Lattarini
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).
>>
Done for GNU Smalltalk as well:

  <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
Reply | Threaded
Open this post in threaded view
|

Re: My "forks" of GNU projects to test Automake-NG

Holger Freyther
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
Reply | Threaded
Open this post in threaded view
|

Re: My "forks" of GNU projects to test Automake-NG

Stefano Lattarini
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
Reply | Threaded
Open this post in threaded view
|

Re: My "forks" of GNU projects to test Automake-NG

Paolo Bonzini-2
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
Reply | Threaded
Open this post in threaded view
|

Re: My "forks" of GNU projects to test Automake-NG

Stefano Lattarini
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.
>
Will do in a follow-up patch series, soon enough.

> 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
Reply | Threaded
Open this post in threaded view
|

[PATCH 0/5] build: refactoring and preparations for Automake-NG

Stefano Lattarini
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
Reply | Threaded
Open this post in threaded view
|

[PATCH 1/5] build: use $(AM_CPPFLAGS), not $(INCLUDES)

Stefano Lattarini
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
Reply | Threaded
Open this post in threaded view
|

[PATCH 2/5] build: prefer pattern rules over suffix rules

Stefano Lattarini
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
Reply | Threaded
Open this post in threaded view
|

[PATCH 3/5] build: don't use files with non-standard extensions in _SOURCES

Stefano Lattarini
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
Reply | Threaded
Open this post in threaded view
|

[PATCH 4/5] svnprintf: modernize and improve its build system

Stefano Lattarini
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
Reply | Threaded
Open this post in threaded view
|

[PATCH 5/5] build: reorganize some stamp files' handling

Stefano Lattarini
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
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 0/5] build: refactoring and preparations for Automake-NG

Paolo Bonzini-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 0/5] build: refactoring and preparations for Automake-NG

Paolo Bonzini-2
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
Reply | Threaded
Open this post in threaded view
|

[BUG] Possible hang of make with tricky use of BUILT_SOURCES (was: Re: [PATCH 0/5] build: refactoring and preparations for Automake-NG)

Stefano Lattarini
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"?
>
Because of a limitation in how BUILT_SOURCES are handled in
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
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 0/5] build: refactoring and preparations for Automake-NG

Stefano Lattarini
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
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 0/5] build: refactoring and preparations for Automake-NG

Paolo Bonzini-2
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
Reply | Threaded
Open this post in threaded view
|

[PATCH] build: support and require Automake-NG (was: Re: [PATCH 0/5] build: refactoring and preparations for Automake-NG)

Stefano Lattarini
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]
>
And here is the patch that converts Smalltalk to Automake-NG, finally:

-----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
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] build: support and require Automake-NG

Paolo Bonzini-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] build: support and require Automake-NG

Stefano Lattarini
[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?
>
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.

> 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?
>
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.

> 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
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] build: support and require Automake-NG

Paolo Bonzini-2
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
123