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

On 08/21/2012 12:20 PM, Paolo Bonzini wrote: But there is an important difference: Automake-NG is *not* the next
version of Automake, it is the "Next Generation": it's not meant to
be merged into the Automake code base, nor to supersede Automake,
because the two projects have different "mission statement":

  - Automake: allow the user to write Makefiles portable to different
    systems *and* make implementation, and help him to *avoid* using
    GNU make specific features would hurt portability,

  - Automake-NG: allow the user to write Makefiles portable to
    different systems *but* tailored for modern GNU make, and allow
    them to take *full advantage* of GNU make features whenever
    possible (which is less than we'd like, due to the code base
    and design inherited from mainline Automake).

Automake-NG might finally supersede Automake when *and if* the great
majority of developers using the the Autotools agree that porting to
non-GNU make is not worth anymore; but that will not mean that
Automake has been merged into Automake-NG, merely that a change in
portability requirements have made it obsolete.  That's very important
to understand.

> Another choice is to find AC_SUBSTed variables that end with LDFLAGS,
> CPPFLAGS, CFLAGS, etc., and whitelist them automatically.  It can be
> done in m4, from Automake-NG's macros.
>
I'm still not sold on this.  What if a user have "foobar" in
bin_PROGRAMS, and then do something like this in its configure.ac:

  if something; then
    AC_SUBST([foobar_LDFLAGS], [-lzap])
  else
    AC_SUBST([foobaz_LDFLAGS], [-lmu])
  fi

I think a warning about "no program or library named 'foobaz'" is
still warranted here.
But, as I've stressed above, Automake-NG is *not* going to be merged
in mainline Automake, ever.  The fork has not been thought with that
aim in mind.  The two projects are meant to co-exists as long as there
still are significant client packages that wants to work with non-GNU
make implementations (and thus need mainline Automake); when *and if*
this portability requirement is finally dropped, Automake will just
be abandoned -- not subsumed, not explicitly obsolete; we'll just stop
developing and bug-fixing it.

>>> 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.
>
(Or I'll accept one, if someone want to beat me at it ;-)

> Nice.
>
> Paolo
>

Hope I've clarified the situation a bit.

Regards,
  Stefano

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Il 21/08/2012 14:44, Stefano Lattarini ha scritto:
Understood.  On the other hand, Automake-NG should strive as much as
possible for backwards-compatibility, so that the obsolescence of
Automake comes naturally, and requires as little manual intervention as
possible.  If one day Automake-NG 0.99 "happens to become" Automake 2.0,
people should not notice.

For this reason, as much deprecation as possible should occur in both
code bases.  Looking at the GNU Smalltalk patches you sent:

* using INCLUDES instead of AM_CPPFLAGS could be deprecated loudly in
Automake 1.13

* pattern rules should be advertised over suffix rules in Automake-NG,
but suffix rules should be accepted

* files with non-standard extensions in _SOURCES should be warned about
in Automake 1.13

This way, people will slowly convert their code bases to the style
preferred for Automake-NG.  If the only point that remains is the
variable typo detection, that's fine.  But all semantic changes should
be suggested by (non-NG) Automake for developer to even consider taking
Automake-NG seriously, IMHO.

I apologize for the useless complaint if you are already doing this;
please let me explain my worries.  The lack of a clear upgrading path
(and bugs in autoupdate, which took a while to get right) was what
caused problems in Autoconf 2.50-2.53, compounded by the lack of
awareness about Autoconf/m4 best practices.

Now the latter has not changed much; try-and-see-debugging is still in
wide use for Autotools (and that is the reason for so many
Autotools-related flamewars).  But (non-NG) Automake is Perl, not m4.
It can provide good error messages and a clear upgrading path.  Please
_do_ provide it.

Yeah, and that's why I initially proposed whitelisting all-uppercase
variables.  It's a convention, but it's a common convention.  Programs
are rarely if-ever all-uppercase.  Libraries never are due to the _a or
_la suffix.

> Hope I've clarified the situation a bit.

Me too. :)

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 08/21/2012 02:59 PM, Paolo Bonzini wrote: This is not going to happen; some people have strongly objected to such
possibility of a final "takover" of Automake-NG over Automake (and I'm
speaking of people who have been very interested and helpful in the
Automake-NG development so far).  I've come to agree with them in this
respect.

Bottom line is: we want to make it clear that Automake-NG is something
different from Automake -- albeit mostly compatible, deliberately, and
with very, very similar design and API; and that a transition between
the two won't be seamless -- albeit it is expected to be simple and to
involve only little churn.

I'm now writing a new little section to the Automake-NG manual to try to
make this clear and explicit; should be ready today or tomorrow.

> For this reason, as much deprecation as possible should occur in both
> code bases.  Looking at the GNU Smalltalk patches you sent:
>
> * using INCLUDES instead of AM_CPPFLAGS could be deprecated loudly in
> Automake 1.13
>
This is a good idea.  Want to attempt a patch?  Otherwise, I will write
it myself in the next days.

> * pattern rules should be advertised over suffix rules in Automake-NG,
> but suffix rules should be accepted
>
They are!  It's actually simpler to accept them rather than to reject
them, since doing the latter would entail more Automake-runtime
processing, which we want to avoid.  The only important difference is
that you'll have to declare '.SUFFIXES:' yourself, as Automake-NG do
not do it automatically for you anymore (a change which I now see is
not listed in the NG-NEWS file; will fix shortly).

> * files with non-standard extensions in _SOURCES should be warned about
> in Automake 1.13
>
Ah, but they are still supported -- it's only that their semantic has
been simplified in Automake-NG, to dump most of the processing on the
shoulders of GNU make.  Banning them would altogether would not be
helpful, and would prevent useful use cases like this:

  %o: %.lisp
  [Our clever rule to compile common lisp to machine code]

  bin_PROGRAMS = foo

  foo_SOURCES = main.lisp opt-parse.lisp features.lisp

> This way, people will slowly convert their code bases to the style
> preferred for Automake-NG.  If the only point that remains is the
> variable typo detection, that's fine.  But all semantic changes should
> be suggested by (non-NG) Automake for developer to even consider taking
> Automake-NG seriously, IMHO.
>
I disagree.  After all, people are taking CMake seriously, and that
is hardly compatible with Automake.  What we need the developer to
understand is that:

  - Automake-NG is *not* Automake 2.0, not is meant to become that;
    they must be prepared to deal with incompatibilities.

  - Automake-NG has however *a lot* in common with Automake, so the
    required porting effort will be small; even in the worst scenario,
    significantly smaller than (say) any Automake -> Cmake switch

  - Also, for the same reason, most of the Automake-related knowledge
    an experience a developer might have will be easy recycled into
    Automake-NG.  It's like switching from perl4 to perl5, not from
    perl to python.

> I apologize for the useless complaint if you are already doing this;
>
Please don't.  I find this exchange very useful and informative for my
own understanding of the status and direction of Automake-NG.

> please let me explain my worries.  The lack of a clear upgrading path
> (and bugs in autoupdate, which took a while to get right) was what
> caused problems in Autoconf 2.50-2.53, compounded by the lack of
> awareness about Autoconf/m4 best practices.
>
The difference here is that people *should* understand that Automake-NG
is not meant as an "Automake 2.0", but as a new projects with different
aims, and thus different idioms, usages, strengths and weaknesses.

Lots and deliberate similarities as well, but which should not shadow
the differences and make them downplayed and forgotten

This is the point I want to drive home, to avoid another transition
debacle like the Autoconf one.  Here's an honest question: if
Autoconf 2.50 has been called "Autoconf-NG 3.0 alpha", and finally
graduated to "Autoconf-NG 3.0" with what we know as Autoconf 2.60,
do you think the transition would have been less painful (I really
hope the answer is yes, of course).

> Now the latter has not changed much; try-and-see-debugging is still in
> wide use for Autotools (and that is the reason for so many
> Autotools-related flamewars).  But (non-NG) Automake is Perl, not m4.
>
Sometimes I'm not anymore sure which is better, honestly :-)

> It can provide good error messages and a clear upgrading path.  Please
> _do_ provide it.
>
I hope to finally do that, but it will be in a form of a how-to and a
set of recipes rather than an attempt to shoehorn Automake-NG semantics
back to Automake.  The latter sounds too slow and too dangerious.
For the moment, we'll agree to differ on this, I say :-)
No hard feelings I hope.

>> Hope I've clarified the situation a bit.
>
> Me too. :)
>
You have.  I hope I've taken a step further in my side of the
clarification ;-)

Thanks,
  Stefano

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 21/08/2012 07:32, Stefano Lattarini wrote:
> do you think the transition would have been less painful (I really
> hope the answer is yes, of course).

From a distribution point of view... it wouldn't have been any less
painful. It would have meant we'd have even more packages using
autoconf-2.1 than we still have right now....

--
Diego Elio Pettenò — Flameeyes
[hidden email] — http://blog.flameeyes.eu/

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Il 21/08/2012 16:32, Stefano Lattarini ha scritto:
> Bottom line is: we want to make it clear that Automake-NG is something
> different from Automake -- albeit mostly compatible, deliberately, and
> with very, very similar design and API; and that a transition between
> the two won't be seamless -- albeit it is expected to be simple and to
> involve only little churn.

Ok.

>> * using INCLUDES instead of AM_CPPFLAGS could be deprecated loudly in
>> Automake 1.13
>>
> This is a good idea.  Want to attempt a patch?  Otherwise, I will write
> it myself in the next days.

I doubt I have time, unfortunately. :(

>> * pattern rules should be advertised over suffix rules in Automake-NG,
>> but suffix rules should be accepted
>>
> They are!  It's actually simpler to accept them rather than to reject
> them, since doing the latter would entail more Automake-runtime
> processing, which we want to avoid.  The only important difference is
> that you'll have to declare '.SUFFIXES:' yourself, as Automake-NG do
> not do it automatically for you anymore (a change which I now see is
> not listed in the NG-NEWS file; will fix shortly).

Ok.  So the question I'd like you to ask yourself are:

* Why does it make sense to request manual declaration of '.SUFFIXES:'?

* Does it make sense to do so in Automake, too?

* Even if not, could a missing '.SUFFIXES:' hide bugs?  Would you
consider adding a warning for missing ".SUFFIXES" in Automake, too?

This needs to be done for each NG-NEWS items.  It could improve the
existing users of Automake, and reduce the size of NG-NEWS.  Both of
which are good things!

>> This way, people will slowly convert their code bases to the style
>> preferred for Automake-NG.  If the only point that remains is the
>> variable typo detection, that's fine.  But all semantic changes should
>> be suggested by (non-NG) Automake for developer to even consider taking
>> Automake-NG seriously, IMHO.
>>
> I disagree.  After all, people are taking CMake seriously, and that
> is hardly compatible with Automake.

But CMake is not almost the same as Automake, Automake-NG is.
Automake-NG is not Automake 2.0, but Automake 2.0 _could_ have the same
user interface as Automake-NG.  What I'm asking is, please consider a
deprecation path in Automake for _every_ _single_ difference between it
and Automake-NG.

If you rewrote Automake in m4 (only partly kidding), I wouldn't have had
these objections.  But changing the name doesn't change the perception.

People won't. :)

> This is the point I want to drive home, to avoid another transition
> debacle like the Autoconf one.  Here's an honest question: if
> Autoconf 2.50 has been called "Autoconf-NG 3.0 alpha", and finally
> graduated to "Autoconf-NG 3.0" with what we know as Autoconf 2.60,
> do you think the transition would have been less painful (I really
> hope the answer is yes, of course).

My answer is that the two cases are different.

On one hand, there was no obstacle between a possible graduation of
Autoconf-NG 2.5x to Autoconf, like the GNU Make dependency could be for
Automake-NG.

On the other hand, it would have been nigh impossible to provide the
smooth deprecation path that I'm suggesting.

All I'm saying is, do not release Automake-NG for public use until
Automake can warn of all incompatible uses, or almost all.

>> It can provide good error messages and a clear upgrading path.  Please
>> _do_ provide it.
>>
> I hope to finally do that, but it will be in a form of a how-to and a
> set of recipes rather than an attempt to shoehorn Automake-NG semantics
> back to Automake.  The latter sounds too slow and too dangerious.

You have to evaluate each case separately of course, but a single
project has already shown several cases where Automake _could_ be
improved this way.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Il 21/08/2012 16:53, Diego Elio Pettenò ha scritto:
>> > do you think the transition would have been less painful (I really
>> > hope the answer is yes, of course).
> From a distribution point of view... it wouldn't have been any less
> painful. It would have meant we'd have even more packages using
> autoconf-2.1 than we still have right now....

Exactly.  The -NG moniker would have made no sense.  What could have
made sense would have been a mapping like

    2.50             2.90
    2.51             2.91
    2.52             2.92
    2.53             2.93
    2.x, x >= 54     3.(x-54)

This would have made it clear that the transition was not expected to be
too smooth.  Note that following each version was a lot of work, but
2.13->2.50 and 2.13->2.54 weren't that different (in fact 2.13->2.54 was
probably easier due to less bugs).

Another thing that was missing was the author's reaching out to convert
other projects, which is what you've been doing (and it's been very
welcome).  Did you try sed and grep already?

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 21/08/2012 08:06, Paolo Bonzini wrote:
> Exactly.  The -NG moniker would have made no sense.  What could have
> made sense would have been a mapping like

Yes that would have helped _a lot_.

Another thing that would have helped would have been out-of-the-box
support for multiple installed versions, whereas it seems most
distributions had to reinvent a different way to deal with this.

As of today, Gentoo still ships quite a few packages that use autoconf
2.1x, and that's quite painful as we can't update them to newer automake
either (when they use automake at all), at least not without rebuilding
the buildsystem altogether, which in turn means we have to keep
automake-1.4 1.5 and so on around. Sigh!

--
Diego Elio Pettenò — Flameeyes
[hidden email] — http://blog.flameeyes.eu/

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 08/21/2012 05:02 PM, Paolo Bonzini wrote: No problem.
I said ".SUFFIXES:"?  Yes, I did.  Oops, my mistake.  What I meant, and
what you must do if you want to remain compatible with mainline Automake,
is to explicitly set the '$(SUFFIXES)' variable.  Mainline Automake would
define that automatically for you (well, most of the times [1] at least),
but Automake-NG will not, since that would require extra automake-runtime
processing.  However both the AUtomake variants will honour an explicit
definition of $(SUFFIXES), and declare '.SUFFIXES:' accordingly [2].

[1] That is, unless you want to generate, say, '.a.b' files from '.c'
    ones, in which case you *must* add '.a.b' and '.c' explicitly to
    said $(SUFFIXES) variable, since the suffix rule:

      .a.b.c:
          ...

    is hopelessly ambiguous.

[2] See how easily Automake-NG can do so:

    $ cat lib/am/footer.am
    ...
    # For better compatibility with mainline Automake.
    $(if $(SUFFIXES),$(eval .SUFFIXES: $$(SUFFIXES)))
    ...

> * Does it make sense to do so in Automake, too?
>
Automake already processes explicit $(SUFFIXES) correctly.  Nothing
to do there.

> * Even if not, could a missing '.SUFFIXES:'
>
[I'm doing 's/.SUFFIXES:/$(SUFFIXES)/' here and blow, in light of what
 said above].

> hide bugs?
>
Not in mainline Automake.

> Would you
> consider adding a warning for missing ".SUFFIXES" in Automake, too?
>
No, because that would be a regression in Automake: until today, it
has been smart enough to initialize $(SUFFIXES) automatically in the
most common (and useful) situations, and stopping doing that for the
sake of a simplified transition to Automake-NG might understandably
annoy that part of the user base that is not interested in such a
transition (at least not now).

> This needs to be done for each NG-NEWS items.  It could improve the
> existing users of Automake, and reduce the size of NG-NEWS.  Both of
> which are good things!
>
And I've done that already where possible and reasonable.  For example,
the 'silent-rules' option is now active by default, and the tags-related
rules have been reworked and improved.  I might consider other similar
backports as well in the future.  But in several areas, similar changes
would risk to cause serious bugs and incompatibilities which, while IMHO
acceptable in a young and still experimental software like Automake-NG,
would not be acceptable in an Automake release.
Not doable, sorry.  Some things which are done better, more easily, or
faster in Automake-NG (and which have thus justified a behavioural or
API change) are that way only thanks to the possibility of relying on
GNU make features.  Deprecating the more-complex-and-messier but still
working equivalent (or similar) features and interfaces in Automake
would in the end mutilate it beyond recognition.

> If you rewrote Automake in m4 (only partly kidding), I wouldn't have had
> these objections.  But changing the name doesn't change the perception.
>
Maybe we just need good PR and "advertisment" in this.  The python
developers has managed to make a 3.0 release incompatible with the 2.x
series, because they've been very clear and vocal about the breakage,
and have been for a long time.  We might need to learn from them here,
and maybe we'll succeed.  Any suggestion?
As I said, I don't believe this would be actually doable.
Are you referring to the Smalltalk "port"?  If yes, I'm not seeing your
point honestly.  Care to elaborate?

Thanks,
  Stefano

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 08/21/2012 05:06 PM, Paolo Bonzini wrote: Not sed, no (maybe you can try it to see how the conversion goes from someone
not involved in Automake-NG as I am?).  But grep, coreutils, m4 (1.4.x branch),
bison, dejagnu, parted and autoconf has already been successfully converted:

  <https://github.com/slattarini/coreutils-am-ng>
  <https://github.com/slattarini/grep-am-ng>
  [ ... and so on, you got the gist ... ]

Regards,
  Stefano


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Il 21/08/2012 17:42, Stefano Lattarini ha scritto:
> Not sed, no (maybe you can try it to see how the conversion goes from someone
> not involved in Automake-NG as I am?).  But grep, coreutils, m4 (1.4.x branch),
> bison, dejagnu, parted and autoconf has already been successfully converted:
>
>   <https://github.com/slattarini/coreutils-am-ng>
>   <https://github.com/slattarini/grep-am-ng>
>   [ ... and so on, you got the gist ... ]

Splitting the patches like you did for GNU Smalltalk would be great, so
we can get the early part merged as soon as possible.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 08/21/2012 05:09 PM, Diego Elio Pettenò wrote: For what concerns Automake-NG, we might simply rename:

  automake -> automake-ng
  aclocal  -> aclocal-ng

in the end.  So far, I have not done that yet because it would require
changes to at least the Autoconf-owned 'autoreconf' programs and the
Gnulib-owned 'bootstrap' script in order to keep Automake-NG able to
bootstrap several important GNU packages.

> As of today, Gentoo still ships quite a few packages that use autoconf
> 2.1x, and that's quite painful as we can't update them to newer automake
> either (when they use automake at all), at least not without rebuilding
> the buildsystem altogether, which in turn means we have to keep
> automake-1.4 1.5 and so on around. Sigh!
>

Regards,
  Stefano

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Il 20/08/2012 21:56, Stefano Lattarini ha scritto:
What part of this is a cleanup, and what part is required?

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 08/21/2012 05:49 PM, Paolo Bonzini wrote: Sorry, but I lack the time for that right now.  I'll certainly help interested
maintainers to proceed to such more gradual conversion, once they're ready to
take the burden for it, but for the time being I'm just interested in verifying
that those packages actually work correctly and quickly enough with Automake-NG
(doing so has already proven useful to avoid bugs and performance regressions).

Regards,
  Stefano


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 08/21/2012 05:52 PM, Paolo Bonzini wrote: Should all be a cleanup (albeit INCLUDES was being AC_SUBST'd, it
was always empty AFAICS, so caused no real incompatibility; just
dead code).  Nothing in this change *should* be actually required
for the Automake-NG conversion.

Regards,
  Stefano


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

>> Ok.  So the question I'd like you to ask yourself are:
>>
>> * Why does it make sense to request manual declaration of 'SUFFIXES'?
>> * Does it make sense to do so in Automake, too?

And another question:

* Alternatively, could Automake-NG suggest converting suffix rules to
pattern rules so that the extra SUFFIXES entries are not necessary
anymore?  Or even do that automatically in the Makefile.am ->
Makefile.in conversion?

>> This needs to be done for each NG-NEWS items.  It could improve the
>> existing users of Automake, and reduce the size of NG-NEWS.  Both of
>> which are good things!
>>
> And I've done that already where possible and reasonable.  For example,
> the 'silent-rules' option is now active by default, and the tags-related
> rules have been reworked and improved.  I might consider other similar
> backports as well in the future.

Cool, please do.

> But in several areas, similar changes
> would risk to cause serious bugs and incompatibilities which, while IMHO
> acceptable in a young and still experimental software like Automake-NG,
> would not be acceptable in an Automake release.

Understood.  It has to be done carefully.

>> But CMake is not almost the same as Automake, Automake-NG is.
>> Automake-NG is not Automake 2.0, but Automake 2.0 _could_ have the same
>> user interface as Automake-NG.  What I'm asking is, please consider a
>> deprecation path in Automake for _every_ _single_ difference between it
>> and Automake-NG.
>>
> Not doable, sorry.

"Consider" != "provide". :)  You can use your judgement and creativity.

>> If you rewrote Automake in m4 (only partly kidding), I wouldn't have had
>> these objections.  But changing the name doesn't change the perception.
>>
> Maybe we just need good PR and "advertisment" in this.  The python
> developers has managed to make a 3.0 release incompatible with the 2.x
> series, because they've been very clear and vocal about the breakage,
> and have been for a long time.  We might need to learn from them here,
> and maybe we'll succeed.  Any suggestion?

Yes, that's correct.  PR and advertisement is what lacked in the early
Autoconf 2.5x releases.

>> All I'm saying is, do not release Automake-NG for public use until
>> Automake can warn of all incompatible uses, or almost all.
>>
> As I said, I don't believe this would be actually doable.

Looking at GNU Smalltalk, I see:

* warn for INCLUDES (vs. AM_CPPFLAGS)

* warn for unknown *_XYZFLAGS variables (btw, why doesn't CAIRO_CFLAGS
raise a warning)?

* warn for treating _SOURCES entries with a custom unknown user
extension as if they were header files

as possible action items for Automake.  And:

* warn for suffix rules or otherwise do something about them

* fix BUILD_SOURCES fork bomb, perhaps warn about it in advance (though
I'm not sure I understood the root cause here)

for Automake-NG.

>> You have to evaluate each case separately of course, but a single
>> project has already shown several cases where Automake _could_ be
>> improved this way.
>>
> Are you referring to the Smalltalk "port"?  If yes, I'm not seeing your
> point honestly.  Care to elaborate?

See above.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Il 21/08/2012 18:01, Paolo Bonzini ha scritto:
Ah, and

* add support for AM_DIST_FORMATS.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

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.

Making it the default in all automake-ng based packages, would escalate
this already unpleasant situation.


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

>>> but Automake 2.0 _could_ have the same
>>> user interface as Automake-NG.  What I'm asking is, please consider a
>>> deprecation path in Automake for _every_ _single_ difference between it
>>> and Automake-NG.
>>>
>> Not doable, sorry.
 >
> "Consider" != "provide". :)  You can use your judgement and creativity.

Well, if automake-ng wants to be a success, feel advised to reconsider
your opion. IMO, the reasons for the issues with the
autoconf-2.1x->2.[456]x and with automake-updates are these not having
provided/providing sufficient deprecation warnings and them often having
suffered from tiny bugs which introduce behavioral breakages.

Really? That's not how I recall the situation. I recall people turning
away from autoconf in disgust because of the numerous incompatiblities
and the often tremendous effort porting would have required.

Instead of "jumping" the "upstream autoconf train", they waited for the
things to settle/stabilize (some projects are still waiting today) while
others started to look out for alternatives (cmake, scons) - Many
switched away.

Ralf



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Il 21/08/2012 18:30, Ralf Corsepius ha scritto:
>>
>> Yes, that's correct.  PR and advertisement is what lacked in the early
>> Autoconf 2.5x releases.
>
> Really? That's not how I recall the situation. I recall people turning
> away from autoconf in disgust because of the numerous incompatiblities
> and the often tremendous effort porting would have required.

Yes, that's correct.

Still, in the end the reason was bad planning: 2.50->2.53 were buggy and
introduced backwards-incompatibilities with respect to earlier 2.5x
versions.  There was no advertisement of the actual state, so you had to
figure out that 2.54 and 2.59 were the really stable ones.  There was
also no proactive effort of the maintainers to push changes to other
projects, etc.

In all fairness, it's very difficult to do such a transition for a build
system.  But it's still a lesson to learn, and you _can_ do better with
Automake-NG.

> Instead of "jumping" the "upstream autoconf train", they waited for the
> things to settle/stabilize (some projects are still waiting today) while
> others started to look out for alternatives (cmake, scons) - Many
> switched away.

Yes, that's also what I recall.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 08/21/2012 10:30 AM, Ralf Corsepius wrote:
>>> 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.

Ralf, how many times do we have to tell you?

Setting the automake option 'silent-rules' does NOT make the build
silent by default, it merely enables the possibility of a silent build.
 Remember, when 'silent-rules' was first implemented, we did it with an
implementation that violated POSIX make, and so we made it optional
whether your Makefile would work on 95% of make implementations by
supporting silent rules at the expense of POSIX (you, the end user,
still decide whether to be silent or noisy), or whether your Makefile
would work on 100% of make implementations but lack the ability to
configure silent vs. noisy (you, the end user, have no choice).  Since
that original implementation, we came up with a way to make silent rules
configurable in a manner compliant with 100% of make implementations,
without violating POSIX.  Therefore, we can now ALWAYS emit the automake
code that allows you, the end user, a choice between silent or noisy.

It is still up to individual packages whether the build will be silent
or noisy by default, and it remains something that you can override
package defaults with a config.site that forces noisy builds.  The
'silent-rules' change in automake change did NOT make more builds
instantly silent, nor are we preventing you from your goal of noisy
builds for the Fedora buildbots.  Quit beating a dead horse to spread
FUD about something which is not true.

--
Eric Blake   [hidden email]    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 21/08/2012 09:30, Ralf Corsepius wrote:
> 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 same is true for Gentoo.

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

Or possibly what people expected Automake to be. Honestly I'm not sure
how many automake-based projects really care about non-GNU make
compatibility nowadays. A lot of them already don't work that well with
anything but GNU make, and they just don't care.

--
Diego Elio Pettenò — Flameeyes
[hidden email] — http://blog.flameeyes.eu/

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk