Re: autoconf 2.53 breaks compatibility (LIBOBJS)

[Akim Demaille]

| Hi guys,

Hi!

| I have read the discussion in your documentation and on the mailing
| lists with regard to AC_LIBOBJS vs LIBOBJS.

| Please let me point out that the autoconf 2.53 behaviour is
| incompatible and at least counter-intuitive:
| 
| - The documentation only teases about how it really shouldn't be used, and
|   that there are so many reasons why it should be done in that other, mucho
|   better way which the documentation doesn't give an example for.

Thanks for spotting, that's to be fixed.

| - All documentation referring to autoconf and libtool still has the LIBOBJS
|   directive, even autoconf itself!

I don't know the state of Libtool today.  The fact is, there used to
be a good relationship between Autoconf, Automake, abd Libtool.  This
is no longer the case, and we never really had an answer when the
question was asked.  I'm CCing to them now, in hope for a new
collaboration.

|   (Combining the above two I really felt like the docs were taunting me...)
|   
| - The recommended work-around if LIBOBJS is really needed (ie, if using
|   libtool) with using LIB@&address@hidden isn't even backwards compatible to 
2.52, it
|   will break slightly older autoconf versions for no good reason.

Well, anyway that's a bonus: using AC_LIBOBJ won't work with older
Autoconf either.  AC_PREREQ is your friend.

|   This makes the scripts only uglier to read, while still allowing what we
|   apparently shouldn't be doing.

The point is: that is only a temporary hack: LIBOBJ is an internal
detail that no maintainer should ever see.  It used to be
exposed... for lack of support.  Now that we are developping real
support (not just to make it cute, but because we do meet actual
problems that we *have* to solve), there is a temptorary hack
installed.

| I see the point in not writing to it and instead using AC_LIBOBJS, but
| breaking compatibility in a minor upgrade isn't very nice, especially not for
| a tool intended to increase portability :-)

Precisely: since we face problem with other tools, the GNU Build
System suite is allowed to depend on itself.

| So please, does anyone of you have a suggestion for a portable workaround?
| What _is_ the recommended way of doing
| 
| Xsed="sed -e s/^X//"
| LTLIBOBJS=`echo X"$LIB@&address@hidden"|[$Xsed -e "s,\.[^.]* ,.lo 
,g;s,\.[^.]*$,.lo,"]`
| AC_SUBST(LTLIBOBJS)
| 
| ... Instead of applying a patch to configure.in depending on the autoconf
| version?

I will not be possible to be backward compatible with this respect.
Please, note that this is not not an absolute backward compatibility:
it requires from the other tools to ship the right .m4 files.
Autoconf is not ``guilty''.