Re: [boost] jamfile for Intel Linux

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-26 08:30:23

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

> Hi David,

> > Absolutely... although there is a strange effect from doing this:
> normally,
> > variables such as IA32ROOT (which I expect is set by the compiler's
> > installation procedure),
>
> No, the user has to execute iccvars.sh in his session.

Yes; I know it's not precise, but when I said "part of the installation
procedure", it was meant to include things like that.

> > are only available if the directory they name is
> > already in the user's PATH. The result is that the tool is invoked with
an
> > explicit path precisely when it doesn't need to be.
>
> Interesting. So basically I could use all IA32 variables (they have some
for
> include and library directories also) directly, i.e. I would presume, that
> the compiler setup is done.

Ah: if you look at, e.g., msvc-tools.jam or metrowerks-tools.jam, you'll see
that every compilation action /potentially/ includes a call to a setup
script. The idea is that users may not want to clutter their environment
with all of the variable settings that happen as a result of running these
scripts, so a simple pointer to the installation directory is enough to
cause the script to be run before the tools are invoked. In other words, the
system should work two ways:

1. The user executes all of the setup scripts for tools she uses before
invoking the build system, which clutters the environment with lots of stuff
for each toolset.

2. The user points the system (on the command-line, in a site-config.jam or
user-config.jam, or in the environment) at the installation directories of
the toolsets, and the build system does the rest.

> Yep. Does that imply, that the difference between IA32 & IA64 should be
> addressed in intel-linux-tools.jam one day?

Yes; see my design proposal on the Wiki:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Build_D
esign_Proposal

Target platform, like compiler version, will be implemented as a subfeature.

> > > > Vladimir's RPM/installer is doing some fancy stuff which determines
> > > > BOOST_ROOT automatically, so that should be less of an issue.
> > >
> > > That's the right thing.
> >
> > I'm not yet sure what it does in case there are multiple boost
> > installations. The next revision of the build system is supposed to be
> able
> > to handle multiple versions of a tool or library being installed.
>
> I've got a little conceptual problem with boost.build: it's a very good
tool
> for the work being done on boost. But the work being done on boost isn't
> very representative for the outside world ;-) And you're going to make
> things even more comfortable (but also more complex, I fear).

Do you have a specific concern, or is this just FUD? ;-)

> > > new jam file in BOOST_ROOT/libs for all sub projects (directories)
> > > containing a jam file. New jam file and build log are attached.
> >
> > Hmm; I think this role is supposed to be played by the Jamfile in
> > BOOST_ROOT. Were you aiming at something different?
>
> But BOOST_ROOT/Jamfile only contains a subset of all possible subprojects?
> My idea was something like this: BOOST_ROOT/Jamfile contains the build
> procedure for an ordinary boost setup, i.e. building static & shared
> libraries and BOOST_ROOT/libs/Jamfile contains the build procedure for all
> of boost including examples and tests, i.e. a preparation of regression
> testing ;-).

Once again, please have a look at BOOST_ROOT/status/Jamfile.

> > > What is your recommendation to cleanup (intermediate) build results?
> >
> > Ah, what did you have in mind? The Win32 toolsets such as msvc and
> > metrowerks which are using command-files do something like that using
> > TEMPORARY. I know that in general, users would rather have object files
> > deleted, while programmers want them to hang around for the next build.
>
> Cleanup is a rather common rule in makefiles.

Yes, but what I meant by "what did you have in mind" was: "what should it
do?"

> I see two options:
> - extending jam with an appropriate mechanism, if necessary. But this
seems
> dangerous, I guess therefore it's not contained in make :-).
> - writing appropriate cleanup actions in every jam file. Do you have any
> samples?

It's easy to make this kind of thing automatic, if you just tell me what
you're after...

> > Do you mean, a way to detect a release build from C++, or from Jam code?
>
> From C++. I recently realized that MSVC _DEBUG isn't very portable ;-).

NDEBUG is the "most-standard" way, but some people may want to ship releases
with assertions enabled, in which case they usually define their own debug
preprocessor symbol.

> > Absolutely; take a look at $(BOOST_ROOT)/status/Jamfile.
>
> I exactly tried to build with this jam file, but nothing happened. I
guess,
> I didn't manage to get the proper command line.

Oh, make the "test" target. It doesn't build by default because the
status/Jamfile is subincluded from the root.

> > I have to integrate
> > the code for generating HTML and capturing compile logs; Jens and I
spent
> > some time discussing this in Redmond. I am a bit torn as to whether to
do
> > this now or after we get the build system rewrite well-established.
>
> I'm a bit sceptical, whether a rewrite of the build system is worth the
> effort. I currently do not see any major problem, that this rewrite could
> address.

* Slowness
* Inflexibility (dealing with multiple compiler versions, target platforms)
* Difficulty of maintenance
* Difficulty of setup

And then there are some really cool things we could do which we're not
currently doing:

http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Configuration
_And_Installation

> I also skimmed the mailing lists at perforce, so I'm not sure, if
> jam or ftjam is the real successor of make.

I hope it's Jam, in the sense that I hope that Perforce decides to roll all
of Boost.Jam back into Jam itself. Anyway, we're not using FTJam anymore -
so much has been changed.

But anyway, I'm not talking about reimplementing Jam, just the Jam rules in
boost-base.jam and allyourbase.jam. That project is already underway in
$(BOOST_BASE)tools/build/new.

> > After
> > all, we have Jens' tool which works quite well for the time being, and
the
> > way the build system is currently organized makes Jam relatively slow at
> > processing the status Jamfile.
>
> Simple argument: if the group accepts boost.build, we should use it
> consistently ;-).

Absolutely agreed. Regression testing gets more painful, anyway, if you have
to run all tests anytime a single thing changes. I'm just talking about
ordering what gets done according to urgency.

Dave