-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tools/Makefile.unix: Remove FORBIDDEN CXD56 code in common Makefile. #442
Comments
I wonder if we don't need to hook in Makefile.unix/win to run:
Where arch is a symbolic link to either a dummy directory or to a directory holding a platform-specific fixup? |
In many case, such as for the ESP32, such post build binary generation could be moved to /arch//src/Makefile. But this is not so convenient for other architectures like CXD56xx since /arch/arm/src/Makefile is shared by so many arm architectures. So I think we need a systematic solution to handle all post-build binary generation that can work in a modular way for all platforms. There is a precedent for achitecture-specific logic in tools/xxxx/, so that would be a first thought for a location to provide such custom binary generation. |
See related #437 I am thinking that a more systematic solution is needed both for CXD56xx and ESP32 and for any future platforms that require custom binary generation after the final linking step. I am thinking that perhaps we should support some Makefiles and tools in directories under tools/. Then perhaps we could do a wildcard check for:
And if it exists, then run it. So in this case, it would check for tools/cxd56xx/Makefile and would executre tools/cxd56xx/Makefile to generate the binary using the changes currently in tools/Makefile.unix This would serve the needs of all architectures, existing and future. |
Can we reuse the existing Makefile? For example:
But tools has the flat directory structure, it's better to put the special tools or script to boards/arch directory: |
Another option is to use a 'define POSTBUILD' in tools/Config.mk. That definition would be empty , but could be overriden in any Make.defs file by adding a 'define POSTBUILD'. I do this for the ZDS-II tools which are not very compatible with GNU tools. I add a zds_Config.mk in tools/zds. That .mk file redefines several things in tools/Config.mk and tools/zds/zds_Config.mk is included by all Make.defs that use ZDS-II tools. As a result, the very strange ZDS-II tools work with not impact to other build-related files. |
PR #457 provide a resolution for this issue. Pleave review and, hopefully, merge. |
[T3PW] Feature/csc himem map
Because of modularity concerns, this logic must be removed from tools/Makefile.unix:
If is FORBIDDEN to include platform specific logic in common build logic.
The text was updated successfully, but these errors were encountered: