Merge pull request #17 from dl9pf/for-master

Add agl-documentation subfolder into agl repo

15 files changed, 693 insertions, 0 deletions

diff --git a/agl-documentation/sdk-devkit/docs/part-2/2_0_Abstract.md b/agl-documentation/sdk-devkit/docs/part-2/2_0_Abstract.md
new file mode 100644
index 0000000..e7eae95
--- /dev/null
+++ b/agl-documentation/sdk-devkit/docs/part-2/2_0_Abstract.md
@@ -0,0 +1,25 @@
+# Part 2 - Build your 1st application
+
+## Abstract
+
+In the first part of this document, entitled "** Build AGL image from scratch**",
+we rebuilt a complete bootable AGL image from source code. We also generated
+and installed related SDK files in our development container.
+This document describes the next step: using the SDK to build applications and
+deploy them on a target board running an AGL image.
+
+AGL DevKit as a whole contains:
+
+- "**AGL Devkit - Image and SDK for porter**" guide for preparing a
+  Docker container with AGL SDK, ready to build AGL applications
+- Application templates and demos, allowing developers to start developing
+  various types of applications:
+  - Services
+  - Native applications
+  - HTML5 applications
+  - ...
+- This guide, focused on how to use these applications templates
+
+*This document focuses on: initializing the SDK environment, building the
+development templates, modifying them, and installing them on the
+target.*
diff --git a/agl-documentation/sdk-devkit/docs/part-2/2_1-Init-sdk-env.md b/agl-documentation/sdk-devkit/docs/part-2/2_1-Init-sdk-env.md
new file mode 100644
index 0000000..c6cf67a
--- /dev/null
+++ b/agl-documentation/sdk-devkit/docs/part-2/2_1-Init-sdk-env.md
@@ -0,0 +1,79 @@
+# Initializing SDK environment and templates
+
+## Initializing the SDK environment
+
+*(This document assumes that you are logged inside the **bsp-devkit** Docker
+container, used to produce Rcar Gen3 BSP image and AGL SDK in the
+previous **"SDK quick setup"** document)*
+
+To be able to use the toolchain and utilities offered by AGL SDK, it is
+necessary to source the proper setup script. This script is in the SDK
+root folder and is named `/xdt/sdk/environment-setup-*` (full name
+depends on the target machine)
+
+For Rcar Gen3 boards, we source the required SDK environment variables like
+this:
+
+```bash
+source /xdt/sdk/environment-setup-aarch64-agl-linux
+```
+
+To verify that it succeeded, we should obtain a non-empty result for
+this command:
+
+```bash
+echo $CONFIG_SITE | grep sdk /xdt/sdk/site-config-aarch64-agl-linux
+```
+
+## Application categories
+
+We provide multiple development templates for the AGL SDK:
+
+- Service
+
+  A Service is a headless background process, allowing Bindings to expose
+  various APIs accessible through the transports handled by the application
+  framework, which are currently:
+  - [HTTP REST (HTTP GET, POST...)](https://en.wikipedia.org/wiki/Representational_state_transfer)
+  - [WebSocket](https://en.wikipedia.org/wiki/WebSocket)
+  - [D-Bus](https://www.freedesktop.org/wiki/Software/dbus/)
+
+- Native application
+
+  A Native application is a compiled application, generally written in C/C++,
+  accessing one or more services, either by its own means or using a helper
+  library with HTTP REST/WebSocket capabilities.
+
+  *(our template is written in C and uses the "libafbwsc" helper library
+  available in the app-framework-binder source tree on AGL Gerrit)*
+
+- HTML5 application
+
+  An HTML5 application is a web application, generally written with a framework
+  (AngularJS, Zurb Foundation...), accessing services with its built-in HTTP
+  REST/WebSocket capabilities.
+
+- Legacy application
+
+  A legacy application contains a native application not made for AGL
+  Application Framework but launched by it. For such application, only
+  security setup is made.
+
+## Getting helloworld templates
+
+Application Framework _helloworld_ example live in a dedicated Git
+Repository, currently hosted on GitHub at the following address:
+
+[https://github.com/iotbzh/helloworld-service](https://github.com/iotbzh/helloworld-service)
+
+To get the templates in our development container, let us simply clone
+the source repository:
+
+```bash
+$ cd ~
+$ git clone --recursive https://github.com/iotbzh/helloworld-service
+Cloning into 'helloworld-service'...
+[...snip...]
+Resolving deltas: 100% (125/125), done.
+Checking connectivity... done.
+```
diff --git a/agl-documentation/sdk-devkit/docs/part-2/2_2-Trying-out-template.md b/agl-documentation/sdk-devkit/docs/part-2/2_2-Trying-out-template.md
new file mode 100644
index 0000000..e477755
--- /dev/null
+++ b/agl-documentation/sdk-devkit/docs/part-2/2_2-Trying-out-template.md
@@ -0,0 +1,134 @@
+# Trying out the templates
+
+In this section, we describe how to build the various templates, how to
+package them and finally how to deploy and run them on the target board.
+
+Every template is stored in a single directory and is independent of the
+rest of the tree: each template can be used as a foundation for a fresh
+new application.
+
+For deployment, we assume that the target board is booted with an AGL
+image and available on the network. Let us use the `BOARDIP` variable
+for the board IP address (replace by appropriate address or hostname)
+and test the SSH connection:
+
+```bash
+$ export BOARDIP=1.2.3.4
+$ ssh root@$BOARDIP cat /etc/os-release
+ID="poky-agl"
+NAME="Automotive Grade Linux"
+VERSION="1.0+snapshot-20160717 (master)"
+VERSION_ID="1.0+snapshot-20160717"
+PRETTY_NAME="Automotive Grade Linux 1.0+snapshot-20160717 (master)"
+```
+
+## Building
+
+All operations are executed inside the Docker "Devkit" container. For
+convenience, a build script named `autobuild` can build template and
+package at once.
+
+Compile the service:
+
+```bash
+$ cd ~/helloworld-service/
+$ ./conf.d/autobuild/agl/autobuild package
+-- The C compiler identification is GNU 6.3.1
+-- The CXX compiler identification is GNU 6.3.1
+[snip]
+[100%] Generating helloworld-service.wgt
+NOTICE: -- PACKING widget helloworld-service.wgt from directory /home/claneys/Workspace/Sources/IOTbzh/helloworld-service/build/package
+++ Install widget file using in the target : afm-util install helloworld-service.wgt
+```
+
+This produced a `helloworld-service.wgt` package. Let us copy it to the
+target:
+
+```bash
+$ scp helloworld-service.wgt root@$BOARDIP:~/
+helloworld-service.wgt                           100%   24KB   24.3KB/s   00:00
+```
+
+## Installing on the target
+
+And then, in a separate window, log in to the target board:
+
+```bash
+ssh root@$BOARDIP
+```
+
+and install our packages:
+
+```bash
+$ afm-util install helloworld-service.wgt
+{ "added": "helloworld-service@1.0" }
+```
+
+We can verify that they were correctly installed by listing all
+available applications:
+
+```bash
+$ afm-util list
+[ { "description": "The name says it all!", "name": "helloworld-service", "shortname": "", "id": "helloworld-service@1.0", "version": "1.0", "author": "Stephane Desneux <sdx@iot.bzh>", "author-email": "", "width": "", "height": "" } ]
+```
+
+## Running the template
+
+Even if the template is mostly skeleton application, we can still
+start them and see them in action.
+
+Once installed Application Framework created appropriate systemD unit file
+to get able to manage the application. You can directly connect to the unix
+socket to get connected to the application template, it will be launched
+automatically if not already started.
+
+when systemD receives a connection to an existing socket that it handles, it
+launch the associated application using its service unit. Service unit is
+generated by wgtpkg-unit at installation, its content depends of the
+`config.xml` configuration file located in its specific directory
+(`/var/local/lib/afm/applications/<appname>/<version>/config.xml`).
+
+Generation is controlled by the global `/etc/afm/afm-unit.conf` config
+file.
+
+This file defines how various applications types are handled by the
+system and application framework.
+
+### Run and connect to the service
+
+Let us first run the Service:
+
+```bash
+$ afm-util run helloworld-service@1.0
+1
+```
+
+Then confirm it is running:
+
+```bash
+$ afm-util ps
+[ { "runid": 20091, "pids": [ 20091 ], "state": "running", "id": "helloworld-service@1.0" } ]
+$ ps -ef | grep afb
+ps -ef|grep afb
+root      5764  3876  0 15:34 ?        00:00:00 /usr/bin/afb-daemon --rootdir=/var/local/lib/afm/applications/helloworld-service/1.0 --workdir=/home/root/app-data/helloworld-service --roothttp=htdocs --binding=/var/local/lib/afm/applications/helloworld-service/1.0/lib/afb-helloworld.so --ws-server=sd:helloworld --no-httpd
+```
+
+We can see that an afb-daemon (Binder) process for this Service started
+and get a websocket server up, meaning that an unix socket is available
+from directory `/var/run/user/<uid>/apis/ws` named as the api name.
+We also see that the shared library as been loaded as binding using `binding`
+flag.
+
+A Service has no user interface, but we can still try the binding API.
+Looking at the Service source code, we see that the Service implements
+an API named '**helloworld**' providing a `ping` verb. Let us try to launch
+a websocket client connected to that service invoking the `ping` verb.
+
+First as we don't know security token used to launch the service, we still can
+connect to through the unix socket and use the websocket client demo:
+
+```bash
+$ afb-daemon --ws-client=/var/run/user/0/apis/ws/helloworld --port=12345 --token='' --roothttp=.
+$ afb-client-demo ws://localhost:12345/api?token= helloworld ping
+ON-REPLY 1:helloworld/ping: {"response":"Make the World great again!","jtype":"afb-reply","request":{"status":"success","info":"Ping Binder Daemon tag=pingSample count=2 query=\"null\"","uuid":"2edcfee9-943b-40d7-a0c6-08a31141f045"}}
+```
diff --git a/agl-documentation/sdk-devkit/docs/part-2/2_3-Dev-with-container.md b/agl-documentation/sdk-devkit/docs/part-2/2_3-Dev-with-container.md
new file mode 100644
index 0000000..eb83c8f
--- /dev/null
+++ b/agl-documentation/sdk-devkit/docs/part-2/2_3-Dev-with-container.md
@@ -0,0 +1,93 @@
+# Developing smoothly with the container
+
+The previous chapter pretty much illustrated the virtues of the Docker
+container by letting you compile AGL applications, independently of your
+host machine.
+
+There is one catch, though, in that the container does not feature a
+full graphical environment similar to those which developers are used to.
+But this can be circumvented.
+
+For this reason, and before we start developing our own apps, we will
+explain how to get the best from the provided development container.
+
+## Remote display
+
+<a id="anchor-remote-display"></a>
+
+Apart from popular console tools such as `vi, git, patch, diff...` our
+container also features graphical applications: `gvim` text editor,
+`gitg` frontend for Git, `gvimdiff` ...
+
+You can display them on your host machine by taking advantage of X11
+protocol remoting capabilities. The procedure differs depending on your
+host machine.
+
+### Linux
+
+You have to connect to your container by specifying the `-X` option:
+
+```bash
+ssh -X -p 2222 devel@localhost
+```
+
+and then any graphical window, such as `gvim`'s, should display on your
+host screen.
+
+### Mac OS X
+
+You have to connect to your container by specifying the `-X` option:
+
+```bash
+ssh -X -p 2222 devel@localhost
+```
+
+together with a running X11 server such as XQuartz.
+
+XQuartz was included in old versions such as 10.5 Leopard; you can find it
+under `Applications -> Utilities -> X11`.
+For more recent versions starting from 10.6.3, you may have to download and
+install it from the following URL:
+[https://dl.bintray.com/xquartz/downloads/XQuartz-2.7.9.dmg](https://dl.bintray.com/xquartz/downloads/XQuartz-2.7.9.dmg)
+(it will end up in the same location).
+
+![mac x11](pictures/mac_x11_logo.png)
+
+And then after having activated the "X11" icon, any graphical window, such as
+`gvim`'s, should display on your host screen.
+
+### Windows
+
+You have to use PuTTY, as suggested in the previous "**Image and SDK
+for porter**" document, together with a running X server such as Xming
+([https://sourceforge.net/projects/xming/files/latest/download](https://sourceforge.net/projects/xming/files/latest/download)).
+
+Before connecting with PuTTY as usual, you have to go
+to `Connection -> SSH -> X11` and check the `Enable X11 forwarding` checkbox.
+
+![putty config](pictures/putty_config.png)
+
+Then, if Xming is installed and running, as displayed
+in the bottom right of the screen:
+
+![xming server](pictures/xming_server.png)
+
+any graphical window, such as `gvim`'s, should display on your screen.
+
+## Installing new applications (IDE...)
+
+The container has access to the whole Linux Debian distribution library,
+and can benefit of only package available for it.
+
+For instance, to install the popular Eclipse IDE, please type:
+
+```bash
+sudo apt-get install eclipse
+```
+
+And then, using the method described in section ["Remote display"](anchor-remote-display),
+you can run it on your host screen by just typing:
+
+```bash
+eclipse
+```
diff --git a/agl-documentation/sdk-devkit/docs/part-2/2_4-Use-app-templates.md b/agl-documentation/sdk-devkit/docs/part-2/2_4-Use-app-templates.md
new file mode 100644
index 0000000..363333c
--- /dev/null
+++ b/agl-documentation/sdk-devkit/docs/part-2/2_4-Use-app-templates.md
@@ -0,0 +1,362 @@
+# AGL CMake templates
+
+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 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.
+
+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/apps/app-templatesconf.d/app-templates conf.d/app-templates
+mkdir conf.d/cmake
+cp conf.d/app-templates/cmake/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/cmake/CMakeLists.txt 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
+
+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.
+
+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
+- **HTDOCS**: Root directory of a web app
+- **DATA**: Resources used by your application
+- **EXECUTABLE**: Entry point of your application executed by the AGL
+ Application Framework
+
+```cmake
+SET_TARGET_PROPERTIES(${TARGET_NAME}
+    PREFIX "afb-"
+    LABELS "BINDING"
+    OUTPUT_NAME "file_output_name")
+```
+
+> **TIP**: You should use the prefix _afb-_ with your **BINDING* targets which
+> stand for **Application Framework Binding**.
+
+## 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
+│   │   ├── autobuild/
+│   │   │   ├── agl
+│   │   │   │   └── autobuild.in
+│   │   │   ├── linux
+│   │   │   │   └── autobuild.in
+│   │   │   └── windows
+│   │   │       └── autobuild.in
+│   │   ├── cmake/
+│   │   │   ├── config.cmake.sample
+│   │   │   ├── export.map
+│   │   │   └── macros.cmake
+│   │   ├── deb/
+│   │   │   └── config.deb.in
+│   │   ├── rpm/
+│   │   │   └── config.spec.in
+│   │   └── wgt/
+│   │       ├── config.xml.in
+│   │       ├── config.xml.in.sample
+│   │       ├── 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 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. |
+| \<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 recommanded 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
+- **HTDOCS**: Root directory of a web app
+- **DATA**: Resources used by your application
+- **EXECUTABLE**: Entry point of your application executed by the AGL
+ Application Framework
+
+Example:
+
+```cmake
+SET_TARGET_PROPERTIES(${TARGET_NAME} PROPERTIES
+        LABELS "HTDOCS"
+        OUTPUT_NAME dist.prod
+    )
+```
+
+If your target output is not named as the ***TARGET_NAME***, you need to specify
+***OUTPUT_NAME*** property that will be used by the ***populate_widget*** macro.
+
+Use the ***populate_widget*** macro as latest statement of your target
+definition. Then at the end of your project definition you should use the macro
+***build_widget*** that make an archive from the populated widget tree using the
+`wgtpkg-pack` Application Framework tools.
+
+## 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]-*")
+```
+
+## Advanced customization
+
+### Including additionnals 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-***.cmake`,
+where `XX` are numbers, `***` file name (ie. `99-my_customs.cmake`).
+
+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')
+```
+
+### 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.
+
+## 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/agl-documentation/sdk-devkit/docs/part-2/pictures/cpu_hybrid_qml.png b/agl-documentation/sdk-devkit/docs/part-2/pictures/cpu_hybrid_qml.png
new file mode 100644
index 0000000..c3b35f5
--- /dev/null
+++ b/agl-documentation/sdk-devkit/docs/part-2/pictures/cpu_hybrid_qml.png
diff --git a/agl-documentation/sdk-devkit/docs/part-2/pictures/html5_app.png b/agl-documentation/sdk-devkit/docs/part-2/pictures/html5_app.png
new file mode 100644
index 0000000..62b8d5e
--- /dev/null
+++ b/agl-documentation/sdk-devkit/docs/part-2/pictures/html5_app.png
diff --git a/agl-documentation/sdk-devkit/docs/part-2/pictures/hybrid_html5_app.png b/agl-documentation/sdk-devkit/docs/part-2/pictures/hybrid_html5_app.png
new file mode 100644
index 0000000..bfb09b3
--- /dev/null
+++ b/agl-documentation/sdk-devkit/docs/part-2/pictures/hybrid_html5_app.png
diff --git a/agl-documentation/sdk-devkit/docs/part-2/pictures/hybrid_html5_app_on_target.png b/agl-documentation/sdk-devkit/docs/part-2/pictures/hybrid_html5_app_on_target.png
new file mode 100644
index 0000000..f4639dd
--- /dev/null
+++ b/agl-documentation/sdk-devkit/docs/part-2/pictures/hybrid_html5_app_on_target.png
diff --git a/agl-documentation/sdk-devkit/docs/part-2/pictures/hybrid_qml_app.png b/agl-documentation/sdk-devkit/docs/part-2/pictures/hybrid_qml_app.png
new file mode 100644
index 0000000..d27dfb2
--- /dev/null
+++ b/agl-documentation/sdk-devkit/docs/part-2/pictures/hybrid_qml_app.png
diff --git a/agl-documentation/sdk-devkit/docs/part-2/pictures/mac_x11_logo.png b/agl-documentation/sdk-devkit/docs/part-2/pictures/mac_x11_logo.png
new file mode 100644
index 0000000..6dace7d
--- /dev/null
+++ b/agl-documentation/sdk-devkit/docs/part-2/pictures/mac_x11_logo.png
diff --git a/agl-documentation/sdk-devkit/docs/part-2/pictures/putty_config.png b/agl-documentation/sdk-devkit/docs/part-2/pictures/putty_config.png
new file mode 100644
index 0000000..56f8d88
--- /dev/null
+++ b/agl-documentation/sdk-devkit/docs/part-2/pictures/putty_config.png
diff --git a/agl-documentation/sdk-devkit/docs/part-2/pictures/qml_app.png b/agl-documentation/sdk-devkit/docs/part-2/pictures/qml_app.png
new file mode 100644
index 0000000..30f574d
--- /dev/null
+++ b/agl-documentation/sdk-devkit/docs/part-2/pictures/qml_app.png
diff --git a/agl-documentation/sdk-devkit/docs/part-2/pictures/web-runtime_app.png b/agl-documentation/sdk-devkit/docs/part-2/pictures/web-runtime_app.png
new file mode 100644
index 0000000..c15e98d
--- /dev/null
+++ b/agl-documentation/sdk-devkit/docs/part-2/pictures/web-runtime_app.png
diff --git a/agl-documentation/sdk-devkit/docs/part-2/pictures/xming_server.png b/agl-documentation/sdk-devkit/docs/part-2/pictures/xming_server.png
new file mode 100644
index 0000000..566cec7
--- /dev/null
+++ b/agl-documentation/sdk-devkit/docs/part-2/pictures/xming_server.png