@@ -46,33 +46,33 @@ import ReleaseSchedule from './_release-schedule.mdx'
46
46
To be ** reproducible** , an operation must remain stable over time and
47
47
across different environments. In other words, if builds are repeated
48
48
after some time, possibly on a different machine or platform, the
49
- resulting behavior must be functionally equivalent.
49
+ resulting behaviour must be functionally equivalent.
50
50
51
51
</details >
52
52
53
53
<Overview />
54
54
55
55
56
56
57
- ## What are xpm packages? (xPacks)
57
+ ## What are xpm packages? (xPacks) { # xpm - packages }
58
58
59
59
** xpm packages** , abbreviated as ** xPacks** , are versatile,
60
60
language-neutral software packages. They have been successfully
61
61
utilised in C/C++ projects.
62
62
63
63
<details >
64
- <summary >What the heck are xpm packages / xPacks? Please, do not introduce another package format!</summary >
64
+ <summary >What the heck are xpm packages ( xPacks) ? Please, do not introduce another package format!</summary >
65
65
66
- While the initial appearance may seem complex, utilizing
66
+ Although the initial appearance may seem complex, utilising
67
67
xpm packages is, in fact, straightforward.
68
68
The design rationale is to automate frequent
69
- operations that occur during software development, in this case the
69
+ operations that occur during software development, such as the
70
70
installation of
71
71
dependencies, and to ensure reproducibility.
72
72
73
73
These packages are managed by ** [ xpm] ( https://xpack.github.io/xpm/ ) **
74
74
(the xPack Project Manager),
75
- a program that complements the ** [ npm] ( https://docs.npmjs.com/cli/ ) ** CLI
75
+ a programme that complements the ** [ npm] ( https://docs.npmjs.com/cli/ ) ** CLI
76
76
(the popular JavaScript package manager), with new language-neutral features.
77
77
78
78
The xPacks Framework ** does NOT introduce a new package format** ; instead,
@@ -87,34 +87,40 @@ are extracted into separate folders within the project.
87
87
88
88
Based on the content, there are two types of xpm packages:
89
89
90
- - ** source packages** (that install source files, usually libraries) and
91
- - ** binary packages** (that install executables/binary files, usually tools).
90
+ - packages with source libraries (** source** xpm packages)
91
+ - packages with executables, usually platform-specific binary
92
+ tools (** binary** xpm packages)
92
93
93
- Binary packages include references to archives with the platform specific
94
- binaries (such as ` .tar.gz ` for Unix or ` .zip ` for Windows).
94
+ ** Source xpm packages** are regular npm packages that include ** library
95
+ source files** , typically in ** C/C++** , though there are no language
96
+ restrictions.
95
97
96
- These archives are also expanded along the package metadata. Since they
97
- include executables, links/forwarders to
98
+ ** Binary xpm packages** are also regular npm packages, but with minimal
99
+ content, typically just the ` package.json ` file. Since these packages
100
+ provide executables for multiple platforms, some of which are quite
101
+ large, it is not practical to include all binaries within the npm
102
+ package itself. Instead, the ` package.json ` file contains references
103
+ (URLs) to platform-specific binary archives (e.g., ` .tar.gz ` for Unix or
104
+ ` .zip ` for Windows).
105
+
106
+ These archives are also expanded along with the package metadata.
107
+ Links/forwarders to
98
108
these executables are created in a ` .bin ` folder,
99
109
eliminating the need to add multiple folders to the ` PATH ` .
100
110
101
- Given that some binary packages, such as toolchains, can have very large
102
- archives, the packages are extracted only once into a user global location to
103
- conserve space. In projects, instead of duplicating the content of these
104
- archives, symbolic links are created.
105
-
106
- Simply put, xpm packages can be used to further automate the
107
- installation of source libraries and tools.
111
+ In summary, xpm packages can enhance and automate the installation
112
+ process for source libraries and tools.
108
113
109
114
</details >
110
115
111
116
## Features
112
117
113
118
All binaries are:
114
119
115
- - ** self-contained** (include all required libraries)
116
- - ** file-system relocatable** (can be installed in any location)
117
- - built on slightly older systems (to make them run on both old and new systems)
120
+ - ** Self-contained** (include all required libraries).
121
+ - ** File-system relocatable** (can be installed in any location).
122
+ - Built on slightly older systems (to ensure compatibility with both
123
+ old and new systems).
118
124
119
125
<details >
120
126
<summary >Compatibility with older systems</summary >
@@ -143,17 +149,17 @@ location, including in user folders.
143
149
144
150
The main advantages of using the ** xPack Binary Development Tools** are:
145
151
146
- - a convenient, uniform and portable install/uninstall/upgrade
152
+ - A convenient, uniform and portable install/uninstall/upgrade
147
153
procedure; the same procedure is used for all major
148
- platforms (** x64 Windows** , ** x64 macOS** , ** arm64 macOS** , ** x64 GNU/Linux** , ** arm64 GNU/Linux** , ** arm GNU/Linux** )
149
- - multiple versions of the same package can be installed at the same time on
150
- the same system
151
- - no need to worry about dependent libraries, they are all included
152
- - not affected by system updates that
153
- might change the versions of the dependent libraries
154
- - significantly lighter and easier to use than Docker images that provide
155
- similar functionality and are GNU/Linux centric
156
- - projects can be tied to specific tools versions; this provides a good
154
+ platforms (** x64 Windows** , ** x64 macOS** , ** arm64 macOS** , ** x64 GNU/Linux** , ** arm64 GNU/Linux** , ** arm GNU/Linux** ).
155
+ - Multiple versions of the same package can be installed at the same time on
156
+ the same system.
157
+ - No need to worry about dependent libraries, they are all included.
158
+ - Not affected by system updates that
159
+ might change the versions of the dependent libraries.
160
+ - Significantly lighter and easier to use than Docker images that provide
161
+ similar functionality and are GNU/Linux centric.
162
+ - Projects can be tied to specific tools versions; this provides a good
157
163
reproducibility, especially useful in ** CI/CD** environments.
158
164
159
165
<OtherBenefits />
0 commit comments