From 66eb96172a9076596ae347b703b3782dc83f6c93 Mon Sep 17 00:00:00 2001 From: Karen Arutyunov Date: Thu, 29 Sep 2016 23:04:04 +0300 Subject: Update idea: Module to help with managing project versions --- build2/version-management-module | 13 ++++--------- 1 file 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. -- cgit v1.1