Re: [jamboost] Re: def files for msvc and more

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-21 00:23:18

Hi Kirill,

> > 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 think so, though it's vague memory from long time ago....

> > docs, please let me know.
>
> Cool, where can I find the doc? If you have attached something, it
> probably got killed by yahoo.

Oops! I though I've atteched it, but it does not seems so. *Now* attached and 
also copied to

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

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

Ok, I'll wait for <def-file> to be implemented, then.

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

Oh, damn! I did not though this issue will arise *that* soon. Let me quote doc 
part that was added in M8:

<li>For each alternative <em>condition</em> is defined as the set of
base properies in requirements. [Note: it might be better to explicitly
specify the condition explicitly, as in conditional requirements].</li>

<li>An alternative is viable only if all properties in condition are
present in build request.</li>

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 ;

Although it separation condition and requirements becomes more desirable. be 

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

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.

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

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?

- Volodya

>
> --Kirill
>
>
>
> To unsubscribe from this group, send an email to:
> jamboost-unsubscribe_at_[hidden]
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
 --Boundary-00=_GLMl/y+B7z3T9rb Content-Type: text/plain;
charset="iso-8859-1";
name="new_feature"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="new_feature"

Adding a new feature.

Suppose you are not happy with the standard set of features, and would like 
to add your own.

Why would you want this, as opposed to passing flags to C++ compiler directly?

1. If you specify a feature, you will be able to build your project with two
different settings of the feature. If you pass compiler options,
Boost.Build assumes you know what you are doing, and would not care about
the options.

2. The feature makes sense for more than one compiler.

3. You use the feature to refer to a target.

Adding a feature requires three steps:

1. Declaring a feature. For that, the "feature.feature" rule is used. You
should have to decide on the set of feature attributes:

- if feature has several value, and significally affects build, make
it "propagated", so that whole project is build with the same value
by default

- if feature does not have a fixed list of value, it must be "free".

- if feature is used to contain value of path, it must be "path".

- if feature is used to refer to some target, it must be "dependency".

2. Converting the feature value into variable. To use feature in build action,
it must be converted into a variable, acessible in build action. This is
accomplished by "toolset.flags" rule.

3. Using the variable. The variable set in step 2 can be used in build action
to form command parameters or files. 

Example 1.

Let's invent fictional feature which causes to use C++ VM, an as-yet
non-existent beast similiar in spirit to Java VM. For example, let's adjust
the gcc toolset.

Step 1.
Add to builtin.jam the following line.

feature cppvm : no yes : propagated ;

Step 2.
Add to gcc.jam the following line.

flags gcc OPTIONS <cppvm>yes : -use-vm ;

Step 3.
Oops. The gcc.link and gcc.compile actions already use OPTIONS variable, so
we don't have anything to do. Assume gcc.compile actions contained
nothing but

actions gcc.compile
{
g++ -o $(<) $(>)
}

then we would rewrite it to be: 

actions gcc.compile
{
g++ $(OPTIONS) -o $(<) $(>)
}

And our <cppvm> feature would work.

Example 2. 

Referring to a file. 

Let's see how we can make a feature which refers to a target. For example,
when linking dynamic libraries on windows, one sometimes needs to specific
"DEF file", telling what functions should be exported. It would be nice to
use this file like this:

lib a : a.cpp : <def-file>a.def ;

Step 1.

Since the feature refers to a target, it must be "dependency".

feature def-file : : free dependency ;

Step 2. 
One of the toolsets which cares about DEF files is msvc. The following line 
should be added to it.

flags msvc.link DEF_FILE <def-file> ;

Step 3.
Since the DEF_FILE variable is not used by the msvc.link action, we need to
modify it to be:

actions link bind DEF_FILE
{
$(.LD) .... /DEF:$(DEF_FILE) ....
}

Note the "bind DEF_FILE" part. It tells bjam that DEF_FILE refers to a file,
otherwise the variable will contain internal target name, which is not likely 
to make sense for the linker.

We've almost done, but should stop for a small workaround. Add the following
code to msvc.jam

rule link
{
DEPENDS $(<) : [ on $(<) return $(DEFFILE) ] ;
}

This is needed to accomodate some bug in bjam, which hopefully will be fixed
one day.

 --Boundary-00=_GLMl/y+B7z3T9rb--