Regression: COMPONENT_OWNBUILDTARGET and COMPONENT_ADD_LDFLAGS broken in v3.3-beta3 (maybe others) (IDFGH-1384)

[jmattsson]

Environment

• IDF version (run git describe --tags to find it): v3.3-beta1-694-g6b3da6b18 (v3.3-beta3 tag used to checkout)
• Build System: Make
• Compiler version (run xtensa-esp32-elf-gcc --version to find it): 1.22.0-80-g6c4433a5
• Operating System: Linux

Problem Description

I wanted to upgrade to the 3.3 branch in order to get access to the rollback support in the bootloader (yay!). However, doing so broke our project as one of our components using COMPONENT_OWNBUILDTARGET then failed to build.

This version IDF appears to completely disregard both COMPONENT_OWNBUILDTARGET and COMPONENT_ADD_LDFLAGS.

We are relying on this to build a host-tool used to generate artifacts that get used by a different component.

At least overriding COMPONENT_ADD_LDFLAGS used to work as per https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/build-system.html#fully-overriding-the-component-makefile . I'm not sure whether the COMPONENT_OWNBUILDTARGET ever worked, since our target is actually called "build".

Expected Behavior

Our own build target gets invoked, and COMPONENT_ADD_LDFLAGS is honored so the IDF doesn't attempt to link in a non-existent library.

Actual Behavior

The build still tries to use the build target:

make[2]: Entering directory '/path/to/project/build/our_host_component'
make[2]: *** No rule to make target 'build'.  Stop.
make[2]: Leaving directory '/path/to/project/build/our_host_component'
make[1]: *** [/path/to/project/sdk/esp32-esp-idf/make/project.mk:552: component-our_host_component-build] Error 2

If we try to avoid this by naming our custom target build, then it fails later:

make[2]: Entering directory '/path/to/project/build/our_host_component'
<our build happens here>
make[2]: Leaving directory '/path/to/project/build/our_host_component'
Generating libour_host_component.a.sections_info
xtensa-esp32-elf-objdump: '/path/to/project/build/our_host_component/libour_host_component.a': No such file
make[1]: *** [/path/to/project/sdk/esp32-esp-idf/make/project.mk:463: /path/to/project/build/our_host_component/libour_host_component.a.sections_info] Error 1

Steps to reproduce

Create a new component in a project, with contents like:

COMPONENT_OWNBUILDTARGET:=custom_target
COMPONENT_ADD_LDFLAGS:=

custom_target:
  @echo Placeholder target to show broken IDF build

Try to build it.

[projectgus]

Hi @jmattsson ,

I'm really sorry for the incredibly long time it's taken for someone to get back to you, especially given the clearly articulated bug report.

Regarding COMPONENT_OWNBUILDTARGET and COMPONENT_OWNCLEANTARGET, a fix for this that will be merged soon and backported to the release/v3.3 branch.

Regarding overriding COMPONENT_ADD_LDFLAGS to change the library name, I actually don't think the statement about changing the component library has ever been 100% correct - although it broke obviously when we added linker script generator in v3.3, there are some other cases where changing the library name may result in failure to correctly build the component or re-link the app. It is still possible to add more libraries to the linker command line from the component, but will update the docs to state that every component should create a component called libcomponentname.a as well, as part of its build target.

Angus

[jmattsson]

Hi Angus,

Thanks for the (belated) update! Regarding COMPONENT_ADD_LDFLAGS it was not to change the library name, but rather to omit the default -lour_host_component, as in this case it was a non-library component. Of course, the obvious workaround (which we used) is to also generate an empty lib as a side-effect, but that felt rather dirty. In the earlier IDF, it was indeed possible to suppress that default -l flag.

Regards,
/Johny

[Alvin1Zhang]

Thanks for reporting and sorry for very slow turnaround, fix on master is available dea52a9, we will back port the fix until release/3.3, will keep updated.

[AxelLin]

@projectgus @Alvin1Zhang
I don't find backport fix in any stable branches.

[sudeep-mohanty]

The fix is added to v4.4 at dea52a9 and subsequently COMPONENT_OWNBUILDTARGET and COMPONENT_OWNCLEANTARGET are no longer supported in CMake. These are overridden by ExternalProject instead.

Unfortunately, the fix cannot be backported to v3.3 as the release has reached EoL.

Closing this issue.