Adding section

Not sure about it being a standalone, but okay for now

Author: Irit Arkin

docs.json

@@ -28,7 +28,7 @@
     {
         "title": "Create applications",
         "description": "Develop your own application for mbed OS",
-        "slug": "mbed-os-create_apps",
+        "slug": "mbed-os-create",
         "type": "markdown",
         "sources": [
             {"type": "markdown", "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/creating_apps/mbed_interface.md"},
@@ -57,6 +57,27 @@
             {"type": "markdown", "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/creating_apps/release_profile.md"}
         ]
     },
+    {
+        "title": "Compile applications",
+        "description": "Targes, flags and exporters for application compilations",
+        "slug": "mbed-os-compile",
+        "type": "markdown",
+        "sources": [
+            {"type": "markdown", "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/compile/options.md"},
+            {"type": "markdown", "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/compile/studio_compile.md"},
+            {"type": "markdown", "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/compile/online_comp.md"},
+            {"type": "markdown", "url": "https://github.com/iriark01/mbed-cli/blob/master/README.md"},
+            {"type": "markdown", "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/compile/third_party.md"},
+            {"type": "markdown", "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/compile/build_profiles.md"},
+            {"type": "markdown", "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/compile/toolchain_profiles.md"},
+            {"type": "markdown", "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/compile/mbedignore.md"},
+            {"type": "markdown", "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/compile/mbed_targets.md"},
+            {"type": "markdown", "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/compile/config_system.md"},
+            {"type": "markdown", "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/compile/mutli_comp.md"},
+            {"type": "markdown", "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/compile/exporters.md"},
+            {"type": "markdown", "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/compile/exporter_instruct.md"}
+        ]
+    },
     {
         "title": "mbed OS API refrences",
         "description": "References to the mbed OS APIs",

docs/dev_tools/build_profiles.md renamed to docs/compile/build_profiles.md

@@ -1,17 +1,17 @@
-# Build Profiles
+## Build Profiles
 mbed OS 5 supports three primary build profiles: *develop*, *debug* and *release*. The Online Compiler uses the *develop* profile. When building from mbed CLI, you can select a profile by adding the ```--profile <profile>``` flag. You can specify custom user-defined profiles by giving the path to the profile.
 
-## Develop profile
+### Develop profile
 * Small and fast code.
 * Full error information. For example, asserts have file name and line number.
 * Hard to follow code flow when using a debugger.
 
-## Debug profile
+### Debug profile
 * Largest and slowest profile.
 * Full error information. For example, asserts have file name and line number.
 * Easy to step through code with a debugger.
 
-## Release profile
+### Release profile
 * Smallest profile and still fast.
 * Minimal error information.
 * Chip is put to sleep when going idle:

docs/advanced/config_system.md renamed to docs/compile/config_system.md

@@ -1,4 +1,4 @@
-# The mbed configuration system
+## The mbed configuration system
 
 The mbed configuration system customizes the compile time configuration of various mbed components (targets, libraries and applications). Each component can define a number of *configuration parameters*. The values of these configuration parameters can then be *overridden* in various ways. Configuration is defined using [JSON](http://www.json.org/). Some examples of configuration parameters:
 
@@ -9,7 +9,7 @@ The mbed configuration system customizes the compile time configuration of vario
 
 The configuration system gathers and interprets all the configurations defined in the source tree. The output of the configuration system is a list of macros that are automatically defined when compiling the code.
 
-# Defining configuration parameters
+### Defining configuration parameters
 
 The configuration system understands configuration data defined in targets, libraries and applications. Although there are some slight differences in the way the configuration system works in these cases, the configuration parameters are always defined in a JSON object called "config".
 
@@ -49,7 +49,7 @@ The configuration system automatically appends an *implicit prefix* to the name
 - **app.** if the parameter is defined in the application.
 - The name of the library followed by a dot (.) if the parameter is defined in a library.
 
-# Configuration data in libraries
+### Configuration data in libraries
 
 Each mbed library can have an optional `mbed_lib.json` file located in the root folder of the library that defines its configuration. For a library called `mylib`, the configuration file can look like this:
 
@@ -103,7 +103,7 @@ As explained [here](#defining-configuration-parameters), the parameters have an
 
 If the source tree has code for more than one library, each library needs its own `mbed_lib.json` file in its root folder.
 
-# Configuration data in targets
+### Configuration data in targets
 
 Like libraries, targets can define their own configuration data. Additionally, targets can override the configuration of the target(s) they inherit from (for more details about how do define a target and target inheritance, check [this link](mbed_targets.md)). Target configuration data is defined in `targets.json` using `config`, as described [here](#defining-configuration-parameters). An example for a hypothetical `Base` target is given below:
 
@@ -152,7 +152,7 @@ Targets can inherit from other targets, and their configuration data is also inh
 
 It is an error for a derived target to redefine a configuration parameter already defined by its parent(s) in its `config` section. It is also an error for a derived target to override a configuration parameter that was not defined by its parent(s) in its `overrides` section.
 
-# Configuration data in applications
+### Configuration data in applications
 
 Like target and library configuration, application configuration is optional; if it exists, it must be defined in an `mbed_app.json` file. Unlike library configuration, there can be a single `mbed_app.json` file in the source tree.
 
@@ -203,7 +203,7 @@ Other than this, `target_overrides` works exactly like it does for libraries. Ke
 
 It is an error for the application configuration to override configuration parameters that were not defined.
 
-## Overriding target attributes
+#### Overriding target attributes
 
 Target configurations contain a set of attributes that you may manipulate with an application configuration. You may override these attributes as if they were a normal configuration parameter. If these attributes are cumulative, you may also manipulate them with the special `attribute_add` and `attribute_remove` meta-attributes.
 
@@ -226,7 +226,7 @@ For example, this `mbed_app.json` disables the IPV4 feature; using this network
 }
 ```
 
-# Configuration data precedence
+### Configuration data precedence
 
 The order in which the various bits of configurations are considered is:
 
@@ -244,10 +244,10 @@ For `myapp` above:
 - The value of `mylib.timer_period` is 100 because that's overridden by the application and takes precedence over the values defined in `mylib`.
 - The values of `mylib.buffer_size` and `mylib.queue_size` are:
  	- 1024 and 10, respectively, when compiling for `Base`, as defined in the `config` section of `mylib`.
- 	- 128 and 20, respectively, because `Derived` defines the `NXP` label and `mylib` defines a specific configuration for this label. 
+ 	- 128 and 20, respectively, because `Derived` defines the `NXP` label and `mylib` defines a specific configuration for this label.
 - Because `Derived` has its own `my_own_config` configuration parameter, `target.my_own_config` will also be defined in this case.
 
-# Using configuration data in the code
+### Using configuration data in the code
 
 When compiling, the configuration system will automatically generate macro definitions for the configuration parameters and all the macros defined in libraries and the application in their `macros` keys. These definitions will be written in a file named `mbed_config.h`, located in the build directory. When compiling `myapp` for target `Base`, the `mbed_config.h` file will look like this (note that the order of the definitions may be different):
 

docs/compile/exporter_instruct.md

@@ -0,0 +1,3 @@
+## Exporter instructions
+
+[A document with detailed step-by-step instructions about exporters.]

docs/advanced/exporters.md renamed to docs/compile/exporters.md

@@ -1,8 +1,8 @@
-# About the exporters
+## About the exporters
 
 Use the mbed exporters to export your code to various third party tools and IDEs. Each exporter implements a `generate` function that produces an IDE specific project file. Exporters benefit from mbed build tools. However, instead of using your source and [config data](config_system.md) to create an executable, we use that information to populate an IDE project file that will be configured to build, flash and debug your code. You can find exporter implementations [here](https://github.com/ARMmbed/mbed-os/tree/master/tools/export).
 
-## mbed CLI command
+### mbed CLI command
 
 ```
 usage: mbed export [-h] [-i IDE] [-m TARGET] [--source SOURCE] [-c] [-S] [-v]
@@ -24,38 +24,38 @@ optional arguments:
   -vv, --very_verbose   Very verbose diagnostic output
 ```
 
-# Adding export support for a target
+### Adding export support for a target
 
 If you have added a new target to mbed OS 5, exporting will allow users to transition from mbed source code to the offline development environment of their choice. More people can use your device.
 
-## Eclipse and Make
+#### Eclipse and Make
 
 Eclipse project export uses a generated Makefile for building. If `mbed compile -t <toolchain> -m <target>` works, then mbed `export -i make_<toolchain> -m <target>` will also work. You can find more information about adding and configuring targets [here](mbed_targets.md).
 
-## GNU ARM Eclipse managed projects
+#### GNU ARM Eclipse managed projects
 
 The GNU ARM Eclipse exporter is available for all targets that use the GCC_ARM toolchain.
 
-## Qt Creator and Make
+#### Qt Creator and Make
 
 The Qt Creator project export is available for the GCC_ARM toolchain; it generates a [Qt Creator generic project](http://doc.qt.io/qtcreator/creator-project-generic.html) and a Makefile, in a similar fashion to the *Eclipse and Make* exporter.
 
 You can open the generated `.creator` project in Qt Creator, enabling integration with the project pane, syntax highlighting and automatic code completion. You can use the Makefile to compile the project; the IDE should automatically invoke the Makefile when you issue the Build command.
 
-## uVision and IAR
+#### uVision and IAR
 
-### CMSIS Packs
+##### CMSIS Packs
 
-uVision and IAR both use [CMSIS packs](http://www.keil.com/pack/doc/CMSIS/Pack/html/index.html) to find target information necessary to create a valid project file. 
+uVision and IAR both use [CMSIS packs](http://www.keil.com/pack/doc/CMSIS/Pack/html/index.html) to find target information necessary to create a valid project file.
 
-We use the tool [ArmPackManager](https://github.com/ARMmbed/mbed-os/tree/master/tools/arm_pack_manager) to scrape [MDK5 Software Packs](https://www.keil.com/dd2/Pack/) for target information by parsing [http://www.keil.com/pack/index.idx](http://sadevicepacksprod.blob.core.windows.net/idxfile/index.idx). [index.json](https://github.com/ARMmbed/mbed-os/blob/master/tools/arm_pack_manager/index.json) stores the relevant information in the [PDSC (Pack Description)](http://www.keil.com/pack/doc/CMSIS/Pack/html/_pack_format.html) retrieved from each URL in the index. 
+We use the tool [ArmPackManager](https://github.com/ARMmbed/mbed-os/tree/master/tools/arm_pack_manager) to scrape [MDK5 Software Packs](https://www.keil.com/dd2/Pack/) for target information by parsing [http://www.keil.com/pack/index.idx](http://sadevicepacksprod.blob.core.windows.net/idxfile/index.idx). [index.json](https://github.com/ARMmbed/mbed-os/blob/master/tools/arm_pack_manager/index.json) stores the relevant information in the [PDSC (Pack Description)](http://www.keil.com/pack/doc/CMSIS/Pack/html/_pack_format.html) retrieved from each URL in the index.
 
-A `.pdsc` file typically describes a family of devices. Each device is uniquely identified by its [device name](mbed_targets.md#device_name). This name makes a natural key to associate a device with its information in `index.json`. 
+A `.pdsc` file typically describes a family of devices. Each device is uniquely identified by its [device name](mbed_targets.md#device_name). This name makes a natural key to associate a device with its information in `index.json`.
 
-#### What's in a device name?
+###### What's in a device name?
 There is no reliable way to map an mbed alias such as [NUCLEO_F030R8](https://github.com/ARMmbed/mbed-os/blob/master/targets/targets.json#L603) to its unique identifier, [STM32F030R8](https://github.com/ARMmbed/mbed-os/blob/master/targets/targets.json#L615), because it is listed in a CMSIS pack (and subsequently `index.json`). So, we added a [device name](mbed_targets.md#device_name) field in `targets.json`. **This field is required for IAR or uVision exporter support**.
 
-#### Code usage
+###### Code usage
 [http://www.keil.com/pack/Keil.Kinetis_K20_DFP.pdsc](http://www.keil.com/pack/Keil.Kinetis_K20_DFP.pdsc) is the PDSC that contains TEENSY_31 device (MK20DX256xxx7). ArmPackManager has parsed it, and `index.json` stores it. The device information begins on line 156:
 ```xml
       <device Dname="MK20DX256xxx7">
@@ -73,13 +73,13 @@ There is no reliable way to map an mbed alias such as [NUCLEO_F030R8](https://gi
       </device>
 ```
 
-##### uVision
+####### uVision
 The `dname` (device name) field on line 156 directly corresponds to that in the uVision5 IDE Target Selection window. [`tools/export/uvision/uvision.tmpl`](https://github.com/ARMmbed/mbed-os/blob/master/tools/export/uvision/uvision.tmpl#L15) uses target information from these packs to generate valid uVision5 projects. If the program cannot find the device name, we use a generic ARM CPU target in uVision5.
 
-##### IAR
+####### IAR
 [`tools/export/iar/iar_definitions.json`](https://github.com/ARMmbed/mbed-os/blob/master/tools/export/iar/iar_definitions.json) uses this device name to store information necessary to set the target in an IAR project.
 
-##### Updating index.json
+####### Updating index.json
 You can regenerate `index.json` to contain a newly made CMSIS pack with the following command:
 
 `mbed export -i [IDE] --update-packs`