Description
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/contentsis 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.