|
Boost Users : |
From: Server Levent Yilmaz (leventyilmaz_at_[hidden])
Date: 2007-01-05 18:37:23
On 12/5/06, Server Levent Yilmaz <leventyilmaz_at_[hidden]> wrote:
> Hi All,
>
> Please correct me if this is off topic here..
>
> I sadly realized that there is no compiler toolset available for Portland
> Group Compilers ( http://www.pgroup.com/). Before submitting an entry in the
> Support Request, and digging in (probably REALLY deep), I was wondering if
> there is anyone that has any experience with these compilers (failure or
> success, *nix or win), particularly for the following libraries:
>
> serialization
> multi_array
> bind
> lambda
> filesystem
>
>
> thank you,
> levent
>
Hi Again Everyone,
And thanks for your comments Vladimir..
I am trying to wake up from this portability nightmare and any help
would be greatly appreciated.
I have been experimenting with PG compilers for the past week and it
seems their C++ compiler is pretty much standards conforming. Here is
how I decided that: I installed Boost using the gcc toolset, and then
used PG compilers to build a couple of codes using header only
libraries, such as Lambda, Bind and MultiArray. Except a couple of
insignificant warnings, the builds were successful.
But with building libraries such as serialization and filesystem, I am
stuck. I have a very limited knowledge of bjam or any other large
scale build system for that matter.
Nevertheless, I summoned courage to follow the source config steps
given here http://tinyurl.com/df7tw, and to the best of my ability
modified the config/user.hpp file. However, as far as I understand, in
order to compile binary libraries (and all tests) one needs to provide
some bjam toolset as well. It seems, by the design of Boost.Build
there is no boilerplate Jamfile that one can customize for a given
compiler, and in fact each library realizes a given toolset using
switches inside their own jam files. Am I right?
Currently I am trying to fool bjam (of rather fool myself :) with
dirty tricks such as using gcc toolset but specifying GXX=pgCC and
GCC=pgcc... Obviously there are unrecognized compiler options popping
up, but in the end some library is being built. I haven't tested it
yet. Another dirty trick I will try is to go to wherever the library
sources are (say libs/serialization/src) and run
pgCC <my-untested-random-compiler-opts> *.cpp
To cut the long story short; I need to get this thing working somehow,
and I am just struggling helplessly. It seems PG itself is not going
to provide any useful help at the moment: http://tinyurl.com/y4m34z
I understand that satisfying a whole set of requirements to come up
with a brand new full-proof end-user toolset it quite a task; and as
Vladimir pointed out it is probably too much to expect from Boost.org
to come up with such a solution any time soon, esp when not many
people seem to need PG support.
Yet, with great appreciation, I can still use any comments that would
shed light on customizing the Boost Build process from a user's stand
point and making it work for at least the Serialization and Filesystem
libraries.. Any other "dirty trick" ideas are also welcome..
thank you
-- Server Levent Yilmaz Mechanical Engineering @ PITT
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net