```bash
git submodule add https://gerrit.automotivelinux.org/gerrit/p/apps/app-templates.git conf.d/app-templates
mkdir conf.d/cmake
-cp conf.d/app-templates/cmake/config.cmake.sample conf.d/cmake/config.cmake
+cp conf.d/app-templates/samples.d/config.cmake.sample conf.d/cmake/config.cmake
```
Edit the copied config.cmake file to fit your needs.
use:
```bash
-cp conf.d/app-templates/cmake/CMakeLists.txt.sample CMakeLists.txt
+cp conf.d/app-templates/samples.d/CMakeLists.txt.sample CMakeLists.txt
```
### Create your CMake targets
to include this target to your project.
Using it, make available the cmake variable ***TARGET_NAME*** until the next
-***PROJECT_TARGET_ADD*** is invoked with a new target name.
+***PROJECT_TARGET_ADD*** is invoked with a new target name.
So, typical usage defining a target is:
SET_TARGET_PROPERTIES(${TARGET_NAME} PROPERTIES.... --> fit target properties
for macros usage
-
-INSTALL(TARGETS ${TARGET_NAME}....
```
### Targets PROPERTIES
Choose between:
- **BINDING**: Shared library that be loaded by the AGL Application Framework
-- **HTDOCS**: Root directory of a web app
-- **DATA**: Resources used by your application
+- **BINDINGV2**: Shared library that be loaded by the AGL Application Framework
+ This has to be accompagnied with a JSON file named like the
+ *${OUTPUT_NAME}-apidef* of the target that describe the API with OpenAPI
+ syntax (e.g: *mybinding-apidef*). Or you can choose the name, without the
+ extension, by setting the *CACHE* cmake variable *OPENAPI_DEF* (***CAUTION***:
+ setting a CACHE variable is needed, or set a normal variable with the
+ *PARENT_SCOPE* option to make it visible for the parent scope where the target
+ is defined) JSON file will be used to generate header file using `afb-genskel`
+ tool.
+- **PLUGIN**: Shared library meant to be used as a binding plugin. Binding
+ would load it as a plugin to extend its functionnalities. It should be named
+ with a special extension that you choose with SUFFIX cmake target property or
+ it'd be **.ctlso** by default.
+- **HTDOCS**: Root directory of a web app. This target has to build its
+ directory and puts its files in the ${CMAKE_CURRENT_BINARY_DIR}/${TARGET_NAME}
+- **DATA**: Resources used by your application. This target has to build its
+ directory and puts its files in the ${CMAKE_CURRENT_BINARY_DIR}/${TARGET_NAME}
- **EXECUTABLE**: Entry point of your application executed by the AGL
Application Framework
+- **LIBRARY**: An external 3rd party library bundled with the binding for its
+ own purpose because platform doesn't provide it.
+
+> **TIP** you should use the prefix _afb-_ with your **BINDING* targets which
+> stand for **Application Framework Binding**.
```cmake
SET_TARGET_PROPERTIES(${TARGET_NAME}
PREFIX "afb-"
LABELS "BINDING"
- OUTPUT_NAME "file_output_name")
+ OUTPUT_NAME "file_output_name"
+)
```
-> **TIP** you should use the prefix _afb-_ with your **BINDING* targets which
-> stand for **Application Framework Binding**.
+> **NOTE**: You doesn't need to specify an **INSTALL** command for these
+> targets. This is already handle by template and will be installed in the
+> following path : **${CMAKE_INSTALL_PREFIX}/${PROJECT_NAME}**
## More details: Typical project architecture
│ │ └── autobuild
│ ├── app-templates/
│ │ ├── README.md
-│ │ ├── autobuild/
-│ │ │ ├── agl
-│ │ │ │ └── autobuild.in
-│ │ │ ├── linux
-│ │ │ │ └── autobuild.in
-│ │ │ └── windows
-│ │ │ └── autobuild.in
│ │ ├── cmake/
-│ │ │ ├── config.cmake.sample
│ │ │ ├── export.map
│ │ │ └── macros.cmake
-│ │ ├── deb/
-│ │ │ └── config.deb.in
-│ │ ├── rpm/
-│ │ │ └── config.spec.in
+│ │ ├── samples.d/
+│ │ │ ├── CMakeLists.txt.sample
+│ │ │ ├── config.cmake.sample
+│ │ │ ├── config.xml.in.sample
+│ │ │ └── xds-config.env.sample
+│ │ ├── template.d/
+│ │ │ ├── autobuild/
+│ │ │ │ ├── agl
+│ │ │ │ │ └── autobuild.in
+│ │ │ │ ├── linux
+│ │ │ │ │ └── autobuild.in
+│ │ │ │ └── windows
+│ │ │ │ └── autobuild.in
+│ │ │ ├── config.xml.in
+│ │ │ ├── deb-config.dsc.in
+│ │ │ ├── deb-config.install.in
+│ │ │ ├── debian.changelog.in
+│ │ │ ├── debian.compat.in
+│ │ │ ├── debian.rules.in
+│ │ │ ├── gdb-on-target.ini.in
+│ │ │ ├── install-wgt-on-target.sh.in
+│ │ │ ├── start-on-target.sh.in
+│ │ │ ├── rpm-config.spec.in
+│ │ │ └── xds-project-target.conf.in
│ │ └── wgt/
-│ │ ├── config.xml.in
-│ │ ├── config.xml.in.sample
│ │ ├── icon-default.png
│ │ ├── icon-html5.png
│ │ ├── icon-native.png
Choose between:
- **BINDING**: Shared library that be loaded by the AGL Application Framework
-- **HTDOCS**: Root directory of a web app
-- **DATA**: Resources used by your application
+- **BINDINGV2**: Shared library that be loaded by the AGL Application Framework
+ This has to be accompagnied with a JSON file named like the
+ *${OUTPUT_NAME}-apidef* of the target that describe the API with OpenAPI
+ syntax (e.g: *mybinding-apidef*). Or you can choose the name, without the
+ extension, by setting the *CACHE* cmake variable *OPENAPI_DEF* (***CAUTION***:
+ setting a CACHE variable is needed, or set a normal variable with the
+ *PARENT_SCOPE* option to make it visible for the parent scope where the target
+ is defined) JSON file will be used to generate header file using `afb-genskel`
+ tool.
+- **PLUGIN**: Shared library meant to be used as a binding plugin. Binding
+ would load it as a plugin to extend its functionnalities. It should be named
+ with a special extension that you choose with SUFFIX cmake target property or
+ it'd be **.ctlso** by default.
+- **HTDOCS**: Root directory of a web app. This target has to build its
+ directory and puts its files in the ${CMAKE_CURRENT_BINARY_DIR}/${TARGET_NAME}
+- **DATA**: Resources used by your application. This target has to build its
+ directory and puts its files in the ${CMAKE_CURRENT_BINARY_DIR}/${TARGET_NAME}
- **EXECUTABLE**: Entry point of your application executed by the AGL
Application Framework
+- **LIBRARY**: An external 3rd party library bundled with the binding for its
+ own purpose because platform doesn't provide it.
+
+> **TIP** you should use the prefix _afb-_ with your **BINDING* targets which
+> stand for **Application Framework Binding**.
Example:
)
```
-If your target output is not named as the ***TARGET_NAME***, you need to specify
-***OUTPUT_NAME*** property that will be used by the ***populate_widget*** macro.
+> **NOTE**: You doesn't need to specify an **INSTALL** command for these
+> targets. This is already handle by template and will be installed in the
+> following path : **${CMAKE_INSTALL_PREFIX}/${PROJECT_NAME}**
+
+#### Add external 3rd party library
+
+You could need to include an external library that isn't shipped in the
+platform. Then you have to bundle the required library in the `lib` widget
+directory.
+
+Templates includes some facilities to help you to do so. Classic way to do so
+is to declare as many CMake ExternalProject as library you need.
+
+An ExternalProject is a special CMake module that let you define how to:
+download, update, patch, configure, build and install an external project. It
+doesn't have to be a CMake project and custom step could be added for special
+needs using ExternalProject step. More informations on CMake [ExternalProject
+documentation site](https://cmake.org/cmake/help/v3.5/module/ExternalProject.html?highlight=externalproject).
+
+Example to include `mxml` library for [unicens2-binding](https://github.com/iotbzh/unicens2-binding)
+project:
+
+```cmake
+set(MXML external-mxml)
+set(MXML_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/mxml)
+ExternalProject_Add(${MXML}
+ GIT_REPOSITORY https://github.com/michaelrsweet/mxml.git
+ GIT_TAG release-2.10
+ SOURCE_DIR ${MXML_SOURCE_DIR}
+ CONFIGURE_COMMAND ./configure --build x86_64 --host aarch64
+ BUILD_COMMAND make libmxml.so.1.5
+ BUILD_IN_SOURCE 1
+ INSTALL_COMMAND ""
+)
+
+PROJECT_TARGET_ADD(mxml)
+
+add_library(${TARGET_NAME} SHARED IMPORTED GLOBAL)
+
+SET_TARGET_PROPERTIES(${TARGET_NAME} PROPERTIES
+ LABELS LIBRARY
+ IMPORTED_LOCATION ${MXML_SOURCE_DIR}/libmxml.so.1
+ INTERFACE_INCLUDE_DIRECTORIES ${MXML_SOURCE_DIR}
+)
+
+add_dependencies(${TARGET_NAME} ${MXML})
+```
+
+Here we define an external project that drive the build of the library then we
+define new CMake target of type **IMPORTED**. Meaning that this target hasn't
+be built using CMake but is available at the location defined in the target
+property *IMPORTED_LOCATION*.
+
+Then target *LABELS* property is set to **LIBRARY** to ship it in the widget.
+
+Unicens project also need some header from this library, so we use the target
+property *INTERFACE_INCLUDE_DIRECTORIES*. Setting that when another target link
+to that imported target, it can access to the include directories.
-Use the ***populate_widget*** macro as latest statement of your target
-definition. Then at the end of your project definition you should use the macro
-***build_widget*** that make an archive from the populated widget tree using the
-`wgtpkg-pack` Application Framework tools.
+We bound the target to the external project using a CMake dependency at last.
-## Macro reference
+#### Macro reference
-### PROJECT_TARGET_ADD
+##### PROJECT_TARGET_ADD
Typical usage would be to add the target to your project using macro
`PROJECT_TARGET_ADD` with the name of your target as parameter.
> set with the specificied name. This variable will change at the next call
> to this macros.
-### project_subdirs_add
+##### project_subdirs_add
This macro will search in all subfolder any `CMakeLists.txt` file. If found then
it will be added to your project. This could be use in an hybrid application by
project_subdirs_add("[0-9]-*")
```
-## Advanced customization
+## Advanced build customization
### Including additionnals cmake files
+#### Machine and system custom cmake files
+
Advanced tuning is possible using addionnals cmake files that are included
automatically from some specifics locations. They are included in that order:
- Home CMake files located in _$HOME/.config/app-templates/cmake.d_
- System CMake files located in _/etc/app-templates/cmake.d_
-CMake files has to be named using the following convention: `XX-***.cmake`,
-where `XX` are numbers, `***` file name (ie. `99-my_customs.cmake`).
+CMake files has to be named using the following convention: `XX-common*.cmake`
+or `XX-${PROJECT_NAME}*.cmake`, where `XX` are numbers, `*` file name
+(ie. `99-common-my_customs.cmake`).
+
+> **NOTE** You need to specify after numbers that indicate include order, to
+which project that file applies, if it applies to all project then use keyword
+`common`.
So, saying that you should be aware that every normal cmake variables used at
project level could be overwrited by home or system located cmake files if
set(VARIABLE_NAME 'value string random' CACHE STRING 'docstring')
```
+#### OS custom cmake files
+
+This is meant to personalize the project depending on the OS your are using.
+At the end of config.cmake, common.cmake will include lot of cmake file to
+customize project build depending on your plateform. It will detect your OS
+deducing it from file _/etc/os-release_ now as default in almost all Linux
+distribution.
+
+So you can use the value of field **ID_LIKE** or **ID** if the
+first one doesn't exists and add a cmake file for that distribution in your
+_conf.d/cmake/_ directory or relatively to your _app-templates_ submodule path
+_app-templates/../cmake/_
+
+Those files has to be named use the following scheme _XX-${OSRELEASE}*.cmake_
+where _XX_ are numbers, ${OSRELEASE} the **ID_LIKE** or **ID** field from
+_/etc/os-release_ file. You can also define default OS configuration file
+to use as fallback is none specific OS configuration is available using the
+scheme _XX-default*.cmake_. Then is you need by example a module that isn't
+named the same in one distro only, you only has to define a specific file to
+handle that case then for all the other case put the configuration in the
+default file.
+
### Include customs templated scripts
As well as for additionnals cmake files you can include your own templated
Code Review / apps / app-templates.git / blobdiff