csanchezdll commented on code in PR #20367: URL: https://github.com/apache/nuttx/pull/20367#discussion_r4167207255
########## boards/arm/common/stm32/src/Make.defs: ########## @@ -215,6 +215,14 @@ endif ifeq ($(CONFIG_STM32_ROMFS),y) CSRCS += stm32_romfs_initialize.c +stm32_romfs_initialize.o: ../../../$(patsubst "%",%,$(CONFIG_STM32_ROMFS_IMAGEFILE)) +../../../../../apps/examples/elf/main/elf_romfs.img: + $(MAKE) -C ../../../../../apps/platform all APPDIR=.. TOPDIR=$(TOPDIR) Review Comment: 1) Use a host-generated autoconf and adapt using CONFIG_xxx I would need to asses which CONFIG_xxx should cause enabling or disabling of each HAVE_xxx, which is not trivial. It would mean basically constructing a Kconfig-based configuration for jimtcl. Moreover, the template will be based on a given NuttX config, which might not include all the configs we want to enable/disable. It would basically remove the advantage of jimtcl autoconf-based configuration (BTW, it uses configure, but not GNU autoconf, but a similar tool for TCL: https://msteveb.github.io/autosetup/ ) 2) Check compiler result instead of link This is jimtcl maintainer(s) choice. I think their choice is correct, because some system might have all the functions declared in the system headers, but them available in the system libraries depending on the build. In any case, I can not change this, it is part of their configure script. I think I am going to drop this, for the moment. When I submitted the PR, all my tests had built, I thought moving libapps.a building to the end of the overall build process was the right thing to do. The patch was small and clean. Only when the pipelines failed I realized in that specific config `nucleo-h743zi:elf` there is a dependency which requires an early libapps.a build. I agree my fix for that is that is too hacky. I will need to find another way to fix jimtcl. I will give it some more thought and maybe raise the problem of library build order on the mailing list. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
