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
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
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.