portland group compilers (pg++, pgi, pgCC)
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
Server Levent Yilmaz 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),
Not to discourage you, but support request won't work. Getting a new toolset added absolutely requires somebody with access to that compiler, at least to run Boost.Build V2 regression tests with that compiler and investigate failures. And so far, you're the first one with such access ;-) That said, usable toolset module is not so much work.
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
The lambda library is header-only, so you can try by hand. If the compiler can cope with the lambda library, you can assume it's good enough. - Volodya
Vladimir Prus wrote:
Server Levent Yilmaz 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),
Not to discourage you, but support request won't work. Getting a new toolset added absolutely requires somebody with access to that compiler, at least to run Boost.Build V2 regression tests with that compiler and investigate failures. And so far, you're the first one with such access ;-)
That said, usable toolset module is not so much work.
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
The lambda library is header-only, so you can try by hand. If the compiler can cope with the lambda library, you can assume it's good enough.
In fact serialization is the only non-header-only library of the above list. jeff Flin
Jeff F wrote: [snip 20 quoted lines]
serialization multi_array bind lambda filesystem
The lambda library is header-only, so you can try by hand. If the compiler can cope with the lambda library, you can assume it's good enough.
In fact serialization is the only non-header-only library of the above list.
filesystem is also non-header, at least in my copy of RC_1_34_0 branch. - Volodya
On 12/5/06, Server Levent Yilmaz
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
participants (3)
-
Jeff F -
Server Levent Yilmaz -
Vladimir Prus