An Automake Primer for HDF5

James Laird - May 2005

Last updated: September 2005


How to:

Change a Makefile

Add a source file to an existing program or library

Add a simple test

Add a test with multiple sources

Add a test script

Add a new directory

Add a program that is only compiled in parallel

Change a program's name when it is compiled in parallel

Add a new library

Change the library's API


Changing a Makefile

Suppose you need to make a minor change to the Makefile in the test directory (hdf5/test/Makefile). You have checked out hdf5 from the CVS repository into ~/scratch/hdf5. You want to build the library in a directory named ~/scratch/build.
First, edit the Makefile.am in the source tree. You must make any changes in the Makefile.am, not the Makefile, since the Makefile is automatically generated.

cd ~/scratch/hdf5/test
vi Makefile.am

Now, go to the root of the source tree and run the reconfigure script, which updates the source tree. It will create a new Makefile.in in the test directory with your changes.

cd ~/scratch/hdf5
./bin/reconfigure

After running bin/reconfigure, you will want to test your change. Go to ~/scratch/build and run configure.

cd ~/scratch/build
../hdf5/configure
make check

Configure generates Makefiles from the Makefiles.in in the source tree. The dependencies are:

Makefile.am -> (bin/reconfigure) -> Makefile.in -> (configure) -> Makefile

Reconfigure should also be used when any change is made to configure.in.


Adding a source file to an existing program or library

Suppose you want to add the source file h5testfoo.c to the HDF5 test library in the test directory. You open up test/Makefile.am in your favorite text editor and scroll down until you see the line:

libh5test_la_SOURCES=h5test.c testframe.c

Just add h5testfoo.c to the list of sources. You're done!
Now run bin/reconfigure to create a new Makefile.in from the Makefile.am you just edited.


Adding a simple test

Suppose you want to create a new test executable named newtest with one source file, newtest.c. You open up test/Makefile.am and find the line

TEST_PROG=testhdf5 lheap ohdr ...

Just add newtest to the list of programs. That's it!� Automake will by default guess that your program newtest has one source file named newtest.c.
Now run bin/reconfigure to update the Makefile.in.


Adding a slightly more complicated test

Suppose you want to create a new test executable named newertest with several source files. You open up test/Makefile.am as before and find the line

TEST_PROG=testhdf5 lheap ohdr ...

Add newertest to the list of programs.
Now you need to tell Automake how to build newertest. Add a new line below TEST_PROG:

newtest_SOURCES = source1.c source2.c source3.c

You don't need to mention header files, as these will be automatically detected.
Now run bin/reconfigure to update the Makefile.in.


Adding a test script

For the most part, test scripts are handled like test programs, except that they don't need to be compiled. You can specify a test script using the check_SCRIPT variable:

TEST_SCRIPT=testh5dump.sh

When your build directory is not the same as your source directory, scripts are often located in the source directory (unlike tests, they are not created when the library is built). If this is the case, be careful to specify the full name of the script using the ${srcdir} variable.

TEST_SCRIPT=testh5dump.sh ${srcdir}/testh5dumpxml.sh

Scripts also need to be told which program they're testing. Do this using the SCRIPT_DEPEND variable.

SCRIPT_DEPEND=h5dump${EXEEXT}

This way, whenever h5dump changes, the Makefile will know that these test scripts need to be run again. After you make changes to a Makefile.am, don't forget to run bin/reconfigure!


Adding a directory

To add the directory for a new tool, h5merge, go to the Makefile.am in the tools directory (the parent directory of the directory you want to add). Find the line that reads

SUBDIRS=lib h5dump...

Add h5merge to this list of subdirectories.
Now you probably want to create a Makefile.am in the h5merge directory. A good starting point for this Makefile.am might be the sample Makefile.am in the config directory (config/Makefile.am.blank). Alternately, you could copy the Makefile.am from another directory.
Once you have your new Makefile.am in place, edit configure.in in the root directory. Near the end of the file is a list of files generated by configure. Add tools/h5merge/Makefile.in to this list.
Now run bin/reconfigure. This will update configure and generate a Makefile.in in the tools/h5merge directory. Don't forget to add both the Makefile.am and the Makefile.in to CVS, and to update the manifest!.


Adding a program that is only compiled in parallel

Suppose you only want to compile a program when HDF5 is configured to run in parallel--for example, a parallel version of h5repack called h5prepack. Open up the h5repack Makefile.am
The simple solution is:

if BUILD_PARALLEL_CONDITIONAL
   H5PREPACK=h5prepack
endif

Now the variable $H5PREPACK will be "h5prepack" if parallel is enabled and "" if parallel is disabled. Add $H5PREPACK to the list of programs to be built:

bin_PROGRAMS=h5repack $(H5PREPACK)

Add sources for this program as usual:

h5prepack_SOURCES=...

Don't forget to run bin/reconfigure when you're done!


Changing a program's name when it is compiled in parallel

Automake conditionals can be a very powerful tool. Suppose that instead of building two versions of h5repack during a parallel build, you want to change the name of the tool depending on whether or not HDF5 is configured to run in parallel--you want to create either h5repack or h5prepack, but not both.
Open up the h5repack Makefile.am and use an automake conditional:

if BUILD_PARALLEL_CONDITIONAL
   H5REPACK_NAME=h5prepack
else
   H5REPACK_NAME=h5repack
endif
bin_PROGRAMS=$(H5REPACK_NAME)

Now you only build one program, but the name of that program changes. You still need to define sources for both h5repack and h5prepack, but you needn't type them out twice if they are the same:

h5repack_SOURCES=...
h5prepack_SOURCES=$(h5repack_SOURCES)

Don't forget to run bin/reconfigure when you're done!


Adding a new library

Suppose you want to add a new library to the HDF5 build tree, libfoo. The procedure for building libraries is very similar to that for building programs:

lib_LTLIBRARIES=libfoo.la
libfoo_la_SOURCES=sourcefoo.c sourcefootwo.c

This library will be installed in the lib directory when a user types "make install".
You might instead be building a convenience library for testing purposes (like libh5test.la) and not want it to be installed. If this is the case, you would type

check_LTLIBRARIES=libfoo.la
instead of
lib_LTLIBRARIES=libfoo.la

To make it easier for other directories to link to your library, you might want to assign its path to a variable in all HDF5 Makefiles. You can make changes to all Makefiles by editing config/commence.am and adding a line like

LIBFOO=$(top_builddir)/foo/src/libfoo.la

config/commence.am is textually included in all Makefiles.am when automake processes them.
As always, if you change a Makefile.am or config/commence.am, don't forget to run bin/reconfigure.


Changing HDF5's API

If you have added or removed a function from HDF5, or if you have changed a function signature, you should indicate this by updating the file lt_vers.am located in the config directory. The libtool shared library version number helps users who use HDF5 applications to link dynamically against new versions of the library. Don't confuse libtool's versioning system with HDF5's library version--the two numbers are not related!

If you have changed the API at all, increment LT_VERS_INTERFACE and set LT_VERS_REVISION to zero. This tells users (and their linkers) that the interface has changed.

If you have added functions but not altered or removed existing ones, also increment LT_VERS_AGE. The age of an interface is its "backwards compatibility," the number of previous interfaces that can use this interface. When you increase both the interface number and the age, you are telling linkers that programs that could use the previous interface can still use this one.

If instead you have altered or removed any functions, reset LT_VERS_AGE to zero. Previous interfaces should not count on being able to use this interface, since some functions might not be present (or might have changed their signatures).

LT_VERS_REVISION is incremented when the library changes internally but the API does not. You shouldn't need to increment it, since this should be done automatically during a snapshot release.