Best way to output multiple executables for the same chapter and language #954

Current Behaviour

Currently SCons assumes that each language's implementation of each chapter has only a single file that needs building. Having multiple files that are compiled together into a single executable is a special case that justifies a SConstruct file to handle it specifically, but often there are two or more files that are compiled into separate executables, such as in Stacks and Queues. An minimal example of the current structure generated is

arcane-algorithm-archive/
|──build/
|   |──c/
|   |   +  barnsley.exe
|   |   +  euclidean_algorithm.exe
|   |
|   |──python/
|   |   +  barnsley.py
|   |   +  euclidean_algorithm.py

If a language has multiple implementations for a chapter, or implements parts of the chapter in separate files then the executable generated from one file will overwrite the other (SCons will actually detect this, throw an error and not build either which is arguably worse).

Desired behaviour

We want all the files to be compiled into separate executables. In order to do this they need either different names or to be put into different folders. Multiple ways to do this have been suggested, described below along with pros and cons for them.

Option 1: Duplicate the structure of arcane-algorithm-archive/contents

This would be putting the executables into folders depending on their chapter, in folders based on language. The executables would be named the same as the source file (with the extension changed as necessary). The structure of this is below

arcane-algorithm-archive/
|──build/
|   |──barnsley/
|   |   |──python/
|   |   |   +  barnsley.py
|   |   |──c/
|   |   |   +  barnsley_1.exe
|   |   |   +  barnsley_2.exe
|   |
|   |──euclidean_algorithm/
|   |   |──python/
|   |   |   +  euclidean_algorithm.py
|   |   |──c/
|   |   |   +  euclidean_algorithm.exe

Pros:

• Easy to navigate
• Will not run have naming issues in future unless the structure of arcane-algorithm-archive/contents is changed
• Building specific chapters is easy with SCons

Cons:

• Deeply nested
• Redundant folder dulplication of the language folders
• Building specific languages is difficult with SCons (unless this is implemented specifically)

Option 2: Same as Option 1, but with languages being the outer folders

This has most of the same pros and cons as Option 1, however building specific languages is easy and specific chapters hard

Option 3: Suffix files with _source_file_name

This would have the same structure as currently, however the executable names would be chapter_filename. The folder structure this would generate is below

arcane-algorithm-archive/
|──build/
|   |──c/
|   |   +  barnsley_barnsley_1.exe
|   |   +  barnsley_barnsley_2.exe
|   |   +  euclidean_algorithm_euclidean.exe
|   |
|   |──python/
|   |   +  barnsley_barnsley.py
|   |   +  euclidean_algorithm_euclidean.py

Pros:

• Folders are no more deeply nested than currently
• Building specific langauges is easy

Cons:

• Many redundant file names e.g. barnsley_barnsley.py
• 'Feels' like a rehash of Option 2, with prefixes instead of folders

Option 4: Only suffix with file name when multiple files are present

Example structure:

arcane-algorithm-archive/
|──build/
|   |──c/
|   |   +  barnsley_barnsley_1.exe
|   |   +  barnsley_barnsley_2.exe
|   |   +  euclidean_algorithm.exe
|   |
|   |──python/
|   |   +  barnsley.py
|   |   +  euclidean_algorithm.py

Pros:

• Folders are no more deeply nested than currently
• Building specific langauges is easy
• No redundant file names

Cons:

• Still 'feels' like a rehash of Option 2

Option 5: Use subfolder when multiple files are present

This is a mix of Option 4 and Option 2. The executables are named after the chapter name when there is only 1 file, and named after the source file name when multiple are present

arcane-algorithm-archive/
|──build/
|   |──c/
|   |   |──barnsley/
|   |   |   +  barnsley_1.exe
|   |   |   +  barnsley_2.exe
|   |   +  euclidean_algorithm.exe
|   |
|   |──python/
|   |   +  barnsley.py
|   |   +  euclidean_algorithm.py

Pros:

• Building specific langauges is easy
• No redundant file names
• Uses folders instead of prefixes

Cons:

• Sometimes more deeply nested than currently, albeit rarely
• (Slightly) harder to traverse programatically

Conclusion

All of these are technically possible, with the exception of being able to build by language in Option 1 and the equivilents in the other options. This isn't a problem with SCons, a decision will be needed regardless of if its built with SCons, make, or our own script.