| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Toolchain and build folder cmake arguments doesn't have in runfile
now. Only features are enumerating in. These deleted defines are point
by CI service to run needed cmake configuration
Signed-off-by: Alexey Gavrilov <alexey.gavrilov@mail.com>
|
|
In `outFeaturesToFile` function toolset is appends to a resulting file
(cmake toolchain file or arch, compiler if previous is not specify).
Toolset mention needs to filter available features for a specific
platform. FEATURE_<feature>_IS_ENABLING var also provides when <feature>
already enabled.
Build type is not in toolset now. That means to parse
`CMAKE_BUILD_TYPE` anyway when toolset is processing even if
`CMAKE_TOOLSCHAIN_FILE` is specified.
Signed-off-by: Alexey Gavrilov <alexey.gavrilov@mail.com>
|
|
Generates file contains command line cmake run to reproduce previous
cmake pass through.
CI service use this run file to start pipeline with needs cmake
configuration that developer was make.
Following code pushing workflow: Commit pushed to a code review system
(`CMakeReplication.txt` required) -> CI service intercepts changes ->
Pipeline start using passed in commit cmake replication command -> CI
submit pipeline finished status
Signed-off-by: Alexey Gavrilov <alexey.gavrilov@mail.com>
|
|
Implements a new feature module function `outFeaturesToFile` to output all
available features into 'CMakeFeatureOut.txt' file. Format of that file
is set of FEATURE_<feature>_<property> variables like defines in `CMakeCache.txt`.
Will to use as proxy between cmake and configuration tools. Those
utilities read features out file to build configuration kernel tree.
Signed-off-by: Alexey Gavrilov <alexey.gavrilov@mail.com>
|
|
Feature is abstraction around cmake build target used to contains
descriptive information in target properties as name, dependencies, tags
and etc.. Feature creation divided by three processes: start creation
process, fields filling and stop creation process. Start creation
process means passed target is handle now, and stop process is finish to
handle a current feature. Using this way helps to construct correct
features hierarchy and simplify kernel configuration process.
This will use in standalone automating kernel configuration tools:
1. Cmake generate a features file with information about them all.
2. Tool read this file and display features tree.
3. User start to configuring his kernel.
Signed-off-by: Alexey Gavrilov <alexey.gavrilov@mail.com>
|
|
Copyright disclaimer and copyright note are prepending to a every source
file.
Add license section in the `README.md` file.
Create the LICENSE` file with license information.
Signed-off-by: Alexey Gavrilov <alexey.gavrilov@mail.com>
|
|
Multi-target architecture implementation:
each root source code directory presents the one
*INTERFACE* target to it's subdirectory subtargets
that link only as *STATIC* library.
For instance, *arch* directory presents *Architecture* target
then *Architecture* target has *CPUID*, *IO*, *PORT*
and etc. dependencies
Exact order of linking targets is: boot.o CRTIBUNDLE <TARGETS> CRTNBUNDLE.
Sequence destruction cause to UB. Please to pay attention to this.
TODO
- Debug information
- Build type
- Toolchain file
- Image creation
- Build by WinGW compiler on Windows platform (optional)
Signed-off-by: Alexey Gavrilov <alexey.gavrilov@mail.com>
|
