Next, you need to know which languages you will need.

One way to do this is to create a complex language definition that performs all of the steps required to go from source to executable code or to whatever you want the final result to be. The drawback to this approach is that when anything changes all of the steps are performed rather than the minimal set. For example, suppose there was a language that:

1. Compiled C source to an .obj
2. Compiled the resource source to an .res
3. Linked the .obj files into an .exe
4. Ran the resource compiler to add the resources from the .res to the .exe file

If the resource source changes, all of those steps are performed when some of them could be avoided.

Another approach is to create a language for each step. However, some tools produce outputs that are only needed until the next command is run. For example, the output from step 3 should not be saved into the hierarchy until after the resource compiler has been run. Saving one .exe into the SCLM hierarchy from the compiler and another copy from the resource compiler increases the project data set size and the time required to build.

A better approach is to create languages for each step that produces outputs that are kept permanently in the hierarchy. So, for the previous example, you would need three languages:

1. One language to compile C source and store the .obj files
2. One language to compile the resource source and store the .res files
3. One language to link the .obj files and add the resources from the .res files.