Alexandre Duret-Lutz wrote: > >>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> 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
