1 of 1 people found this helpful
I don't think you would need to create a separate make target. Although, it might just be that I did not get your question correctly.
Say, you are working with snip.bluetooth.ble_hello_sensor in a hosted platform like 4343w. If you look at the .mk file, you would find
$(info "Host Stack") $(NAME)_COMPONENTS += libraries/drivers/bluetooth/low_energy
As the low_energy component gets included, it jumps to 43xxx_Wi-Fi/libraries/drivers/bluetooth/low_energy/low_energy.mk and includes the pre-built ble library based on some condition checks like rtos, host_arch etc in the WICED buildsystem.
Now in your case, in the mylib.mk, you can run the shell script and then add the generated .a file in $(NAME)_PREBUILT_LIBRARY in the same .mk. Please let me know if I picked the correct idea or your main query is still unanswered?
Sure, I use the "component" system extensively and have added a bunch of source-level libraries and some prebuilt ones (e.g. CMSIS-DSP).
However: in this case, I want to trigger the shell script as part of building the WICED project. In my case, this generates a library from a totally separate build system, which I then want to link in. So if I change that source, the custom sub-build will also execute.
I have a sort-of solution to this, but I am not sure if it is final. It is fairly circuitous, as it seems to require an empty dummy.c source file.
My library makefile is:
NAME := Lib_mylib
GLOBAL_INCLUDES := .
$(NAME)_SOURCES := dummy.c
$(NAME)_PRE_BUILD_TARGETS += libmylib.a
echo ">>>>> MYLIB BUILD <<<<<<"
cd $(Lib_mylib_LOCATION) && PATH="$(SAVED_PATH)" mylib_custom_build.sh
cd $(Lib_mylib_LOCATION) && mv -f build_output/libmylib.a . 2>/dev/null; true
$(NAME)_PREBUILT_LIBRARY := libmylib.a