Re: [boost] jamfile for Intel Linux

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-27 17:11:37

----- Original Message -----
From: "joerg.walter" <jhr.walter_at_[hidden]>

> Sorry, it seems I didn't explain it good enough. My problem is not to
> integrate iccvars.sh into the build actions. My problem is that it's
> settings live in a sub shell and are lost, when the build rule terminates.

No problem; it gets called again at the beginning of each build action.
You can arrange things to detect that it's already been called when Jam is
invoked, and avoid calling it if possible.

> iccvars.sh changes pathes to point to Intel specific shared libraries,
which
> are in turn linked to the compiled objects.
>
> So to get executables build by $(BOOST_ROOT)/status/Jamfile working for
> example, I'd have to modify the part of boost.build, which executes the
> regression tests, to also call iccvars.sh, so that the references to the
> Intel specific shared libraries could be resolved.

Oh, I see. I guess what you'd have to do instead is encode some of the
information from iccvars.sh into Jam rules and get that into
$(gRUN_PATH(target)) for each generated target.

> > None, I guess. Often the examples are part of the regression tests (or
at
> > least they should be)...
>
> That was my original reason to create a new Jamfile in $(BOOST_ROOT)/libs
> :-)

I think this warrants a question to the boost list about how to build
examples. My inclination would be to make a pseudotarget called "example"
which can be built from the top-level or any subproject.

> If you are sure of this being the correct solution (despite my efforts to
> explain the problem :-), I'll add the invocaction of iccvars.sh.
>

I think I see what the problem is, but I also think it's worth some effort
to address it. There are a number of possible approaches, including the use
of the JAMSHELL variable. For now, we might consider adding the invocation
for the sake of /building/ libraries and executables, even if it won't help
when running executables.

I am beginning to think that in the new build system, part of the answer is
to define targets as first-class objects, with attributes that can be
inherited (passed from dependent to dependency) or synthesized (vice-versa).
That would allow a toolset to set, e.g. the synthesized "run-setup"
attribute on a built target, each element of which would be used to prepare
its dependents to be run. The current $(gRUN_PATH(target)) would be replaced
by a similar attribute. Build requirements would be "inherited" attributes,
which propagate from user-specified "main targets" to the intermediate
targets on which they depend.

-Dave