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
|
Have a base-only "monorepo"? It would contain the following:
* Bootstrap compiler
- Bootstrap compiler itself
- RTL implementation
* Self-hosting compiler
* Base RTL
- Safe, platform independent, code.
- Including slow, unoptimized, functions (e.g. strchr, etc.)
* libc "override RTL"
- Uses C99
- Uses POSIX where available (can it be detected in pure C?)
- Uses Linux/BSD specific functions where available
- Implements native and optimized functions
* Win32 "override RTL"
- Freestanding libc-less, using kernel32/user32
* Assembly-language "override RTL"
- Implements optimized "data" functions, e.g. memcpy, strchr, etc.
* Maybe: no-libc Linux "override RTL"
* Maybe: Assembly-language Linux "override RTL"
* Maybe: Assembly-language <other os> "override RTL"
* Language reference
The top-level items above would then be releasable items, and would have
separate releases archives.
Perhaps they should even have separate versions numbers, and then of course
separate git tagging namespaces, e.g.
bootstrap-0.1.2
slul-0.0.1
slulrt-core-0.1.0
slulrt-core-libc-0.2.1
slulrt-core-linux-0.0.5
....
Combined packages
-----------------
Combined packages could still be build for users who don't want to
download several separate packages.
These could include:
* Everything from the repo itself
* A makefile or build script to build everything
(should be part of the repo)
* Maybe additional modules that are stable, and are useful for users
(e.g. a "SLUL distribution")
The repo needs to include the script to build the combined packages.
It will be necessary to create patch releases and/or diff-sets for
security fixes and other important bug fixes.
Advantages
----------
Easier to get the project started.
Easier to get started with the project (from scratch).
Simpler refactorings (only a good thing as API stability is a complete
non-issue, e.g. 0.0.x, maybe 0.1.x).
Disadvantages
-------------
A bit nonstandard (but common for programming languages, see below!).
Will lead to a LOT of tags.
Difficult to limit push/merge permissions.
Repo could eventually become large (in case SLUL gets widely adopted).
Simpler refactorings (when API stability starts to become an issue,
e.g. "slul 0.2" perhaps).
Harder to do small changes, e.g. 1-line fix in some specific RTL library.
Ties the implementation to the interface, at least symbolically.
What do other proglangs do?
---------------------------
Separate compiler/RTL projects (and of course separate repos):
* C (e.g. gcc/clang + glibc/musl)
Combined compiler/RTL project with separate repos:
* Hare (harec(compiler written in C) and hare(stdlib) are separate)
Combined repo:
* FreePascal (= "compiler, RTL, packages and utilities" and tests)
* Nim (= compiler, RTL, tools, tests)
* Node (= C++ runtime, JS stdlib, docs, tests)
* PHP
* Python (= CPython + C modules + Python modules)
* Rust ("It contains the compiler, standard library, and documentation")
* V (= compiler and "vlib"(RTL))
To check:
* C++ (can you mix and match compiler / libstdc++ / STL?)
* OpenJDK / other common JDKs (do they combine JVM and classes?)
* Ruby
Version numbering?
------------------
* Plain semver?
* Odd(wip)/even(stable) semver?
- But this also leads to multiple x.y.<odd-number>, which can be confusing
|
