Hello. Thanks for your response. I'm create a my module and component into
the coll. But when I execute autogen.sh, it's return ../../libtool: line
847: X--tag=CC: command not found
../../libtool: line 880: libtool: ignoring unknown tag : command not found
../../libtool: line 847: X--mode=compile: command not found
I have a libtool v 1.5.26. Can you get me a some guide about create
configure.m4.
2008/12/2 Jeff Squyres
> On Nov 25, 2008, at 10:29 AM, Максим Чусовлянов wrote:
>
> Hello! How i can integrated my collective communication algorithm in
>> openMPI with MCA?
>>
>
> Sorry for the delay in answering -- SC08 and the US holiday last week got
> in the way and I'm way behind on answering the mails in my INBOX.
>
> Just to make sure we're talking about the same thing -- you have a new
> collective algorithm for one of the MPI collective functions, and you want
> to include that code in Open MPI so that it can be invoked by MPI_ in
> MPI applications, right?
>
> If so, the right way to do this is to build a new Open MPI "coll"
> (collective) component containing the code for your new algorithm. Our coll
> components are basically a few housekeeping functions and a bunch of
> function pointers for the functions to call that are the back-ends to MPI
> collective functions (i.e., MPI_Bcast and friends).
>
> All the "coll" component code is under the ompi/mca/coll/ directory. The
> "base" directory is some "glue" code for the coll framework itself -- it's
> not a component. But all other directories are standalone components that
> have corresponding dynamic shared objects (DSOs) installed under $pkglibdir
> (typically $prefix/lib/openmpi).
>
> You can build a component inside or outside of the Open MPI tree. If you
> build outside of the Open MPI tree, you need to configure OMPI with
> --with-devel-headers, which will install all of OMPI's internal headers
> under $prefix. That way, you can -I these headers when you compile your
> component. Just install your DSO in $pkglibdir; if all goes well,
> "ompi_info | grep coll" should show your component.
>
> If you build inside of the Open MPI tree, you need to make your component
> dir under ompi/mca/coll/ and include a configure.params file (look at
> ompi/mca/coll/basic/configure.params for a simple example) and a Makefile.am
> (see ompi/mca/coll/basic/Makefile.am for an example). Then run the
> "autogen.sh" script that is at the top of the tree and then run configure.
> You should see your component listed in both the autogen.sh and configure
> output; configure should not that it plans to build that component. When
> you finish configure, build and install Open MPI. "ompi_info | grep coll"
> should show your component.
>
> But I'm getting ahead of myself... Let's go back a few steps...
>
> When building inside the OMPI tree, if you need to check for various things
> to determine if you can build the component (i.e., some tests during
> configure, such as checking for various hardware support libraries), you can
> also add a configure.m4 file in your component's directory. This gets a
> little tricky if you're not familiar with Autoconf; let me know if you need
> some guidance here.
>
> Now you can add the source code to the component. We have 2 important
> abstractions that you need to know about:
>
> - component: there is only one component instance in an MPI process. It
> has global state.
> - module: in the coll framework, there is one module instance for every
> communicator that uses this component. It has local state relevant to that
> specific communicator.
>
> Think of "component" as a C++ class, and "module" as a C++ object.
>
> Now read the comments in ompi/mca/coll/coll.h. This file contains the
> struct interfaces for both the coll component and module. We basically do
> everything by function pointer; the component returns a set of function
> pointers and each module returns a struct of function pointers. These
> function pointers are invoked by libmpi at various times for various
> functions; see coll.h for a description of each.
>
> During coll module initialization (i.e., when a new communicator has been
> created), there's a process called "selection" where OMPI determines which
> coll modules will be used on this communicator. Modules can include/exclude
> themselves from the selection process. For example, your algorithm may only
> be suitable for intracommunicators. So if the communicator in question that
> is being created is an intercommunicator, you probably want to exclude your
> module from selection. Or if your algorithm can only handle powers-of-two
> MPI processes, it should exclude itself if there is a non-power-of-two
> number of processes in the communicator. And so on.
>
> We designed coll modules in OMPI v1.3 to be "mix-n-match"-able such that in
> a single communicator, you can use the broadcast function from one module,
> but the gather function from a different module. Hence, multiple coll
> mod
