summaryrefslogtreecommitdiff
path: root/build2/version-management-module
diff options
context:
space:
mode:
Diffstat (limited to 'build2/version-management-module')
-rw-r--r--build2/version-management-module13
1 files changed, 4 insertions, 9 deletions
diff --git a/build2/version-management-module b/build2/version-management-module
index f4086dd..caed945 100644
--- a/build2/version-management-module
+++ b/build2/version-management-module
@@ -1,22 +1,17 @@
-- module to help with managing project versions [idea]
+- Module to help with managing project versions [idea]
The place where we have all the information (this project version, all its
dependencies and their versions) is the manifest. So what if we have a module
-which loads the manifest (using libbpkg), extracts all this information, and
-presents it to the buildfile in a nicely parsed and converted way. That is,
-split MAJOR/MINOR/PATCH, pre-release, converted to numeric form, etc.
+which extracts this information from the manifest (using libbutl), and presents
+it to the buildfile in a nicely parsed and converted way. That is, split
+MAJOR/MINOR/PATCH, pre-release, converted to numeric form, etc.
We can then use this to set all the buildfile-level values (version, revision,
abi_*, etc) as well as generate the version file and even generate the version
header which will define this library version as well as check versions of
dependencies. This generation will probably be done via a custom/inline rule.
-* Since this module will depend on libbpkg, would make sense to make it dyn
- loadable and optional (include pre-generated files in dist).
-
* Will require the use of semantic versioning.
* What about using build2@X.Y.Z? Theoretically, the version module could
even issue this. Though it is optional.
-
-* Don't think we allow bootable optional modules at the moment.