Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Make.defs under board folder can still overwrite the default as needed
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I1c300a8ace4b54d475ef8d398661ed65ca273a2e
* tools/Config.mk - Add empty definition POSTBUILD
* tools/Makefile.unix/win - Replace CXD56xx specific logic with $(call POSTBUILD)
* boards/arm/cxd56xx/scripts/Config.mk - Add POSTBUILD definitions with logic removed from Makefile.unix/win
* boards/arm/cxd56xx/spresense/scripts/Make.defs - Include the CXD56xx Config.mk immediately after tools/Config.mk so that the empty POSTBUILD definition will be replaced with the correct one
NOTE: There is a precedent for this approach. This is the way that other architecture-specific build options are implemented. See, for example, tools/zds/Config.mk
This tools needs to CD to directory holding the library because it requires that the library be in the current working directory when objects are inserted. Previously, the tool did this by creating an absolute path to the object file itself. So instead of the object file being in the current directory and the library in a directory at an absolute path, this tool used an abolte path to the object file with the library in the current directory.
For the most part, that worked fine. However, in the apps directory the object file names are greatly extended in length. In the object file name was extended to a full absolute path and these huge file names were were exceeding some internal limit within the ZDS-II librarian. But useing shorter, relative paths, we were able to avoid hitting this limit and the entire build completed correctly.
* tools/zds/zds_Config.mk: Move boards/z80/ez80/scripts/eZ80_Config.mk to tools/zds/zds_Config.mk where it can be shared by other ZDS-II platforms.
* boards/z16/z16f: Duplicate changes for new ZDS-II support from ez80
* boards/z80/z8: Duplicate changes for new ZDS-II support from ez80
* arch/z16/src/z16f/Toolchain.defs: Create required Toolchain.defs file for Z16f
tools/zds/zdsgen.c: Remove this program. It should have been a simpler way to manage ZDS-II compiler and assember differences. However, the compiler arguments needed to pass through too many layers of bash command line modifications and, as a result, it was not possible to retain quotes on critical strings. This approch was abandoned for an alternative approach.
boards/z80/ez80/scripts/eZ80_Config.mk: Add definitions to move the object files as necessary. This seems to work well and is implemented for both native and Cygwin Windows build -- but only for the Z20x.
And additional wrapper that is needed for the ZDS-II build is a wrapper for the compiler and assemble. This is needed because the ZDS-II cannot control the name or location of the output of the output object file: it is always in the same directory as the source file and with the same name as the source file except with the .obj extension.
This was handled in the past with the MOVEOBJ definition which was specifically called Makefiles to move the objects to the correct position. However, now there is a new behavior: Output object files may also be named differently with added decoration in the file name. This is done in the current apps/ directory build.
There is currently some ugly implementation that includes a long sequence of Bash code to handle the moving and/or renaming. There is nothing in place for the Windows native case.
This wrapper, when complete, will clean up the Makefiles, improve build performance, and provide a solution that is portable to both the Cywin/MSYS environment as well as to the Windows native environment.
This zdsar librarian wrapper is code complete and has no known bugs.
However, there are still some build instabilities so perhaps there
are still some bug to be identified. Or perhaps there are other
undiscovered bugs unrelated to zdsar which appears to be behaving
correctly in all cases.
It will take some additional testing know for sure.
A pointer to a string in a memory buffer was losing its value. The reason was that the buffer was occasionally being used for other purposes. The fix is to strdup() the string so that there is a private, protected copy.
tools/zds: A new tool sub-directory intended to hold tools for making life working with the ZDS-II toolchain less painful.
tools/zds/zdsar.c: This is a wrapper around the ZDS_II librarian. It simplifies the build scripts by replacing large sequences of complex Bash script that were added to the build files. Not only does this clean up the build files but it also improves performance and, more importantly, provides a common solution for the Windows native build case. This tool should work with all ZDS-II based platforms including z8, zNeo, and ez80.
tools/README.txt: Add a brief description about the zds sub-directory. Also re-ordered some tool descriptions. They are supposed to be in alphabetical order, but this seems to have fallen apart.
boards/z80/ez80/scripts/eZ80_Config.mk: Updated to use tools/zds/zdsar.exe.
