2011-06-22T17:44:20Z

Brad Berg: /* Create your Sandbox */

These are terse instructions for setting up a typical sandbox at Brown using Linux. Even if you intend to develop on a different platform such as Windows you should initially get set up on Linux. If you need more explicit instructions or you want a more complex setup then revert back to the full instructions.

== Create your Sandbox ==

Create a user directory for yourself in the groups work area. Be sure to use your login name as the directory name. Before you do anything double check to see that your primary group is graphics. If it is not ask tStaff (mail problem@cs.brown.edu) to change it for you.

> groups
graphics grad guest # The first item must be graphics.
> mkdir /research/graphics/users/$USER

== Set Environment Variables ==

Setup your environment variables in the login script for your shell. If you are using Windows you will also want to set these variables on your Windows system as well.

<pre>
Linux Windows

CVSROOT /map/gfx0/cvsroot Y:\map\gfx0\cvsroot
GROOT /map/gfx0 Y:\map\gfx0
G /map/gfx0/users/$USER Y:\map\gfx0\users\<User ID>
GTO /map/gfx0/users/$USER Y:\map\gfx0\users\<User ID>
GARCH linux WIN32
</pre>

The '''G_COMPILER''' variable is set to the compiler you want to work with. This may change depending on project requirements. Most projects will build if you set it to '''gcc4''' on Linux and '''cl9''' on Windows. Supported settings are:

<pre>
Linux Windows

gcc2 - gcc version 2.95 cl6 - Microsoft Studio version 6
gcc3 - gcc version 3.4 cl8 - Microsoft Studio version 8 (2005)
gcc4 - gcc version 4.1 cl9 - Microsoft Studio version 9 (2008)
</pre>

Also on Linux set your umask in your login shell to: 002

umask 002

== Get the Build System ==

The '''common/''' directory has the build make files and shared programs and libraries written at Brown. You only need the '''common/build/''' directory to develop programs, but since you probably will eventually want other common code just check the whole directory out.

> cd /map/gfx0/users/$USER
> cvs co common

When software is installed (via the "make install" command) it is copied to the install directory. There is an install directory for each platform. Create install directories for Linux and Windows with:

> mkdir /map/gfx0/users/$USER/install_linux
> mkdir /map/gfx0/users/$USER/install_WIN32

The install directories are populated by a "make install" command and are organized like this:

install_linux/lib/<Project Name>/lib*.a
install_linux/bin/<Project Name>/<Program>
install_linux/include/<Project Name>/*.h

Try a simple build to see that everything is properly set up.

> cd /map/gfx0/users/$USER/common/utility
> make all # Build the utilities.
> make install # Install the utilities.

Here is a transcript for [[Building and Installing Common Components]].

This should populate the install directory. Take a look with:

> ls /map/gfx0/users/$USER/install_linux/*/*

== Get Project Code ==

Project code is kept in CVS under the '''project/''' directory. Note that inside your sandbox project code can be kept in any directory and you can have multiple versions of projects in different directories. If you want to work with a project already in CVS then you can check it out now.

> cd /map/gfx0/users/$USER
> cvs co project/<Project Name>

If you want to create a new project then make a new directory for it in your sandbox.

> mkdir -p /map/gfx0/users/$USER/project/<Project Name>

You are free to organize your project within the new directory as you see fit. For instructions on writing make files visit:

https://sourceforge.net/apps/mediawiki/vrg3d/index.php?title=Writing_Make_Files

== Get Third Party Software ==

Many projects depend on downloaded software. Create the '''import/''' directory in your sandbox where downloaded software is installed.

> mkdir /map/gfx0/users/$USER/import

The packages you need are determined by the projects you are working on. Project documentation is the first place to check for required software. Copies of some packages are installed in a shared public area, however the public area may not have the versions your projects require and the installations may change over time without notice. The only sure fire method is to download and install the software.

To see how the '''import/''' directory is organized and what packages are installed browse the public installations:

/map/gfx0/tools/linux/import/...

If there is a copy there that looks like one you need you can first try it and if it doesn't work then download and install your own copy. Copy the packages you need from the public area to your own:

> copy -R /map/gfx0/tools/linux/import/<Package> /map/gfx0/users/$USER/import

== Build a Project on Windows ==

Windows users need a few Unix utilities installed to build projects. You can check these out of cvs on a Linux computer with:

> cd /map/gfx0/users/$USER
> cvs co import/make # Check out the utilities on a Linux computer.
:
> ls /map/gfx0/users/$USER/import/make/g.utility_1.0/
CVS/ cp.exe* echo.exe* libiconv2.dll make.exe* mkdir_gnu.exe*
READ_ME.txt diff.exe* false.exe* libintl3.dll mkdir.exe* rm.exe*

Now switch to the Windows computer. You will need to add the path to '''g.utility_1.0\''' to the front of your Windows '''PATH''' environment variable. On Windows the path is '''"Y:\map\gfx0\users\<User ID>\import\make\g.utility_1.0"''' After it is set verify that you can run these utilities from the command shell of your choosing. The native Windows command shell is '''cmd.exe'''.

If you've not already done so, set your Windows environment variables according to the section "Setting Environment Variables". To see if you can build software run the 'cmd.exe' shell and try:

> cd/d Y:\map\gfx0\users\<User ID>\common\utility
> make all # Build utilities on Windows.
> make install # Install them to: install_WIN32/

Finally inspect '''Y:\map\gfx0\users\<User ID>\install_WIN32''' to ensure it was properly populated.

2011-03-11T15:27:27Z

Brad Berg: /* Coding Tips */

Just about everyone in the [[VRL]] ends up re-using code and programs that someone else wrote previously, and undoubtedly the code that they write will be used by someone else in the future. Therefore the golden rule applies well to software development in our lab: do unto others as you would have them do unto you. This page records best practices for getting started developing software in an environment where code lives on through many generations of researchers.

The primary things to keep in mind are that:
* Future users of your code need read and write permission; and
* Future users of your code can't read your mind, so it must be organized and well-documented.

=== Minimal Coding Conventions ===

* Tabs are only meaningful in your edit session.
Do not use tabs (except in Makefiles as needed).
Indent 4 spaces, but 3 is okay if you prefer.

* Name script files with suffixes.
Use Python for scripts (very portable).
Avoid reliance on Cygwin.

* Commenting code does not slow progress.
If you make it a habit it speeds things up.
At a minimum write a method’s purpose and parameter usage.

* Linux file system links are not portable. Never use them.

=== Coding in C++ ===

* Use .cpp and .h suffixes for c++ source file names. Not: .C and .H

* Avoid conditional compilation (#ifdef).

* Use brackets around code bodies over multiple lines.

<pre>
Evil: if (condition)
action;

Good: if (condition) action; if (condition) { action };

if (condition) if (condition)
{ action; {
} action;
}
</pre>

* Line up brackets so they are easier to match visually.

* Do not #include .cpp files.

=== Coding Tips ===

* Order <code>#include</code> statements from the most universal to the more specific. The likelihood of interference between headers is diminish and the code is easier to read. For example:

<pre>
#include <unistd.h> // Standard C headers.
#include <fstream> // Standard C++ headers
#include <sys/types.h> // Low level system headers.

#include <mri/image.h> // Common Brown libraries.
#include <utils/Utils_SVD.h> // Internal project libraries.

#include "../setup/setup.h" // Internal project headers.
#include "Config.h" // Headers in the same directory.
</pre>

* The order that libraries are linked to build a program is significant.

In some cases the link order has been established for you when you use the [[G_USE]] variable. The [[LDLIB_VER]] and [[LDLIB_PROJECT]] variables are shorthand for linking the correct versions of libraries.

Libraries are linked in the the order they are listed on the link step. Libraries can contain different methods with the same names. Conflicts are resolved by the link order. Only methods that are referenced by the program or methods in other libraries are linked. Consequently if a method in a library calls a method in a second library then the second library must be listed after the first.

In the link step of a build you will know there is a library out of order or missing if you get error messages regarding undefined references. To fix this locate the library containing the missing method or variable. If the library is not being linked, add it. Otherwise move it back in the link order.

[[Category:HOWTO]][[Category:$G HOWTO]][[Category:Software Development]]

2011-03-11T14:52:27Z

Brad Berg:

Just about everyone in the [[VRL]] ends up re-using code and programs that someone else wrote previously, and undoubtedly the code that they write will be used by someone else in the future. Therefore the golden rule applies well to software development in our lab: do unto others as you would have them do unto you. This page records best practices for getting started developing software in an environment where code lives on through many generations of researchers.

The primary things to keep in mind are that:
* Future users of your code need read and write permission; and
* Future users of your code can't read your mind, so it must be organized and well-documented.

=== Minimal Coding Conventions ===

* Tabs are only meaningful in your edit session.
Do not use tabs (except in Makefiles as needed).
Indent 4 spaces, but 3 is okay if you prefer.

* Name script files with suffixes.
Use Python for scripts (very portable).
Avoid reliance on Cygwin.

* Commenting code does not slow progress.
If you make it a habit it speeds things up.
At a minimum write a method’s purpose and parameter usage.

* Linux file system links are not portable. Never use them.

=== Coding in C++ ===

* Use .cpp and .h suffixes for c++ source file names. Not: .C and .H

* Avoid conditional compilation (#ifdef).

* Use brackets around code bodies over multiple lines.

<pre>
Evil: if (condition)
action;

Good: if (condition) action; if (condition) { action };

if (condition) if (condition)
{ action; {
} action;
}
</pre>

* Line up brackets so they are easier to match visually.

* Do not #include .cpp files.

=== Coding Tips ===

* Order <code>#include</code> statements from the most universal to the more specific. The likelihood of interference between headers is diminish and the code is easier to read. For example:

<pre>
#include <unistd.h> // Standard C headers.
#include <fstream> // Standard C++ headers
#include <sys/types.h> // Low level system headers.

#include <mri/image.h> // Common Brown libraries.
#include <utils/Utils_SVD.h> // Internal project libraries.

#include "../setup/setup.h" // Internal project headers.
#include "Config.h" // Headers in the same directory.
</pre>

* The order that libraries are linked to build a program is significant. In some cases the link order has been established for you when you use the [[G_USE]] variable. The [[LDLIB_VER]] and [[LDLIB_PROJECT]] variables are shorthand for referencing the correct versions of libraries.

Libraries are linked in the the order they are listed on the link step. Libraries can contain different methods with the same names. Conflicts are resolved by the link order. Only methods that are referenced by the program or methods in other libraries are linked. Consequently if a method in a library calls a method in a second library then the second library must be listed after the first.

In the link step of a build you will know there is a library out of order or missing if you get error messages regarding undefined references. To fix this check locate the library containing the missing method or variable. If the library is not being linked, add it. Otherwise move it back in the link order.

[[Category:HOWTO]][[Category:$G HOWTO]][[Category:Software Development]]

Minimal Coding Conventions

2011-03-10T20:06:05Z

Brad Berg: /* Coding Tips */

Minimal Coding Conventions

2011-03-10T20:05:33Z

Brad Berg:

Writing Make Files

2011-03-08T18:11:47Z

Brad Berg: /* Make File Contents */

A Makefile that uses the G Build make system will build a single directory containing one library and/or one or more programs. Projects can consist of a directory tree with a Make File in each directory.

If you are new to Make you will need to familiarize yourself with it before reading this document. Make is a fairly user hostile language. The semantics are difficult to learn and error messages tend to be uninformative. However, Make is a language that is hard to avoid so most programmers become familiar with it. The G Build system uses Gnu make as it has consistent behavior over many platforms.

http://www.gnu.org/software/make/manual/make.html

Sample Makefiles for a simple '''[[program]]''' and '''[[library]]'''.

=== '''Make File Contents''' ===

* '''Make Variable Settings'''

[[G_COMPILER]] = <Compiler Version> Designate a compiler and version.
[[PROJECT]] = <Project Name> Required project name.
[[PROJECT_HOME]] = <Root Directory> Subdirectories reference the project root.

[[LIBRARY]] = <Library Name> Use when the directory contains a library.
[[CXXSRC]] = <C++ Source>.cpp ... List C++ source files for a library.
[[CSRC]] = <C Source>.c ... List C source files for a library.
[[INCLUDE_H]] = <C/C++ Header> ... List public library headers to install.

[[PROGRAM]] = <Program Name> ... List each program in the directory.
[[CXX]]<Program> = <C++ Source>.cpp ... List C++ source files for a program.
[[C]]<Program> = <C Source>.c ... List C source files for a program.

[[G_USE]] = <Package Name> ... Predefined settings for packages.
[[LDLIB_VER]] = <Library Name> ... Link a program with a library.
[[LDLIB_PROJECT]] = <Project Name> ... Add a project library to the search path.

* '''Variable Settings For Experts'''
[[BIN_SCRIPT]] += <Script Files> ... Install files in the bin directory.
[[SHARE_FILE]] += <Shared Files> ... Install files in the share directory.

[[LDLIB]] += <Linker Setting> ... Pass libraries directly to the linker.
[[CXXFLAGS]] += <C++ Compiler Flag> ... Pass flags directly to the C++ compiler.
[[CFLAGS]] += <C Compiler Flag> ... Pass flags directly to the C compiler.
[[CXXINC]] += <Include Directory> ... Pass includes directly to the C++ compiler.
[[CINC]] += <Include Directory> ... Pass includes directly to the C compiler.

Always add this include statement to bring in the G Build make files.

<pre>
include $(G)/common/build/make/directory.make
</pre>

Optionally add this include statement to build using all available compilers. Note that when including this make file additional targets are declared for: 
:::install all allclean

<pre>
include $(G)/common/build/make/build.multiple.make
</pre>

* '''Directory Access variables'''

These variables can be used to access directories to avoid using hard coded paths. Do not set these variables.

[[G_IMPORT]] Location where third party software is installed.
[[G_INSTALL]] Location where files are installed with "make install".

=== '''Projects With Multiple Directories''' ===

Projects can contain a directory tree that can be organized any way the developers chooses. Make files using the Build system each build a single directory in the tree. By convention the default Make target ("make" with no operand) will build the current directory for a single compiler. By convention an "all" target will build the current directory and all of it's subdirectories.

Usually Makefiles in a directory above several subdirectories will use Gnu Make commands to build the subdirectories. In this case you won't need to include the '''directory.make''' file. Here are some typical Gnu Make commands you might want to use:

<pre>
# Require that the all targets always be used.
#
default:
@echo "Use: make all"

clean:
@echo "Use: make allclean"

test:
@echo "Use: make alltest"
</pre>

<pre>
# Create a target to clean all the subdirectories.
#
allclean:
$(MAKE) -C utility allclean
$(MAKE) -C library allclean
$(MAKE) -C program allclean
</pre>

<pre>
# Create a target to build one subdirectory.
#
.PHONY: utility
utility:
$(MAKE) -C utility all
</pre>

Only a small subset of Unix Utilities is included in the G Build system. Limiting the use of Unix commands in rules makes it easier to get a project developed on Unix to work on native Windows. Complex commands can invoke scripts. Python is recommended as you can use it to easily write platform independent scripts with good error reporting.

Writing Make Files

2011-03-07T14:46:26Z

Brad Berg:

A Makefile that uses the G Build make system will build a single directory containing one library and/or one or more programs. Projects can consist of a directory tree with a Make File in each directory.

If you are new to Make you will need to familiarize yourself with it before reading this document. Make is a fairly user hostile language. The semantics are difficult to learn and error messages tend to be uninformative. However, Make is a language that is hard to avoid so most programmers become familiar with it. The G Build system uses Gnu make as it has consistent behavior over many platforms.

http://www.gnu.org/software/make/manual/make.html

Sample Makefiles for a simple '''[[program]]''' and '''[[library]]'''.

=== '''Make File Contents''' ===

* '''Make Variable Settings'''

[[G_COMPILER]] = <Compiler Version> Designate a compiler and version.
[[PROJECT]] = <Project Name> Required project name.
[[PROJECT_HOME]] = <Root Directory> Subdirectories reference the project root.

[[LIBRARY]] = <Library Name> Use when the directory contains a library.
[[CXXSRC]] = <C++ Source>.cpp ... List C++ source files for a library.
[[CSRC]] = <C Source>.c ... List C source files for a library.
[[INCLUDE_H]] = <C/C++ Header> ... List public library headers to install.

[[PROGRAM]] = <Program Name> ... List each program in the directory.
[[CXX]]<Program> = <C++ Source>.cpp ... List C++ source files for a program.
[[C]]<Program> = <C Source>.c ... List C source files for a program.

[[G_USE]] = <Package Name> ... Predefined settings for packages.
[[LDLIB_VER]] = <Library Name> ... Link a program with a library.
[[LDLIB_PROJECT]] = <Project Name> ... Add a project library to the search path.

* '''Variable Settings For Experts'''
[[BIN_SCRIPT]] += <Script Files> ... Install files in the bin directory.
[[SHARE_FILE]] += <Shared Files> ... Install files in the share directory.
[[SHARE_DIRECTORY]] += <Shared Directories> ... Install directories in the share directory.
[[LDLIB]] += <Linker Setting> ... Pass libraries directly to the linker.
[[CXXFLAGS]] += <C++ Compiler Flag> ... Pass flags directly to the C++ compiler.
[[CFLAGS]] += <C Compiler Flag> ... Pass flags directly to the C compiler.
[[CXXINC]] += <Include Directory> ... Pass includes directly to the C++ compiler.
[[CINC]] += <Include Directory> ... Pass includes directly to the C compiler.

Always add this include statement to bring in the G Build make files.

<pre>
include $(G)/common/build/make/directory.make
</pre>

Optionally add this include statement to build using all available compilers. Note that when including this make file additional targets are declared for: 
:::install all allclean

<pre>
include $(G)/common/build/make/build.multiple.make
</pre>

* '''Directory Access variables'''

These variables can be used to access directories to avoid using hard coded paths. Do not set these variables.

[[G_IMPORT]] Location where third party software is installed.
[[G_INSTALL]] Location where files are installed with "make install".

=== '''Projects With Multiple Directories''' ===

Projects can contain a directory tree that can be organized any way the developers chooses. Make files using the Build system each build a single directory in the tree. By convention the default Make target ("make" with no operand) will build the current directory for a single compiler. By convention an "all" target will build the current directory and all of it's subdirectories.

Usually Makefiles in a directory above several subdirectories will use Gnu Make commands to build the subdirectories. In this case you won't need to include the '''directory.make''' file. Here are some typical Gnu Make commands you might want to use:

<pre>
# Require that the all targets always be used.
#
default:
@echo "Use: make all"

clean:
@echo "Use: make allclean"

test:
@echo "Use: make alltest"
</pre>

<pre>
# Create a target to clean all the subdirectories.
#
allclean:
$(MAKE) -C utility allclean
$(MAKE) -C library allclean
$(MAKE) -C program allclean
</pre>

<pre>
# Create a target to build one subdirectory.
#
.PHONY: utility
utility:
$(MAKE) -C utility all
</pre>

Only a small subset of Unix Utilities is included in the G Build system. Limiting the use of Unix commands in rules makes it easier to get a project developed on Unix to work on native Windows. Complex commands can invoke scripts. Python is recommended as you can use it to easily write platform independent scripts with good error reporting.

Software Development

2011-03-07T14:44:03Z

Brad Berg:

* '''Essential Background Reading'''
** [[Shared Public Directory Structure]]
** [[Understanding File Permissions]]
** [[Setting Environment Variables]]
** [[Introduction to CVS]]
** [[Minimal Coding Conventions]]

* '''Create a Linux Sandbox'''
** [[Get a Linux Account]]
** Set up Your Sandbox
*** [[Automated Quick Start|Automated Quick Start - Linux only]]
*** [[Quick Start for CIT Users|Manual Quick Start - Windows and Linux]]
** [[Merge Installed Programs Into One Directory]]

* '''Software Development Tasks'''
** Before you start, [[Building and Installing Common Components]]
** Work on Existing Projects
*** [[Check out projects|Check out and build existing projects]]
*** [[Contribute to projects|Contribute to existing projects]]
** Add a project
*** [[Add a new project]]
**** [[Build a Trivial Program]]
**** [[Build a Trivial Library]]
*** [[Port existing project|Port existing project to the new $G]]
**[[Writing Make Files]]

* '''Advanced Topics'''
** [[Create a Windows Sandbox|Create a Windows Sandbox (In or out of CIT)]]
** [[Software tests|Create and automate software tests]]
** [[Install 3rd party code|Install 3rd-party programs or libraries]]
** [[Using Public or Private Programs and Libraries]]
** [[Multiple Directories|Set up a project with multiple directories]]
** [[Working With Multiple Sandboxes]]
** [[Working With Legacy Software]]
** [[Software demos|Create and install software demos]]
** [[Distribute software|Distribute software and data]]

[[Category:Software Development]]

SHARE DIRECTORY

2011-03-07T14:42:31Z

Brad Berg:

SHARE_DIRECTORY = <Shared Directories> ...

Designate directories to be installed in the '''share/''' directory. The directories typically contain data files, but they can have any type of file. The directories will be installed in:

$GTO/install_$GARCH/share/$PROJECT/

Note that the directories are installed at the top level of the target directory. In order to set up multiple levels of directories you will need to stage them within your project with the desired layout. For example if you wanted to set up a directory '''data/''' with a subdirectory '''data/result/''' you might write this as:

<pre>
SHARE_DIRECTORY = data

install:
rm -r -f data/result
cp -r $(GROOT)/data/$PROJECT/result data
$(MAKE) installshare
</pre>

You can also avoid staging by directly installing the '''data/result/''' directory:

<pre>
SHARE_DIRECTORY = data

install: installshare
rm -r -f $(G_INSTALL)/share/$(PROJECT)/data/result
cp -r -f $(GROOT)/data/$PROJECT/result $(G_INSTALL)/share/$(PROJECT)/data/result
</pre>

SHARE DIRECTORY

2011-03-07T14:42:20Z

Brad Berg:

2011-03-07T14:21:18Z

Brad Berg:

A Makefile that uses the G Build make system will build a single directory containing one library and/or one or more programs. Projects can consist of a directory tree with a Make File in each directory.

If you are new to Make you will need to familiarize yourself with it before reading this document. Make is a fairly user hostile language. The error messages tend to be uninformative. However, Make is a language that is hard to avoid so most programmers are familiar with it. The G Build system uses Gnu make as it has consistent behavior over many platforms.

http://www.gnu.org/software/make/manual/make.html

Sample Makefiles for a simple '''[[program]]''' and '''[[library]]'''.

=== '''Make File Contents''' ===

* '''Make Variable Settings'''

[[G_COMPILER]] = <Compiler Version> Designate a compiler and version.
[[PROJECT]] = <Project Name> Required project name.
[[PROJECT_HOME]] = <Root Directory> Subdirectories reference the project root.

[[LIBRARY]] = <Library Name> Use when the directory contains a library.
[[CXXSRC]] = <C++ Source>.cpp ... List C++ source files for a library.
[[CSRC]] = <C Source>.c ... List C source files for a library.
[[INCLUDE_H]] = <C/C++ Header> ... List public library headers to install.

[[PROGRAM]] = <Program Name> ... List each program in the directory.
[[CXX]]<Program> = <C++ Source>.cpp ... List C++ source files for a program.
[[C]]<Program> = <C Source>.c ... List C source files for a program.

[[G_USE]] = <Package Name> ... Predefined settings for packages.
[[LDLIB_VER]] = <Library Name> ... Link a program with a library.
[[LDLIB_PROJECT]] = <Project Name> ... Add a project library to the search path.

* '''Variable Settings For Experts'''
[[BIN_SCRIPT]] += <Script Files> ... Install files in the bin directory.
[[SHARE_FILE]] += <Shared Files> ... Install files in the share directory.
[[SHARE_DIRECTORY]] += <Shared Directories> ... Install directories in the share directory.
[[LDLIB]] += <Linker Setting> ... Pass libraries directly to the linker.
[[CXXFLAGS]] += <C++ Compiler Flag> ... Pass flags directly to the C++ compiler.
[[CFLAGS]] += <C Compiler Flag> ... Pass flags directly to the C compiler.
[[CXXINC]] += <Include Directory> ... Pass includes directly to the C++ compiler.
[[CINC]] += <Include Directory> ... Pass includes directly to the C compiler.

Always add this include statement to bring in the G Build make files.

<pre>
include $(G)/common/build/make/directory.make
</pre>

Optionally add this include statement to build using all available compilers. Note that when including this make file additional targets are declared for: 
:::install all allclean

<pre>
include $(G)/common/build/make/build.multiple.make
</pre>

* '''Directory Access variables'''

These variables can be used to access directories to avoid using hard coded paths. Do not set these variables.

[[G_IMPORT]] Location where third party software is installed.
[[G_INSTALL]] Location where files are installed with "make install".

=== '''Projects With Multiple Directories''' ===

Projects can contain a directory tree that can be organized any way the developers chooses. Make files using the Build system each build a single directory in the tree. By convention the default Make target ("make" with no operand) will build the current directory for a single compiler. By convention an "all" target will build the current directory and all of it's subdirectories.

Usually Makefiles in a directory above several subdirectories will use Gnu Make commands to build the subdirectories. In this case you won't need to include the '''directory.make''' file. Here are some typical Gnu Make commands you might want to use:

<pre>
# Require that the all targets always be used.
#
default:
@echo "Use: make all"

clean:
@echo "Use: make allclean"

test:
@echo "Use: make alltest"
</pre>

<pre>
# Create a target to clean all the subdirectories.
#
allclean:
$(MAKE) -C utility allclean
$(MAKE) -C library allclean
$(MAKE) -C program allclean
</pre>

<pre>
# Create a target to build one subdirectory.
#
.PHONY: utility
utility:
$(MAKE) -C utility all
</pre>

Only a small subset of Unix Utilities is included in the G Build system. Limiting the use of Unix commands in rules makes it easier to get a project developed on Unix to work on native Windows. Complex commands can invoke scripts. Python is recommended as you can use it to easily write platform independent scripts with good error reporting.