Re: def files for msvc and more

From: Kirill Lapshin (klapshin_at_[hidden])
Date: 2003-10-21 21:31:35

Hi Volodya,

> http://zigzag.cs.msu.su:7813/new_feature

Nice doc. It turned the task into 1st grade school excercise :)

I don't see a way to attach file through yahoo web interface and I
don't have nntp access at the moment so please get patch from here:
http://lapshin.net/deffile.tar

BTW if you are planning to include this doc into main documentation,
ot has a typo -- variable named incosistently, DEF_FILE vs DEFFILE.

> So, in 
> 
> lib xlw : xlw-sources : <toolset>msvc <link>static ;
> 
> you really would like <toolset>msvc to be part of condition, and
<link>static 
> to be requirement, used if this alternative is selected. Boost.Build 
> considers <link>static as part of alternative. Bad.
> 
> A possible workaround will be
> 
> alias xlw-select : xlw : <toolset>msvc ;
> alias xlw-select : 
> lib xlw : xlw-sources : <link>static ;
>

I see. I'll give it a try as soon as alias rule get fixed (not copying
usage-requirements bug I posted in different thread).

> Maybe, the right solution is to use the trick only on
my-excel-addin, and 
> prevent building of xlw by default with
> 
> explicit xlw ;
> 
> this way, xlw will only be built when requested from
my-excel-adding, and this 
> latter target will be built only with msvc. I don't yet see any general 
> scheme to achieve this effect.

Yep, it is certainly a nice alternative. If I have to explcitly
specify toolset for addins why not drop this requirement for xlw
framework itself. However, I have one framework and potentially
numerous addins, so I was hoping to save on typing of addins
declarations (and make them less error-prone), but if it is
impossible... Oh well.

Another quick question -- these excel addins are dlls renamed to
*.xll. Is there an easy way to instruct boost.build to generate files
with different extension? If it is not easy then don't worry, I can
certainly deal with this on installation phase.

> The project rule *should* handle both usage-requirements and
requirements, and 
> it seems to work okay when I add requirements to
examples-v/2libraries/lib1/
> Jamfile. Do you have a testcase for me?

You are right. It is possible indeed. I just got confused by docs
which have examples for project with requirements and projects with
usage requirements, and for both of them second argument to project
rule was used, so I naively tried

project foo : requirements <include>. usage-requirements <include>. ;

while the right way was 

project foo : requirements <include>. : usage-requirements <include>. ;

BTW, it would be probably nice to add usage-requirements to top boost
project, would not it? It will not buy us much, since most libraries
are implemented in headers, but still it might simplify life for those
who is using say threads library only.

--Kirill