The files which control the build system are named "Makefile.mm". Developers should not touch Makefile.am, as these are automatically generated by the autoconf/automake wrapper.
Makefile.mm files contain zero or more lines of the form keyword [name1] [name2] ... where keyword is a directive for the autoconf/automake wrapper which controls the creation of the actual Makefiles, and the [names] are zero or more arguments for the keyword. More details on keywords and their arguments can be found below.
Lines in Makefile.mm which start with the '#' character are ignored. Blank lines are also ignored. Note that backspace continuation (i.e. terminating a line with a backspace to join multiple lines) is not supported.
The build system uses the notion of a "package". A package is a collection of related source files which compiles to a single target (either a library or an executable program). The one-to-one relation between a package and a single target is strict; to create more than one executable, for example, one package per executable must be created.
Each package is associated with a directory. All the source files for a package must be contained in the package directory or its subdirectories.
Package directories may contain subdirectories which are themselves associated with some other package. Typically this is used to create executable packages which are closely related to library packages; the executable package directory becomes a subdirectory of the the library package directory.
The name of a package is the same as the name of its associated directory. Package names must be unique across OA Gear.
Each package must have a Makefile.mm in its associated directory which controls the compilation of that package.
The Makefile.mm for a library package should start with the keyword type library to indicate the type of the package. This should be followed by one or more lines of the form source [file1] [file2] ... which list the source files to be included in the library. *.cpp, *.h, .lxx and *.yxx files should be listed. *.cxx and *.hxx files generated by lex/yacc should not be listed.
If the package uses another package (i.e. requires header files from another package) the keyword requires [packageName] should be used. If more than one package is required this keyword can be repeated for each required package. Note that the order that the packages are listed is used to determine the order the libraries are passed to the linker. If package A requires packages B and C, and package B requires package C in turn, then the Makefile.mm for package A should list package B before package C.
If the package uses an external package the keyword external [externalPackageName] should be used. A list of the recognized external packages can be found below. If more than one external package is used, this keyword should be repeated for each.
The name of the library file created for a library package is lib[packageName].a, where [packageName] is the name of the package.
The Makefile.mm for a program package should start with the keyword type program The source, requires and external keywords can be used as with library packages.
The name of the executable created for a program package is the same as the name of the package itself.
Libraries should have subdirectories named "UnitTest". These should contain the files related to the unit tests for that library. The UnitTest subdirectory should contain a Makefile.mm which is identical to that of a program package, but the type directive should instead be type unittest
Libraries should have subdirectories named "Documentation". These should have a Makefile.mm where the type directive is type documentation
Additional directives of the form source [file1] [file2] ... should be used to indicate *.fig files used for figures.
Currently Doxyfile.in is not automatically created; this will have to be created by hand (or copied from an existing Doxyfile.in and modified).
The documentation must be updated according to maintainness purpose when the source code is changed. The documentation is generated by doxygen. To generate documentation, one must type "make doc" in the "Documentation" directory.
The setup-developer script in the Build/ directory should be run whenever a Makefile.mm is deleted from or added to the source tree (changing a directory's name or moving a directory can be considered a deletion followed by an addition). cd to the top level directory and execute Build/setup-developer Note that ./configure should also be run after setup-developer.
If Makefile.mm files are simply edited, it is not necessary to rerun setup-developer. "make" will regenerate the appropriate files.
Normally developers should only need to edit Makefile.mm in the appropriate (sub)directories.
Makefile.am is now generated automatically from Makefile.mm. While hand-generated Makefile.am files are now deprecated, they may still be used with the wrapper (and are still currently being used, where conversion to the new Makefile.mm format has not been done yet). Note that, in a directory which contains both Makefile.am and Makefile.mm, Makefile.am should never be modified by hand, as any changes will be overwritten by the automake wrapper.
Developers should never modify configure.ac by hand. The autoconf wrapper scans for subdirectories and modifies configure.ac automatically using the template file Build/configure.mm.
BruinSyn is developed under Redhat Linux 9.1. Source code is compiled by g++3.2.3. It is built on the Open Access (OA) package. Currently we are using the OA library compiled by g++3.2.3. To make sure the compability of the OA library and our BruinSyn package, we'd better use g++3.2.3 to compile our source code. In fact, I saw problems when I use g++3.4.3 to compile BruinSyn package, it will crash for no reason duing runtime. Lexier and yaccer for the VHDL parser are flex 2.5.4 and bison 1.875c, respectively.
1.3.9.1