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
+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:
- **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 you can choose the name, without the
- extension, by setting the *CACHE* cmake variable *OPENAPI_DEF* (***CAUTION***:
- setting a CACHE variable is needed, or set a normal variable with the
- *PARENT_SCOPE* option to make it visible for the parent scope where the target
- is defined) JSON file will be used to generate header file using `afb-genskel`
- tool.
-- **PLUGIN**: Shared library meant to be used as a binding plugin. Binding
- would load it as a plugin to extend its functionnalities. It should be named
+ *${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
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 "BINDING"
- OUTPUT_NAME "file_output_name"
-)
+ LABELS "BINDINGV3"
+ OUTPUT_NAME "file_output_name")
```
> **NOTE**: You doesn't need to specify an **INSTALL** command for these
| \<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 differents platforms.|
+| 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. |
### Build a widget
-#### config.xml.in file
+## 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 recommanded that you use the sample one which is more complete. You can
+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.
> _config.xml.in.sample_ which had all new Application Framework
> features explained and examples.
-#### Using cmake template macros
+## 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
- **BINDINGV2**: Shared library that be loaded by the AGL Application Framework
This has to be accompagnied with a JSON file named like the
*${OUTPUT_NAME}-apidef* of the target that describe the API with OpenAPI
- syntax (e.g: *mybinding-apidef*). Or you can choose the name, without the
- extension, by setting the *CACHE* cmake variable *OPENAPI_DEF* (***CAUTION***:
- setting a CACHE variable is needed, or set a normal variable with the
- *PARENT_SCOPE* option to make it visible for the parent scope where the target
- is defined) JSON file will be used to generate header file using `afb-genskel`
- tool.
-- **PLUGIN**: Shared library meant to be used as a binding plugin. Binding
+ 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.
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**.
Finally, you can link any other lib or executable target with this imported
library like any other target.
-#### Macro reference
+## Macro reference
-##### PROJECT_TARGET_ADD
+### PROJECT_TARGET_ADD
Typical usage would be to add the target to your project using macro
`PROJECT_TARGET_ADD` with the name of your target as parameter.
> set with the specificied name. This variable will change at the next call
> to this macros.
-##### project_subdirs_add
+### project_subdirs_add
This macro will search in all subfolder any `CMakeLists.txt` file. If found then
it will be added to your project. This could be use in an hybrid application by
project_subdirs_add("[0-9]-*")
```
+### 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 additionnals cmake files
+### Including additional cmake files
#### Machine and system custom cmake files
-Advanced tuning is possible using addionnals cmake files that are included
+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 normaly located in _<project-root-path>/conf.d/app-templates/cmake/cmake.d_
+- 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_
`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
+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:
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
+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.
### Include customs templated scripts
-As well as for additionnals cmake files you can include your own templated
+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: