@craig.scott
I’m trying to fix an issue that I have with the GHS generator.
Currently GHS_CUSTOMIZATION handles only a single filename.
But a user could have multiple customization files for their project. I need to add two.
I think that the GHS platform has the variable as filetype so that it works well with cmake-gui interface.
Is the best method to just create GHS_CUSTOMIZATION_FILE_1 through GHS_CUSTOMIZATION_FILE_4 (or something) to support multiple files?
What would be the implication on uses of GHS_CUSTOMIZATION if it contained a list instead of a single file? Would all existing consumers of that variable handle that correctly? If so, then I’d suggest we take that route rather than adding numbered variables. We do something similar with CMAKE_PREFIX_PATH and probably other variables, where the name implies a single path, but it can contain a list. The variable type should probably be changed to STRING in that case, which means slightly less nice presentation in the CMake GUI, but is technically more correct.
Note that I’m not at all familiar with how and where GHS_CUSTOMIZATION is used. My comments are based purely on general observations.
GHS_CUSTOMIZATION is used in only one spot in the generator. The GHS project file has a field called customization which lists all of the toolset customization files. There is no limit on the number of customization files that can be included. Its a way of extending the toolset behavior and is used by GHS themselves when providing Integrity middleware addons.
I prefer that it be a STRING so that I can use the GHS project internal macros to make it easier to include GHS provided customization files ("/path/to/GHS/installation/special/file.bod" vs "${GHS_TOOLS}/special/file.bod").