Before this PR:
```
Successful exports:
* K64F::uvision .\projectfiles\uvision\Unnamed_Project_K64F
```
After this PR:
```
Successful exports:
* K64F::uvision .\projectfiles\uvision_K64F\Unnamed_Project
```
The directory name now contains <ide>_<target>, and there's a single
project per directory as a result.
if we work with relative sources, the flag should be set to True, otherwise
False.
This fixes wrong paths when exporting with --source argument. The exporter would
assume sources were copied, and thus reference them all within the root of the generated
project.
For example .mbedignore in tools/ contains '*' and naturally should match all files, folders including tools/ itself. Without this fix, tools/ is added to the include path
ARM and GNU compilers currently are in a mode where they will accept VLAs
in C++ as an extension. IAR does not accept them in C++.
Avoid potential portability surprises by making GCC warn, and
deactivating the extension in ArmCC.
IAR defaults to C99 mode, but doesn't enable VLAs by default. Enable them
to make it more conformant.
We don't have much if any code using actual variable-length arrays, but
variably-modified types are occasionally used. The same switch controls
both.
(VLAs were actually already enabled in most of the project export
templates, but not the build script).
PR #1974 added a new configuration parameter to K64F, which in turn made
some tests break, because they found an unexpected configuration
parameter. Fixed by defining a special target for the tests
(test_target) that can be used independently of the actual mbed targets.
This commit uses the previously introduced feature of generating
configuration data as a C header file rather than as command line macro
definitions. Each toolchain was modified to use prefix headers if
requested, and build_api.py was modified to set up the toolchain's
prefix header content using the data generated by the config system.
Tested by compiling blinky for GCC and ARMCC. I'm having a few issues
with my IAR license currently, but both ARMCC and IAR use the same
`--preinclude` option for prefix headers, so this shouldn't be an issue.
Note that at the moment all exporters still use the previous
configuration data mechanism (individual macro definitions as opposed to
a prefix header). Exporters will be updated in one or more PRs that will
follow.