-
Notifications
You must be signed in to change notification settings - Fork 0
/
COMPILING
113 lines (86 loc) · 4.05 KB
/
COMPILING
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
Unilib Build Instructions
Written by Alexander Nicholi
§1. PREREQUISITES
------------------
1. Arch Linux: base-devel, clang-format
2. Debian: gcc, g++, make, clang-format
3. macOS: XCode tools (note 1), clang-format
§2. BUILD COMMAND
------------------
As of October 2020, unilib has been restructured as a collection of smaller,
modular subfolders in this monorepo. Whenever calling ‘make’, use the -C flag
to tell it to change directories into the desired module’s folder. Note that
each module has a new DEPENDS file in its etc/ directory listing what other
modules it depends on at link time. Makefiles in unilib only build static
libraries.
Use a POSIX-compliant shell, and run ‘make’ to build the default target
(debug). The ‘-j’ option is fully supported for job control, and can be given
an argument for the number of parallel jobs with the form ‘-j$(nproc)’ (on
Linux) or ‘-j$(sysctl -n hw.ncpu)’ (on macOS). The ‘-j$(nproc)’ form works on
macOS too if GNU coreutils is installed.
Several targets are available: debug, release, check, cov, and asan. Below is
a breakdown of each:
debug:
- default for daily development
- consumed nicely by GDB and LLDB
- all asserts enabled
- is unoptimised (-O0) for compilation speed
release:
- for shipping
- has no extra symbols at all
- uses -O2 or -O3 for maximum optimisation
check:
- run for sanity check before diving into the debugger
- turns on ALL warnings, and treats them as errors too
- a successful build is a happy codebase :o)
cov:
- the basic option for unit testing
- actual code coverage is still a WIP
- uses -O1 to provide unobtrusive optimisations
asan:
- a cheap but effective alternative to Valgrind
- requires rebuilding all 3rd-party dependencies with asan (tedious)
- also brings in the unit tests like ‘cov’
The default target is ‘debug’. There are also two additional phony targets,
‘clean’ and ‘format’: the former removes all build artefacts, while the latter
invokes the auto-formatter (usually clang-format, it’s defined as $(FMT) in
base.mk) to run on all the source and header files.
§3. TARGET PLATFORMS
---------------------
Development only happens on one of two platforms: macOS or Linux. All other
platforms are target-only, and macOS and Linux may be targets as well, of
course. The steps for each target will be described below.
Before compiling this repository, be sure to address each subfolder of the
3rdparty/ directory and compile them first. If you just cloned this repository
and the folder is empty, its README file will contain a list of dependencies
and their online locations. Download, clone or symlink them into that folder
to check them in.
§3.1. APPLE macOS
------------------
Targeting macOS is only supported natively. The process uses XCode command
line utilities along with GNU coreutils and binutils (obtainable by Homebrew).
Valgrind, LLDB, and normal debug/release/check builds are supported. On recent
versions of macOS (esp. Mojave and Catalina) you may need to dig around for a
patched Valgrind that runs on those versions.
§3.2. GNU/LINUX
----------------
Targeting Linux is only supported natively. The process can use GCC or LLVM
based tools, and both GCC and Clang are actively used in development. As with
macOS, Valgrind, LLDB, and the usual debug/release/check builds are supported.
GDB is used on Linux as the debugger of choice.
For its simplicity and sheer compilation speed, TinyCC is also used in
development builds. Set ‘CC=tcc’ in the make invocation to try it out.
§3.3. MICROSOFT WINDOWS
------------------------
Windows may be targeted for cross-compilation from either macOS or Linux.
MinGW-W64 is used to achieve this (provided by the system’s package manager),
and runtime testing is done in WINE. For now, this target is still very much a
work-in-progress.
§3.4. ANDROID (AOSP)
---------------------
Currently unevaluated. Pending support checks for a Google-free
cross-compilation environment.
§3.5. APPLE iOS
----------------
Currently unevaluated. Pending examination of Apple toolchains and C-friendly
APIs.