diff options
| -rw-r--r-- | README.md | 607 | ||||
| -rw-r--r-- | docs/README.md | 22 | ||||
| -rw-r--r-- | docs/dev_guide/0_Abstract.md | 45 | ||||
| -rw-r--r-- | docs/dev_guide/1_Quickstart.md | 34 | ||||
| -rw-r--r-- | docs/dev_guide/2_project_architecture.md | 104 | ||||
| -rw-r--r-- | docs/dev_guide/5_autobuild.md | 97 |
6 files changed, 166 insertions, 743 deletions
diff --git a/README.md b/README.md deleted file mode 100644 index 4e9b78b..0000000 --- a/README.md +++ /dev/null @@ -1,607 +0,0 @@ -# AGL CMake template - -Files used to build an application, or binding, project with the -AGL Application Framework. - -To build your AGL project using these templates, you have to install -them within your project and adjust compilation option in `config.cmake`. -For technical reasons, you also have to specify **cmake** target in -sub CMakeLists.txt installed. Make a global search to find source files -isn't recommended now to handle project build especially in a multi-users -project because CMake will not be aware of new or removed source files. - -You'll find usage samples here: - -- [helloworld-service](https://github.com/iotbzh/helloworld-service) -- [low-level-can-service](https://gerrit.automotivelinux.org/gerrit/apps/low-level-can-service) -- [high-level-viwi-service](https://github.com/iotbzh/high-level-viwi-service) -- [audio-binding](https://github.com/iotbzh/audio-binding) -- [unicens2-binding](https://github.com/iotbzh/unicens2-binding) - -## Quickstart - -### Initialization - -To use these templates files on your project just install the reference files using -**git submodule** then use `config.cmake` file to configure your project specificities : - -```bash -git submodule add https://gerrit.automotivelinux.org/gerrit/p/apps/app-templates.git conf.d/app-templates -mkdir conf.d/cmake -cp conf.d/app-templates/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 **app-templates** submodule that you can copy and -use: - -```bash -cp conf.d/app-templates/samples.d/CMakeLists.txt.sample CMakeLists.txt -``` - -### Create your CMake targets - -For each target part of your project, you need to use ***PROJECT_TARGET_ADD*** -to include this target to your project. - -Using it, make available the cmake variable ***TARGET_NAME*** until the next -***PROJECT_TARGET_ADD*** is invoked with a new target name. - -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 -``` - -### Targets PROPERTIES - -You should set properties on your targets that will be used to package your -apps in a widget file that could be installed on an AGL system. - -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 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. 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. -- **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} - PREFIX "afb-" - LABELS "BINDINGV3" - OUTPUT_NAME "file_output_name") -``` - -> **NOTE**: You doesn't need to specify an **INSTALL** command for these -> targets. This is already handle by template and will be installed in the -> following path : **${CMAKE_INSTALL_PREFIX}/${PROJECT_NAME}** - -## More details: Typical project architecture - -A typical project architecture would be : - -```tree -<project-root-path> -│ -├── conf.d/ -│ ├── autobuild/ -│ │ ├── agl -│ │ │ └── autobuild -│ │ ├── linux -│ │ │ └── autobuild -│ │ └── windows -│ │ └── autobuild -│ ├── app-templates/ -│ │ ├── README.md -│ │ ├── cmake/ -│ │ │ ├── export.map -│ │ │ └── macros.cmake -│ │ ├── samples.d/ -│ │ │ ├── CMakeLists.txt.sample -│ │ │ ├── config.cmake.sample -│ │ │ ├── config.xml.in.sample -│ │ │ └── xds-config.env.sample -│ │ ├── template.d/ -│ │ │ ├── autobuild/ -│ │ │ │ ├── agl -│ │ │ │ │ └── autobuild.in -│ │ │ │ ├── linux -│ │ │ │ │ └── autobuild.in -│ │ │ │ └── windows -│ │ │ │ └── autobuild.in -│ │ │ ├── config.xml.in -│ │ │ ├── deb-config.dsc.in -│ │ │ ├── deb-config.install.in -│ │ │ ├── debian.changelog.in -│ │ │ ├── debian.compat.in -│ │ │ ├── debian.rules.in -│ │ │ ├── gdb-on-target.ini.in -│ │ │ ├── install-wgt-on-target.sh.in -│ │ │ ├── start-on-target.sh.in -│ │ │ ├── rpm-config.spec.in -│ │ │ └── xds-project-target.conf.in -│ │ └── wgt/ -│ │ ├── icon-default.png -│ │ ├── icon-html5.png -│ │ ├── icon-native.png -│ │ ├── icon-qml.png -│ │ └── icon-service.png -│ ├── packaging/ -│ │ ├── config.spec -│ │ └── config.deb -│ ├── cmake -│ │ └── config.cmake -│ └── wgt -│ └── config.xml.in -├── <libs> -├── <target> -│ └── <files> -├── <target> -│ └── <file> -└── <target> - └── <files> -``` - -| # | Parent | Description | -| - | -------| ----------- | -| \<root-path\> | - | Path to your project. Hold master CMakeLists.txt and general files of your projects. | -| conf.d | \<root-path\> | Holds needed files to build, install, debug, package an AGL app project | -| app-templates | conf.d | Git submodule to app-templates AGL repository which provides CMake helpers macros library, and build scripts. config.cmake is a copy of config.cmake.sample configured for the projects. SHOULD NOT BE MODIFIED MANUALLY !| -| autobuild | conf.d | Scripts generated from app-templates to build packages the same way for various platforms.| -| cmake | conf.d | Contains at least config.cmake file modified from the sample provided in app-templates submodule. | -| wgt | conf.d | Contains at least config.xml.in template file modified from the sample provided in app-templates submodule for the needs of project (See config.xml.in.sample file for more details). | -| packaging | conf.d | Contains output files used to build packages. | -| \<libs\> | \<root-path\> | External dependencies libraries. This isn't to be used to include header file but build and link statically specifics libraries. | Library sources files. Can be a decompressed library archive file or project fork. | -| \<target\> | \<root-path\> | A target to build, typically library, executable, etc. | - -### Update app-templates submodule - -You may have some news bug fixes or features available from app-templates -repository that you want. To update your submodule proceed like the following: - -```bash -git submodule update --remote -git commit -s conf.d/app-templates -``` - -This will update the submodule to the HEAD of master branch repository. - -You could just want to update at a specified repository tag or branch or commit -, here are the method to do so: - -```bash -cd conf.d/app-templates -# Choose one of the following depending what you want -git checkout <tag_name> -git checkout --detach <branch_name> -git checkout --detach <commit_id> -# Then commit -cd ../.. -git commit -s conf.d/app-templates -``` - -### 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 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** - 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 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** - 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 files needed by your tests. These files - will appear in a separate test widget. -- **TEST-PLUGIN**: Shared library meant to be used as a binding - plugin. 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 the 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 different 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. - -## Advanced build customization - -### Including additional cmake files - -#### Machine and system custom cmake files - -Advanced tuning is possible using additional cmake files that are included -automatically from some specifics locations. They are included in that order: - -- Project CMake files normally 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 overwritten 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 platform. 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 additional 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. - -## Autobuild script usage - -### 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 _conf.d/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. - -You can specify variables that modify the behavior of compilation using -the following variables: - -- **CONFIGURE_ARGS** : Variable used at **configure** time. -- **BUILD_ARGS** : Variable used at **build** time. -- **DEST** : Directory where to output ***wgt*** file. - -Variable as to be in CMake format. (ie: BUILD_ARGS="-DC_FLAGS='-g -O2'") - -Usage example: - -```bash -./conf.d/autobuild/wgt/autobuild package DEST=/tmp -``` diff --git a/docs/README.md b/docs/README.md deleted file mode 100644 index 39f9209..0000000 --- a/docs/README.md +++ /dev/null @@ -1,22 +0,0 @@ -# Introduction - -This document explain how to use the CMake templates files and associated -files to ease developement of AGL application. - -<br> -<br> -<br> -<br> -<br> - -| *Meta* | *Data* | -| -- | -- | -| **Title** | {{ config.title }} | -| **Author** | {{ config.author }} | -| **Description** | {{ config.description }} | -| **Keywords** | {{ config.keywords }} | -| **Language** | English | -| **Published** | Published {{ config.published }} as an electronic book | -| **Updated** | {{ gitbook.time }} | -| **Collection** | Open-source | -| **Website** | [{{ config.website }}]({{ config.website }}) | diff --git a/docs/dev_guide/0_Abstract.md b/docs/dev_guide/0_Abstract.md index a04cc87..88e841b 100644 --- a/docs/dev_guide/0_Abstract.md +++ b/docs/dev_guide/0_Abstract.md @@ -1,21 +1,38 @@ -# Developper Guide: use AGL CMake Templates +# Abstract -## Abstract +Files used to build an application, or a binding project with the AGL +Application Framework. -Files used to build an application, or binding, project with the -AGL Application Framework. +To build your AGL project using these templates, you have to installed 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 build your AGL project using these templates, you have to install -them within your project and adjust compilation option in `config.cmake`. -For technical reasons, you also have to specify **cmake** target in -sub CMakeLists.txt installed. Make a globbing search to find source files -isn't recommended now to handle project build especially in a multiuser -project because CMake will not be aware of new or removed source files. +Then install it, depending of 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 +``` + +---- You'll find usage samples here: - [helloworld-service](https://github.com/iotbzh/helloworld-service) -- [low-level-can-service](https://gerrit.automotivelinux.org/gerrit/apps/low-level-can-service) -- [high-level-viwi-service](https://github.com/iotbzh/high-level-viwi-service) -- [audio-binding](https://github.com/iotbzh/audio-binding) -- [unicens2-binding](https://github.com/iotbzh/unicens2-binding) +- [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 index e910178..992f4ca 100644 --- a/docs/dev_guide/1_Quickstart.md +++ b/docs/dev_guide/1_Quickstart.md @@ -2,33 +2,37 @@ ## Initialization -To use these templates files on your project just install the reference files using -**git submodule** then use `config.cmake` file to configure your project specificities : +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 -git submodule add https://gerrit.automotivelinux.org/gerrit/p/apps/app-templates.git conf.d/app-templates -mkdir conf.d/cmake -cp conf.d/app-templates/samples.d/config.cmake.sample conf.d/cmake/config.cmake +mkdir -p conf.d/cmake +# RPM based distribution +cp /usr/share/cmake/Modules/CMakeAfbTemplates/samples.d/config.cmake.sample conf.d/cmake/config.cmake +# DEB based distribution with X.Y as cmake version +cp /usr/share/cmake-X.Y/Modules/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 **app-templates** submodule that you can copy and -use: +An example is available in the **cmake module** that you can copy and use: ```bash -cp conf.d/app-templates/samples.d/CMakeLists.txt.sample CMakeLists.txt +# RPM based distribution +cp /usr/share/cmake/Modules/CMakeAfbTemplates/samples.d/CMakeLists.txt.sample CMakeLists.txt +# DEB based distribution with X.Y as cmake version +cp /usr/share/cmake-X.Y/Modules/CMakeAfbTemplates/samples.d/CMakeLists.txt.sample CMakeLists.txt ``` ## Create your CMake targets -For each target part of your project, you need to use ***PROJECT_TARGET_ADD*** -to include this target to your project. +For each target that is part of your project, you need to use +***PROJECT_TARGET_ADD*** to include this target to your project. -Using it, make available the cmake variable ***TARGET_NAME*** until the next -***PROJECT_TARGET_ADD*** is invoked with a new target name. +> **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: @@ -45,8 +49,8 @@ INSTALL(TARGETS ${TARGET_NAME}.... ## Targets PROPERTIES -You should set properties on your targets that will be used to package your -apps in a widget file that could be installed on an AGL system. +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**: @@ -92,6 +96,6 @@ SET_TARGET_PROPERTIES(${TARGET_NAME} OUTPUT_NAME "file_output_name") ``` -> **NOTE**: You doesn't need to specify an **INSTALL** command for these +> **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/2_project_architecture.md b/docs/dev_guide/2_project_architecture.md index 6365539..9e5503f 100644 --- a/docs/dev_guide/2_project_architecture.md +++ b/docs/dev_guide/2_project_architecture.md @@ -5,57 +5,32 @@ A typical project architecture would be : ```tree <project-root-path> │ +├── autobuild/ +│ ├── agl +│ │ └── autobuild +│ ├── linux +│ │ └── autobuild +│ └── windows +│ └── autobuild ├── conf.d/ -│ ├── autobuild/ -│ │ ├── agl -│ │ │ └── autobuild -│ │ ├── linux -│ │ │ └── autobuild -│ │ └── windows -│ │ └── autobuild -│ ├── app-templates/ -│ │ ├── README.md -│ │ ├── cmake/ -│ │ │ ├── export.map -│ │ │ └── macros.cmake -│ │ ├── samples.d/ -│ │ │ ├── CMakeLists.txt.sample -│ │ │ ├── config.cmake.sample -│ │ │ ├── config.xml.in.sample -│ │ │ └── xds-config.env.sample -│ │ ├── template.d/ -│ │ │ ├── autobuild/ -│ │ │ │ ├── agl -│ │ │ │ │ └── autobuild.in -│ │ │ │ ├── linux -│ │ │ │ │ └── autobuild.in -│ │ │ │ └── windows -│ │ │ │ └── autobuild.in -│ │ │ ├── config.xml.in -│ │ │ ├── deb-config.dsc.in -│ │ │ ├── deb-config.install.in -│ │ │ ├── debian.changelog.in -│ │ │ ├── debian.compat.in -│ │ │ ├── debian.rules.in -│ │ │ ├── gdb-on-target.ini.in -│ │ │ ├── install-wgt-on-target.sh.in -│ │ │ ├── start-on-target.sh.in -│ │ │ ├── rpm-config.spec.in -│ │ │ └── xds-project-target.conf.in -│ │ └── wgt/ -│ │ ├── icon-default.png -│ │ ├── icon-html5.png -│ │ ├── icon-native.png -│ │ ├── icon-qml.png -│ │ └── icon-service.png │ ├── packaging/ -│ │ ├── config.spec -│ │ └── config.deb +│ │ ├── 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 -│ └── config.xml.in -├── <libs> +│ ├── icon.png +│ └── config.xml.in ├── <target> │ └── <files> ├── <target> @@ -67,42 +42,9 @@ A typical project architecture would be : | # | Parent | Description | | - | -------| ----------- | | \<root-path\> | - | Path to your project. Hold master CMakeLists.txt and general files of your projects. | +| 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, package an AGL app project | -| app-templates | conf.d | Git submodule to app-templates AGL repository which provides CMake helpers macros library, and build scripts. config.cmake is a copy of config.cmake.sample configured for the projects. SHOULD NOT BE MODIFIED MANUALLY !| -| autobuild | conf.d | Scripts generated from app-templates to build packages the same way for differents platforms.| | cmake | conf.d | Contains at least config.cmake file modified from the sample provided in app-templates submodule. | -| wgt | conf.d | Contains at least config.xml.in template file modified from the sample provided in app-templates submodule for the needs of project (See config.xml.in.sample file for more details). | | packaging | conf.d | Contains output files used to build packages. | -| \<libs\> | \<root-path\> | External dependencies libraries. This isn't to be used to include header file but build and link statically specifics libraries. | Library sources files. Can be a decompressed library archive file or project fork. | +| 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). | | \<target\> | \<root-path\> | A target to build, typically library, executable, etc. | - -## Manage app-templates submodule - -### Update - -You may have some news bug fixes or features available from app-templates -repository that you want. To update your submodule proceed like the following: - -```bash -git submodule update --remote -git commit -s conf.d/app-templates -``` - -This will update the submodule to the HEAD of master branch repository. Save -the modification by commiting it in your master git project. - -### Checkout submodule to a git tag - -You could just want to update at a specified repository tag or branch or commit -, here are the method to do so: - -```bash -cd conf.d/app-templates -# Choose one of the following depending what you want -git checkout <tag_name> -git checkout --detach <branch_name> -git checkout --detach <commit_id> -# Then commit -cd ../.. -git commit -s conf.d/app-templates -``` diff --git a/docs/dev_guide/5_autobuild.md b/docs/dev_guide/5_autobuild.md index fe1c63d..f6788fc 100644 --- a/docs/dev_guide/5_autobuild.md +++ b/docs/dev_guide/5_autobuild.md @@ -1,4 +1,87 @@ -# Autobuild script usage +# 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 @@ -13,7 +96,7 @@ cd build cmake .. && make autobuild ``` -You should see _conf.d/autobuild/agl/autobuild_ file now. +You should see _autobuild/agl/autobuild_ file now. ## Available targets @@ -24,18 +107,24 @@ Here are the available targets available from _autobuild_ scripts: - **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. +- **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 -./conf.d/autobuild/wgt/autobuild package DEST=/tmp +./autobuild/wgt/autobuild package DEST=/tmp ``` |