CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2019-04-15T10:52:27-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/18909GHS - add_custom_command results not built before other targets2019-04-15T10:52:27-04:00Matt SoucyGHS - add_custom_command results not built before other targetsAs of 3.14.0-rc1, the GHS top level project contains a list of all of the subprojects, in alphabetical order. Due to the way gbuild builds targets (sequentially, based on the order they're written), alphabetical order prevents subproject...As of 3.14.0-rc1, the GHS top level project contains a list of all of the subprojects, in alphabetical order. Due to the way gbuild builds targets (sequentially, based on the order they're written), alphabetical order prevents subprojects from automatically being built when pressing the "build" button.
Subproject listing for GHS should follow the order that the targets are declared in the cmakelists files.3.15.0Fred BaksikFred Baksikhttps://gitlab.kitware.com/cmake/cmake/-/issues/15995GHS Multi Generator: add_custom_command / add_custom_target does not work2019-04-15T10:52:26-04:00Kitware RobotGHS Multi Generator: add_custom_command / add_custom_target does not workThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15995). Further discussion may take place here.
`add_custom_command(TARGET <target> PRE_LINK ...)` is not implemented. One option may...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15995). Further discussion may take place here.
`add_custom_command(TARGET <target> PRE_LINK ...)` is not implemented. One option may be to make it the same as PRE_BUILD as submitted in #16488 feature 3.
#16488 feature 17 addressed issues regarding parallel running of commands and the use of the terminal by using `:preexec=` vs `:preexecSafe=` vs `:preexecShell=` vs `:preexecShellSafe` and new `[SAFE_CMD]` signature.
The `<commands>` in a single `add_custom_command(TARGET .. COMMANDS <commands>)` run out of order.
`add_custom_command(OUTPUT <file> ...)`, `add_custom_target()`, `add_dependency()` are not implemented.3.15.0Fred BaksikFred Baksikhttps://gitlab.kitware.com/cmake/cmake/-/issues/15902ExternalProject Module doesn't work with GHS Multi Generator and Git2019-04-15T10:52:27-04:00Kitware RobotExternalProject Module doesn't work with GHS Multi Generator and GitThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15902). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15902). Further discussion may take place here.3.15.0Fred BaksikFred Baksikhttps://gitlab.kitware.com/cmake/cmake/-/issues/20985Green Hills Multi Segmentation Fault since v3.18.02020-07-21T07:26:46-04:00Daniel HirtGreen Hills Multi Segmentation Fault since v3.18.0Hello all. When trying to generate a Multi project, I run into a segmentation fault:
```
# running cmake
$ gdb --args /opt/cmake-debug/bin/cmake -G"Green Hills MULTI" -Appc -DGHS_TOOLSET_ROOT=$(realpath ~/ghs/) ..
# segfault
Program r...Hello all. When trying to generate a Multi project, I run into a segmentation fault:
```
# running cmake
$ gdb --args /opt/cmake-debug/bin/cmake -G"Green Hills MULTI" -Appc -DGHS_TOOLSET_ROOT=$(realpath ~/ghs/) ..
# segfault
Program received signal SIGSEGV, Segmentation fault.
cmGhsMultiTargetGenerator::WriteSources (this=this@entry=0x7fffffffc530, fout_proj=...)
at /home/danielh/git/cmake/Source/cmGhsMultiTargetGenerator.cxx:553
553 bool useProjectFile = cmIsOn(*this->GeneratorTarget->GetProperty(
# source:
551 for (auto& sg : groupFilesList) {
552 std::ostream* fout;
553 bool useProjectFile = cmIsOn(*this->GeneratorTarget->GetProperty(
554 "GHS_NO_SOURCE_GROUP_FILE")) ||
555 cmIsOn(this->Makefile->GetDefinition("CMAKE_GHS_NO_SOURCE_GROUP_FILE"))
556 if (useProjectFile || sg.empty()) {
557 fout = &fout_proj;
558 } else {
559 // Open the filestream in copy-if-different mode.
560 std::string gname = sg;
561 cmsys::SystemTools::ReplaceString(gname, "\\", "_");
562 std::string lpath = cmStrCat(
563 this->LocalGenerator->GetTargetDirectory(this->GeneratorTarget), '/',
564 gname, cmGlobalGhsMultiGenerator::FILE_EXTENSION);
```
This is apparently fixed in `master`. However, I see that a related MR is marked for `3.19`.
Is it possible to include those fixes in `3.18.1`?
Admittedly, I haven't pinpointed the fixing commits, so if they are actually intended for `3.18.1`, then disregard this issue :)
Best,
Danny3.18.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25737GHS: custom_command with multiple outputs executes multiple times2024-03-04T16:17:27-05:00William SciaroniGHS: custom_command with multiple outputs executes multiple times# Background
- Using CMake with the `Green Hills MULTI" generator
With the following configuration:
```cmake
cmake_minimum_required(VERSION 3.27)
project(Example LANGUAGES CXX)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/...# Background
- Using CMake with the `Green Hills MULTI" generator
With the following configuration:
```cmake
cmake_minimum_required(VERSION 3.27)
project(Example LANGUAGES CXX)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/one.cpp ${CMAKE_CURRENT_BINARY_DIR}/two.cpp
COMMAND touch ${CMAKE_CURRENT_BINARY_DIR}/one.cpp ${CMAKE_CURRENT_BINARY_DIR}/two.cpp
COMMENT "GENERATING one.cpp and two.cpp"
)
add_library(SomeLib ${CMAKE_CURRENT_BINARY_DIR}/one.cpp ${CMAKE_CURRENT_BINARY_DIR}/two.cpp)
```
The generation output is similar to the following
```log
Building ALL_BUILD.tgt.gpj
Processing Custom Rule SomeLib_cc0_one.cpp.rule.sh because one.cpp does not exist
GENERATING one.cpp and two.cpp
Processing Custom Rule SomeLib_cc0_one.cpp.rule.sh because two.cpp does not exist
GENERATING one.cpp and two.cpp
Compiling one.cpp because it has changed
Compiling two.cpp because it has changed
Archiving libSomeLib.a because two.o has changed
Done
```https://gitlab.kitware.com/cmake/cmake/-/issues/25647GHS: CMake 3.22.1 - Projects targeting INTEGRITY are generated incorrectly2024-02-01T09:49:41-05:00JonGHS: CMake 3.22.1 - Projects targeting INTEGRITY are generated incorrectly`/usr/ghs/installed_version_of_INTEGRITY` is added to the generated gpj which is not an accepted statement in the gpj file, resulting in generating unusable project files. (should instead be the value provided by the flag `-os_dir`) The ...`/usr/ghs/installed_version_of_INTEGRITY` is added to the generated gpj which is not an accepted statement in the gpj file, resulting in generating unusable project files. (should instead be the value provided by the flag `-os_dir`) The way that MULTI's new project wizard creats gpjs is that `OS_DIR` gets defined by a macro in the top-level GPJ, and the flag `-os_dir` is set to the macro.https://gitlab.kitware.com/cmake/cmake/-/issues/25171FetchContent: fails with GHS to populate a repository due to shell syntax2023-08-16T09:46:50-04:00William SciaroniFetchContent: fails with GHS to populate a repository due to shell syntax# Background
This behavior is observed on CMake 3.26.4
## The config
```CMake
include(FetchContent)
FetchContent_Declare(
depname
GIT_REPOSITORY git@gitpath:/some/depname.git
GIT_TAG 1.0
)
FetchContent_MakeAvailable(depname)
```...# Background
This behavior is observed on CMake 3.26.4
## The config
```CMake
include(FetchContent)
FetchContent_Declare(
depname
GIT_REPOSITORY git@gitpath:/some/depname.git
GIT_TAG 1.0
)
FetchContent_MakeAvailable(depname)
```
# The Result
This generates a subbuild for the `depname` including a script that actually does the clone.
depname-populate_cc1_depname-populate-download.rule.sh
```sh
echo Performing download step (git clone) for 'depname-populate'
if [ ...
```
The problem is that this echo command uses invalid syntax. This results in a configure error that the project fails to populate because:
```sh
/path/to/depname-populate_cc1_depname-populate-download.rule.sh: line 1: syntax error near unexpected token `('
/path/to/depname-populate_cc1_depname-populate-download.rule.sh: line 1: 'echo Performing download step (git clone) for 'depname-populate''
```
This occurs on Linux and appears to be generator specific.https://gitlab.kitware.com/cmake/cmake/-/issues/23252GHS: CMake build job control uses incorrect command line2022-03-21T14:36:45-04:00Fred BaksikGHS: CMake build job control uses incorrect command lineAs mentioned here https://gitlab.kitware.com/cmake/cmake/-/merge_requests/1962#note_400261, `gbuild` command line is "-parallel[=n]".As mentioned here https://gitlab.kitware.com/cmake/cmake/-/merge_requests/1962#note_400261, `gbuild` command line is "-parallel[=n]".Fred BaksikFred Baksikhttps://gitlab.kitware.com/cmake/cmake/-/issues/22882GHS: ar.exe can't handle backslashes in rsp files2021-11-10T07:16:08-05:00Tatiana BorisovaGHS: ar.exe can't handle backslashes in rsp filesI am compiling Qt6 source code with CMake 3.22 -DNinja and GHS compiler on WINDOWS OS.
Qt is recommending to use Ninja build system for building Qt6 source code (officially supported).
But there is an issue connected with following pro...I am compiling Qt6 source code with CMake 3.22 -DNinja and GHS compiler on WINDOWS OS.
Qt is recommending to use Ninja build system for building Qt6 source code (officially supported).
But there is an issue connected with following problem: "ar.exe can't handle backslashes in rsp files"
It is already fixed for GCC on WINDOWS (like here https://gitlab.kitware.com/cmake/cmake/-/blob/v3.18.1/Source/cmNinjaNormalTargetGenerator.cxx#L724-728)
But GHS compiler for WINDOWS has the same trouble in case of using Ninja build system and CMake's Ninja generator.
Generated paths inside *.rsp file have backslashes which cannot be handled by ar.exe:
[284/1083] Linking CXX static library qtbase\lib\libQt6Core.a
FAILED: qtbase/lib/libQt6Core.a qtbase/src/corelib/Core.version C:/Users/taboriso/targetbuild/qtbase/src/corelib/Core.version
cmd.exe /C "cmd.exe /C "cd /D C:\Users\taboriso\qt5\qtbase\src\corelib && "C:\Program Files\Git\usr\bin\perl.exe" C:/Users/taboriso/qt5/qtbase/mkspecs/features/data/unix/findclasslist.pl < C:/Users/taboriso/targetbuild/qtbase/src/corelib/Core.version.in > C:/Users/taboriso/targetbuild/qtbase/src/corelib/Core.version && cd C:\Users\taboriso\targetbuild" && "C:\Program Files\CMake\bin\cmake.exe" -E rm -f qtbase\lib\libQt6Core.a && C:\Qt\Tools\mingw810_64\bin\ar.exe qc qtbase\lib\libQt6Core.a @CMakeFiles\Core.rsp && C:\Qt\Tools\mingw810_64\bin\ranlib.exe qtbase\lib\libQt6Core.a && cd ."
C:\Qt\Tools\mingw810_64\bin\ar.exe: qtbasesrccorelibCMakeFilesCore.dirCore_autogenmocs_compilation.cpp.o: No such file or directory
ninja: build stopped: subcommand failed.
But GHS compiler problem can be easy fixed in the same way like it was fixed for GCC on WIN:
```
diff --git a/Source/cmGlobalNinjaGenerator.cxx b/Source/cmGlobalNinjaGenerator.cxx
index d5b5eb0e4c..38f6a971e7 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -180,7 +180,7 @@ std::string cmGlobalNinjaGenerator::EncodePath(const std::string& path)
{
std::string result = path;
#ifdef _WIN32
- if (this->IsGCCOnWindows())
+ if (this->IsGCCOnWindows() || this->UsingGHSOnWindows)
std::replace(result.begin(), result.end(), '\\', '/');
else
std::replace(result.begin(), result.end(), '/', '\\');
@@ -941,6 +941,9 @@ void cmGlobalNinjaGenerator::EnableLanguage(
cmHasLiteralSuffix(compilerId, "Clang")))) {
this->UsingGCCOnWindows = true;
}
+ else if(compilerId == "GHS") {
+ this->UsingGHSOnWindows = true;
+ }
#endif
}
}
diff --git a/Source/cmGlobalNinjaGenerator.h b/Source/cmGlobalNinjaGenerator.h
index ec73475db5..a8b5f47f1a 100644
--- a/Source/cmGlobalNinjaGenerator.h
+++ b/Source/cmGlobalNinjaGenerator.h
@@ -540,6 +540,7 @@ private:
std::unordered_map<std::string, int> RuleCmdLength;
bool UsingGCCOnWindows = false;
+ bool UsingGHSOnWindows = false;
/// The set of custom command outputs we have seen.
std::set<std::string> CustomCommandOutputs;
```
Maybe fix can be used?
Just wish to notify about problem existence and propose a fix as soon as CMake + Ninja + GHS + WIN failing for now.https://gitlab.kitware.com/cmake/cmake/-/issues/22169Green Hills MULTI issue with external project - primaryTarget=arm_.tgt2022-12-12T23:54:54-05:00Andrey BorisovGreen Hills MULTI issue with external project - primaryTarget=arm_.tgtHi, I try to make green hill project file using cmake.
My project contains fetching of google test (I know that google test doesn't support GHS compiler, but I expect to get at least project file itself).
Cmake command string is
`cmake ...Hi, I try to make green hill project file using cmake.
My project contains fetching of google test (I know that google test doesn't support GHS compiler, but I expect to get at least project file itself).
Cmake command string is
`cmake -G "Green Hills MULTI" -DGHS_PRIMARY_TARGET=arm_standalone.tgt ..`
in build folder.
Google tests are included as:
```cmake
include(FetchContent)
FetchContent_Declare(
googletest
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG release-1.10.0
)
FetchContent_GetProperties(googletest)
if(NOT googletest_POPULATED)
FetchContent_Populate(googletest)
set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
set(GHS_PRIMARY_TARGET "arm_standalone.tgt" CACHE INTERNAL "Use GHS target" FORCE)
add_subdirectory(${googletest_SOURCE_DIR} ${googletest_BINARY_DIR} EXCLUDE_FROM_ALL)
endif()
```
But as a result the file `build\_deps\googletest-subbuild\googletest-populate.top.gpj` has a string:
`8: primaryTarget=arm_.tgt`
I have found that this string is assembled in Source\cmGlobalGhsMultiGenerator.cxx (649):
```
fout << "primaryTarget=" << tgt << "\n"
"customization=" << root->GetBinaryDirectory()
<< "/CMakeFiles/custom_rule.bod\n"
"customization=" << root->GetBinaryDirectory()
<< "/CMakeFiles/custom_target.bod" << '\n';
```
and tgt is formed from GHS_PRIMARY_TARGET or from CMAKE_GENERATOR_PLATFORM and GHS_TARGET_PLATFORM
When I change in this expression tgt to "arm_standalone.tgt" cmake creates the GHS project well.
It looks like in one of the run of this code the tgt is lost or some of the GHS constants is lost.Fred BaksikFred Baksikhttps://gitlab.kitware.com/cmake/cmake/-/issues/19785GHS: CMake testing exercises GHS generator differently from how the other gen...2021-11-30T10:40:27-05:00Fred BaksikGHS: CMake testing exercises GHS generator differently from how the other generators get exercisedThe way that CMake testing is setup it exercises CMake and a generator based on how CMake itself was built. Since GHS is essentially a cross compiler it is never used for building CMake and there are only a few tests that get run when t...The way that CMake testing is setup it exercises CMake and a generator based on how CMake itself was built. Since GHS is essentially a cross compiler it is never used for building CMake and there are only a few tests that get run when the GHS generator is active. Most of the tests are run when a different generator is being used.
Now that GHS generator supports custom targets and commands GHS generator can support a much larger set of the standard tests that are run for each generator. Some of the standard tests may need be updated to pass in GHS specific settings to work. Other tests may need to be bypassed as they may not make much sense or won't work because they use third party libraries that are not available in a cross-target environment.Fred BaksikFred Baksikhttps://gitlab.kitware.com/cmake/cmake/-/issues/19743GHS-MULTI: Enable compiler with Ninja and Makefile generators2022-09-24T07:34:23-04:00Brad KingGHS-MULTI: Enable compiler with Ninja and Makefile generatorsAccording to https://gitlab.kitware.com/cmake/cmake/merge_requests/3839#note_629414 it is possible to use these generators with the GHS compiler by always passing `-bsp ...` and `-os_dir ...` arguments. We have other platforms where we ...According to https://gitlab.kitware.com/cmake/cmake/merge_requests/3839#note_629414 it is possible to use these generators with the GHS compiler by always passing `-bsp ...` and `-os_dir ...` arguments. We have other platforms where we add necessary arguments to compilers automatically based on configurable settings rather than asking users to pass flags themselves. We should consider doing that for GHS-MULTI too.
It could be done in `Modules/Platform/GHS-MULTI-GHS-{C,CXX}.cmake` modules.Fred BaksikFred Baksikhttps://gitlab.kitware.com/cmake/cmake/-/issues/18772GHS: Integrity Applications should not use C / CXX language flags2019-01-09T12:00:20-05:00Fred BaksikGHS: Integrity Applications should not use C / CXX language flagsIntegrity Applications are implemented as an executable. They take other executable targets and bundles them together using an integrate file. It requires the ability of setting options to the integrate tool. But it shouldn't follow t...Integrity Applications are implemented as an executable. They take other executable targets and bundles them together using an integrate file. It requires the ability of setting options to the integrate tool. But it shouldn't follow the conventions of being a `C` / `CXX` application.Fred BaksikFred Baksikhttps://gitlab.kitware.com/cmake/cmake/-/issues/18752GHS - Transitive Link Libraries2019-01-18T08:42:32-05:00Matt SoucyGHS - Transitive Link LibrariesWhen testing GHS support in v3.13.0, I discovered that transitive link libraries are not put into the .gpj file.When testing GHS support in v3.13.0, I discovered that transitive link libraries are not put into the .gpj file.Fred BaksikFred Baksikhttps://gitlab.kitware.com/cmake/cmake/-/issues/18128[Green Hills Multi] Can't set CMAKE_C_COMPILER or CMAKE_CXX_COMPILER2019-01-05T00:49:25-05:00Shahzeb Ihsan[Green Hills Multi] Can't set CMAKE_C_COMPILER or CMAKE_CXX_COMPILERI fully understand that this is an experimental generator, but I was trying to evaluate CMake to directly generate a sample GHS project instead of generating, for instance, MINGW make files.
I tried setting environment variables "CC" an...I fully understand that this is an experimental generator, but I was trying to evaluate CMake to directly generate a sample GHS project instead of generating, for instance, MINGW make files.
I tried setting environment variables "CC" and "CXX" and also tried to set "CMAKE_C_COMPILER" and "CMAKE_CXX_COMPILER" in CMakeLists.txt but in both cases I get the same error:
> **CMake Error at CMakeLists.txt:6 (project):
> The CMAKE_C_COMPILER:
>
> /ccarm.exe
>
> is not a full path to an existing compiler tool.
>
> Tell CMake where to find the compiler by setting either the environment
> variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
> the compiler, or to the compiler name if it is in the PATH.
>
>
> CMake Error at CMakeLists.txt:6 (project):
> The CMAKE_CXX_COMPILER:
>
> /cxarm.exe
>
> is not a full path to an existing compiler tool.
>
> Tell CMake where to find the compiler by setting either the environment
> variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
> to the compiler, or to the compiler name if it is in the PATH.**
And this seems to happen only if I use the GHS generator.https://gitlab.kitware.com/cmake/cmake/-/issues/18051Difference between gpj file generation on windows and Linux machine2019-01-18T08:46:35-05:00Yancho TsikovDifference between gpj file generation on windows and Linux machineUsing CMake 3.7 on Windows 7 and Ubuntu 18.04. with GHS MULTI Generator.
Debug tools on Windows 7: Visual Studio 2017 and Qt Creator 4.2.0/Based on Qt 5.7.1(MSVC 2015,32 bit)
Debug tools on Linux: Qt Creator 4.5.2/Based on Qt 5.9.5(GCC 7...Using CMake 3.7 on Windows 7 and Ubuntu 18.04. with GHS MULTI Generator.
Debug tools on Windows 7: Visual Studio 2017 and Qt Creator 4.2.0/Based on Qt 5.7.1(MSVC 2015,32 bit)
Debug tools on Linux: Qt Creator 4.5.2/Based on Qt 5.9.5(GCC 7.3.0 64 bit)
Hello
I'm working on project, where is using CMAKE to generate gpj files on Windows and Linux machine.
I found out, that gpj files are filling in different order on both machines.
For example:
On Windows machine:
-AAA [Program]
-BBB [Program]
-CCC [Program]
-DDD [INTEGRITY Application]
-EEE [Program]
-FFF [Program]
-III [Program]
-JJJ [Program]
-KKK [Library]
-LLL [Library]
-MMM [Library]
On Linux machine:
-AAA [Program]
-BBB [Program]
-CCC [Program]
-DDD [Program]
-KKK [Library]
-GGG [Program]
-DDD [INTEGRITY Application]
-LLL[Library]
-FFF [Program]
-MMM [Program]
-HHH [Program]
-KKK [Program]
In follow example you can see order on windows machine is quite different than Linux machine and for example [INTEGRITY Application] is on 4-position on Win and 7-th position on Linux.
After debugging CMAKE on my project, I found out in file cmMakefile.cxx in function AddNewTarget is fill all Targets:
cmTarget* cmMakefile::AddNewTarget(cmState::TargetType type,
const std::string& name)
{
cmTargets::iterator it =
this->Targets
.insert(cmTargets::value_type(
name, cmTarget(name, type, cmTarget::VisibilityNormal, this)))
.first;
this->GetGlobalGenerator()->IndexTarget(&it->second);
this->GetStateSnapshot().GetDirectory().AddNormalTargetName(name);
return &it->second;
}
The ordering of files is done by function insert, which for different mashine call different file.
On Window machine is calling xhash file(C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include), where the targets are place in correct order FIFO(first in , first out into gpj file)
On Linux machine is calling move.h (/usr/include/c++/7/bits/move.h),where the targets are place in random order.
I am expecting targets ordering on Linux to exact as Windows.
Do you have any suggestion or advice how to make window and Linux file alignment in gpj file to be a same?
Don't hesitate to contact, if you want any additional information or unclear points.
Thanks in advance.Fred BaksikFred Baksikhttps://gitlab.kitware.com/cmake/cmake/-/issues/16918GHS - Output directory should not be written for non-builtin filetypes2019-01-18T08:49:51-05:00Matt SoucyGHS - Output directory should not be written for non-builtin filetypesCurrently the `-object_dir` line is written after each source file. This causes problems for any custom filetypes, as at the very least they need to add a special handler in their `.bod` build customization files so that it swallows `-ob...Currently the `-object_dir` line is written after each source file. This causes problems for any custom filetypes, as at the very least they need to add a special handler in their `.bod` build customization files so that it swallows `-object_dir`.
Suggest changing it to only output that line for known languagesFred BaksikFred Baksikhttps://gitlab.kitware.com/cmake/cmake/-/issues/16911GHS - Multi7 and Integrity IOT compatability2024-02-01T09:21:08-05:00Fred BaksikGHS - Multi7 and Integrity IOT compatabilityOne of the features of Multi7 and GHS compilers 2015.1 and newer is that it allows for multiple configurations to be chosen to be built. For the BSP that I am using the choices are Debug / Checked / Release. This in turn picks which opt...One of the features of Multi7 and GHS compilers 2015.1 and newer is that it allows for multiple configurations to be chosen to be built. For the BSP that I am using the choices are Debug / Checked / Release. This in turn picks which option files to use and include in the top-level project. One of the items that is set is the build directory location and where object files are stored after generation. This conflicts with the current ``Green Hills MULTI`` generator that hard codes the object file output in the sub-projects.https://gitlab.kitware.com/cmake/cmake/-/issues/16908GHS - Unexpected Top-Level Project2022-02-18T19:03:02-05:00Fred BaksikGHS - Unexpected Top-Level ProjectI'm trying to use the ``Green Hills MULTI`` generator with Integrity178. I've never used regular Integrity so I don't know what the differences are. Trying to setup a hello world style project and I'm seeing some unexpected results. My...I'm trying to use the ``Green Hills MULTI`` generator with Integrity178. I've never used regular Integrity so I don't know what the differences are. Trying to setup a hello world style project and I'm seeing some unexpected results. My input file looks something like this:
<pre><code>project( test_system LANGUAGES C)
add_executable( test1
test.c
INTEGRITY.ld
)
add_executable( test_kernel
kernel.c
kernel.ld
)
add_executable( test_system
test_system.int
)
add_dependencies( test_system test1 test_kernel )</code></pre>
My first observation is that any target that includes a source of `*.int` will become an `[INTEGRITY Application]`. Is this the desired behavior? Secondly the top-level project and Integrity project files look like this:
<pre><code># Top Level Project File
[Project]
-os_dir="C:/ghs/int-mz-1501-richland-beta/rtos"
-bsp intel-gr
test1/test1.gpj [Program]
test_system/test_system.gpj [INTEGRITY Application]
test_kernel/test_kernel.gpj [Program]</code></pre>
<pre><code>[INTEGRITY Application]
-o "C:/Users/RTc/Documents/FBAK/test/Build/test/cmake/test_ApolloLake/test_system/test_system.elf"
:extraOutputFile="C:/Users/RTc/Documents/FBAK/test/Build/test/cmake/test_ApolloLake/test_system/test_system.elf.ael"
-L"C:/Users/RTc/Documents/FBAK/test/Build/test/cmake/test_ApolloLake/test1/"
-L"C:/Users/RTc/Documents/FBAK/test/Build/test/cmake/test_ApolloLake/test_kernel/"
C:/Users/RTc/Documents/FBAK/test/Source/test_system.int</code></pre>
Unfortunately this doesn't produce a working system as it has errors during the build phase. I was expecting to see something like this:
<pre><code># Top Level Project File
[Project]
-os_dir="C:/ghs/int-mz-1501-richland-beta/rtos"
-bsp intel-gr
test_system/test_system.gpj [INTEGRITY Application]</code></pre>
<pre><code>[INTEGRITY Application]
-o "C:/Users/RTc/Documents/FBAK/test/Build/test/cmake/test_ApolloLake/test_system/test_system.elf"
:extraOutputFile="C:/Users/RTc/Documents/FBAK/test/Build/test/cmake/test_ApolloLake/test_system/test_system.elf.ael"
C:/Users/RTc/Documents/FBAK/test/Source/test_system.int
test1/test1.gpj [Program]
test_kernel/test_kernel.gpj [Program]
</code></pre>
By manually editing these two file then the system finishes being built. I haven't created a more complicated scenario where the `intex` tool needs to produce header files for the kernel and applications. I don't think that the original results would run in the correct order for that. I would appreciate any insight into the situation.Fred BaksikFred Baksikhttps://gitlab.kitware.com/cmake/cmake/-/issues/16902GHS: Quoting issues when using target_compile_options() and add_custom_command()2022-07-21T18:54:36-04:00Fred BaksikGHS: Quoting issues when using target_compile_options() and add_custom_command()When using the command in the CMakeLists.txt file
> target_compile_options(my_target
BEFORE PRIVATE
:optionsFile=\${__OPTIONDEFS}/full_c_vas_program.opt
)
the generated output was
> :optionsFile=\$${__OPTIONDEFS}/full_c_vas_pro...When using the command in the CMakeLists.txt file
> target_compile_options(my_target
BEFORE PRIVATE
:optionsFile=\${__OPTIONDEFS}/full_c_vas_program.opt
)
the generated output was
> :optionsFile=\$${__OPTIONDEFS}/full_c_vas_program.opt
I was expecting it to be
>:optionsFile=${__OPTIONDEFS}/full_c_vas_program.opt
I traced to several lines of code in ``cmOutputConverter.cxx`` where it was performing ``Makefile`` quoting. I adapted the file to not perform any special quoting when using the GHS Multi generator.
#16488 Feature 4 and Feature 5 included patches for fixing `add_custom_command()`.Fred BaksikFred Baksik