Create a test widget
[apps/app-templates.git] / docs / dev_guide / 3_advanced_usage.md
index ae8d1ec..114230f 100644 (file)
@@ -33,12 +33,17 @@ Choose between:
 - **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.
+ syntax (e.g: *mybinding-apidef*).
+ Or Alternatively, you can choose the name, without the extension, using macro
+ **set_openapi_filename**. If you use C++, you have to set **PROJECT_LANGUAGES**
+ with *CXX*.
+- **BINDINGV3**: Shared library that be loaded by the AGL Application Framework
+ This has to be accompagnied with a JSON file named like the
+ *${OUTPUT_NAME}-apidef* of the target that describe the API with OpenAPI
+ syntax (e.g: *mybinding-apidef*).
+ Or Alternatively, you can choose the name, without the extension, using macro
+ **set_openapi_filename**. If you use C++, you have to set **PROJECT_LANGUAGES**
+ with *CXX*.
 - **PLUGIN**: Shared library meant to be used as a binding plugin. Binding
  would load it as a plugin to extend its functionnalities. It should be named
  with a special extension that you choose with SUFFIX cmake target property or
@@ -51,6 +56,32 @@ Choose between:
  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.
+
+Two optionnals **LABELS** are available to define which resources are your tests
+materials:
+
+- **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.
+
+Here is a mapping between LABELS and directories where files will be puted 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-CONFIG** : \<TESTwgtrootdir\>/etc
+- **TEST-DATA** : \<TESTwgtrootdir\>/var
 
 > **TIP** you should use the prefix _afb-_ with your **BINDING* targets which
 > stand for **Application Framework Binding**.
@@ -68,8 +99,13 @@ SET_TARGET_PROPERTIES(${TARGET_NAME} PROPERTIES
 > 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.
@@ -114,9 +150,13 @@ add_dependencies(${TARGET_NAME} ${MXML})
 
 Here we define an external project that drive the build of the library then we
 define new CMake target of type **IMPORTED**. Meaning that this target hasn't
-be built using CMake but is available at the location defined in the target
+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
@@ -125,6 +165,31 @@ 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
@@ -163,3 +228,38 @@ 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.