From: Kirill Lapshin (klapshin_at_[hidden])
Date: 2003-10-20 22:15:04
--- In jamboost_at_[hidden], Vladimir Prus <ghost_at_c...> wrote:
> I think the feature is specific to windows platform, not only to
> since we don't have common definitions to windows platform (yet),
> can be dumped to "builtins.jam".
Yep, looks like it is at least supported by borland, not sure if
borland uses the same def file format though.
> I've put together a small doc for the task of adding a new feature
> to be added to "extending.html" soon. It outlines the steps for
> <def-file> feature. If you could try to do the steps, it would be
> sure, if you find any problems along the way, either with
Boost.Build or the
> docs, please let me know.
Cool, where can I find the doc? If you have attached something, it
probably got killed by yahoo.
> And one caveat: if you succeed, you'll find that <def-file> can be
> "exe" targets, where it probably should have any effect. I'm not
sure this is
> a problem at all, but if it is, I can fix it in a minute.
Yep, it is meaningless for exe-s, so it would be nice to disable it
> lib a : a.cpp : <toolset>msvc ;
> alias a ;
> See the trick: alternatives for main target "a" can be declared with
> rules. The first alternative will be selected on msvc to create a
> and the second one will be selected elsewhere to produce nothing.
Nice trick. One problem though. In my case I am using so called xlw
framework for writing excel add-ins. The framework is a static
library. The add-in built with help of framework is shared library. So
I tried to do something like
lib xlw : xlw-sources : <toolset>msvc <link>static ;
alias xlw ;
lib my-excel-addin : my-sources xlw : <link>shared ;
Guess what? It picks up dummy alias xlw because of different <link>
values. Removing alias xlw ; fixes build. Unfortunetly I can't say
alias xlw : : <link>static ;
in this case "no best alternative" error reported.
> > Ideally I would like this feature to
> > propagate to other targets which are using that platform specific
> > library.
> Could you describe how this should work in more detail. I don't seem
to get --
> probably I'm just too dense, having woke at 4:00 ;-)
Sorry for not making much sense.. In my previous example I would like
my-excel-addin to be compiled with msvc only, and skipped for other
toolsets, because it depends on msvc only xlw library. I can use the
lib my-excel-addin : my-sources xlw : <link>shared <toolset>msvc ;
alias my-excel-addin ;
but it is too much typing. Not sure if it is trttd -- what if it is
actually the goal to build dependent lib with toolset A and link it in
lib built with toolset B. But then again, linking libs built with
different toolsets is probably not the most typical use case.
I've got another question -- while writing a Jamfile for XLW, I had
trouble specifying include dir for the library in such way that it is
a) used during library build b) added to usage-requirements of the libs
looks like project rule can handle either requirements or
usage-requirements but not both. So I ended up with adding include dir
to project requirements and library usage-requirements, which is Ok in
this case, since project has a single lib, but how is it supposed to
work for projects with zillions of libs?
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