A component of the CMakeProjectFramework. It provides the CMake code that implements a CI-pipeline.
License: MIT License
Please note that this project is in an early state of development. Interfaces are not stable.
The mechanism for executing commands that have a configuration specific output is complicated and bug-prone. Especcially the escaping of special characters is hard to get right. The mechanism was implemented as a workaround for the problem that add_custom_command() does not support generator expressions in its OUTPUT argument.
Maybe we can use mitigate the problem by.
; in generator expressions has become possible i think.If cmake should implement generator expressions in OUTPUT we may able to get rid of this completely.
This should be fixed when implementing #18
Is theere a tool that can do this?
The CPF should provide a target that formats the source files with a given ruleset. This task is about finding a tool that does that and than implement a target that runs the tools. Cross-platform tools should be preferred.
Currently users have to manually reexecute the 2_Generate.py <config> command in order to make changes in the config file apply to the project. This is annoying when these changes occur often, like when changing the name of the executed test.
Maybe including the config file in the cpfInit.cmake file will do the trick.
This is particularly annoying when following the tutorials. I think this was not always the case. Maybe the changes to the stylesheet caused this problem.
CMake 3.11 enabled the use of custom target properties for interface libraries. This should allow us to create interface libraries via the cpfAddPackage() calls that have the usual custom properties of the CPF.
The task is to enhance cpfAddPackage() that it can be used in the libSwitchWarningsOff package.
CMake does allow custom properties on interface targets now. So it should be possible to do this.
This happens when the 1_Configure.py script from CPFBuildscripts is used with the -D option.
COMPONENT option of the install() command to handle different package content types.Some of the debug flags of msvc require the source file to allow debugging. Currently the packages do not contain .cpp files and private headers. We should check for compiler flags and add the files to the debug directory in the package if they are set.
It should not be possible to set a different package name then the package directory. The functions should internally get the name from the directory.
Superfluos includes increase build-times and usually accumulate over time in C++ projects.
It would be nice if the CPF head a target that could prevent developers from introducing superfluous includes.
This task is about finding a free tool that finds and possibly removes superfluos includes.
Currently the pipeline can only create test coverage reports on Windows using OpenCppCoverage. We should add a target that does the same on Linux.
Notes:
This was observed on the SimpleOneLibCPFTestPproject. We should have MyLib create both package formats to make sure the automated tests check that it works.
On windows this is required to add .rc files with the application icon.
Currently all linked libraries are pulicly linked. We should allow private linkage as well.
Currently the the user needs to do a 2_Generate.py <config> after making changes to the config file.
This can easily be forgotten and it would be more convenient if changes had effect without the need for a second manual step. We should find out if this is possible, without getting negative side-effects.
Reproduce by changing the project name in the checked in config file.
The function reduces the warning level for a hard-coded source-file which is added by linking to the staticly compiled qt hunter package via the INTERFACE_SOURCES property. The code suggests that this is only a problem on Linux.
The function should at least remove the hard-coded filename and lower the warning-level on all imported INTERFACE_SOURCES. What is the correct solution?
Currently the files lie parallel to the MyLib directory in the zip file. They should be in this directory, maybe in a debug sub-directory.
Currently the cmake version files are the only files that are generated in the source tree.
They should also be generated in the build tree and later added to the developer distribution packages.
The package version read mechanism must check install and build-tree locations of the file then.
Only write the tests for functions that can be run in script mode and that are complex enought to be worthy to be tested.
These tests require some extra thoughts because we must find a way to provide the CPF with previously created distribution packages. We have to see if we can simply add a file location as the web-page address.
If this works we can add a TestData directory that provides the download directory structure of the webpage.
The target_compile_option() function will set the target properties instead of the global flag.
The variable is currently used for setting the cosmetic compiler options like waring level, warning as error and /MP flag.
I am not completely happy with Doxygen. I do not like the style of the output and I lack the skills to create my own css file which may make it better.
Problems with Doxygen:
Good things about Doxygen:
We could either look at other doxygen based projects how to improve the default style, or use a different generator. Doxygens documentation itself seams to be heavily customized. Other examples are linked in the doxygen docs http://www.stack.nl/~dimitri/doxygen/results.html
Other alternatives could be:
The status massage could be improved to say "package is now at verified version " to signal that the version has been successfully build by the build-server when it has a version tag.
The last time i tried this I had errors because there seemed to be parallel access to some debug info databases. However Visual Studio's CMake mode uses Ninja out of the box. So it should work. Why did it not work for me? Is the /MD option vorbidden with Ninja?
Currently all libraries use the same linkage defined by BUILD_SHARED_LIBS. In some cases it may be desireable to have some libraries as shared and some as static libraries.
This could be added by having an optional SHARED or STATIC keyword in the CPF_PACKAGES variable that is defined in the packages.cmake file.
The default settings when compiling debug configurations with VC require the .cpp files to be present.
If these compiler flags are used, we should make sure that the install target copies the .cpp files in the debug directory of the package.
Clazy is a clang based tool that does static analysis of C++/Qt code. This task is to investigate if it is usefull enough to justify a clazy target in the CPF pipeline.
We have to check if this works:
Build library in release
Build library in debug
Build test executable in release -> The touched dlls may not be replaced by the real ones.
The CPF should provide the developer with the option to consume a CPF package dependencie via precompiled binaries or by including its sources into the source tree. The first option is usefull to reduce compile times when a package is rarely changed. The second option is of advantage if the package is changed regularly because of the current working activity of the developer. Enabling this switch by only changing a CMake variable seems to be usefull in day to day development.
The idea was first brought up here: ruslo/hunter#932
I currently believe that this should not be implemented in hunter but rather in the CPF. Hunter can in general not guarantee that a package can be inlined, while CPF packages can be designed to be inlineable.
The mechanism would have to change a git-submodule dependency to a hunter dependency and back.
The cpf would have to know how a repository based dependency can be transformed into a dependency on the distribution package.
Problems to solve
add_subdirectroy(). To achieve this we can use alias targets to create targets withPossibly related discussions on hunter for "decentralized" packages and git-repo packages.
The CPF currently implements only the "exact same version" compatibility scheme. It may be useful for general use if the user could also choose between "same patch version", "same minor version" and "same major version" schemes. This would require changes to the install commands where a scheme is selected for the packages .cmake files. It may also have an effect on the api-checker targets. It will also have an effect on the installed symbolic links on linux which are involved in implementing the compatibility scheme.
VS2017 in CMake mode allows keeping multiple configurations in a CMakeSettings.json file.
It more or less holds the information that we now keep in our .cmake file + cmake command line arguments.
If we could use that format we would support Visual Studio out of the box. Our .json file however also contains information about on which system the build should happen. Can this information be added to the CMakeSettings.json file without breaking it?
The .pc file seems to be a commonly used package file on linux. Currently I do not know enough about it to make a decision.
Currently doxygen is run on the whole CI-project which will not scale for big projects. Doxygen has the ability to generate indexes for single packages and than combine the results with another call. This approach was first used when implementing the documentation target, but it turned out that this functionality was buggy at the time. Bugreport. The result is not the same when using this method compared to one global call of doxygen.
If the global doxygen target turns out to be a problem we may need to revisit this problem.
Rename targets
This should increase the transparency what is actually done by the target. Maybe it is useful to add an extra global bundle target with the special name.
It would be nice to have a page that displays project statistics like lines-of-code or git statistics.
For lines of code we could use cloc on Linux. Does it create html pages?
The goal of the investigation is to manually construct a solution that allows debugging packages without the need of manually searching for source files in the Visual Studio pop-up dialog.
Because .pdb files hold only absolute pathes to the .cpp file that belongs to them, the source files of a package are not automatically found when debugging into a package. It somehow seems to be possible to specify a source file server command in the .pdb file which is intended to load sources from a central server.
Maybe this mechanism can be high-checked to load sources from a relative path in the package.
More Information:
https://www.codeproject.com/Articles/245824/Sourcepack-indexing-PDB-files-with-source-archive
https://github.com/MicrosoftDocs/visualstudio-docs/blob/master/docs/debugger/specify-symbol-dot-pdb-and-source-files-in-the-visual-studio-debugger.md
If this is possible, create a task for implementing the solution in CPFCMake.
Check if this is neccesarry because of the links in the generated package .dox file. If not, it should not appear.
The cmake function was extended in cmake version 3.9 with the NATIVE_COMMAND option which does the same thing that the cpfSeparateArgumentsForPlatform(). We already require cmake 3.10 so our custom implementation is no longer needed.
Currently the different content types are handled with custom targets and the install() commands install the developer files. We should consider using the COMPONENT option of the install command to handle various file. Components could be
For very large projects it must be possible to have different versions of a library in the dependency tree at the same time. If this is not allowed, all clients of the library must be updated at the same time when the library version changes. This does not scale. Allowing multiple versions of one library at the same time allows updating one client at a time in non global steps.
This can happen when creating dev-bin packages for library targets.
The target is currently added by calling cpfAddGlobalMonolithicDocumentationTarget() in cpfAddPackages(). We should move this in a separate CMakeLists file and add the function call there.
Then we can add all global doxygen files to that package and re-use them for other build-projects.
It would be good if users could access the documentation pages that where created for older release versions of the CI-project and the packages.
The CMake documentation does it with a combo-box https://cmake.org/cmake/help/latest/
On windows, the version number can be included in the binary. CMake alows us to do this, so we should do it.
React
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
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
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.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.