CMake Section: Complete re-write.

Completely re-wrote the section.  New file names that do
not use the numbers also.

Change-Id: I443feb41cf83d760a57179473439e89e7b71f9c5
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>

14 files changed, 609 insertions, 748 deletions

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