Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-06-16 07:47:22

On Thursday 16 June 2005 16:32, Toon Knapen wrote:
> Vladimir Prus wrote:
> > FYI,
> > I've committed a change that prepend a "lib" prefix to all targets with
> > types derived from LIB, on Unix. (Cygwin is not considered Unix for this
> > case).
> >
> > This is needed mostly because on Unix, all libraries always have this
> > prefix, and there's no reason for us to be different.
> AFAICT it's not true that all libraries need to start with the 'lib'
> prefix on unix. It is necessary though if you link to the library using
> the '-l' flag (e.g. '-lfoo' on the link-line will search for a library
> or libfoo.a). However when specifying the patch and filename,
> the filename of the library need not start with the 'lib' prefix.

I know, but still most libraries have the "lib" prefix.

> So this change will break all projects that generate libraries that do
> not have the 'lib' prefix ;-(

Hmm... why? Only if there are outside projects, like IDE project files that
use the name without "lib".

> Personally I think this new behaviour tries to automate soth that is
> difficult to automate and I'm afraid that adding this 'lib' prefix
> automatically will consume more resources than not having the automation
> (and finally automation is about reducing resources).

I'm not so sure. As it stands now, every project should manually add "lib"
prefix when installing.

BTW, SCons has this "implicit 'lib'" behaviour too.

> > At the moment, prefix is not
> > configurable by the user because I don't want to implement any
> > flexibility unless it's needed. So if you need to customize the prefix,
> > let me know.
> >
> > This should be break anything, except that if you have "lib" prefix
> > already, current code will add yet another "lib". If that's a problem for
> > anybody, let me know -- I can make the code omit "lib" prefix if already
> > present.
> Here you go already, explain that to a new user: that bbv2 will add a
> lib-prefix unless there is already one. And suppose somebody want to
> call his library Imagine the support-questions about this on
> the ml!

I don't see this as a problem. (And SCons does exactly the same ;-) ).

> I do not want to be negative here, I'm just getting more convinced
> everyday that before automating soth one must be certain that it will
> safe spending (development-) time.

In this case I was sure it's safe.

- Volodya

Vladimir Prus
Boost.Build V2:

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at