Difference between revisions of "Building MPICH For Development"

From Mpich
Jump to: navigation, search
Line 1: Line 1:
When developing MPICH2 itself it is often useful to build the library differently than you would for production use.  This page aggregates several tips and tricks for making your development life easier when working with MPICH2.
+
When developing MPICH itself it is often useful to build the library differently than you would for production use.  This page aggregates several tips and tricks for making your development life easier when working with MPICH.
  
 
== Enable Debugging Symbols ==
 
== Enable Debugging Symbols ==
Line 21: Line 21:
  
 
== Configure With "strict" ==
 
== Configure With "strict" ==
MPICH2 is a very portable project and one of the only ways to ensure that we are developing portable code on a permissive compiler like gcc is to configure gcc to be as strict and pedantic as possible.  The MPICH2 configure provides an option to make this easy: <code>--enable-strict</code>.
+
MPICH is a very portable project and one of the only ways to ensure that we are developing portable code on a permissive compiler like gcc is to configure gcc to be as strict and pedantic as possible.  The MPICH configure provides an option to make this easy: <code>--enable-strict</code>.
  
 
I recommend using <code>--enable-strict=all</code> or <code>--enable-strict=posix</code> for those situations where <code>all</code> is too constraining and you know what you are doing.  This strictness will also help to catch general programming errors, not just portability issues.
 
I recommend using <code>--enable-strict=all</code> or <code>--enable-strict=posix</code> for those situations where <code>all</code> is too constraining and you know what you are doing.  This strictness will also help to catch general programming errors, not just portability issues.
  
 
== Use ccache ==
 
== Use ccache ==
When developing MPICH2 it's not uncommon to need to <code>make clean</code> or <code>make distclean</code> fairly often for various reasons.  One way to help reduce the time drain that this can be is to use [http://ccache.samba.org/ ccache].  On my desktop this utility cuts my build times in half or better.  For setup just read the docs on the ccache site, they are pretty good.
+
When developing MPICH it's not uncommon to need to <code>make clean</code> or <code>make distclean</code> fairly often for various reasons.  One way to help reduce the time drain that this can be is to use [http://ccache.samba.org/ ccache].  On my desktop this utility cuts my build times in half or better.  For setup just read the docs on the ccache site, they are pretty good.
  
 
== Don't Build Unnecessary Code ==
 
== Don't Build Unnecessary Code ==
If you know you won't need a particular feature of MPICH2 then you might be able to disable it to speed up compilation or to prevent configure from complaining.  For example you can pick and choose from the following list of systems that can be disabled:
+
If you know you won't need a particular feature of MPICH then you might be able to disable it to speed up compilation or to prevent configure from complaining.  For example you can pick and choose from the following list of systems that can be disabled:
  
 
<pre>
 
<pre>
Line 36: Line 36:
 
--disable-cxx
 
--disable-cxx
 
--disable-romio
 
--disable-romio
--disable-mpe
 
 
</pre>
 
</pre>
  
The first three are useful if you only need the MPI C language bindings.  They disable the Fortran and C++ bindings.  The last two disable MPI-IO support and the MPE performance analysis tools respectively.
+
The first three are useful if you only need the MPI C language bindings.  They disable the Fortran and C++ bindings.  The last one disables MPI-IO support.
 
 
== Don't Use "make -j N" ==
 
MPICH2's build system does not currently support parallel make invocations (<code>make -j N</code>).  The reasons are arcane, but suffice it to say the fix is non-trivial.  There's a trac ticket ({{ticket|297}}) open to track this issue if you're interested.
 
 
 
The upshot though is, just don't use <code>-j</code> or you'll get strange failures at build time.
 
  
 
== Use VPATH Builds ==
 
== Use VPATH Builds ==
You can build several versions of MPICH2 from the same source tree by doing what's known as a [http://www.gnu.org/software/make/manual/make.html#General-Search "VPATH build"].  Let's assume you have your source in some directory like: <code>/foo/bar/mpich2-trunk</code>.  If you are using an svn version of the code you will need to do a ./maint/updatefilesin this source directory (see [[Getting_And_Building_MPICH2#Setting_up_the_build_environment|here]].
+
You can build several versions of MPICH from the same source tree by doing what's known as a [http://www.gnu.org/software/make/manual/make.html#General-Search "VPATH build"].  Let's assume you have your source in some directory like: <code>/foo/bar/mpich-trunk</code>.  If you are using an svn version of the code you will need to do a ./maint/autogen.sh in this source directory (see [[Getting_And_Building_MPICH#Setting_up_the_build_environment|here]].
  
 
Now let's say that you want to build two versions, one with a supported thread level of MPI_THREAD_SINGLE and one with MPI_THREAD_MULTIPLE.  You would create two directories that are '''not''' in the source directory like <code>/foo/bar/single</code> and <code>/foo/bar/multiple</code>.  Change to the <code>single</code> directory and run
 
Now let's say that you want to build two versions, one with a supported thread level of MPI_THREAD_SINGLE and one with MPI_THREAD_MULTIPLE.  You would create two directories that are '''not''' in the source directory like <code>/foo/bar/single</code> and <code>/foo/bar/multiple</code>.  Change to the <code>single</code> directory and run
 
<pre>
 
<pre>
  ../mpich2-trunk/configure --prefix=/foo/bar/single-installed --enable-threads=single
+
  ../mpich-trunk/configure --prefix=/foo/bar/single-installed --enable-threads=single
 
</pre>
 
</pre>
 
Then <code>make</code> and <code>make install</code>.
 
Then <code>make</code> and <code>make install</code>.
  
Next change to the <code>multiple</code> directory and issue the same commands but replace "single" with "multiple" everywhere.  You now have two builds of MPICH2 from the same source tree.
+
Next change to the <code>multiple</code> directory and issue the same commands but replace "single" with "multiple" everywhere.  You now have two builds of MPICH from the same source tree.
 
 
'''PLEASE NOTE THAT <code>make dependencies</code> DOESN'T WORK WITH VPATH BUILDS!'''  Sorry :(
 
  
 
== Use Makefile Dependency Tracking ==
 
== Use Makefile Dependency Tracking ==
 
For non-VPATH builds, you can run <code>make dependencies</code> before <code>make</code> and you will get dependency tracking in the build process.  This is useful because if you make a change to a header file then the appropriate including files will be updated the next time you run <code>make</code>.  Otherwise you might need to <code>make clean</code> before running <code>make</code> to ensure that you have a consistent build.
 
For non-VPATH builds, you can run <code>make dependencies</code> before <code>make</code> and you will get dependency tracking in the build process.  This is useful because if you make a change to a header file then the appropriate including files will be updated the next time you run <code>make</code>.  Otherwise you might need to <code>make clean</code> before running <code>make</code> to ensure that you have a consistent build.
 
'''Again, PLEASE NOTE THAT <code>make dependencies</code> DOESN'T WORK WITH VPATH BUILDS!'''
 
  
 
<!-- vim: set ft=wikipedia tw=0 : -->
 
<!-- vim: set ft=wikipedia tw=0 : -->

Revision as of 18:11, 20 November 2012

When developing MPICH itself it is often useful to build the library differently than you would for production use. This page aggregates several tips and tricks for making your development life easier when working with MPICH.

Enable Debugging Symbols

Configure with --enable-g=dbg to get debugging symbols included in the build.

  --enable-g=option - Control the level of debugging support in the MPICH
  implementation.  option is a list of comma separated names including
      none     - No debugging
      mem      - Memory usage tracing
      handle   - Trace handle operations
      dbg      - Add compiler flag, -g, to CFLAGS, CXXFLAGS FFLAGS and F90FLAGS.
      log      - Enable debug event logging
      meminit  - Preinitialize memory associated structures and unions to
                 eliminate access warnings from programs like valgrind
      mutex    - Enable error checking on pthread mutexes
      all      - All of the above choices

Personally I (goodell@) usually build with: --enable-g=dbg,mem,meminit,handle or --enable-g=all. I will drop some or all of these for performance testing. I also find that it is useful to include CFLAGS=-g3 to enable gcc to expand macros.

Configure With "strict"

MPICH is a very portable project and one of the only ways to ensure that we are developing portable code on a permissive compiler like gcc is to configure gcc to be as strict and pedantic as possible. The MPICH configure provides an option to make this easy: --enable-strict.

I recommend using --enable-strict=all or --enable-strict=posix for those situations where all is too constraining and you know what you are doing. This strictness will also help to catch general programming errors, not just portability issues.

Use ccache

When developing MPICH it's not uncommon to need to make clean or make distclean fairly often for various reasons. One way to help reduce the time drain that this can be is to use ccache. On my desktop this utility cuts my build times in half or better. For setup just read the docs on the ccache site, they are pretty good.

Don't Build Unnecessary Code

If you know you won't need a particular feature of MPICH then you might be able to disable it to speed up compilation or to prevent configure from complaining. For example you can pick and choose from the following list of systems that can be disabled:

--disable-f77
--disable-f90
--disable-cxx
--disable-romio

The first three are useful if you only need the MPI C language bindings. They disable the Fortran and C++ bindings. The last one disables MPI-IO support.

Use VPATH Builds

You can build several versions of MPICH from the same source tree by doing what's known as a "VPATH build". Let's assume you have your source in some directory like: /foo/bar/mpich-trunk. If you are using an svn version of the code you will need to do a ./maint/autogen.sh in this source directory (see here.

Now let's say that you want to build two versions, one with a supported thread level of MPI_THREAD_SINGLE and one with MPI_THREAD_MULTIPLE. You would create two directories that are not in the source directory like /foo/bar/single and /foo/bar/multiple. Change to the single directory and run

 ../mpich-trunk/configure --prefix=/foo/bar/single-installed --enable-threads=single

Then make and make install.

Next change to the multiple directory and issue the same commands but replace "single" with "multiple" everywhere. You now have two builds of MPICH from the same source tree.

Use Makefile Dependency Tracking

For non-VPATH builds, you can run make dependencies before make and you will get dependency tracking in the build process. This is useful because if you make a change to a header file then the appropriate including files will be updated the next time you run make. Otherwise you might need to make clean before running make to ensure that you have a consistent build.