A build file vs list files vs single-file
=========================================


List files
----------

Example project structure:

    sources.index
    dependencies.index
    exports.index
    SomeClass.slul

Pros:
+ Trivial to parse in e.g. shell scripts
+ Trivial to generate
+ Maybe lower risk of merge conflicts:
    - sources.index: Only when adding/renaming/removing files.
    - dependencies: Only when adding/removing dependencies or
      when using features from a new API version.
+ Could add commit rules, for example:
    - Allow only specific users to add dependencies
    - Require a code review from one additional person when
      a new symbol is exported (added line in exports.index)
    - Disallow changes/removal of lines in exports.index
+ Most files can be optional:
    - No sources.index = load *.slul
    - No exports.index for applications/non-libraries
    - No dependencies.index when using only the stdlib
      (and the latest version?)

Cons:
- More cluttered project/module directories.
- No file for metadata? But it could be added.
- Could become really cluttered IF lots of new features are added

Build files
-----------

Was used in really early versions of SLUL. Example project structure:

    slulbuild.conf
    SomeClass.slul

Pros:
+ Possibly easier (for a human) to "scan" a new project.
+ Slightly less clutter
+ Can have attributes like name, version, license etc.
+ Extensible

Cons:
- Requires some kind of configuration syntax


Embedded "build header" lines in main.slul file
-----------------------------------------------

Was used in SLUL versions before slul-try2. Example project structure:

    main.slul

Pros:
+ Can have attributes like name, version, license etc.
+ Somewhat extensible

Cons:
- main.slul file could get really large
- (Soft) merge conflicts are very likely if the main.slul file contains
  lots of code and also lots of metadata.
- Tooling that wants to process the metadata needs to be able to parse a
  custom format (hence it should be fairly simple)


Single-file without metadata
----------------------------

This could include the standard library, or maybe even all installed modules.

Example project structure:

    SomeFile.slul

Pros:
+ Very simple to get started with
+ Metadata can be added afterwards, perhaps even generated by a command.

Cons:
- Easy to forget to add the metadata before publishing the source file.