blob: 5259ee52ba20286d665949d5cd1050e6ce615615 (
plain)
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
|
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.
|
