Re: [PATCH] {maint} multilib: deprecate, will be moved to contrib

[Stefano Lattarini]

On 01/18/2012 11:46 AM, Ralf Corsepius wrote:
> On 01/18/2012 11:22 AM, Stefano Lattarini wrote:
>> As of 2012-01-17, according to Google codesarch, almost no active
>> package is using the 'multilib' feature offered by automake.
> 
> This is only partially correct. Multilibs are a compiler's feature
> (esp. a GCC feature) and widely used in the embedded world.
>
What I meant is that the *Automake support* for multilibs was hardly
used at all, at least according to Google codesearch.  If multlibs
are used in a way that does not require Automake special support for
them, then it's OK to remove such support for Automake.

>> The only major exception seems to be GCC...
>
> Not quite. GCC is the #1 user of multilibs itself and framework
> multilib'ed libraries are using.
>
Which is consistent with what I said, no?

>>  But on a closer look,
>> it become clear that GCC basically carries its own version of
>> multilib support.  In fact, Automake syncs its 'config-ml.in' and
>> 'symlink-tree' scripts from GCC; and the GCC repository contains a
>> version of the 'multi.m4' file that is *more* updated than the one
>> in the automake repository (the former having being modified the
>> last time in 2008, the latter only in 2006).
>
> Correct, multilibs in automake have always been the automake
> maintainer's unloved and obviously ununderstood step child.
>
Very likely.  Which is why I think it's a good idea to move the support
for them out of Automake core, and let more motivated and knowledgeable
people handle it.  Otherwise, the implementation will just remain
untouched, undocumented and unloved in the Automake repository, never
being extended or improved, slowly bit-rotting into irrelevance.

With the move I'm proposing, the only changes you'll have to do to
continue using multilibs will be:

  1. Have a copy of multi.m4 in an aclocal-accessible directory, or copy
     the automake-provided multi.m4 from contrib/ in your local m4/ dir;

  2. Copy the Automake-provided multi.am fragment in your source tree,
     and include it in the relevant Makefile.am files with a simple
     "include $(top_srcdir)/multi.am"

> It's only a reflection of multilibs not being widely used by main-stream
> Linux distros and architectures having been used for Linux so far. (The
> "arms" being on the raise could change this situation)
> 
>> The 'multilib' feature was anyway hardly documented at all, only
>> being briefly cited in the manual as an "obscure feature", "still
>> experimental", that was only for users "familiar with multilibs"
>> and which "can debug problems they might encounter".
>
> I don't know who wrote this, but I prefer to abstain from further
> commenting on it :(
>
"git blame" tells me it was no one less than Tom Tromey writing that
characterization.  Which should lend it some credibility, no? :-)

>> * NEWS (Future backward incompatibility): Update.
>> * doc/automake.texi: Deprecate multilib support.  State that it
>> will be removed from automake core in the next major release.
>> * m4/multi.m4 (AM_ENABLE_MULTILIB): Deprecate.  If called, now
>> gives a proper warning in the 'obsolete' category (while still
>> retaining its former behaviour for the rest).
>> * tests/multilib.test: Update.
>> * contrib/multilib/multi.m4: New, verbatim copy of the earlier
>> version of multi.m4, without the new deprecation warning.
>> ---
>>
>> I will push this patch to maint in 72 hours if there is no objection.
>> Then I'll proceed with a patch for master that removes the multilib
>> support from the Automake core and moves it into 'contrib/' (I will
>> post that patch here before committing, of course).
> 
> Maximum veto ... this step would be a massive regression to me.
> It's a step which would throw my works back ca. 10 years.
>
Please don't exaggerate.  In light of my explanation above, it will
just require you a few minutes (per-project) to do the relevant
adjustments (and only starting with Automake 1.12 anyway).

Regards,
  Stefano