|
Boost-Build : |
From: Phillip Seaver (phil_at_[hidden])
Date: 2005-05-04 08:44:21
Vladimir Prus wrote:
> On Tuesday 03 May 2005 18:56, Phillip Seaver wrote:
>
> > > You can write:
> > >
> > > lib foobar : $(SRC) ;
> > >
> > > and then use the 'tag' feature to decorate the name to your liking.
> > > Take a
> > > look at tests/tag.py. It has a big Jamfile block at the beginning
> > > which can
> > > serve as example. You can also look at tools/stage.jam, rule 'rename'.
> >
> > Unless I'm mistaken, <tag> appends to the base name, and we would want
> > to prepend "lib".
>
> Yes, that's if you use the first (historically) form:
>
> <tag>_d
>
> The newer form is
>
> <tag>@some_rule
>
> The 'some_rule' is passed name of target, type and properties and
> returns the
> name that should really be used. It can add both prefix and suffix.
Ah. I didn't know about that. I'm still learning about BB. :-)
>
> > > But probably we should add 'lib' automatically on Unix if no <tag> is
> > > specified?
> >
> > Actually, I think it should prepend "lib" on Unix whether or not a <tag>
> > is specified. You may want it to be "libfoobar.so" &"foobar.dll" for
> > release and "libfoobar_d.so" & "foobar_d.dll" for debug, for example.
>
> So, you suggest that "lib" is prepended unconditionally, even if any
> form of
> <tag> is present? I think that at least for <tag>@some_rule, user
> should have
> full control over the generated name.
I think the default should be prepending "lib" on Unix, since that's
what most (all?) linkers look for when you give it "-lfoobar". I agree
(now that I know about it) that for the <tag>@some_rule form, it should
not be done, though.
On a side note, I'd like to express my thanks to the developers --
Boost.Build V2 is solving a lot of the build problems that have been
driving me crazy over the years. Keep up the good work!
Thanks,
Phillip
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk