Bruno Haible <[EMAIL PROTECTED]> wrote:
>> Gnulib is more than a little about portability.
>> Do we really want to discourage creation of packages
>> that will work on IRIX 6.1 and AIX older than 4.3.2?
>
> The systems which don't have atexit() ... raise() are things like
> Solaris 2.3, IRIX 5, SunOS 4, NeXTstep, Ultrix. Museumware. We haven't
> heard any report from anyone using such old systems in 3 years.
Hi Bruno,
Since you listed Irix 6.2 and AIX 4.3.2 as being immune, I presumed
that versions earlier than those, yet with the same major number,
may be impacted. If, as you now imply, all of 6.x and 4.x.x are
not affected by the removal of those modules, then it may be
less of a problem. The trouble is that it's hard to _know_.
What if there are other systems?
>> How about giving a more verbose diagnostic (or referencing a URL)
>> that lists the aging systems on which they are still useful?
>
> I'm not even in a position to compile the list of these old systems.
> Most machines of this era have already been turned off.
My concern is that package maintainers will address the warning
(remove those modules) without realizing that for minimal benefit they
are removing pieces that may make their project less portable to fringe
systems. Not just old ones, but perhaps embedded ones, too, and they
would be unlikely to notice the regression right away.
A more conservative approach would be to make each of those
proposed-obsolete module AC_REQUIRE a new macro with code to run at
configure-time if ever the module is required. That code could make
configure fail by default with a diagnostic saying e.g.,
This configure script has detected a surprising situation on your
system. It actually requires gnulib's $module, and that module
is slated to be marked as obsolete. If it is marked as obsolete,
there's a good chance it will be removed from future releases of this
package, and your build on this system will fail as a result.
You can help avoid that by informing the gnulib maintainers.
You can get past this interruption by rerunning configure in the
following ways. The first way sends email, the second merely
prepares an email message in $TMPDIR, and the third just ignores
this situation:
env OBSOLETE_CHECK=send-email ./configure
env OBSOLETE_CHECK=prepare-msg ./configure
env OBSOLETE_CHECK=ignore ./configure
----------------------------------
Or, as I suggested before, a more detailed diagnostic than
"module is obsolete".
------------------
On the other hand, since I'm not volunteering to implement the
proposed alternative, this is more "for the record" than a formal
objection.
