Re: [boost] jamfile for Intel Linux

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-25 18:16:39

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

> Hi David,
>
> you wrote:
>
> > Thanks for the toolset file! It looks like there's still a lot of
> > Win32-specific flotsam in there (remember, gcc-tools.jam works with
> > Cygwin-g++). In particular, the IMPLIB_COMMAND stuff doesn't really
> > belong in a unix-specific toolset. Try stripping out anything you don't
> > understand, to make a minimal toolset, and see if that still works...
>
> Yep, done. Interestingly enough, IMPLIB didn't matter. The corrected tool
> file is attached.

It's not surprising: since it is "multiplied" by $(<[2]), it disappears
unless there's a second file product as a result of the link. That's only
the case when an import library is being generated (Win32).

> > it seems everybody
> > uses gcc as their prototype;
>
> I first tried to adapt Beman Dawes's intel-win32-tools.jam, but realized
> that the Linux compiler version is rather gcc compatible.
>
> Would it be correct to replace the environment variable
INTEL_ROOT_DIRECTORY
> with IA32ROOT, i.e. the environment variable used by the compiler setup
> script iccvars.sh?

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), 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. I guess it doesn't hurt,
though.

> BTW, shouldn't I rename intel-tools.jam to intel-linux-tools.jam or may be
> ia32-linux-tools.jam?

The former, I think. IA32 refers to an architecture, not a compiler.

> > I really should clean it up and add some
> > comments so that people know how to proceed!
>
> May be some kind of template would do the job. I didn't spent too much
time
> figuring out, how to map the various compiler & linker switches on
> boost.build features.

Agreed.

> > Boost.Python currently has a few known problems which keep it from
> > working with Intel, though this one doesn't seem to be the deal-breaker
I
> > expected to see from this compiler.
>
> I played a little bit with extension_class.hpp. It compiles now (at least)
> with gcc and intel. Source is attached.

Thanks; I think I got it compiling, too, but Intel has some
exception-handling bugs which prevent it from working.

> > I guess you hadn't noticed, but a full-fledged effort to distribute
> binaries
> > is already underway. Vladimir Prus has been making RPMs and windows
> > installers, and Toon Knapen has been compiling jam for lots of different
> > platforms.
>
> Nope, I can't watch all boost motions ;-)

Pay attention to www.yahoogroups.com/group/jamboost

> > What problems did you have building the delivered jam_src?
>
> I checked again and it seems as if the problems stemmed from unpacking a
> .zip file on linux (really a novice's problem ;-).

Aha. We should distribute .tar.gz files as well.

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

> To check the intel compiler config more thoroughly, I decided to create a
> 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?

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

> Is there another method to detect a release build than checking for
NDEBUG?

Do you mean, a way to detect a release build from C++, or from Jam code?

> I just started to play with boost.regression and noticed that Jens Maurer
> earlier implemented something like his own build system to get regression
> tests running. Shouldn't boost.regression depend on boost.build one day?

Absolutely; take a look at $(BOOST_ROOT)/status/Jamfile. 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. 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.

-Dave