For example,
SRCDIRS = comp_a happy/comp_b /c/dev/comp_c
Then the following are built:
build/comp_a/libcomp_a.a
build/comp_b/libcomp_b.a
build/comp_c/libcomp_c.a
But when LD is run the -L is calculated as follows
-L build/comp_a
-L build/happy/comp_b
-L build//c/dev/comp_c
This means comp_b and comp_c are not found by LD. With this change set -L is calculated correctly for comp_b and comp_c
Merges #504https://github.com/espressif/esp-idf/pull/504
Version parameter was added in git 2.11, while default git on macOS is
currently 2.10. According to the latest git docs, if the version
parameter is not provided, it defaults to ‘v1’, so removing it doesn’t
change the format.
Windows setup improvements
* Tweak Makefile to significantly reduce startup time on Windows (also reduced on other platforms, but less obvious.)
* Revise windows setup installation script to fix various issues, use latest toolchain.
* Tweak Windows config docs
See merge request !597
CI support for testing & deploying release tags & branches
For CI testing & deployment of release branches:
* Test release tags as well as branches
* Swap gitlab submodule URLs to github when testing release tags or branches.
These changes are already pushed to the release/v2.0 branch.
See merge request !604
This is substantially faster than the 'git submodule status' command, has same effect. Particularly noticeable on
Windows, where 'submodule status' takes 2 seconds and 'status' takes 0.2 seconds.
Expand 'make monitor' support
New 'make monitor' idf_monitor tool for better monitor output. Running 'make monitor' will now:
* Automatically look up code addresses via addr2line and print function, source file, line number in terminal.
* Can reset the ESP32 by typing Ctrl-T Ctrl-R.
* Can run "make flash" by typing Ctrl-T Ctrl-F.
* Can run "make app-flash" by typing Ctrl-T Ctrl-A.
* If gdb stub starts, monitor will automatically run gdb and connect. When gdb exits, ESP32 resets and monitor resumes.
* Exit is still Ctrl-[
Have some more features I'd like to add (log output to file, crash dump support) but I think this is at the point of being useful.
See merge request !565
make: don’t override TEST_COMPONENTS
When idf_monitor is launched from make, it gets modified `TEST_COMPONENTS`
variable which contains full paths to the test components instead of the
names. This causes `TEST_COMPONENT_PATHS` to be empty and the unit test
app gets built without any test components.
This change introduces an internal `TEST_COMPONENTS_LIST` variable which
gets set either from `COMPONENTS` if `TESTS_ALL` is 1, or from
`TEST_COMOPONENTS` otherwise.
Bootloader makefile is also fixed to avoid propagating `TESTS_ALL` to the
bootloader build step.
See merge request !569
When idf_monitor is launched from make, it gets modified TEST_COMPONENTS
variable which contains full paths to the test components instead of the
names. This causes TEST_COMPONENT_PATHS to be empty and the unit test
app gets built without any test components.
This change introduces an internal TEST_COMPONENTS_LIST variable which
gets set either from $(COMPONENTS) if TESTS_ALL is 1, and from
TEST_COMOPONENTS otherwise.
Bootloader makefile is also fixed to avoid propagating TESTS_ALL to the
bootloader build step.
make: look for TEST_COMPONENTS in all component directories
This change allows building unit tests found inside the project components directory.
fixes https://github.com/espressif/esp-idf/issues/354
See merge request !537
See github #311https://github.com/espressif/esp-idf/issues/311
Should fix weird compiler/linker bugs where config says something is
enabled, but build system says it is disabled.
Particularly noticeable when WiFi/BT libraries fail to
compile/link despite being enabled.
Underlying cause is configuration file regenerating, but component
Makefiles not reevaluating.
Entirely removes the idea that we don't need to generate config for some
targets (like 'clean'). We need valid config for these targets,
otherwise they don't know which files to clean (etc).
fix mbedtls unit tests, fix IDF_VER when building a project outside ESP-IDF tree
- mbedTLS test needs about 5% more time to run (in debug mode) when building with 5.2.0, compared to 4.8.5. Increase the timeout to let the test pass.
- when doing `git describe` in IDF_VER definition, `-C $(IDF_PATH)` is needed to get the version of ESP-IDF, and not the project being built (which may not even be in git)
See merge request !411
build system: add IDF_VER environment variable and preprocessor define
This adds an `IDF_VER` preprocessor define which is obtained from `git describe`.
Looks like `v1.0-275-g0efaa4f` for non-release version or `v2.0` for a tagged (release) version.
See merge request !403
C++ support
This change adds necessary support for compiling C++ programs:
- linking against libstdc++
- implementation of static initialization guards using FreeRTOS primitives: since we don't have condition variables at our disposal, and we don't want to allocate a synchronization primitive for every guard variable generated by the compiler, we imitate condition variables using a combination of a mutex, counting semaphore, and a counter (based on [Microsoft Research paper](https://www.microsoft.com/en-us/research/wp-content/uploads/2004/12/ImplementingCVs.pdf), albeit because we don't need *arbitrary* code to use these CVs, implementation gets simpler).
Note that libstdc++ also contains an implementation of `__cxa_guard_{acquire,release,abort}` functions. These implementations come from an `#ifndef GXX_THREADS` branch, i.e. are not aware of multthreading. There are three ways of replacing these libstdc++ functions with our implementation:
1. Move our code into gcc. Pros: cleanest solution. Cons: Such changes are unlikely to be merged by any upstream, so we end up maintaining our own forks of {gcc,crosstool-ng}.
2. Use library as it is built by crosstool, use `ar` to delete one object file (`guards.o`), add this library to ESP-IDF. Pros: easy to implement. Cons: libstdc++ is a 15MB binary 😯
3. Keep using libstdc++ from crosstool, force our implementation to be linked using a `-u` linker flag. Pros: no impact on repo size, easy to implement. Cons: somewhat less clean than 1 (and about as hacky as 2).
For the reasons mentioned, option (3) looks like the best tradeoff.
Ref. TW6702
See merge request !364
