diff options
| -rw-r--r-- | docs/dev_guide/0_Abstract.md | 103 | ||||
| -rw-r--r-- | docs/dev_guide/1_Quickstart.md | 116 | ||||
| -rwxr-xr-x | docs/dev_guide/4-advanced-usage.md | 278 | ||||
| -rwxr-xr-x | docs/dev_guide/5-advanced-customization.md | 66 | ||||
| -rwxr-xr-x | docs/dev_guide/6-autobuild.md | 130 | ||||
| -rwxr-xr-x | docs/dev_guide/advanced-customization.md | 114 | ||||
| -rwxr-xr-x | docs/dev_guide/advanced-usage.md | 307 | ||||
| -rwxr-xr-x | docs/dev_guide/autobuild.md | 132 | ||||
| -rwxr-xr-x | docs/dev_guide/cmake-overview.md (renamed from docs/dev_guide/0-cmake-overview.md) | 0 | ||||
| -rwxr-xr-x | docs/dev_guide/configuring-cmake.md (renamed from docs/dev_guide/2-configuring-cmake.md) | 0 | ||||
| -rwxr-xr-x | docs/dev_guide/installing-cmake.md | 50 | ||||
| -rwxr-xr-x[-rw-r--r--] | docs/dev_guide/pictures/iotbzh_logo_small.png | bin | 6989 -> 6989 bytes | |||
| -rwxr-xr-x | docs/dev_guide/project-architecture.md (renamed from docs/dev_guide/3-project-architecture.md) | 1 | ||||
| -rwxr-xr-x | docs/dev_guide/using-cmake.md (renamed from docs/dev_guide/1-installing-cmake.md) | 60 |
14 files changed, 609 insertions, 748 deletions
diff --git a/docs/dev_guide/0_Abstract.md b/docs/dev_guide/0_Abstract.md deleted file mode 100644 index 9d44890..0000000 --- a/docs/dev_guide/0_Abstract.md +++ /dev/null @@ -1,103 +0,0 @@ -# Abstract - -This CMake module is used to build an application or a binding project for the -AGL Application Framework. It allows to easily build a widget and its related -test widget for running on top the application framework. - -## Installation for a native environment - -To build your AGL project using the templates, you have to install them as -a CMake module. The easy way is to install using your distro package manager -following [this guide](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/host-configuration/docs/1_Prerequisites.html). - -To install it, depending on your distro: - -* **Debian/Ubuntu** - -```bash -sudo apt-get install agl-cmake-apps-module-bin -``` - -* **openSUSE** - -```bash -sudo zypper install agl-cmake-apps-module -``` - -* **Fedora** - -```bash -sudo dnf install agl-cmake-apps-module -``` - -## Installing in a cross compilation environment - -### Using AGL SDK - -Beginning with the `Grumpy Guppy`, version 7, the CMakeAfbTemplates CMake module -is installed by default in the SDKs. So, you don't need anything to use it. - -Here are some links to the latest SDKs on the master branch: - -* [dra7xx-evm](https://download.automotivelinux.org/AGL/snapshots/master/latest/dra7xx-evm/deploy/sdk/) -* [dragonboard-410c](https://download.automotivelinux.org/AGL/snapshots/master/latest/dragonboard-410c/deploy/sdk/) -* [intel-corei7-64](https://download.automotivelinux.org/AGL/snapshots/master/latest/intel-corei7-64/deploy/sdk/) -* [m3ulcb-nogfx](https://download.automotivelinux.org/AGL/snapshots/master/latest/m3ulcb-nogfx/deploy/sdk/) -* [qemux86-64](https://download.automotivelinux.org/AGL/snapshots/master/latest/qemux86-64/deploy/sdk/) -* [raspberrypi3](https://download.automotivelinux.org/AGL/snapshots/master/latest/raspberrypi3/deploy/sdk/) - -### Using bitbake recipes - -If you have developed an application and you want to include it in the AGL image, -you have to add a `bitbake` recipe in one of the **AGL Yocto layer**: - -* [meta-agl](https://gerrit.automotivelinux.org/gerrit/#/admin/projects/AGL/meta-agl): - meta-agl layer (core AGL) -* [meta-agl-cluster-demo](https://gerrit.automotivelinux.org/gerrit/#/admin/projects/AGL/meta-agl-cluster-demo): - cluster demo specific recipes and configuration -* [meta-agl-demo](https://gerrit.automotivelinux.org/gerrit/#/admin/projects/AGL/meta-agl-demo): - meta-agl-demo layer (demo/staging/"one-shot") -* [meta-agl-devel](https://gerrit.automotivelinux.org/gerrit/#/admin/projects/AGL/meta-agl-devel): - meta-agl-devel (Development and Community BSPs) -* [meta-agl-extra](https://gerrit.automotivelinux.org/gerrit/#/admin/projects/AGL/meta-agl-extra): - meta-agl-extra (additional/optional components for AGL) - -Then in your recipe, you simply have to add the class `aglwgt` to the *inherit* -line: - -```bb -inherit aglwgt -``` - -i.e with the **HVAC** app recipe: - -```bb -SUMMARY = "HVAC Service Binding" -DESCRIPTION = "AGL HVAC Service Binding" -HOMEPAGE = "https://gerrit.automotivelinux.org/gerrit/#/admin/projects/apps/agl-service-hvac" -SECTION = "apps" - -LICENSE = "Apache-2.0" -LIC_FILES_CHKSUM = "file://LICENSE;md5=ae6497158920d9524cf208c09cc4c984" - -SRC_URI = "gitsm://gerrit.automotivelinux.org/gerrit/apps/agl-service-hvac;protocol=https;branch=${AGL_BRANCH}" -SRCREV = "${AGL_APP_REVISION}" - -PV = "1.0+git${SRCPV}" -S = "${WORKDIR}/git" - -DEPENDS = "json-c" -RDEPENDS_${PN} += "agl-service-identity-agent" - -inherit cmake aglwgt pkgconfig -``` - ----- - -You'll find usage samples here: - -* [helloworld-service](https://github.com/iotbzh/helloworld-service) -* [agl-service-can-low-level](https://gerrit.automotivelinux.org/gerrit/apps/agl-service-can-low-level) -* [agl-service-audio-4a](https://gerrit.automotivelinux.org/gerrit/#/admin/projects/apps/agl-service-audio-4a) -* [agl-service-unicens](https://gerrit.automotivelinux.org/gerrit/#/admin/projects/apps/agl-service-unicens) -* [4a-hal-unicens](https://gerrit.automotivelinux.org/gerrit/#/admin/projects/src/4a-hal-unicens) diff --git a/docs/dev_guide/1_Quickstart.md b/docs/dev_guide/1_Quickstart.md deleted file mode 100644 index 6a6be1d..0000000 --- a/docs/dev_guide/1_Quickstart.md +++ /dev/null @@ -1,116 +0,0 @@ -# Quickstart - -## Initialization - -To use these templates files on your project just install the reference files -using **cmake module** then use `config.cmake` file to configure your project specificities : - -```bash -mkdir -p conf.d/cmake -# From the SDK sysroot >= 6.99.2 b992 -cp ${OECORE_NATIVE_SYSROOT}/usr/share/doc/CMakeAfbTemplates/samples.d/config.cmake.sample conf.d/cmake/config.cmake -# From the SDK sysroot < 6.99.2 b992 -cp ${OECORE_NATIVE_SYSROOT}/usr/share/cmake-3.8/Modules/CMakeAfbTemplates/samples.d/config.cmake.sample conf.d/cmake/config.cmake -# From a native installation -cp /usr/share/doc/CMakeAfbTemplates/samples.d/config.cmake.sample conf.d/cmake/config.cmake -``` - -Edit the copied config.cmake file to fit your needs. - -Now, create your top CMakeLists.txt file which include `config.cmake` file. - -An example is available in the **cmake module** that you can copy and use: - -```bash -# From the SDK sysroot >= 6.99.2 b992 -cp ${OECORE_NATIVE_SYSROOT}/usr/share/doc/CMakeAfbTemplates/samples.d/CMakeLists.txt.sample CMakeLists.txt -# From the SDK sysroot < 6.99.2 b992 -cp ${OECORE_NATIVE_SYSROOT}/usr/share/cmake-3.8/Modules/CMakeAfbTemplates/samples.d/CMakeLists.txt.sample CMakeLists.txt -# From a native installation -cp /usr/share/doc/CMakeAfbTemplates/samples.d/CMakeLists.txt.sample CMakeLists.txt -``` - -## Auto-detection of CMakeLists.txt and *.cmake files - -The directories matching the pattern ***PROJECT_SRC_DIR_PATTERN*** (defaults to "*") -will be automatically scanned. - -When a files ***CMakeLists.txt*** is found, its directory is automatically added to -the cmake project. - -Similarily, when a file named with the extension ***.cmake*** is found, it is automatically -added to the cmake project. - -## Create your CMake targets - -For each target that is part of your project, you need to use -***PROJECT_TARGET_ADD*** to include this target to your project. - -> **NOTE**: Using it, make available the cmake variable ***TARGET_NAME*** until -> the next ***PROJECT_TARGET_ADD*** is invoked with a new target name. - -So, typical usage defining a target is: - -```cmake -PROJECT_TARGET_ADD(SuperExampleName) --> Adding target to your project - -add_executable/add_library(${TARGET_NAME}.... --> defining your target sources - -SET_TARGET_PROPERTIES(${TARGET_NAME} PROPERTIES.... --> fit target properties -for macros usage - -INSTALL(TARGETS ${TARGET_NAME}.... -``` - -## Targets PROPERTIES - -Targets properties is used to determine nature of targets and where they will be -stored in the package that will be build. - -Specify what is the type of your targets that you want to be included in the -widget package with the property **LABELS**: - -Choose between: - -- **BINDING**: Shared library that be loaded by the AGL Application Framework -- **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 Alternatively, you can choose the name, without the extension, using macro - **set_openapi_filename**. If you use C++, you have to set **PROJECT_LANGUAGES** - with *CXX*. -- **BINDINGV3**: 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 Alternatively, you can choose the name, without the extension, using macro - **set_openapi_filename**. If you use C++, you have to set **PROJECT_LANGUAGES** - with *CXX*. -- **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. -- **BINDING-CONFIG**: Any files used as configuration by your binding. - -> **TIP** you should use the prefix _afb-_ with your **BINDING* targets which -> stand for **Application Framework Binding**. - -```cmake -SET_TARGET_PROPERTIES(${TARGET_NAME} PROPERTIES - PREFIX "afb-" - LABELS "BINDINGV3" - OUTPUT_NAME "file_output_name") -``` - -> **CAUTION**: 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}** diff --git a/docs/dev_guide/4-advanced-usage.md b/docs/dev_guide/4-advanced-usage.md deleted file mode 100755 index 3e0ace1..0000000 --- a/docs/dev_guide/4-advanced-usage.md +++ /dev/null @@ -1,278 +0,0 @@ -# Build a widget - -## config.xml.in file - -To build a widget you need a _config.xml_ file describing what is your apps and -how Application Framework would launch it. This repo provide a simple default -file _config.xml.in_ that should work for simple application without -interactions with others bindings. - -It is recommended that you use the sample one which is more complete. You can -find it at the same location under the name _config.xml.in.sample_ (stunning -isn't it). Just copy the sample file to your _conf.d/wgt_ directory and name it -_config.xml.in_, then edit it to fit your needs. - -> ***CAUTION*** : The default file is only meant to be use for a -> simple widget app, more complicated ones which needed to export -> their api, or ship several app in one widget need to use the provided -> _config.xml.in.sample_ which had all new Application Framework -> features explained and examples. - -## Using cmake template macros - -To leverage all cmake templates features, you have to specify ***properties*** -on your targets. Some macros will not works without specifying which is the -target type. - -As the type is not always specified for some custom targets, like an ***HTML5*** -application, macros make the difference using ***LABELS*** property. - -Choose between: - -- **BINDING**: Shared library that be loaded by the AGL Application Framework -- **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 describes the API with OpenAPI - syntax (e.g: *mybinding-apidef*). - Or Alternatively, you can choose the name, without the extension, using macro - **set_openapi_filename**. If you use C++, you have to set **PROJECT_LANGUAGES** - to *CXX*. -- **BINDINGV3**: 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 describes the API with OpenAPI - syntax (e.g: *mybinding-apidef*). - Or Alternatively, you can choose the name, without the extension, using macro - **set_openapi_filename**. If you use C++, you have to set **PROJECT_LANGUAGES** - to *CXX*. -- **PLUGIN**: Shared library are meant to be used as a binding plugin. A 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. -- **BINDING-CONFIG**: Any files used as configuration by your binding. - -Optional **LABELS** are available to define which resources type your test -materials are: - -- **TEST-CONFIG**: JSON configuration files that will be used by the afb-test - binding to know how to execute tests. -- **TEST-DATA**: Resources used to test your binding. It is at least your test - plan and also could be fixtures and any needed files by your tests. These files - will appear in a separate test widget. -- **TEST-PLUGIN**: Shared library are meant to be used as a binding - plugin. A binding would load it as a plugin to extend its functionalities. It - should be named with a special extension that you choose with SUFFIX cmake - target property or it'd be **.ctlso** by default. -- **TEST-HTDOCS**: Root directory of a web app. This target has to build its - directory and put its files in the ${CMAKE_CURRENT_BINARY_DIR}/${TARGET_NAME} -- **TEST-EXECUTABLE**: Entry point of your application executed by the AGL - Application Framework -- **TEST-LIBRARY**: An external 3rd party library bundled with the binding for its - own use in case of platform doesn't provide it. - -Here is a mapping between LABELS and directories where files will be placed in -the widget: - -- **EXECUTABLE** : \<wgtrootdir\>/bin -- **BINDING-CONFIG** : \<wgtrootdir\>/etc -- **BINDING** | **BINDINGV2** | **BINDINGV3** | **LIBRARY** : \<wgtrootdir\>/lib -- **PLUGIN** : \<wgtrootdir\>/lib/plugins -- **HTDOCS** : \<wgtrootdir\>/htdocs -- **BINDING-DATA** : \<wgtrootdir\>/var -- **DATA** : \<wgtrootdir\>/var - -And about test dedicated **LABELS**: - -- **TEST-EXECUTABLE** : \<wgtrootdir\>/bin -- **TEST-CONFIG** : \<TESTwgtrootdir\>/etc -- **TEST-PLUGIN** : \<wgtrootdir\>/lib/plugins -- **TEST-HTDOCS** : \<wgtrootdir\>/htdocs -- **TEST-DATA** : \<TESTwgtrootdir\>/var - -> **TIP** you should use the prefix _afb-_ with your **BINDING* targets which -> stand for **Application Framework Binding**. - -Example: - -```cmake -SET_TARGET_PROPERTIES(${TARGET_NAME} PROPERTIES - LABELS "HTDOCS" - OUTPUT_NAME dist.prod - ) -``` - -> **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}** - -> **NOTE**: if you want to set and use `rpath` with your target you should use -> and set the target property `INSTALL_RPATH`. - -## Add external 3rd party library - -### Build, link and ship external library with the project - -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 -been built using CMake but is available at the location defined in the target -property *IMPORTED_LOCATION*. - -You could want to build the library as *SHARED* or *STATIC* depending on your needs -and goals. Then you only have to modify the external project configure step and change -filename used by **IMPORTED** library target defined after external project. - -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. - -We bound the target to the external project using a CMake dependency at last. - -Then this target could be use like any other CMake target and be linked etc. - -### Only link and ship external library with the project - -If you already have a binary version of the library that you want to use and you -can't or don't want to build the library then you only have to add an **IMPORTED** -library target. - -So, taking the above example, `mxml` library inclusion would be: - -```cmake -PROJECT_TARGET_ADD(mxml) - -add_library(${TARGET_NAME} SHARED IMPORTED GLOBAL) - -SET_TARGET_PROPERTIES(${TARGET_NAME} PROPERTIES - LABELS LIBRARY - IMPORTED_LOCATION /path/to/library/libmxml.so.1 - INTERFACE_INCLUDE_DIRECTORIES /path/to/mxml/include/dir -) -``` - -Finally, you can link any other lib or executable target with this imported -library like any other target. - -## Macro reference - -### 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. - -Example: - -```cmake -PROJECT_TARGET_ADD(low-can-demo) -``` - -> ***NOTE***: This will make available the variable `${TARGET_NAME}` -> set with the specificied name. This variable will change at the next call -> to this macros. - -### 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 -example where the binding lay in a sub directory. - -Usage : - -```cmake -project_subdirs_add() -``` - -You also can specify a globbing pattern as argument to filter which folders -will be looked for. - -To filter all directories that begin with a number followed by a dash the -anything: - -```cmake -project_subdirs_add("[0-9]-*") -``` - -### set_openapi_filename - -Used with a target labelized **BINDINGV2** to define the file name, and -possibly a relative path with the current *CMakeLists.txt*. - -If you don't use that macro to specify the name of your definition file -then the default one will be used, *${OUTPUT_NAME}-apidef* with -**OUTPUT_NAME** as the [target property]. - -> **CAUTION** you must only specify the name **WITHOUT** the extension. - -```cmake -set_openapi_filename('binding/mybinding_definition') -``` - -[target property]: https://cmake.org/cmake/help/v3.6/prop_tgt/OUTPUT_NAME.html "OUTPUT_NAME property documentation" - -### add_input_files - -Create custom target dedicated for HTML5 and data resource files. This macro -provides syntax and schema verification for differents languages which are -about now: LUA, JSON and XML. - -You could change the tools used to check files with the following variables: - -- XML_CHECKER: set to use **xmllint** provided with major linux distribution. -- LUA_CHECKER: set to use **luac** provided with major linux distribution. -- JSON_CHECKER: no tools found at the moment. - -```cmake -add_input_file("${MY_FILES_LIST}") -``` - -> **NOTE**: an issue at the check step on a file will stop at the build step. diff --git a/docs/dev_guide/5-advanced-customization.md b/docs/dev_guide/5-advanced-customization.md deleted file mode 100755 index 30c704e..0000000 --- a/docs/dev_guide/5-advanced-customization.md +++ /dev/null @@ -1,66 +0,0 @@ -# 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: - -- Project CMake files normaly located in _<project-root-path>/conf.d/app-templates/cmake/cmake.d_ -- 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-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 -variables got the same name. Exceptions are cached variables set using -**CACHE** keyword: - -Example: - -```cmake -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 -scripts that will be passed to cmake command `configure_file`. - -Just create your own script to the following directories: - -- Home location in _$HOME/.config/app-templates/scripts_ -- System location in _/etc/app-templates/scripts_ - -Scripts only needs to use the extension `.in` to be parsed and configured by -CMake command. diff --git a/docs/dev_guide/6-autobuild.md b/docs/dev_guide/6-autobuild.md deleted file mode 100755 index 6977e09..0000000 --- a/docs/dev_guide/6-autobuild.md +++ /dev/null @@ -1,130 +0,0 @@ -# Autobuild script - -The Applications based on AGL framework should have a full packaging solution, -independently of yocto workflow. - -Unfortunately the build part of the Applications is only in documentation or in -yocto recipes. - -The Applications build with AGL framework must be automated without any yocto -recipes. - -A script named **autobuild** is used to control applications build operations. -The bbclass aglwgt.bbclass will call the **autobuild** script for all operations -and is located at the top level of the application repository. - -This script could be written in one of the following languages: - -* Makefile -* Bash -* Python - -The script will be executed directly after a chmod() on it (this implies that the caller should make the script executable before calling it: caller could be aglwgt.bbclass, a jenkins job, a 'real' developer ...) -An appropriate shebang is required to make the script callable directly: - -* '#!/usr/bin/make -f' for Makefile format, -* '#!/usr/bin/bash' for Bash -* etc. - -The calling convention is close to the one from make, in particular to pass arguments through env variables. This is also easy for bash, as a simple eval on arguments will set environment variables correctly. -The generic call has the following format: - -```bash -autobuild/agl/autobuild <command> [ARG1="value1" [ARG2="value2" ... ]] -``` - -autobuild can be invoked from any directory and all relative paths are -considered to be relative to the location of autobuild. - -For makefile scripts, this is the usual behaviour. - -For bash scripts, running a 'cd $(dirname $0)' at the beginning is mandatory. - -At build time, the following calls must be made in the following order: - -```bash -autobuild/agl/autobuild configure CONFIGURE_ARGS="..." -``` - -initializes the build environment (ex: if app uses cmake, the 'configure'' -step will run cmake) - -```bash -autobuild/agl/autobuild build BUILD_ARGS="...." -``` - -builds the application (compile, link binaries, assembles javascript etc.) - -```bash -autobuild/agl/autobuild package PACKAGE_ARGS="..." DEST=<path for resulting wgt -file(s)> -``` - -creates the widget package(s) in the specified destination path prepared by the -caller - -```bash -autobuild/agl/autobuild package-test PACKAGE_ARGS="..." DEST=<path for resulting wgt -file(s)> -``` - -creates the test widget package(s) in the specified destination path prepared by the -caller - -```bash -autobuild/agl/autobuild clean CLEAN_ARGS="..." -``` - -clean the built files (removes the result of autobuild build) - -```bash -autobuild/agl/autobuild distclean DISTCLEAN_ARGS="..." -``` - -clean everything (removes the result of autobuild build + autobuild configure) - -## Generation - -To be integrated in the Yocto build workflow you have to generate `autobuild` -scripts using _autobuild_ target. - -To generate those scripts proceeds: - -```bash -mkdir -p build -cd build -cmake .. && make autobuild -``` - -You should see _autobuild/agl/autobuild_ file now. - -## Available targets - -Here are the available targets available from _autobuild_ scripts: - -- **clean** : clean build directory from object file and targets results. -- **distclean** : delete build directory -- **configure** : generate project Makefile from CMakeLists.txt files. -- **build** : compile all project targets. -- **package** : build and output a wgt package. -- **package-test** : build and output the test wgt as well as the normal wgt - package. -- **install** : install the project in your filesystem - -You can specify variables that modify the behavior of compilation using -the following variables: - -- **CLEAN_ARGS** : Variable used at **clean** time. -- **DISTCLEAN_ARGS** : Variable used at **distclean** time. -- **CONFIGURE_ARGS** : Variable used at **configure** time. -- **BUILD_ARGS** : Variable used at **build** time. -- **DEST** : Directory where to output ***wgt*** file (default at build root - directory). - -Variable as to be in CMake format. (ie: BUILD_ARGS="-DC_FLAGS='-g -O2'") - -Usage example: - -```bash -./autobuild/wgt/autobuild package DEST=/tmp -``` diff --git a/docs/dev_guide/advanced-customization.md b/docs/dev_guide/advanced-customization.md new file mode 100755 index 0000000..dacc2e8 --- /dev/null +++ b/docs/dev_guide/advanced-customization.md @@ -0,0 +1,114 @@ +# Advanced Customization + +Beyond the configurations described in the +[Configuring CMake Templates](configuring-cmake.html) section, +you can provide some advanced configurations. + +This section describes how you can include additional CMake files +and custom template scripts. + +## Including Additional CMake Files + +You can include machine and system custom CMake files and +operating system custom CMake files. + +### Machine and System Custom CMake Files + +Advanced configuration is possible by automatically including +additional CMake files from specific locations. +Following are the locations from which you can add CMake +files. +Inclusions occur in the order shown here: + +- `<project-root-path>/conf.d/app-templates/cmake/cmake.d` - normally located CMake project files +- `$HOME/.config/app-templates/cmake.d` - the home location +- `/etc/app-templates/cmake.d` - the system location + +The CMake files you include must be named using either of the following conventions: + +- `XX-common*.cmake` +- `XX-${PROJECT_NAME}*.cmake` + +In both formats, `XX` are numbers and indicate the order in which the file +is included. +The `*` character represents the filename. + +When naming the file, consider the projects in which the file needs to be +included. +If you want to include the file in all projects, use the keyword `common`. +If you want to include the file in a specific project, use the `${PROJECT_NAME}` +value. + +For example, if you want a CMake file whose name is `my_custom_file` +included first and you want it included in all projects, name the file +`01-common-my_custom_file.cmake`. +If you want the same file included in a single project defined by the +`PROJECT_NAME` variable, and you want it included after all other files, +name the file `99-${PROJECT_NAME}-my_custom_file.cmake`. + +When you include CMake files that use CMake variables, the values override +variables with the same name. +The exception to this rule is if you use a cached variable. +Following is an example: + +```cmake +set(VARIABLE_NAME 'value string random' CACHE STRING 'docstring') +``` + +In this example, the `VARIABLE_NAME` variable is defined as a cached +variable by using the **CACHE** keyword. +Consequently, `VARIABLE_NAME` does not get overridden as a result of +including a CMake file that sets the same variable. + +### Operating System Custom CMake Files + +Including custom CMake files based on the operating system +lets you personalize a project depending on the operating system +you are using. + +At the end of the `config.cmake` file `common.cmake` includes +CMake files to customize your project build depending on your platform. +The operating system is detected by using `/etc/os-release`, +which is the default method used in almost all Linux distributions. +Consequently, you can use the value of field **ID_LIKE** to +add a CMake file for that distribution. +The file comes from your `conf.d/cmake/` directory or relatively +from your `app-templates` submodule path `app-templates/../cmake/`. + +**NOTE:** If the **ID_LIKE** field does not exist, you can use the +**ID** field. + +Files that you add must be named according to the following file naming +convention: + +- `XX-${OSRELEASE}*.cmake` + +In the naming convention, `XX` represents numbers and is the order in which +you want a file included. +The ${OSRELEASE} value is taken from either the **ID_LIKE** or **ID** field +of the `/etc/os-release` file. + +You can also configure a CMake file to be included in cases where no +specific operating system can be found. +To do so, name your CMake file as follows: + +- `XX-default*.cmake` + +A good use case example for these two naming conventions is when you have +a several Linux distributions and all but one can use the same module. +For that case, name one CMake file using the `${OSRELEASE}` value and +name the CMake file to be used with the other distributions using +the `XX-default*.cmake` method. + +## Including Custom Template Scripts + +You can include your own custom template scripts that are passed to the +CMake command `configure_file`. + +Just create your own script and place it in either of the following directories: + +- `$HOME/.config/app-templates/scripts` - the home location +- `/etc/app-templates/scripts` - the system location + +Scripts only need to use the extension `.in` to be parsed and configured by +CMake. diff --git a/docs/dev_guide/advanced-usage.md b/docs/dev_guide/advanced-usage.md new file mode 100755 index 0000000..5df247d --- /dev/null +++ b/docs/dev_guide/advanced-usage.md @@ -0,0 +1,307 @@ +# Advanced Usage + +This topic describes some advanced ways of using the CMake templates. + +## Building a Widget + +To build a widget, you need a `config.xml` file that describes +your application (widget) and how the Application Framework launches it. +Your repository contains a simple default file named +`config.xml.in` that should work for simple applications and should +not require interactions with other bindings. + +It is also recommended that you use the sample configuration +file that you can find in the location. +This file is named `config.xms.in.sample` and is more complete. +Copy the sample file to your `conf.d/wgt` directory and name it +`config.xml.in`. +Once you have your copy, edit the file to fit your needs. + +**CAUTION:** The default file is only meant to be used for a +simple widget application. +For more complicated applications that need to export +their API, or ship several applications in one widget +need to use the provided `config.xml.in.sample` file, which has +all new Application Framework features explained and provides +examples. + +## Using CMake Template Macros + +To leverage all CMake template features, you must specify properties +on your targets. +Some macros do not work unless you specify the target type. +If you do not specify a type (e.g. a custom target such as an +HTML5 application), the macro uses the `LABELS` property to +determine the target type. + +The `LABELS` property can be set to the values shown in the +[Target Properties](configuring-cmake.html#target-properties) +Section. + +Aside from those values, the following optional values can be +assigned to the `LABELS` property. +These values define the resource types that make up your test materials: + +- **TEST-CONFIG**: JSON configuration files used by the `afb-test` + binding. + These files execute the tests. +- **TEST-DATA**: Resources used to test your binding. + Minimally, you need a test plan. + You should also consider fixtures and any files required by your tests. + These required files appear as part of a separate test widget. +- **TEST-PLUGIN**: A shared library used as a binding plugin. + A binding loads the library as a plugin to extend the binding's functionality. + You should use a special file extension when you name the library + by using the `SUFFIX` CMake target property. + If you do not choose an extension, `.ctlso` is used by default. +- **TEST-HTDOCS**: The root directory of a web application. + This target has to build its directory and put its files in + the `${CMAKE_CURRENT_BINARY_DIR}/${TARGET_NAME}` directory. +- **TEST-EXECUTABLE**: The entry point of your application executed by the AGL + Application Framework. +- **TEST-LIBRARY**: An external third-party library bundled with the binding + for its own purpose. + The platform does not provide this library. + +Following is a mapping between `LABELS` and directories where files reside in +the widget: + +- **EXECUTABLE** : \<wgtrootdir\>/bin +- **BINDING-CONFIG** : \<wgtrootdir\>/etc +- **BINDING** | **BINDINGV2** | **BINDINGV3** | **LIBRARY** : \<wgtrootdir\>/lib +- **PLUGIN** : \<wgtrootdir\>/lib/plugins +- **HTDOCS** : \<wgtrootdir\>/htdocs +- **BINDING-DATA** : \<wgtrootdir\>/var +- **DATA** : \<wgtrootdir\>/var + +Following is a mapping between test-dedicated `LABELS` and directories where +files reside in the widget: + +- **TEST-EXECUTABLE** : \<wgtrootdir\>/bin +- **TEST-CONFIG** : \<TESTwgtrootdir\>/etc +- **TEST-PLUGIN** : \<wgtrootdir\>/lib/plugins +- **TEST-HTDOCS** : \<wgtrootdir\>/htdocs +- **TEST-DATA** : \<TESTwgtrootdir\>/var + +**TIP:** Use the prefix `afb-` (Application Framework Binding) +with your **BINDING** targets. + +Following is an example that sets the `LABELS` and `OUTPUT_NAME` properties: + +```cmake +SET_TARGET_PROPERTIES(${TARGET_NAME} PROPERTIES + LABELS "HTDOCS" + OUTPUT_NAME dist.prod + ) +``` + +**NOTE**: You do not need to specify an **INSTALL** command for these + targets. + Installation is handled by the template and installs using the + following path : **${CMAKE_INSTALL_PREFIX}/${PROJECT_NAME}** + + Also, if you want to set and use `rpath` with your target, you should use + and set the target property `INSTALL_RPATH`. + +## Adding an External Third-Party Library + +You can add an external third-party library that is built, linked, +and shipped with the project. +Or, you can link and ship the library only with the project. + +### Building, Linking, and Shipping an External Library with the Project + +If you need to include an external library that is not shipped +with the project, you can bundle the required library in the +`lib` widget directory. + +Templates includes facilities to help you work with external +libraries. +A standard method is to declare as many CMake ExternalProject +modules as you need to match the number of needed libraries. + +An ExternalProject module is a special CMake module that lets you define how +to download, update, patch, configure, build, and install an external project. +The project does not need to be a CMake project. +Additionally, you can provide custom steps to account for special +needs using ExternalProject step. +See the CMake +[ExternalProject documentation site](https://cmake.org/cmake/help/v3.5/module/ExternalProject.html?highlight=externalproject) +for more information. + +Following is an example that includes the `mxml` library for the +[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}) +``` + +The example defines an external project that drives the building of the library. +The example also defines a new CMake target whose type is **IMPORTED**. +The **IMPORTED** target type indicates the target has yet to be built using +CMake but is available at the location defined using the **IMPORTED_LOCATION** +target property. + +You might want to build the library as **SHARED** or **STATIC** depending on your needs +and goals. +Next, the example only has to modify the external project configure step and change +the filename used by **IMPORTED** library target defined after external project. + +The target's **LABELS** property is set to **LIBRARY** to ship it in the widget. + +In this example, the Unicens project also needs header +information from this library. +Consequently, the **INTERFACE_INCLUDE_DIRECTORIES** target property +is used. +Setting that property when another target links to that imported target +allows access to included directories. + +Finally, the example binds the target to the external project +by using a CMake dependency. + +The target can now be linked and used like any other CMake target. + +### Link and Ship an External Library with the Project + +If you already have a binary version of the library that you want to use and you +cannot or do not want to build the library, you can use the **IMPORTED** +library target. + +To illustrate, consider the same example in the previous section. +Following are the relevant modifications: + +```cmake +PROJECT_TARGET_ADD(mxml) + +add_library(${TARGET_NAME} SHARED IMPORTED GLOBAL) + +SET_TARGET_PROPERTIES(${TARGET_NAME} PROPERTIES + LABELS LIBRARY + IMPORTED_LOCATION /path_to_library/libmxml.so.1 + INTERFACE_INCLUDE_DIRECTORIES /path_to_mxml/include/dir +) +``` + +In the previous example, notice the changes to the +`IMPORTED_LOCATION` and `INTERFACE_INCLUDE_DIRECTORIES` statements. +These locate the binary version of the library. + +Finally, you can link any other library or executable target with this imported +library just as you would for any other target. + +## Macro Reference + +Following are several macros that are useful for advanced CMake usage. + +### PROJECT_TARGET_ADD + +This macro adds the target to your project. +Following is a typical example that adds the target to your project. +You need to provide the name of your target as the macro's parameter: + +Example: + +```cmake +PROJECT_TARGET_ADD(low-can-demo) +``` + +The macro makes the variable `${TARGET_NAME}` available and it is defined +using the specified name (e.g. `low-can-demo`). +The variable changes each time the `PROJECT_TARGET_ADD` macro is called. + +### project_subdirs_add + +This macro searches within specified subfolders of the CMake project for +any `CMakeLists.txt` file. +If the file is found, it is added to your project. +You can use this macro in a hybrid application (e.g. where the binding +exists in a subfolder). + +The following example searches within all subfolders: + +Usage : + +```cmake +project_subdirs_add() +``` + +You might want to restrict the subfolders being searched. +If so, you can specify a +[globbing](https://en.wikipedia.org/wiki/Glob_(programming)) pattern +as the argument. +Doing so effectively creates a search filter. + +Following is an example that specifies all directories that begin +with a number, are followed by the dash character, and then followed +by any characters: + +```cmake +project_subdirs_add("[0-9]-*") +``` + +### set_openapi_filename + +This macro is used with a **BINDINGV2** target and defines the +binding definition filename. +You can use it to also define a relative path to +the current `CMakeLists.txt` file. + +If you do not use this macro to specify the name of your definition file, +the default one is used, which is `${OUTPUT_NAME}-apidef` and uses +**OUTPUT_NAME** as the [target property]. + +**CAUTION** When specifying the binding definition filename, +you must not use the file's extension as part of the name. +Following is an example: + +```cmake +set_openapi_filename('binding/mybinding_definition') +``` + +[target property]: https://cmake.org/cmake/help/v3.6/prop_tgt/OUTPUT_NAME.html "OUTPUT_NAME property documentation" + +### add_input_files + +This macro creates a custom target dedicated for HTML5 and data resource files. +The macro provides syntax and schema verification for different languages that +include LUA, JSON and XML. + +Alongside the macro are tools used to check files. +You can configure the tools by setting the +following variables: + +- XML_CHECKER: Uses **xmllint** that is provided with major linux distributions. +- LUA_CHECKER: Uses **luac** that is provided with major linux distributions. +- JSON_CHECKER: Currently, not used by any tools. + +Following is an example: + +```cmake +add_input_file("${MY_FILES_LIST}") +``` + +**NOTE**: If an issue occurs during the "check" step of the macro, +the build halts. diff --git a/docs/dev_guide/autobuild.md b/docs/dev_guide/autobuild.md new file mode 100755 index 0000000..6a1f97c --- /dev/null +++ b/docs/dev_guide/autobuild.md @@ -0,0 +1,132 @@ +# Autobuild + +Applications based on the AGL framework should have a +full build and packaging solution that is independent of the +[Yocto Project](https://www.yoctoproject.org) workflow. + +You can create a script named **autobuild** to control applications +build operations. +AGL provides a BitBake class file (`aglwgt.bbclass`) that calls the +**autobuild** script for all operations. +The class file is located at the top level of the application repository. + +You can write the **autobuild** script using any of the following languages: + +* Makefile +* Bash +* Python + +The script executes directly after applying a `chmod()` command. +The caller, which can be the `aglwgt.bbclass`, a Jenkins job, or an actual person, +must make the **autobuild** executable before calling it. +To facilitate direct execution, you need to start the script with a +[shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) sequence: + +* '#!/usr/bin/make -f' for Makefile format +* '#!/usr/bin/bash' for Bash format + +The calling convention is similar to the convention used in `make`. +To pass arguments, use environment variables. + +**NOTE:** For Bash, an evaluation of the arguments +sets the environment variables correctly. + +The following format shows the generic call: + +```bash +autobuild/agl/autobuild <command> [ARG1="value1" [ARG2="value2" ... ]] +``` + +The **autobuild** script can be invoked from any directory +with all paths considered to be relative to the +script's location. +For makefile scripts, this is the usual behavior. +For Bash scripts, a `cd $(dirname $0)` command must be run at +the beginning of the script. + +At build time, the following calls must be made in the following order: + +1. Initialize the build environment (e.g if the application uses + `cmake` the configure step runs CMake). + + ```bash + autobuild/agl/autobuild configure CONFIGURE_ARGS="..." + ``` + +2. Build the application (i.e. compile, link binaries, assembles javascript, + and so forth). + + ```bash + autobuild/agl/autobuild build BUILD_ARGS="...." + ``` + +3. Create the widget package(s) in the specified destination path + prepared by the caller. + + ```bash + autobuild/agl/autobuild package PACKAGE_ARGS="..." DEST=<path-for-resulting-wgt-files> + ``` + +4. Create the test widget package(s) in the specified destination path + prepared by the caller. + + ```bash + autobuild/agl/autobuild package-test PACKAGE_ARGS="..." DEST=<path-for-resulting-wgt-files> + ``` + +5. Clean the built files by removing the result of the **autobuild** build. + + ```bash + autobuild/agl/autobuild clean CLEAN_ARGS="..." + ``` + +6. Clean everything by removing the result of the **autobuild** build + and the **autobuild** configure. + + ```bash + autobuild/agl/autobuild distclean DISTCLEAN_ARGS="..." + ``` + +## Integrating **autobuild** into the Yocto Project Workflow + +If you want to integrate the **autobuild** script into the Yocto Project +workflow, you need to generate the script. +To generate the script, use the `autobuild` target. + +The following commands create the **autobuild** script in the +`autobuild/agl` directory: + +```bash +mkdir -p build +cd build +cmake .. && make autobuild +``` + +## Available Targets + +Following are the targets available from the **autobuild** script: + +- **clean**: Removes object file and target results from the build directory. +- **distclean**: Deletes the build directory. +- **configure**: Generates the project Makefile from the `CMakeLists.txt` files. +- **build**: Compiles all project targets. +- **package**: Builds a widget (**wgt**) package. +- **package-test**: Builds the test **wgt** package and the normal **wgt** package. +- **install**: Installs the project into your filesystem. + +Specifying the following variables lets you modify compilation behavior: + +- **CLEAN_ARGS**: Variable used at **clean** time. +- **DISTCLEAN_ARGS**: Variable used at **distclean** time. +- **CONFIGURE_ARGS**: Variable used at **configure** time. +- **BUILD_ARGS**: Variable used at **build** time. +- **DEST**: Directory in which to place the created ***wgt*** file. + The default directory is the build root directory. + +When you provide a variable, use the CMake format (i.e. +BUILD_ARGS="-DC_FLAGS='-g -O2'"). +Following is an example: + +```bash +./autobuild/wgt/autobuild package DEST=/tmp +``` diff --git a/docs/dev_guide/0-cmake-overview.md b/docs/dev_guide/cmake-overview.md index ca76728..ca76728 100755 --- a/docs/dev_guide/0-cmake-overview.md +++ b/docs/dev_guide/cmake-overview.md diff --git a/docs/dev_guide/2-configuring-cmake.md b/docs/dev_guide/configuring-cmake.md index 12842ac..12842ac 100755 --- a/docs/dev_guide/2-configuring-cmake.md +++ b/docs/dev_guide/configuring-cmake.md diff --git a/docs/dev_guide/installing-cmake.md b/docs/dev_guide/installing-cmake.md new file mode 100755 index 0000000..d1edcb6 --- /dev/null +++ b/docs/dev_guide/installing-cmake.md @@ -0,0 +1,50 @@ +# Installing CMake Templates + +You can install CMake templates on your native Linux system. + +In order to use the templates, you need to install them as +a CMake module. +On your native Linux system, use your distribution's package manager. +See the +"[Prerequisites](../../2-download-packages.html)" +section for how to install packages using your distribution's package +manager. +Be sure to use the following with you install the packages: + +```bash +export DISTRO="xUbuntu_16.10" +export REVISION=Master +``` + +**NOTE:** In order to use the CMake templates, you must be using the +AGL Guppy release. +You cannot use prior releases. + +## Installing on Debian or Ubuntu + +Use the following command to install AGL's CMake Application Module +on a native Debian or Ubuntu system: + +```bash +sudo apt-get install agl-cmake-apps-module-bin +``` + +## Installing on OpenSUSE + +Use the following command to install AGL's CMake Application Module +on a native OpenSUSE system: + +```bash +sudo zypper install agl-cmake-apps-module +``` + +## Installing on Fedora + +Use the following command to install AGL's CMake Application Module +on a native Fedora system: + +```bash +sudo dnf install agl-cmake-apps-module +``` + + diff --git a/docs/dev_guide/pictures/iotbzh_logo_small.png b/docs/dev_guide/pictures/iotbzh_logo_small.png Binary files differindex 6a98c60..6a98c60 100644..100755 --- a/docs/dev_guide/pictures/iotbzh_logo_small.png +++ b/docs/dev_guide/pictures/iotbzh_logo_small.png diff --git a/docs/dev_guide/3-project-architecture.md b/docs/dev_guide/project-architecture.md index aefaca3..d36fc76 100755 --- a/docs/dev_guide/3-project-architecture.md +++ b/docs/dev_guide/project-architecture.md @@ -1,6 +1,5 @@ # Project architecture -CMake projects follow a typical file hierarchy. The following tree structure represents a typical CMake project directory structure: diff --git a/docs/dev_guide/1-installing-cmake.md b/docs/dev_guide/using-cmake.md index 5de16cd..1153310 100755 --- a/docs/dev_guide/1-installing-cmake.md +++ b/docs/dev_guide/using-cmake.md @@ -1,53 +1,9 @@ -# Installing CMake Templates - -You can install CMake templates on your native Linux system. - -In order to use the templates, you need to install them as -a CMake module. -On your native Linux system, use your distribution's package manager. -See the -"[Prerequisites](../host-configuration/docs/2-download-packages.html)" -section for how to install packages using your distribution's package -manager. -Be sure to use the following with you install the packages: - -```bash -export DISTRO="xUbuntu_16.10" -export REVISION=Master -``` - -**NOTE:** In order to use the CMake templates, you must be using the -AGL Guppy release. -You cannot use prior releases. - -## Installing on Debian or Ubuntu - -Use the following command to install AGL's CMake Application Module -on a native Debian or Ubuntu system: +# Using CMake Templates -```bash -sudo apt-get install agl-cmake-apps-module-bin -``` - -## Installing on OpenSUSE +You can use CMake templates in a cross-compilation environment +or from BitBake recipes. -Use the following command to install AGL's CMake Application Module -on a native OpenSUSE system: - -```bash -sudo zypper install agl-cmake-apps-module -``` - -## Installing on Fedora - -Use the following command to install AGL's CMake Application Module -on a native Fedora system: - -```bash -sudo dnf install agl-cmake-apps-module -``` - -# Using CMake Templates in a Cross-Compilation Environment +## Using CMake Templates in a Cross-Compilation Environment Beginning with the `Grumpy Guppy`, version 7, the CMakeAfbTemplates CMake module is installed by default in the SDKs supplied by AGL. @@ -62,7 +18,7 @@ Following are links to the latest SDKs on the AGL master branch: * [qemux86-64](https://download.automotivelinux.org/AGL/snapshots/master/latest/qemux86-64/deploy/sdk/) * [raspberrypi3](https://download.automotivelinux.org/AGL/snapshots/master/latest/raspberrypi3/deploy/sdk/) -# Using CMake Templates from BitBake Recipes +## Using CMake Templates from BitBake Recipes If you have developed an application and you want to include it in an AGL image, you must add a BitBake recipe in one of the following layers: @@ -109,11 +65,7 @@ RDEPENDS_${PN} += "agl-service-identity-agent" inherit cmake aglwgt pkgconfig ``` ----- - -# Additional Examples - -The following links provide further examples of recipes that use the +The following links provide more examples of recipes that use the CMake templates: * [helloworld-service](https://github.com/iotbzh/helloworld-service) |
