From 16829a33f77f9d9eda435f5f1c36f36bc33fb267 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 19 Mar 2019 11:59:52 -0600 Subject: cmake-apps-module: New file names. Created some new file names based on some re-writing. Also, updated the devguides-book.yml file to reflect the state of things. Change-Id: I6a9a91fe9c2f271493404ab7d63b6d6a8faf586e Signed-off-by: Scott Rifenbark --- docs/dev_guide/0-cmake-overview.md | 9 + docs/dev_guide/1-installing-cmake.md | 122 +++++++++++++ docs/dev_guide/2-configuring-cmake.md | 138 ++++++++++++++ docs/dev_guide/2_project_architecture.md | 50 ------ docs/dev_guide/3-project-architecture.md | 76 ++++++++ docs/dev_guide/3_advanced_usage.md | 278 ----------------------------- docs/dev_guide/4-advanced-usage.md | 278 +++++++++++++++++++++++++++++ docs/dev_guide/4_advanced_customization.md | 66 ------- docs/dev_guide/5-advanced-customization.md | 66 +++++++ docs/dev_guide/5_autobuild.md | 130 -------------- docs/dev_guide/6-autobuild.md | 130 ++++++++++++++ 11 files changed, 819 insertions(+), 524 deletions(-) create mode 100755 docs/dev_guide/0-cmake-overview.md create mode 100755 docs/dev_guide/1-installing-cmake.md create mode 100755 docs/dev_guide/2-configuring-cmake.md delete mode 100644 docs/dev_guide/2_project_architecture.md create mode 100755 docs/dev_guide/3-project-architecture.md delete mode 100644 docs/dev_guide/3_advanced_usage.md create mode 100755 docs/dev_guide/4-advanced-usage.md delete mode 100644 docs/dev_guide/4_advanced_customization.md create mode 100755 docs/dev_guide/5-advanced-customization.md delete mode 100644 docs/dev_guide/5_autobuild.md create mode 100755 docs/dev_guide/6-autobuild.md (limited to 'docs/dev_guide') diff --git a/docs/dev_guide/0-cmake-overview.md b/docs/dev_guide/0-cmake-overview.md new file mode 100755 index 0000000..ca76728 --- /dev/null +++ b/docs/dev_guide/0-cmake-overview.md @@ -0,0 +1,9 @@ +# Overview + +The CMake AGL Framework Template Module +helps to build applications or bindings for the +AGL Application Framework. +You can use the template module to easily build a widget and its related +test widget for running on top the AGL Application Framework. + + diff --git a/docs/dev_guide/1-installing-cmake.md b/docs/dev_guide/1-installing-cmake.md new file mode 100755 index 0000000..5de16cd --- /dev/null +++ b/docs/dev_guide/1-installing-cmake.md @@ -0,0 +1,122 @@ +# 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: + +```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 +``` + +# 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. +Consequently, you do not need to take steps to install the modules. + +Following are links to the latest SDKs on the AGL 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 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: + +* [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) + +Once you have the recipe in place, edit it to include the following +line to cause the `aglwgt` class to be inherited: + +```bb +inherit aglwgt +``` + +Following is an example that uses the HVAC application recipe (i.e. `hvac.bb`), which +builds the HVAC application: + +```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 +``` + +---- + +# Additional Examples + +The following links provide further examples of recipes that use the +CMake templates: + +* [helloworld-service](https://github.com/iotbzh/helloworld-service) +* [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/2-configuring-cmake.md b/docs/dev_guide/2-configuring-cmake.md new file mode 100755 index 0000000..12842ac --- /dev/null +++ b/docs/dev_guide/2-configuring-cmake.md @@ -0,0 +1,138 @@ +# Configuring CMake Templates + +Configuration consists of editing the `config.cmake` file for your +specific project. + +## Creating Your `config.cmake` File + +First, you need to create a `confd/cmake` file in your CMake project +directory. + +```bash +mkdir -p conf.d/cmake +``` + +Next, use one of the following commands to copy a `cmake.sample` file to +your `config.cmake` file. +The first command applies if you have the SDK installed, while the +second command applies if you installed the modules on your native Linux system. + +**NOTE:** The `OECORE_NATIVE_SYSROOT` variable is defined once you have +a project folder, the AGL SDK source files, and the CMake modules installed. + +```bash +mkdir -p conf.d/cmake +# From the SDK sysroot >= RC2 of the 7.0.0 Guppy release +cp ${OECORE_NATIVE_SYSROOT}/usr/share/doc/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 +``` + +Once you have created your `config.cmake` file, you need to make the changes +specific to your project. + +## Creating Your `CMakeLists.txt` File + +To create this file, use the example in the **cmake module**. +Use one of the following two commands to create your file. +The first command applies if you have the SDK installed, while the +second command applies if you installed the modules on your native Linux system. + +**NOTE:** The `OECORE_NATIVE_SYSROOT` variable is defined once you have +a project folder, the AGL SDK source files, and the CMake modules installed. + +```bash +# From the SDK sysroot >= RC2 of the 7.0.0 Guppy release +cp ${OECORE_NATIVE_SYSROOT}/usr/share/doc/CMakeAfbTemplates/samples.d/CMakeLists.txt.sample CMakeLists.txt +# From a native installation +cp /usr/share/doc/CMakeAfbTemplates/samples.d/CMakeLists.txt.sample CMakeLists.txt +``` + +## Creating Your CMake Targets + +Creating a CMake target is the result of editing your `CMakeLists.txt` file. + +For each target that is part of your project, you need to use the +***PROJECT_TARGET_ADD*** statement. +Using this statement includes the target in your project. + +Using the ***PROJECT_TARGET_ADD*** statement makes the CMake ***TARGET_NAME*** +variable available until the next ***PROJECT_TARGET_ADD*** statement is +encountered that uses a new target name. + +Following is typical use within the `CMakeLists.txt` file to create a target: + +```cmake +PROJECT_TARGET_ADD(target_name) --> Adds *target_name* to the project. +*target_name* is a sub-folder in the CMake project. + +add_executable/add_library(${TARGET_NAME}.... --> Defines the target sources. + +SET_TARGET_PROPERTIES(${TARGET_NAME} PROPERTIES.... --> Configures the target properties +so they can be used by macros. + +INSTALL(TARGETS ${TARGET_NAME}.... +``` + +## Target Properties + +Target properties are used to determine the nature of the +target and where the target is stored within the package being built. + +Use the **LABELS** property to specify the target type that you want +included in the widget package. +You can choose the following target types: + +Choose between: + +- **BINDING**: A shared library loaded by the AGL Application Framework. +- **BINDINGV2**: A shared library loaded by the AGL Application Framework. + This library must be accompanied by a JSON file named similar to the + *${OUTPUT_NAME}-apidef* of the target, which describes the API with OpenAPI + syntax (e.g: *mybinding-apidef*). + Alternatively, you can choose the name without the extension using the + **set_openapi_filename** macro. + If you use C++, you must set **PROJECT_LANGUAGES** through *CXX*. +- **BINDINGV3**: A shared library loaded by the AGL Application Framework. + This library must be accompanied by a JSON file named similar to the + *${OUTPUT_NAME}-apidef* of the target, which describes the API with OpenAPI + syntax (e.g: *mybinding-apidef*). + Alternatively, you can choose the name without the extension using the + **set_openapi_filename** macro. + If you use C++, you must set **PROJECT_LANGUAGES** through *CXX*. +- **PLUGIN**: A shared library meant to be used as a binding plugin, which + would load the library as a plugin consequently extending its + functionalities. + You should name the binding using a special extension that you choose + with `SUFFIX cmake target property`. + If you do not use the special extension, it defaults to **.ctlso**. +- **HTDOCS**: The root directory of a web application. + 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**: The entry point of your application executed by the AGL + Application Framework. +- **LIBRARY**: An external third-party library bundled with the binding. + The library is bundled in this manner because the platform does not + provide bundling. +- **BINDING-CONFIG**: Any files used as configuration by your binding. + +**TIP:** you should use the prefix _afb-_ (**Application Framework Binding**) +with your *BINDING* targets. + +Following is an example that uses the **BINDINGV3** property: + +```cmake +SET_TARGET_PROPERTIES(${TARGET_NAME} PROPERTIES + PREFIX "afb-" + LABELS "BINDINGV3" + OUTPUT_NAME "file_output_name") +``` + +**CAUTION**: You do not need to specify an **INSTALL** command for these +targets. +Installation is performed by the template. +Targets are installed in the **${CMAKE_INSTALL_PREFIX}/${PROJECT_NAME}** +directory. diff --git a/docs/dev_guide/2_project_architecture.md b/docs/dev_guide/2_project_architecture.md deleted file mode 100644 index 9e5503f..0000000 --- a/docs/dev_guide/2_project_architecture.md +++ /dev/null @@ -1,50 +0,0 @@ -# Project architecture - -A typical project architecture would be : - -```tree - -│ -├── autobuild/ -│ ├── agl -│ │ └── autobuild -│ ├── linux -│ │ └── autobuild -│ └── windows -│ └── autobuild -├── conf.d/ -│ ├── packaging/ -│ │ ├── rpm -│ │ │ └── package.spec -│ │ └── deb -│ │ ├── package.dsc -│ │ ├── debian.package.install -│ │ ├── debian.changelog -│ │ ├── debian.compat -│ │ ├── debian.control -│ │ └── debian.rules -│ ├── cmake -│ │ ├── 00-debian-osconfig.cmake -│ │ ├── 00-suse-osconfig.cmake -│ │ ├── 01-default-osconfig.cmake -│ │ └── config.cmake -│ └── wgt -│ ├── icon.png -│ └── config.xml.in -├── -│ └── -├── -│ └── -└── - └── -``` - -| # | Parent | Description | -| - | -------| ----------- | -| \ | - | Path to your project. Hold master CMakeLists.txt and general files of your projects. | -| autobuild | \ | Scripts generated from app-templates to build packages the same way for differents platforms.| -| conf.d | \ | Holds needed files to build, install, debug, package an AGL app project | -| cmake | conf.d | Contains at least config.cmake file modified from the sample provided in app-templates submodule. | -| packaging | conf.d | Contains output files used to build packages. | -| wgt | conf.d | Contains config.xml.in, and optionnaly test-config.xml.in template files modified from the sample provided in cmake module for the needs of project (See config.xml.in.sample and test-config.xml.in.sample file for more details). | -| \ | \ | A target to build, typically library, executable, etc. | diff --git a/docs/dev_guide/3-project-architecture.md b/docs/dev_guide/3-project-architecture.md new file mode 100755 index 0000000..aefaca3 --- /dev/null +++ b/docs/dev_guide/3-project-architecture.md @@ -0,0 +1,76 @@ +# Project architecture + +CMake projects follow a typical file hierarchy. +The following tree structure represents a typical CMake project +directory structure: + +```tree + +| +├── CMakeLists.txt +│ +├── autobuild/ +│ ├── agl +│ │ └── autobuild +│ ├── linux +│ │ └── autobuild +│ └── windows +│ └── autobuild +├── conf.d/ +│ ├── packaging/ +│ │ ├── rpm +│ │ │ └── package.spec +│ │ └── deb +│ │ ├── package.dsc +│ │ ├── debian.package.install +│ │ ├── debian.changelog +│ │ ├── debian.compat +│ │ ├── debian.control +│ │ └── debian.rules +│ ├── cmake +│ │ ├── 00-debian-osconfig.cmake +│ │ ├── 00-suse-osconfig.cmake +│ │ ├── 01-default-osconfig.cmake +│ │ └── config.cmake +│ └── wgt +│ ├── icon.png +│ └── config.xml.in +├── +│ └── +├── +│ └── +└── + └── +``` + +| File or Directory | Parent | Description | +|----|----|----| +| *root_path* | n/a | CMake project root path. Holds the master CMakeLists.txt file and all general project files. +| CMakeLists.txt | The master CMakeLists.txt file. +| autobuild/ | *root_path* | Scripts generated from app-templates to build packages the same way for differents platforms. +| conf.d/ | *root_path* | Holds needed files to build, install, debug, and package an AGL application project. +| packaging/ | confd/ | Contains output files used to build packages. +| cmake/ | confd/ | Minimally contains the config.cmake file, which is modified from the sample provided in the app-templates submodule. +| wgt/ | confd/ | Contains config.xml.in and optionaly the test-config.xml.in template files that are modified from the sample provided with the CMake module for the needs of the project. For more details, see the config.xml.in.sample and test-config.xml.in.sample files. +| *target* | *root_path* | A target to build, which is typically a library or executable. + +When building projects using CMake, the build process automatically detects +the `CMakeLists.txt` and `*.cmake` files. +To help with this process, the `PROJECT_SRC_DIR_PATTERN` variable +is used for recursive pattern searching from the CMake project's +*root_path* downward. +Each sub-folder below *root_path* in the project is searched and included +during compilation. +The directories matching the pattern `PROJECT_SRC_DIR_PATTERN` variable +are scanned. + +**NOTE:** The `PROJECT_SRC_DIR_PATTERN` variable defaults to "*". + +When the `CMakeLists.txt` file is found, the directory in which it is found +is automatically added to the CMake project. + +Similarly, when a file whose extension is `.cmake` is found, the directory in +which that file resides is also added to the CMake project. + + + diff --git a/docs/dev_guide/3_advanced_usage.md b/docs/dev_guide/3_advanced_usage.md deleted file mode 100644 index 3e0ace1..0000000 --- a/docs/dev_guide/3_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** : \/bin -- **BINDING-CONFIG** : \/etc -- **BINDING** | **BINDINGV2** | **BINDINGV3** | **LIBRARY** : \/lib -- **PLUGIN** : \/lib/plugins -- **HTDOCS** : \/htdocs -- **BINDING-DATA** : \/var -- **DATA** : \/var - -And about test dedicated **LABELS**: - -- **TEST-EXECUTABLE** : \/bin -- **TEST-CONFIG** : \/etc -- **TEST-PLUGIN** : \/lib/plugins -- **TEST-HTDOCS** : \/htdocs -- **TEST-DATA** : \/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/4-advanced-usage.md b/docs/dev_guide/4-advanced-usage.md new file mode 100755 index 0000000..3e0ace1 --- /dev/null +++ b/docs/dev_guide/4-advanced-usage.md @@ -0,0 +1,278 @@ +# 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** : \/bin +- **BINDING-CONFIG** : \/etc +- **BINDING** | **BINDINGV2** | **BINDINGV3** | **LIBRARY** : \/lib +- **PLUGIN** : \/lib/plugins +- **HTDOCS** : \/htdocs +- **BINDING-DATA** : \/var +- **DATA** : \/var + +And about test dedicated **LABELS**: + +- **TEST-EXECUTABLE** : \/bin +- **TEST-CONFIG** : \/etc +- **TEST-PLUGIN** : \/lib/plugins +- **TEST-HTDOCS** : \/htdocs +- **TEST-DATA** : \/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/4_advanced_customization.md b/docs/dev_guide/4_advanced_customization.md deleted file mode 100644 index 30c704e..0000000 --- a/docs/dev_guide/4_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 _/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/5-advanced-customization.md b/docs/dev_guide/5-advanced-customization.md new file mode 100755 index 0000000..30c704e --- /dev/null +++ b/docs/dev_guide/5-advanced-customization.md @@ -0,0 +1,66 @@ +# 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 _/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/5_autobuild.md b/docs/dev_guide/5_autobuild.md deleted file mode 100644 index 6977e09..0000000 --- a/docs/dev_guide/5_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 [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= -``` - -creates the widget package(s) in the specified destination path prepared by the -caller - -```bash -autobuild/agl/autobuild package-test PACKAGE_ARGS="..." DEST= -``` - -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/6-autobuild.md b/docs/dev_guide/6-autobuild.md new file mode 100755 index 0000000..6977e09 --- /dev/null +++ b/docs/dev_guide/6-autobuild.md @@ -0,0 +1,130 @@ +# 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 [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= +``` + +creates the widget package(s) in the specified destination path prepared by the +caller + +```bash +autobuild/agl/autobuild package-test PACKAGE_ARGS="..." DEST= +``` + +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 +``` -- cgit 1.2.3-korg