Re: My "forks" of GNU projects to test Automake-NG
Locked
123
123
Re: Automake vs. Automake-NG
 
|
On 08/21/2012 06:30 PM, Ralf Corsepius wrote:
> On 08/21/2012 06:01 PM, Paolo Bonzini wrote: >> >>>> Ok. So the question I'd like you to ask yourself are: > >>>> This needs to be done for each NG-NEWS items. It could improve the >>>> existing users of Automake, and reduce the size of NG-NEWS. Both of >>>> which are good things! >>>> >>> And I've done that already where possible and reasonable. For example, >>> the 'silent-rules' option is now active by default, and the tags-related >>> rules have been reworked and improved. > > Well, from a distro maintainer's view this a bad idea. > > In Fedora we already are pushing around package maintainers to pass > appropriate options to configure to revert this change, because silent > make rules are non-suitable for building distros in batch jobs. > The use of 'silent-rules' (even now that is implicit) *don't* cause the make output to become more silent* by default*. For that, the maintainer has to call 'AM_SILENT_RULES([yes])' *explicitly* in configure.ac (and the automake manual even advise against it IIRC). The only change is that the *user* will be allowed to *require* a more quiet output from make if he wants to (at least for the Automake provided recipes), without the package maintainer being forced to cater to that. That's all. That has been explained to you few times already in the past, unless I'm mistaken (and I doubt I am in this case). > Making it the default in all automake-ng based packages, would escalate > this already unpleasant situation. > It will be the default in Automake 1.13 already. But the packages whose output was verbose by default before will still have it that way, without *any* need of extra tweaking or tinkering. >>>> But CMake is not almost the same as Automake, Automake-NG is. >>>> Automake-NG is not Automake 2.0, > > In other words, it is a fork with a backward incompatible API, > a probably backward-incompatible runtime environment and a different > target audience. > > Somewhat exaggerated: Yet another tool the world has not been > waiting for. > hoping to obtain with it? Stefano _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: Automake vs. Automake-NG
|
|
In reply to this post by Paolo Bonzini-2
On 08/21/2012 06:01 PM, Paolo Bonzini wrote:
> >>> Ok. So the question I'd like you to ask yourself are: >>> >>> * Why does it make sense to request manual declaration of 'SUFFIXES'? >>> * Does it make sense to do so in Automake, too? > > And another question: > > * Alternatively, could Automake-NG suggest converting suffix > rules to pattern rules > > so that the extra SUFFIXES entries are not necessary > anymore? Or even do that automatically in the Makefile.am -> > Makefile.in conversion? > Oh no; Automake-NG does not specially recognize nor handle suffix rules anymore. It just passes them through. In fact, I'm deliberately trying to remove automake runtime processing whenever possible, moving it to GNU make runtime instead. In this case, since GNU make can with pattern rules itself, without any extra '.SUFFIXES:' shenanigan, I just want to suggest to use pattern rules where possible, and to explicitly initialize $(SUFFIXES) otherwise (for example, when Gnulib-generated Makefile.am are used, since they are tailored to Automake-NG and thus use suffix rules). > [SNIP] >>> All I'm saying is, do not release Automake-NG for public use until >>> Automake can warn of all incompatible uses, or almost all. >>> >> As I said, I don't believe this would be actually doable. > > Looking at GNU Smalltalk, I se, ase possible action items for Automake: > > * warn for INCLUDES (vs. AM_CPPFLAGS) > Easy to do, and will do. Maybe even for Automake 1.12.4 (it has been deprecated in the documentation for ages already). > * warn for unknown *_XYZFLAGS variables > I'm still unconvinced it would be a good idea to introduce this incompatibility in Automake just for the sake of simplifying transition to Automake-NG, sorry. > * warn for treating _SOURCES entries with a custom unknown user > extension as if they were header files > Ditto. > (btw, why doesn't CAIRO_CFLAGS raise a warning)? > Probably because it's still handled at Automake runtime rather than at make runtime. > And as possible action items for Automake-NG: > > * warn for suffix rules or otherwise do something about them > That would prevent an easy use of Automake-NG with Gnulib-generated Makefile.am files. Causing cascade issues in all of coreutils, m4, grep, ... A simple explanation in NG-NEWS will have to be enough. > * fix BUILD_SOURCES fork bomb, perhaps warn about it in advance (though > I'm not sure I understood the root cause here) > Absolutely. Erroring out and making you tweak your build system is acceptable, fork-bombing is not. >>> You have to evaluate each case separately of course, but a single >>> project has already shown several cases where Automake _could_ be >>> improved this way. >>> >> Are you referring to the Smalltalk "port"? If yes, I'm not seeing your >> point honestly. Care to elaborate? > > See above. > We'll have to agree to differ in most respects then. Sorry. Best regards, Stefano _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [Automake-NG] Automake vs. Automake-NG
|
|
In reply to this post by Stefano Lattarini
On Tue, 21 Aug 2012, Stefano Lattarini wrote:
>> > Maybe we just need good PR and "advertisment" in this. The python > developers has managed to make a 3.0 release incompatible with the 2.x > series, because they've been very clear and vocal about the breakage, > and have been for a long time. We might need to learn from them here, > and maybe we'll succeed. Any suggestion? It is not clear that there is any significant use of Python 3 at all. It is easier to create an subtly incompatible version with more features but difficult to get users to transition to it when older versions are working "fine" and are still supported. This discussion thread has really gotten out of hand. Why has it spilled onto two more discussion lists (automake and help-smalltalk)? If it had been held only on the automake list then there would be less harm to the free software world since everyone on the automake-ng list is surely already on the automake list. Bob -- Bob Friesenhahn [hidden email], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [Automake-NG] Automake vs. Automake-NG
|
|
On 08/21/2012 07:36 PM, Bob Friesenhahn wrote:
> On Tue, 21 Aug 2012, Stefano Lattarini wrote: >>> >> Maybe we just need good PR and "advertisment" in this. The python >> developers has managed to make a 3.0 release incompatible with the 2.x >> series, because they've been very clear and vocal about the breakage, >> and have been for a long time. We might need to learn from them here, >> and maybe we'll succeed. Any suggestion? > > It is not clear that there is any significant use of Python 3 at all. > compatible with Python 3, or are in the process of being made so. Once that is completed, a new program or library that wants to target only python 3 will be able to do so while still being able to use all the important libraries that have made the fortune of python. That sounds like a success to me. But that is more an impression rather than a reasoned conclusion coming from hard data. Do you maybe have data or references that shows my impression is wrong? > It is easier to create an subtly incompatible version with more > features but difficult to get users to transition to it when older > versions are working "fine" and are still supported. > > This discussion thread has really gotten out of hand. Why has > it spilled onto two more discussion lists (automake and help-smalltalk)? > Because all of us have forgotten to drop the 'CC:' to that list (where the discussion originated from) at a proper time :-( > If it had been held only on the automake list then there would be less > harm to the free software world > Which harm are you referring to? Honest question. The fact that me and Paolo disagree (politely!) on some issues should not be taken as some sort of sign that the community is "split" or "quarrelsome". In fact, I highly value his input, and his opinion as well (even where it differs from mine). > since everyone on the automake-ng list is surely already on the > automake list. > That is true; but since the discussion pertains to Automake-NG as well, it seemed a good idea to me to have it registered in the Automake-NG archives too. Regards, Stefano _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
|
|
In reply to this post by Stefano Lattarini
Il 21/08/2012 19:14, Stefano Lattarini ha scritto:
>> > * warn for unknown *_XYZFLAGS variables >> > > I'm still unconvinced it would be a good idea to introduce this > incompatibility in Automake just for the sake of simplifying > transition to Automake-NG, sorry. > >> > * warn for treating _SOURCES entries with a custom unknown user >> > extension as if they were header files >> > > Ditto. Uhm, either they are good warnings for both, or pointless incompatibilities for both... You had almost convinced me of the former! :P Paolo _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: Automake vs. Automake-NG
|
|
On 08/21/2012 08:51 PM, Paolo Bonzini wrote:
> Il 21/08/2012 19:14, Stefano Lattarini ha scritto: >>>> * warn for unknown *_XYZFLAGS variables >>>> >> I'm still unconvinced it would be a good idea to introduce this >> incompatibility in Automake just for the sake of simplifying >> transition to Automake-NG, sorry. >> >>>> * warn for treating _SOURCES entries with a custom unknown user >>>> extension as if they were header files >>>> >> Ditto. > > Uhm, either they are good warnings for both, or pointless > incompatibilities for both... You had almost convinced me > of the former! :P > too, but that would cause extra headaches and incompatibilities. Not much serious (so that they are OK tackle for someone ready to jump on the NG wagon), but noisy and annoying enough to make them unpalatable as an addition to mainline Automake. Regards, Stefano _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
|
|
On Tue, Aug 21, 2012 at 9:10 PM, Stefano Lattarini
<[hidden email]> wrote: > On 08/21/2012 08:51 PM, Paolo Bonzini wrote: >> Il 21/08/2012 19:14, Stefano Lattarini ha scritto: >>>>> * warn for unknown *_XYZFLAGS variables >>>>> >>> I'm still unconvinced it would be a good idea to introduce this >>> incompatibility in Automake just for the sake of simplifying >>> transition to Automake-NG, sorry. >>> >>>>> * warn for treating _SOURCES entries with a custom unknown user >>>>> extension as if they were header files >>>>> >>> Ditto. >> >> Uhm, either they are good warnings for both, or pointless >> incompatibilities for both... You had almost convinced me >> of the former! :P >> > No, I mean, we might make the warnings stricter for mainline Automake > too, but that would cause extra headaches and incompatibilities. Not > much serious (so that they are OK tackle for someone ready to jump on > the NG wagon), but noisy and annoying enough to make them unpalatable > as an addition to mainline Automake. Yes, I understood. But if they are noisy and annoying, they are _wrong_ to have in Automake-NG, no matter how it lets you simplify things. On the other hand, you almost convinced me that they are _good_ warnings, and in general cryptic behavior is one of the common criticisms of Autotools; so we need more warnings, not less. By implementing the warnings in mainline (1.13) you could hear user's opinions even if they do not jump on NG, and perhaps help people find a couple of bugs. If you get too many complaints, you can either make them opt-in (-Wsomething) and review your NG plans, or refine the warnings. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [PATCH 0/5] build: refactoring and preparations for Automake-NG
|
|
In reply to this post by Stefano Lattarini
Reference:
<http://lists.gnu.org/archive/html/help-smalltalk/2012-08/msg00021.html> On 08/20/2012 09:56 PM, Stefano Lattarini wrote: > 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(-) > GNU Smalltalk repository ... Regards, Stefano _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [PATCH 0/5] build: refactoring and preparations for Automake-NG
|
|
Il 06/09/2012 11:31, Stefano Lattarini ha scritto:
> Any news on this series? It seems it hasn't been applied in the official > GNU Smalltalk repository ... I need to test and push. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Re: [PATCH 0/5] build: refactoring and preparations for Automake-NG
|
|
On 09/06/2012 11:43 AM, Paolo Bonzini wrote:
> Il 06/09/2012 11:31, Stefano Lattarini ha scritto: >> Any news on this series? It seems it hasn't been applied in the official >> GNU Smalltalk repository ... > > I need to test and push. > Ah, OK. I feared it might have been forgotten. If that's not the case, no need hurry. Thanks, Stefano _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
«
Return to Gnu
|
1 view|%1 views
| Free forum by Nabble | Edit this page |