Cmake package manager in rust-cargo style
- unloading and caching of dependencies;
- formalization of the project structure and configuration;
- semantic version control;
- automatic target generation (lib/bin/test/bench);
- cross-compilation;
- post-commit hook for clang-format
- pre-commit hook for auto-tagg by version
- CMake >= 3.10
- git
- python3 (optional for git-hooks)
Copy and include bastard_setup.cmake file in CMakeLists.txt:
cmake_minimum_required(VERSION 3.10)
include(cmake/bastard_setup.cmake)
bastard_setup()
project(${BASTARD_PACKAGE_NAME})Run cmake
cd build && cmake ..Project initialization will begin. Bastard's files will be unloaded into the .deps directory as an simple dependence. Next, config of the package will be unloaded from bastard.toml file and all build targets will be generated.
Project initialization begins after calling the bastard_setup() function, so any global specific options must be set higher.
- 
[package] - name: strPackage name (must be unique for build)
- authors: list[str]List of authors
- autogen-defines: boolDefines autogeneration from options (with prefix)
- version: strPackage version (vX.X.X)
- lang: strDefault lang for all targets of package- c90|c99|c++98|c++11|c++14|c++17|c++20
- system: [str]Default platform specification (usually- Unix | Windows | Generic)
- processor: [str]Default processor specification (see. CMAKE_SYSTEM_PROCESSOR)
 
- 
[dependencies] General package dependencies - <package>: strPackage name- git: strGit url (- git@or- http)
- tag: strGit tag (format- vX.X.X)
- branch: strGit branch
- rev: strGit hash
- links: list[str]List of libraries for links. Only for non-bastard packages, cause bastard package can contain only single library.
- path: strPath for local dependency
- interface: strPath for header library files
- system: [str]Platform specification (see [package.system])
- processor: [str]Processor specification (see [package.processor])
 
 
- 
[dev-dependencies] Developers dependencies - Similar to [dependencies]
 
- Similar to 
- 
[sys-dependencies] System dependencies (cmake find_package) - <package>: strPackage name (example Thread, Boost)
- components: list[str]Components list
- links: list[str]Library list
 
- 
[lib] General package library - name: strLibrary name
- lang: strUsing language (see. package.lang)
- include: [str]Include files relative by- libdir (example- [*.cpp, *.c])
- exclude: [str]Exclude files (see- include)
 
- 
[[bin]] Package binaries - name: strTarget name (or path for default, if- pathsection not exist)
- path: strPath of file/directory for build
- lang: strUsing language (see. package.lang)
- include: [str]Include files
- exclude: [str]Exclude files
- includeи- excluderelative- bin/nameor- bindirectory
- console: boolIf application is console (by default true)
 
- 
[[test]] Package test-binaries - Similar to [bin]
 
- Similar to 
- 
[[example]] Package examples - Similar to [bin]
 
- Similar to 
- 
[options] CMake variables for targets (legacy) - <package> = { <name>=<value> }
 
By default, if the sections [lib] [[bin]] are not specified, the legacy agreement is accepted when all dependencies are connected manually in CMakeLists.txt. For legacy mode, it is possible to use any project structure, however, the bastard functionality is limited only to uploading dependencies and setting options. If you follow the project structure agreement, then the package configuration will occur automatically.
-- cmake/
-- include/
---- mylib/
------ mylib.h
-- lib/
---- mylib.cpp
-- tests/
---- main.cpp
-- bastard.toml
-- CMakeLists.txt
-- cmake/
-- bin/
---- app1/
------ main.cpp
---- app2/
------ main.cpp
-- bastard.toml
-- CMakeLists.txt
-- cmake/
-- bin/
---- app1/
------ main.cpp
---- app2/
------ main.cpp
-- include/
---- mylib/
------ mylib.h
-- lib/
---- mylib.cpp
-- tests/
---- test1.cpp
---- test2.cpp
-- bastard.toml
-- CMakeLists.txt
to be continued...
