Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-22 01:26:42


Hi Kirill,

> > 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:
> http://lapshin.net/deffile.tar

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
>
> <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).

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

http://zigzag.cs.msu.su:7813/working_copy/examples-v2/ct

> > 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.

My copy has

usage-requirements <include>.

at top-level. Is there anything else needed?

- Volodya

 


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