Re: def files for msvc and more

From: Kirill Lapshin (klapshin_at_[hidden])
Date: 2003-10-20 22:15:04

Hi Volodya,

--- In jamboost_at_[hidden], Vladimir Prus <ghost_at_c...> wrote:
> I think the feature is specific to windows platform, not only to
msvc. But 
> since we don't have common definitions to windows platform (yet),
the feature 
> 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
--- likely 
> to be added to "extending.html" soon. It outlines the steps for
creating of 
> <def-file> feature. If you could try to do the steps, it would be
great. And, 
> 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
used on 
> "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
for them.

> lib a : a.cpp : <toolset>msvc ;
> alias a ;
> 
> See the trick: alternatives for main target "a" can be declared with
different 
> rules. The first alternative will be selected on msvc to create a
library, 
> 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
same trick

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?

--Kirill