Multiple versions of an application

The environment is well suited for handling multiple versionsof an application targeting different operating systems.

Hint: The default output paths assigned by the environmentchange based upon the target operating system. For example, the OBJ output directoryis named win32obj when targeting Win32 and named linuxobj when targeting Linux.  Thisallows the user to maintain multiple versions of their programs in a single directorystructure which target different operating systems. This could be done within thesame directory structure, but each version would overwrite the others object andsymbol files, forcing everything to be re-compiled when switching between projects.

Lets assume the following

• We have a single application that can be build for Win32 or Linux.
• The source directories are all the same, or at least mostly the same.
• The project files are in the same directory.

In this case you nave nothing to do since the environment bydefault will automatically place the object and symbol files into unique directories.This allows both projects to coexist with the same source directories, but differingsymbol and object directories.

Now lets consider an example that we use for our Modula-2 compilers.

The scenario is as follows

• We want to build multiple compilers.
• Multiple code generation targets are supported.
• Multiple host platforms for the compiler executable are supported.
• All of the source directories are identical.
• The project files for each executable are to be in the same directory.
• Version tags select any changes necessary in the multiple versions.

The solution we came up with was to have unique sym and obj outputdirectories for each unique target, and each project would uniquely identify theprogram, host platform, and code generation target. The net result here is that wecan have four different versions of the compiler, all using the same source files,in the same directory, and all versions can peacefully coexist without harming theothers while compiling. In this example all versions link to the same executablename m2.exe. We could have set things up such that each project linked to a differentexecutable name, but that was deemed to be an unnecessary complication. The Examplescript file shows you the details of this setup.