knitschi / cmakeprojectframework Goto Github PK
View Code? Open in Web Editor NEWA C++ project infrastructure.
License: MIT License
A C++ project infrastructure.
License: MIT License
On windows, the version number can be included in the binary. CMake alows us to do this, so we should do it.
We should update all third party components to the latest stable versions before the release is published.
Components:
cmake 3.19 introduced the preset .json files for the same purpose for which I introduced my config.cmake files. Switching to default cmake solution would probably improve acceptance in the user base.
This ticket is about examining if cmakes preset files can replace the custom solution in CPFCMake and CPFBuildscripts and what would need to be done to implement it. We also have not yet removed the duplication of configuration information between the package manager configuration and the local configuration files.
The current solution that pushes the install results to a git repostiry does not work well.
The publish / archive step in the build-pipeline needs to be customizable. So this is what we need to do:
Currently cpf projects do not work well when opened with Visual Studios CMake mode. We get CMake errors and in the target overview the targets have no files attached. We should try to make that VS-feature work for cpf projects.
This would allow sharing build-artefacts between developers.
Allowing the selection of the compiler-configuration after CMake's generate step causes multiplie headaches:
add_custom_command()
. CPFCMake makes heavy use of that function and working around that limitation requires a lot of complicated and error prone CMake code and brings an performance overhead.The advantage of allowing multiple configurations is that Visual Studio users are used to being able to select the build configuration in the UI. But practice showed that you can get used to the alternative workflow where you just open one IDE instance for each configuration that you want to build.
In order to remove the above mentioned problems I decided to change the CPFCMake and CPFBuildscripts to only allow one configuration at a time when using the Visual Studio Generator.
TODO:
cpfCIBuildConfigurations.json
file.3_Make.py
.The documentation is not completely worked out right now. This should be finished when all features for the 1.0 Release are done.
We should consider the following:
Currently we do not verify that the created packages work for consumers. We should try to add custom targets that test if created packages.
The currently enforced structure <build-project-dir>/src/<module_package_dir>
does not allow having multiple module-packages in one module repository.
We also have the constraint that all modules in a deployment-package must be at the same version.
Additionally we want to follow the doctrine that the commits in the repository are the single source for all versions.
All constraints together limit us to only allowing one module per deployment-package. This ticket is about removing this limitation.
We want to extend the cpfAddPackages() funktion to allow package definitions in the packages.cmake file in the form
set( CPF_PACKAGES
EXTERNAL <deployment-package-dir>/x/y/<module_package_dir>
# or
EXTERNAL <single-package-dir>
)
In the second scenario the <deployment-package-dir>
and the <module-package-dir>
have the same name.
It shall be possible to have an arbitrary number of directories in between the <deployment-package-dir>
and the <module_package_dir>
.
The name of the <deployment-package-dir>
shall be the only source for the deployment-package-name
. This is the name that will be used in package managers to retrieve a binary package and as a part of binary archive files. This will also be the name of the CMake export set and the targetnamespace for the all targets that are exported by the module packages.
The name of the <module-package-dir
shall be the only source for the module-package-name
. This is the name of the main target in a module-package. It also appears as the first directory in the C++ #include
statements.
This ticket should also implement the mechanism that derives the deployment-package-name
and the module-package-name
from the relative path in the CPF_PACAKGES
variable and propagates them to the install commands etc. We also need to make sure that package config files are only generated once per deployment-package.
The following issues need to be done before the release.
The major C++ package manager are.
We could also consider making CPFBuildscripts available via pip.
First we should support hunter because this is what I am most familiar with.
We currently use the term package for two different things which will lead to confusion. The work for this ticket is to go through all source-files of the CPF and make sure that comments, function-names, variable-names etc. consistently use the name convention the is described below.
The host-repository that contains root CMakeLists file will be called the deployment-repository.
The toplevel-cmake-project will be called the deployment-project.
The binary archives that can be obtained via package managers are called deployment-packages.
The cmake-projects that are defined in the formerly package CMakeLists file are called module-projects.
The collection of source files that define one production binary target and additional test-targets etc. and that were formerly known as package are now called module-package.
The repository that holds one or multiple module-packages but no top-level CMakeLists file is called the module-repository.
We need automated tests, that run the pipeline with all the underlying tools. Currently we only have a view unit tests for low-level python and cmake code. As these tests will test the functionality of multiple packages at once we should put them in their own package CPFTests
. This package can also contain utility functionality like test driver code or a project generator. The CPFTests
package should create an extra custom target to run the integration tests.
Tests should
Random Questions:
Implementing this ticket is not possible if the conan-profile file does not allow defining arbitrary cmake variables. Before I work on this, I have to check that this is possible.
I imagine the following setup:
2_GetDependencies.py
. The numbers of the following steps need to be incremented accordingly. I should also consider dropping the numbers completely. The GetDependencies.py
script will then run the conan install step which downloads or builds the dependencies and creates the conanbuildinfo.cmake file in the build-tree. This file is used to inject the configuration into the CMake generate step.Problems:
2_GetDependencies.py
to support other package managers.Currently it is not clear how we handle incrementing the CPF version for clients.
Problems:
The CPF components do not verify that depended on components have the correct versions. The jenkinsjob uses the buildscript interface. CPFBuildscripts uses the CPFCMake interface. The components should check for the presence of compatible version. In the case of the CPFBuildscripts -> CPFCMake dependency that would be an argument to merge the two packages into one.
The build-infrastructure can only build jobs of the current cpf version. Upgrading the CPF version can introduce a barrier for building older revisions. The CPF should therefore implement a mechanism that allows running build-slaves that are able to run older versions of the build-job.
The post-receive triggers use the parameter interface of the job. This may cause problems when we push to branches that use an older CPF version.
Currently the tools that are used by the CPFCMake pipeline are installed by the dockerfiles of the linux containers or require manual installation for windows slaves.
This is problematic because:
To get rid of these problems we should create conan packages for all required dependencies. This will also kill the "cyclic" dependency that is created by CPFCMake requireing the tools that are provided by CPFCMake.
After this, developers should only need to install git, python, and possibly the IDE.
Motivation
Initially the python and cmake code where seperated into two packages. The CMake code however expects
the directory structure that is enforced by the python scripts. It is therefore not practical to use CPFCMake without CPFBuildscripts. By putting both packages into one, client projects would only need to add one package instead of two.
Currently I am no sure if the simplification is worth the trouble. An alternative could be to turn the python scripts into cmake scripts to get rid of the python dependency. But that would probably decrease the usability.
Advantages:
Disadvantages:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.