SLUL Build File format
======================
Sectioned conf format. The tokens are the same as for SLUL files with the
addition of [Sections], which can appear at the start of a line (i.e.
they may not be indented).

    [SLUL Build File]
    name = MyProject
    id = org.kodafritt.myproject
    version = 0.1.0
    repo = git+https://githosting.example/myproject
    repo = git://git.example.org/myproject
    website = https://example.org
    # license for the whole module
    license = GPLv3
    # license override for individual files
    license = GPLv3 a.slul b.slul

    [Dependencies]
    # SLUL should search for:
    #   /usr/share/slul-modules/NAME/IDENTIFIER_VERSION.slul
    #   /usr/share/slul-modules/NAME/IDENTIFIER_VERSION.info
    #   /usr/local/share/slul-modules/NAME/IDENTIFIER_VERSION.slul
    #   /usr/local/share/slul-modules/NAME/IDENTIFIER_VERSION.info
    #   ~/.local/share/slul-modules/NAME/IDENTIFIER_VERSION.slul
    #   ~/.local/share/slul-modules/NAME/IDENTIFIER_VERSION.info
    #   %COMMONFILES%/slul-modules/NAME/IDENTIFIER_VERSION.slul
    #   %COMMONFILES%/slul-modules/NAME/IDENTIFIER_VERSION.info
    #   %APPDATA%/slul-modules/NAME/IDENTIFIER_VERSION.slul
    #   %APPDATA%/slul-modules/NAME/IDENTIFIER_VERSION.info
    # Higher versions may be used as well, since SLUL modules
    # are required to be backward compatible.
    # The .slul files are copies of the interface.slul files for the libraries.
    # The .info files are copies of the slulbuild.conf files.
    #     (the [Source] section could be skipped though)
    gtk3 3.0.0 or qt5
    optional libogg 1.3.0 from org.example.libogg as ogg13
    optional libogg 1.1.0 from org.example.libogg as ogg11

    [Source]
    main.slul
    something.slul
    dir/somethingelse.slul
    "file with spaces.slul"
    "å.slul"

    [Targets]
    # automatic
    executable myproject
    library mylibrary interface.slul
    objfile myobject objfile.slul
    manpage man.1
    # more specific
    executable elf myproject if posix
    executable pe myproject.exe if win32

    [References]
    # Each line corresponds to one possible way to obtain the dependency.
    #
    # Running something like "slul --dep-install=XXX" will download and
    # install dependencies.
    #
    # In the early versions of the "slul" implementated in SLUL,  it will
    # probably not support compilation, and instead call "cslul" for that.
    #
    # When auto-downloading, the download should be keyed to the
    # (URL,signature) tuple or to (hash).
    # Unsigned/unhashed downloads can be used/re-used after a user prompt.
    #
    # Note that # is a special character!
    # But we should have special handling for -+*/ etc.
    gtk3 = gpg:1E39A66D940D... "git+https://githosting.example/user/repo" so-lib:libgtk-3.so
    gtk3 = dist:deb:libgtk3-slul-dev pkgversion:0.1-3
    # should multi-line entries be allowed?
    # these lines specify a specific implementation of libogg
    org.xiph.libogg =
        gpg:329FA354...
        "git+https://githosting.example/user/repo#/some/dir/in/repo"
    org.xiph.libogg 1.1.0 =
        sha256:2E48A53...
        "git+https://githosting.example/user/repo#v1.1.0/some/dir/in/repo"
    somepkg = gpg:C24AF490.... sigfile:.asc "tar+zstd+https://example.org/releases/somepkg-1.0.0.tar.zst"
    somepkg = bundled:lib/somepkg

Syntax definition:

* # is the comment character. It may appear anywhere on a line, but is
  treated as an ordinary character inside strings. A comment may not follow
  directly after a non-whitespace character (this applies to SLUL source files
  also). There may not be a comment inside an entry.
* [ starts a section header. It may contain letters, spaces and digits and
  must end with a ]. It may not have leading, trailing or repeated spaces.
  It must start at the beginning of a line (no indentation allowed).
  If a non-comment token comes before the section header, then there must
  be a blank line inbetween.
* Blank lines are ignored, but they are not allowed inside entries.
* An entry is any of the following:
    1. An identifier/string followed by a = is a key-value entry. 
    2. A section specific keyword (like "executable", "library") followed
       by a series of tokens specific to that keyword.
    3. A single identifier/string.
    4. A single identifier/string optionally followed by a series of tokens
       specific to the section.
* Each type of section allows one kind of entry.
FIXME simplify this?


Styles:
(Should the style be enforced?)

    [Section]
    SomeKey=Value
    OtherKey=Value

    [section]
    some_key=value
    other_key=value

    [Section]
    SomeKey = Value
    OtherKey = Value

    [Section]
    some_key = value
    other_key = value

    [Section]
    Some Key = Value
    Other Key = Value

    [Section]
    some key = value
    other key = value