On 08/21/2012 05:02 PM, Paolo Bonzini wrote:
> 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. :(
>
No problem.
>>> * 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:'?
>
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.
>>> 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.
>
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?
>>> I apologize for the useless complaint if you are already doing this;
>>>
>> Please don't. I find this exchange very useful and informative for my
>> own understanding of the status and direction of Automake-NG.
>>
>>> please let me explain my worries. The lack of a clear upgrading path
>>> (and bugs in autoupdate, which took a while to get right) was what
>>> caused problems in Autoconf 2.50-2.53, compounded by the lack of
>>> awareness about Autoconf/m4 best practices.
>>>
>> The difference here is that people *should* understand that Automake-NG
>> is not meant as an "Automake 2.0", but as a new projects with different
>> aims, and thus different idioms, usages, strengths and weaknesses.
>
> People won't. :)
>
>> This is the point I want to drive home, to avoid another transition
>> debacle like the Autoconf one. Here's an honest question: if
>> Autoconf 2.50 has been called "Autoconf-NG 3.0 alpha", and finally
>> graduated to "Autoconf-NG 3.0" with what we know as Autoconf 2.60,
>> do you think the transition would have been less painful (I really
>> hope the answer is yes, of course).
>
> My answer is that the two cases are different.
>
> On one hand, there was no obstacle between a possible graduation of
> Autoconf-NG 2.5x to Autoconf, like the GNU Make dependency could be for
> Automake-NG.
>
> On the other hand, it would have been nigh impossible to provide the
> smooth deprecation path that I'm suggesting.
>
> All I'm saying is, do not release Automake-NG for public use until
> Automake can warn of all incompatible uses, or almost all.
>
As I said, I don't believe this would be actually doable.
>>> 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.
>
Are you referring to the Smalltalk "port"? If yes, I'm not seeing your
point honestly. Care to elaborate?
Thanks,
Stefano
