Re: library name enforcement?

[Bob Proulx]

Alexandre Duret-Lutz wrote:
> >>> "Ralf" == Ralf Corsepius <address@hidden> writes:
> 
>  Ralf> On Mon, 2004-05-03 at 06:52, Bob Proulx wrote:
>  >> Older versions of automake allowed arbitrary library names.
>  >>
>  >> noinst_LIBRARIES = foo.a
>  >>
>  >> Recent versions of automake now complain about this naming.

Sorry for not being explicit about the particular versions.  I did not
know at the time which version did which behavior.  All I knew was
that it had changed and had made an assumption that these changes
would have been known.  But my assumption was flawed.  It had changed,
but not explicitly.  After researching this further I finally have
some more information.

>  Ralf> Recent? Well, AFAICT this (mal-) feature is in automake for years.
>  Ralf> I wish it had never been introduced :(

I saw it relatively recently.  I was using automake-1.4d on HP-UX.

> I've dug some interesting bit of history out of the CVS
> repository.

Wow.  Interesting history.  Thanks for sharing it.

> I'm quite surprised by this thread, though.  First I don't know
> how Bob could have possibly used arbitrary library names (a
> patched Automake, maybe?)

I had automake-1.4d installed on HP-UX and people in my lab were
trying to port a legacy application to it.  The comment came to me
that it worked on our HP-UX but failed on our Debian GNU/Linux
machines.  Different versions with the Debian version much newer.  The
port has stagnated since.  I eventually updated our HP-UX machines to
a newer automake.  That sort'a solved the problem of them being
different because then both platforms behaved the same.  :-/

Getting back to the problem after a delay and I decided to post the
question to the list.  I had assumed it would be well known.  I did
not expect that this check had been in place for so long.

I walked through every previous version of automake that I had
installed in order to determine how this was "working" previously.  I
was starting to doubt my own sanity after a while.  But when I finally
got back to automake-1.4d I was able to recreate the behavior.  That
version does not seem to check that libraries have a lib*.a pattern.

I looked at the code and I do not know why it is not complaining.  I
can only guess that it is a bug which is causing the check to be
avoided.  But from the code that is certainly not the intention.  So I
think this was a bug in 1.4d which by chance gave me a "good"
behavior.

> Then I confess I don't really realize to what extent this
> restriction is annoying.

When creating new projects it is not a problem.  When porting
applications normally it is not a problem.  But in my case I have a
relatively large (>625K ncss/sloc) project which is using an existing
build system (spms+mkmf+zillions of scripts) and I was trying to
retrofit it in place.  It currently creates libraries without any lib
prefix.  These are linked in later using a full name and path.

If I can make both build systems work side by side for a transition
interval I can probably move the project onto the autotools.  But if I
can't then it is unlikely that I will convince the powers that be that
things should be dismantled and reassembled under a different one.  So
for me it is purely a matter of marketing this to others without any
prior open source or free software experience.  Think corp programmers
who have spent their entire career within the private sector.  They
expect things to be difficult and pecular to a project.  But if you
show them a better way they will use it.

My preference would be that if the automake options included 'foreign'
that the naming conventions were relaxed.  This is only for static
archives and not for shared objects.

Bob