ARMmbed
/
mbed-os
mirror of https://github.com/ARMmbed/mbed-os.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
5,899 Commits
52 Branches
336 Tags
624 MiB
Commit Graph

67 Commits (5e5e1568bebdad30fa695a42f45922ddb007dad0)

Author SHA1 Message Date
Bogdan Marinescu cdfa46c790 Fixes to the new targets code 
It is now possible to remove a macro using "_remove" for both macros
without vale (MACRO) and macros with value (MACRO=VALUE) simply by
specifying the macro name.
 2016-05-20 17:27:43 +03:00
Bogdan Marinescu 7c57269dcf Moved target definitions to JSON format 
(long commit message ahead. Sorry about that, it can't be helped.)

This commit changs targets definition from Python to JSON format, as
part of the configuration mechanism implementation. There is a new file
under tools/ called "targets.json" which contains the target
definitions. "targets.py" remains, but becomes a wrapper on top of
"targets.json", with the same interface as before. This has the
advantage of not requiring code changes outside "targets.py".

Most of the JSON definitions of targets were automatically generated by a
script (available upon request since it doesn't make a lot of sense to
include it here), only those targets that had more than one parent in
the Python implementation were converted by hand. The target definitions
should be pretty self-explanatory. A number of things are different in
the JSON implementation (this is just a summary, a separate commit that
documents how to write target definitions will follow later):

- "program_cycle_s" is now a value (as opposed to a function in the
Python implementation), since it only returned a number in all the
Python target implementations. The main definition that actually contains
some code (in class "Target") remains in target.py
- array values in "macros" and "extra_labels" can be modified
dynamically. Values can be added using "macros_add" and
"extra_labels_add" or removed using "macros_remove" and
"extra_labels_remove". This mechanism is available for all attributes
with a list type, but it's currently enabled only for "macros" and
"extra_labels" to keep things simple.
- "init_hooks"/"binary_hook" are now implemented in terms of a single
JSON key valled "post_binary_hook". The corresponding code is also in
"targets.py", under the various TargetCode classes (see for example
LPC4088Code in targets.py).

Just like in the Python implementation, a target can inherit from zero,
one or more targets. The resolution order for the target's attributes
follows the one used by the Python code (I used
http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path
as a reference for the implementation of resolution order).

This is obviously a very dangerous commit, since it affects all targets.
Unfortunately, since mbed-os only compiles for K64F, I didn't have many
chances to try to compile mbed-os with different targets. I did it for
K64F in different scenarios (pretending that it has hooks, for example),
but there's definitely a lot more to be done there. The threaded blinky
example for K64F compiles and works.

I tried to test in a different way: I wrote a script that imports the
old (Python) and the new (JSON) implementations and verifies that the
attributes in the old implementations exist and have the same values
in the new implementations (it also verifies that the attribute
resolution order is the same in the two implementations). If you're
interested, the script is here:

https://gist.github.com/bogdanm/4caf3a11613dcec834b05d5ab87c65dc

And the results of running the script are below (note that the script
outputs only the target names that were found to be problematic):

F51_MICROBIT_BOOT:
    Resolution order is different in old and new
        old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110']
        new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target']
    'extra_labels' has different values in old and new
        old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT']
        new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT']
    'macros' has different values in old and new
        old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']
        new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']
NRF51_MICROBIT:
    Resolution order is different in old and new
        old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110']
        new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target']
    'extra_labels' has different values in old and new
        old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110']
        new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K']
    'macros' has different values in old and new
        old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC']
        new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC']
NRF51_MICROBIT_OTA:
    Resolution order is different in old and new
        old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110']
        new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target']
    'extra_labels' has different values in old and new
        old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT']
        new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT']
    'macros' has different values in old and new
        old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']
        new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']
NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA']

The reasons for the above output are subtle and related to the
extremely weird way in which we defined target data in the old
implementation: we used both class attributes and instance attributes.
This can complicate resolution order quite a bit and those two levels
don't exist in JSON: there's only one attribute type (equivalent to
Python's instance attributes). To make that work, I had to change the
inheritance order of the above targets (that use multiple inheritance)
which in turn changed the order of some macros and extra_labels (and of
course the resolution order). No harm done: the values are the same,
only their ordering is different. I don't believe this causes any
problems for 'extra_labels' and 'macros'.

This method of testing has its limitations though; in particular, it
can't test the hooks. I'm opened to ideas about how to test this better,
but I think that we need to remember that this commit might break some
targets and keep an eye out for "weird errors" in the future.
 2016-05-17 11:34:02 +03:00
Brian Daniels 4ae7d54830 Fixing build issues for tests. 
Build artifacts from previous builds were polluting the current build. Now
shared sources are built as a library, then tests are built into their own
folder.
 2016-05-10 14:53:35 +01:00
Bogdan Marinescu 904ea446eb Merge pull request #84 from screamerbg/compile-response-files 
Response files for includes, de-duplicate includes and more
 2016-05-10 12:05:16 +03:00
Mihail Stoyanov 7e3b69ec13 Add dot to include response file name, which follows the naming convention with .link_totals.txt and .link_files.txt 2016-05-09 19:08:56 +01:00
Mihail Stoyanov d33f890fdd Minor code cleanup 2016-05-09 19:08:56 +01:00
Mihail Stoyanov 7e11174a00 Calculate md5 of all include paths in compile_sources() and remove calculation from <toolchaon>get_compile_options(), thus significantly reduce repetitive md5 calculations 
Unify handling of the include response file in mbedToolchain::get_inc_file()
Sanitize obsolete no-longer needed methods
 2016-05-09 19:08:56 +01:00
Mihail Stoyanov f01e1363d1 De-duplicate the include paths. Without this all compiles are passed include paths twice 2016-05-09 19:08:56 +01:00
Mihail Stoyanov 868942a148 Build system response files for all macros and includes. This also allows developers to check the response file after/during compile for the list of all macros and includes being used. 2016-05-09 19:08:56 +01:00
Mihail Stoyanov ecb9651873 Unified command-line handling of defines and includes with response files for all toolchains (ARM, GCC, IAR) 
Capture system/OS error during command execution and report the command
Report command before executing it in default_cmd()
 2016-05-09 19:08:56 +01:00
Mihail Stoyanov 2be0385f73 Response files for includes during assemble() and compile() 
Moved unified compile to toolchains to enable specific toolchain support for response files
 2016-05-09 19:08:55 +01:00
Sam Grove fc4f1e2da3 Merge pull request #71 from bridadan/test-build 
Building tests and test specs
 2016-05-05 13:51:11 -05:00
Mihail Stoyanov fb03e5a2c1 Fixed parameter to match documentation (allow multiple build) 2016-05-05 19:09:58 +01:00
Brian Daniels 1d28050686 Adding test compiling and test spec generation to test.py 2016-05-05 15:37:37 +01:00
Brian Daniels 65fae781a1 Toolchain should create artifact directory for link step 2016-05-05 09:39:01 +01:00
Mihail Stoyanov 34ec8297a4 Copy .o and .ar files for when building static library (needed for uVisor for example) 2016-05-04 12:06:57 +01:00
Mihail Stoyanov ba31ed0550 Support for response files for ARMCC, GCC and IAR archiving (static library) 
Support for compiling static libraries via build.py
Support for build.py --no-archive flag which compiles static library as multiple objects
Change default number of jobs when compiling to 0 (auto)
Fix for relative path issue when compiling, which flattened the output whenever absolute path is passed to --build (make.py and build.py)
Fix for temporary files when pre-processing of assembler files with ARMCC
Fix issue with response files where one of the elements is empty string
 2016-04-30 00:32:26 +01:00
Sam Grove b337c7fd00 Merge pull request #63 from bridadan/set-project-name-option 
Allow the output binary of make.py to be named from the command line
 2016-04-28 14:26:59 -05:00
Marcus Shawcroft bd37e5ac0a Merge pull request #65 from geky/make-follow-symlinks 
Add support for following symlinks in make.py
 2016-04-28 16:03:40 +01:00
Bogdan Marinescu 6b3d841664 Merge pull request #56 from 0xc0170/fix_generated_dir 
Fix generated dir
 2016-04-27 10:56:19 +03:00
Martin Kojtal 80cecbfcfb Exporters - if source, generate to projectfiles/{{ide}} 
This allows to use multiple tools within a project, they don't affect
each other.

An example:
projectfiles/gcc_arm
projectfiles/uvision
projectfiles/iar
 2016-04-26 11:44:26 -05:00
Brian Daniels dac491645d Allow the output binary of make.py to be named from the command line 2016-04-26 10:59:28 -05:00
Bogdan Marinescu e472a51e45 Merge pull request #64 from bridadan/add-test-discovery-tool 
Adding test.py script in tools that allows you to discover tests
 2016-04-25 18:17:18 +03:00
Bogdan Marinescu 22e1e9837c Merge pull request #58 from bridadan/allow-toolchain-exclude-path 
Allow toolchains to exclude a path when scan for resources
 2016-04-25 18:14:28 +03:00
Brian Daniels 1a8b973aab Moving test discovery logic into test_api.py. test.py is now just the CLI interface to these functions 2016-04-22 16:29:55 -05:00
Brian Daniels 9a126c4e3a Adding script in the tools directory that allows you to discover tests 2016-04-21 13:51:51 -05:00
Christopher Haster 1fdb86eda7 Add support for following symlinks in make.py 2016-04-20 21:08:47 -05:00
Brian Daniels bbc6e2aba3 Allowing a list of exclude paths to be passed 2016-04-20 10:56:33 -05:00
Martin Kojtal 3e91490259 Build - raise exception if toolchain is not recognized 
This sends the message that toolchain specified is not valid.
 2016-04-20 13:16:37 +01:00
Martin Kojtal 227ffecb83 Make - handle invalid targets (catch KeyError) 2016-04-20 13:04:53 +01:00
Brian Daniels 8cc6a58162 Providing mechainsm for toolchains to exclude a path when scanning for resources 2016-04-19 14:53:42 -05:00
Martin Kojtal 647cf23cf1 Exporters - add relative paths handling 
If we use source option, the paths should be relative to the source dir.
Otherwise, mbed export scripts copies sources to temp dir.
 2016-04-19 14:55:16 +01:00
Martin Kojtal fc005d50cd Exporters - use relative project dirnames 
For file like mbed-os\net\sal-stack-nanostack-private\source\BorderRouter\br_rf_interface.c,
virtual dir is: mbed-os\net\sal-stack-nanostack-private\source\BorderRouter.

This sould better organize virtual folders in IDE. The next step would be to break into
groups. For instance hal could be groped together, net together and other components.
 2016-04-18 11:55:48 +01:00
Brian Daniels 5b36a4cfd0 Adding a proper exit return code on a toolchain failure 2016-04-12 18:32:33 -05:00
Bogdan Marinescu 7996649d96 Merge pull request #43 from screamerbg/master 
Add reponse files for GCC, ARMCC and IAR linking
 2016-04-12 14:17:30 +03:00
Mihail Stoyanov 76f6374f4a Merge pull request #42 from meriac/mainline 
Fix check on UVISOR_PRESENT=1 macro
 2016-04-12 12:15:10 +01:00
Mihail Stoyanov 61298334c2 Introduce response file for linking with IAR toolchain 2016-04-12 12:11:22 +01:00
Mihail Stoyanov 40fc10401b Merge https://github.com/screamerbg/mbed-os 2016-04-12 11:37:43 +01:00
Mihail Stoyanov 927caca09f Introduce response files for ARMCC and GCC toolchains and also document code 2016-04-12 11:37:15 +01:00
Alessandro Angelino ec0e403bf9 Fix check on UVISOR_PRESENT=1 macro 2016-04-12 11:11:02 +01:00
Martin Kojtal 75d04a3903 Add debug symbols to all builds (release/debug) 
All toolchains affected. Fixes #39.
 2016-04-12 09:35:55 +01:00
Bogdan Marinescu 55e68380cd Merge pull request #32 from 0xc0170/fix_build_dir 
Fix build dir for uvision and IAR
 2016-04-08 10:05:59 +01:00
Martin Kojtal 5b8e65b80e Exporters - uvision and iar appends its name to build dir 2016-04-07 18:54:58 +01:00
Martin Kojtal adfcf2c689 Exporters - .build dir for progen as output dir 2016-04-07 18:47:49 +01:00
Marcus Shawcroft e3afc94f65 Merge pull request #30 from screamerbg/master 
Update GCC toolchain to support the new format for the first line of …
 2016-04-07 18:00:57 +01:00
Mihail Stoyanov fe75990e4c Update GCC toolchain to support the new format for the first line of .d files 2016-04-07 17:49:05 +01:00
Bogdan Marinescu f28588c3c2 Merge pull request #8 from mjs-arm/botch-fixing 
Fix merge of support for --source for exporters
 2016-04-07 09:16:56 +01:00
Bogdan Marinescu 0b593484db Merge pull request #5 from 0xc0170/fix_project 
Tools - project options.macros None fix
 2016-04-07 09:14:52 +01:00
Marcus Shawcroft 810ecc5b21 Fix merge of support for --source for exporters 
The original merge of this patch was botched, this patch re-instantes
the missing part.
 2016-04-06 20:55:17 +01:00
Martin Kojtal a058ab98a4 Tools - project options.macros None fix 
Handle when options.macros is None, which results in Traceback
 2016-04-06 19:07:23 +01:00