Re: [cmake-developers] CMAKE :: mingw make files with response file for includes
On 04/11/2018 12:25 PM, Jayakumar, Lenindarbi wrote: > Is the below issue solved in latest release 3.11.0 ? > Could you please confirm? The fix discussed elsewhere in the thread: https://gitlab.kitware.com/cmake/cmake/merge_requests/1691 is in 3.11.0. The `@` is no longer hard coded. I think it should work now. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMAKE :: mingw make files with response file for includes
Hi Brad,
Is the below issue solved in latest release 3.11.0 ?
Could you please confirm?
Grüße
Lenin
-Original Message-
From: Jayakumar, Lenindarbi
Sent: Freitag, 19. Januar 2018 15:26
To: 'Brad King' ; cmake-developers@cmake.org
Subject: RE: [cmake-developers] CMAKE :: mingw make files with response file
for includes
Thanks for the reply.
It is not compiler and linker.
I have to use response file for both includes and objects.
Tasking compiler expects -f as Response file link flag for both. But cmake
produces command line for objects using -f and includes using @.
I prefer to get it fixed in generator. Unfortunately I don't have enough time
and experience.
Perhaps an cmake expert could confirm and fix it.
Possible cause:
The @ symbol is hardcoded in "cmMakefileTargetGenerator::AddIncludeFlags"
function in file ../Source/cmMakefileTargetGenerator.cxx
if (useResponseFile) {
std::string name = "includes_";
name += lang;
name += ".rsp";
std::string arg = "@" +
this->CreateResponseFile(name.c_str(), includeFlags,
this->FlagFileDepends[lang]);
this->LocalGenerator->AppendFlags(flags, arg);
}
However, the implementation should be like in
"cmMakefileTargetGenerator::CreateObjectLists" function.
// Lookup the response file reference flag.
std::string responseFlagVar = "CMAKE_";
responseFlagVar +=
this->GeneratorTarget->GetLinkerLanguage(this->ConfigName);
responseFlagVar += "_RESPONSE_FILE_LINK_FLAG";
const char* responseFlag = this->Makefile->GetDefinition(responseFlagVar);
if (!responseFlag) {
responseFlag = "@";
}
Thanks,
Lenin
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Freitag, 19. Januar 2018 15:01
To: Jayakumar, Lenindarbi
mailto:lenindarbi.jayaku...@magna.com>>;
cmake-developers@cmake.org
Subject: Re: [cmake-developers] CMAKE :: mingw make files with response file
for includes
On 01/17/2018 03:52 AM, Jayakumar, Lenindarbi wrote:
> Response file link flag "CMAKE_C_RESPONSE_FILE_LINK_FLAG" is not
> customizable for include paths.
> The @ symbol is hardcoded in "cmMakefileTargetGenerator::AddIncludeFlags"
In case the compiler and link driver want different response file flags, one
could add a separate "CMAKE__RESPONSE_FILE_COMPILE_FLAG" variable to use
for include flags. See
https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst
for contribution instructions if you'd like to work on it.
Thanks,
-Brad
--- Begin Message ---
Hello,
I have encountered a problem with response file usage for includes.
My project is using tasking compiler.
Issue:
Response file link flag "CMAKE_C_RESPONSE_FILE_LINK_FLAG" is not customizable
for include paths.
Cmake generated the *.rsp file always using @ but this is not accepted by
tasking compiler. Tasking compiler expects -f instead of @.
...
C_INCLUDES = @CMakeFiles/dummyTarget/includes_C.rsp
This issue is only with includes response file. For objects,
CMAKE_C_RESPONSE_FILE_LINK_FLAG works.
Project setup:
set(CMAKE_C_RESPONSE_FILE_LINK_FLAG "-f ")
set(CMAKE_C_USE_RESPONSE_FILE_FOR_OBJECTS 1)
set(CMAKE_C_USE_RESPONSE_FILE_FOR_INCLUDES 1)
Possible cause:
The @ symbol is hardcoded in "cmMakefileTargetGenerator::AddIncludeFlags"
function in file
https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmMakefileTargetGenerator.cxx.
if (useResponseFile) {
std::string name = "includes_";
name += lang;
name += ".rsp";
std::string arg = "@" +
this->CreateResponseFile(name.c_str(), includeFlags,
this->FlagFileDepends[lang]);
this->LocalGenerator->AppendFlags(flags, arg);
}
However, the implementation should be like in
"cmMakefileTargetGenerator::CreateObjectLists" function.
// Lookup the response file reference flag.
std::string responseFlagVar = "CMAKE_";
responseFlagVar +=
this->GeneratorTarget->GetLinkerLanguage(this->ConfigName);
responseFlagVar += "_RESPONSE_FILE_LINK_FLAG";
const char* responseFlag = this->Makefile->GetDefinition(responseFlagVar);
if (!responseFlag) {
responseFlag = "@";
}
Regards,
Lenindarbi Jayakumar
Software Engineer
Magna Electronics Europe GmbH & Co. OHG
Kurfürst-Eppstein-Ring 9
63877 Sailauf
OFFICE +49 6093 9942 6462
FAX +49 6093 9942 6001
MOBILE
lenindarbi.jayaku...@magna.com
http://www.magna.com
Re: [cmake-developers] Usage Requirements with Object Libraries
On 04/11/2018 10:48 AM, Gößwein Matthias / eeas gmbh wrote: > CMake Error: The inter-target dependency graph contains the following > strongly connected component (cycle): > "lib1" of type OBJECT_LIBRARY > depends on "lib2" (strong) > "lib2" of type OBJECT_LIBRARY > depends on "lib1" (weak) > At least one of these targets is not a STATIC_LIBRARY. Cyclic > dependencies are allowed only among static libraries. > > add_library(lib1 OBJECT lib1.c) > target_link_libraries(lib1 PUBLIC lib2) > add_library(lib2 OBJECT lib2.c) > target_link_libraries(lib2 PUBLIC lib1) > > Is it possible to implement the same thing for object libraries too For reference, the documentation of tll behavior for object libraries is here: https://cmake.org/cmake/help/git-master/command/target_link_libraries.html#linking-object-libraries It states that "linking" object libraries to each other only propagates usage requirements and does nothing special with the object files. If there are dependencies like this then consumers would need to list both object libraries together. All object files would be listed once on the link line and no repetition would be needed since explicitly listing them guarantees they are linked. Likely this will be okay. However, I'd like to avoid supporting the case until we gain more experience with the current design. I've opened an issue to track it here: * OBJECT library circular target_link_libraries https://gitlab.kitware.com/cmake/cmake/issues/17905 Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
[cmake-developers] Usage Requirements with Object Libraries
Hello, Right now I'm using a nightly build (3.11.20180407-g268d0) to use and test the Usage Requirements with Object Libraries, which is planned for CMake 3.12.0 (https://gitlab.kitware.com/cmake/cmake/issues/14778) It's working great so far, but I if i have a construct of two object libraries, which depend in some way of each other I get an error message: CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle): "lib1" of type OBJECT_LIBRARY depends on "lib2" (strong) "lib2" of type OBJECT_LIBRARY depends on "lib1" (weak) At least one of these targets is not a STATIC_LIBRARY. Cyclic dependencies are allowed only among static libraries. CMakeLists.txt: add_library(lib1 OBJECT lib1.c) target_link_libraries(lib1 PUBLIC lib2) add_library(lib2 OBJECT lib2.c) target_link_libraries(lib2 PUBLIC lib1) If i use Static libraries, then it works (in fact even if only one library is an object library it fails). Is it possible to implement the same thing for object libraries too, or are there some technical restrictions? In the past i had sometimes such cyclic dependencies with legacy code and i think it would be great if it is possible to support such dependencies with object libraries as well. Best regards, Matthias Goesswein. -- matthias.goessw...@eeas.at /mail www.eeas.at /web +43 660 1280 131 /phone -- eeas gmbh Technologiepark 17 4320 Perg Austria -- ATU67456549 /uid FN385458a /firmenbuchnummer landesgericht linz /firmenbuch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
