1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
[slul]
name = MyProject
id = org.kodafritt.myproject
version = 0.1.0
# for libraries, this must be updated each time the API is changed.
# this way, API changes can be traced with repeative "git blame" calls (or equivalent).
# - there must be a command to generate "apilock" codes also
# - how about modules that expose multiple APIs / multiple libraries/interfaces?
api.latest = 0.0.8 3fKf3-2kCAvc....
# these could cause problems with the 50 byte limit for values
# (allow up to 250 bytes for repo and website lines? and perhaps other lines?)
# - what limitations do INI parsing libraries have?
repo = git://git.example.org/myproject git+https://githosting.example/myproject
repo.mirror = git://git-mirroring.example.net/myproject
website = https://example.org
# license for the whole module
license = GPLv3
license.file = COPYING
license.list = doc/licenses.txt
[platform]
# default: 32
# - do we need min_pointer? maybe useful for some kind of intptr_t type
min_int = 16
min_pointer = 16
min_size = 16
# default: on
float = false
function_pointers = false
# XXX FIXME we need to split this in:
# 1. dependencies needed to compile the interface
# 2. dependencies needed to compile the implementation
# - have a separate keyword "exposed" to make it usable in the interface
# - in order for a module M that use a module with exposed dependencies, to
# actually be able to access declarations that refer to the "exposed"
# dependencies' types, then M must also list the "exposed" dependencies
# as its own dependencies (but they don't necessarilly have to be listed
# as exposed)
# - this way, recursive dependencies are avoided.
# - XXX what about minimum versions for exposed modules?
# - parsing interfaces of dependencies must be done with care:
# - the interface of a dependency should only be able to access
# declarations from modules that it lists as exposed
# - different modules could have conflicting versions/identifiers
# in exposed dependencies.
# (perhaps simply forbid them from being used together then?)
[dependencies]
glib = exposed
ui = set
ui.gtk3 = 3.0.1
ui.qt5
ui.sdl2
audio = set
audio.sdl2
audio.portaudio
ogglib = optional set
ogglib.ogg =
[source]
main.slul
something.slul
dir/somethingelse.slul
# ^ dots in names... this makes it tricky to add sub-properties later on
# renames, for resolving name conflicts.
# only identifiers in the requested minimum versions become available (and can lead to conflicts).
# unresolved name conflicts simply makes the affected identifiers unavailable.
[renames]
glib.g_keyfile_new = glib_keyfile_new
[targets]
myproject = executable
mylibrary = library interface.slul
myobject = objfile objfile.slul
elfproject = elf if posix
peproject.exe = pe if win32
# ^ dots in names... this makes it tricky to add sub-properties later on
# should we have it? probably a good idea.
# - i think the only downside is that it might use quite a lot of space here after many versions have been released (say 100 versions with API changes...)
# - needs some command like "slul prepare-release" to move obsolete versions here (after prompting?)
# (maybe based on GIT revision history, if not available we can just print an error if the API has changed.)
# - perhaps even require apilock in the [references]?
# perhaps this should be a separate file?
# - that way we could also include basically version control information
# (how the API was changed in each version)
# XXX can recursive incompatiblities happen? if so, how to detect and prevent it?
# XXX there needs to be a way to undo incompatible changes,
# e.g. if version 0.0.9 turns out to break stuff, we want to be able
# to release 0.0.9.1 and go back to the old API (which means that 0.0.9 is
# incompatible with both newer and older versions, but that older versions
# and newer versions remain compatible)
[api]
0.0.1 = sl39fja_kwL...
0.0.4 = a3wstVIi2acC...
0.0.8 = 3fKf3-2kCAvc...
# with changes: (how long will those typically be? how much can we compress the data, and the changes?)
# - can we optimize for compatible changes?
# the only allowed compatible changes are:
# - adding a new function/type/variable/constant
# - adding a field last to an incomplete struct
# - adding a value to an incomplete enum
# - something else?
# - also, all "paths" (of changes) to get to one specific API should result in the same final hash.
# - i.e. an API should be compatible *if and only if* the hash is the same (aside from hash collisions)
# - we should sort everything in a deterministic order.
# - byte 1: name length
# - byte 2: type & number of shared bytes in name with previous name.
# - byte 3: name (6-bit? a-zA-Z0-9_ are the allowed characters)
# - byte 4-: varint of index of return/data type
# - ...
# (or put all this data columns-wise, with delta-coded integers. and maybe compress it?)
# - a change can then be:
# - name length of new item (only additions, not changes!)
# - type & number of shared bytes in name with previous name
# - here we need 5 types (new-func, new-type, new-data, and also new-field and new-enum-value)
# - new-field and new-enum needs a varint index of the modified type
# - 6-bit name
# - varint of index of return/data type
# - ...
# - there needs to be some reserved byte sequence for future extensibility for adding backwards incompatible language features.
[api]
0.0.1 = sl39fja_kwL... sfdaKCO2k3Ck_aFrWdchy55hlafJca52oaFczldfkjAJIda54sscGaxOC34xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...
0.0.4 = a3wstVIi2acC... fdskJALWJLASsafFDFsdfsdfsdfsfdfGSDDVv-dfSDFSDGDSFJVdGLSJKxxxxxxxxxxxxxxxxxxxx...
0.0.8 = 3fKf3-2kCAvc... FKRJcxcfalfccascKkccACFDFFFSdsfsFSDVDSvkldsdsvcxxxvcxxxxxxxxxxxxxxxxxxxxxxxxxx...
2.0.0 = incompatible Dz2gdosd... daKRP3ffsflfAKrOFa2flcaafk-lvosdvmvkDG2xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx....
[references]
# it must be clear that these are just *suggestions*.
# dependencies can still be found in other locations,
# as long as they provide the same *name* (=promise to implement an interface) and are *trusted* by the user.
common.gpg.pubkeys = lib/pubkeys/
# ^ gpg must be connected to a project... this requires that filenames match dependency names
gtk3.repo = git+https://githosting.example/user/repo
gtk3.repo.gpg = 1E39A66D940D...
gtk3.debian = libgtk3-slul-dev
gtk3.debian.min_version = 0.1-3
# make it possible to lock to a specific API (strongly recommended!)
# later versions can still be used, but they must be compatible.
# XXX allow multiple versions/hashes here?
# XXX also, make it clear that this is NOT a GIT revision!
# perhaps use base64url?
gtk3.apilock = 3.0.0 DwsK3sc9fxI5cE....
# lock to a testsuite (this should really have a permissive license, or at least F/OSS)
gtk3.testlock = TODO....
# should the version be included in the key?
# e.g. somepkg.1.0.0.release = xxxxxx
# but it kind of doesn't make sense to link to multiple versions
somepkg.release = tar+zstd+https://example.org/releases/somepkg-1.0.0.tar.zst
somepkg.release.ver = 1.0.0
somepkg.release.gpg = C24AF490....
somepkg.release.sigfile = .asc
somepkg.bundled = lib/somepkg
other.release = tar+zstd+https://example.org/releases/somepkg-*.tar.zst
other.release.verlist = https://example.org/releases/somepkg/
# URLs... should they include tar+zstd or should that be separate?
# - having them in the URL makes it possible to have multiple formats etc.
|
