Re: [jamboost] linking with 2 different mpi libraries

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-06-23 02:25:09

Hi Toon,

> But now a few problems show up with this approach.
> First, the mpi types (MPI_Group, MPI_Comm etc.) are generally typedef'ed
> to an int. So my fake mpi libraries relies on all these types being
> int's. However in the MPI library of HP for instance MPI_Group and
> MPI_Comm are actually structs. As my fake library implementation relies
> on all these types being int's, I would need to define these types
> myself. But when I define this type myself for the fake, every C++ file
> that includes the mpi headers would need to either include the headers
> of the real or the fake library and this would result in having to
> compile an object file for the sequential application and another object
> file for the parallel application.
> A second problem comes up when my framework is compiled to shared
> libraries instead of static libraries. When linking the shared library,
> all dependencies need to be provided on the link-line. However these
> dependencies are different if the framework-library will be used in a
> sequential or a parallel application.

I'm not sure I follow. On Unix, shared libraries can have unresolved 
references, which will be finally resolved during linking of exe. I think 
it's not that case on Windows, though. 

> So my conclusion is that object-files and libraries that are to be used
> in a sequential and a parallel application are not link-compatible (and
> I would thus need to compile all my files twice to generate a sequential
> _and_ a parallel application).
>
> My question is now: how do I handle this best with bjam? Should I add a
> feature (which affects link-compatibility) or is there any other way?
>
> If I would add a feature in e.g. features.jam, this feature could look
> like:
>
> feature parallelism : default mpi fake-mpi ;
>
> But the fake-mpi case of course makes no sense for people that don't
> have a fake-mpi library. Additionally no fake-mpi is easily available on
> the Net. However I could add my fake-mpi libary to boost-sandbox for
> instance.
>
> So if you read this mail this far, thanks for your interest and any
> feedback would be appreciated.

You surely guess that I'll take every opportunity to promote Boost.Build 
V2 ;-)

In this case, V2 allows to to write the following in project-root.jam:

feature parallelism : mpi fake : composite ;
feature.compose : <parallelism>mpi : <library>/mpi//mpi ;
feature.compose : <parallelism>fake : <library>/mpi//fake ;

I suspect that you can declare feature in Jamrules even using V1, but the 
point is that with V2 approach the right library should be linked 
automatically.

You can see the complete example (which differs by some additional tricks) at

http://zigzag.lvk.cs.msu.su/~ghost/working_copy/v2/example/custom_variant/

- Volodya