From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-22 01:26:42
> > http://zigzag.cs.msu.su:7813/new_feature
> Nice doc. It turned the task into 1st grade school excercise :)
Great that you liked it.
> 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:
Got, applied, comitted. Thanks!
> BTW if you are planning to include this doc into main documentation,
> ot has a typo -- variable named incosistently, DEF_FILE vs DEFFILE.
Yea, I plan to include this doc. Thanks for catching the typo.
> > So, in
> > lib xlw : xlw-sources : <toolset>msvc <link>static ;
> > you really would like <toolset>msvc to be part of condition, and
> > 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).
Okay. Did you seing my reply asking if we should simply combine usage
requirements from all sources?
> > 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.
I think there's one really secret trick. It's so simple that I myself did not
know about it for some time.
rule excel-addin ( name : sources : requirements )
lib $(name)-real : $(sources) xlw : $(requirements) ;
alias $(name) : $(name)-real : <toolset>msvc ;
alias $(name) ;
After that, you can write
excel-addin first : first.cpp ;
excel-addin second : second.cpp ;
> 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.
Yes, it's possible, if you create a new target type for xll:
type.register XLL : : SHARED_LIB : main ;
type.set-generated-target-suffix XLL : : xll ;
Because XLL is derived from SHARED_LIB, it will inherit generators for
SHARED_LIB, so all you need to change suffix. The complete example, which is
only a couple of lines longer, is available at
> > The project rule *should* handle both usage-requirements and
> requirements, and
> > it seems to work okay when I add requirements to
> > 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.
My copy has
at top-level. Is there anything else needed?
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