[cmake-developers] [patch] handle RC files as resources
hi all,
i've came across, that .rc files are treated as windows resources, but
not upper-case .RC files. attached patch tries to correct this. it is a
functional change, though it brings the implementation in line with
Modules/CMakeCXXCompiler.cmake.in and the like.
would be great if someone could review and/or commit it.
thanks a lot,
tim
From 0e41cb7df9dcb2587d928504c042a8ed0b51bc39 Mon Sep 17 00:00:00 2001
From: Tim Blechmann t...@klingt.org
Date: Fri, 6 Jun 2014 09:59:33 +0200
Subject: [PATCH] SystemTools: handle RC as resource file format extension
.RC files are not recorgnized as resource files by GetFileFormat, though
the CMakeLangCompiler.cmake.in files list this file extension:
Modules/CMakeCXXCompiler.cmake.in:
set(CMAKE_CXX_IGNORE_EXTENSIONS inl;h;hpp;HPP;H;o;O;obj;OBJ;def;DEF;rc;RC)
this patch resolve this inconsistency
Signed-off-by: Tim Blechmann t...@klingt.org
---
Source/cmSystemTools.cxx | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index ff05975..4b91aaa 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -1222,7 +1222,8 @@ cmSystemTools::FileFormat
cmSystemTools::GetFileFormat(const char* cext)
ext == in || ext == .in ||
ext == txx || ext == .txx
) { return cmSystemTools::HEADER_FILE_FORMAT; }
- if ( ext == rc || ext == .rc )
+ if ( ext == rc || ext == .rc ||
+ ext == RC || ext == .RC)
{ return cmSystemTools::RESOURCE_FILE_FORMAT; }
if ( ext == def || ext == .def )
{ return cmSystemTools::DEFINITION_FILE_FORMAT; }
--
2.0.0
--
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:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [patch] handle RC files as resources
On 06/06/2014 04:16 AM, Tim Blechmann wrote: i've came across, that .rc files are treated as windows resources, but not upper-case .RC files. attached patch tries to correct this. it is a functional change, though it brings the implementation in line with Modules/CMakeCXXCompiler.cmake.in and the like. would be great if someone could review and/or commit it. The cmSystemTools::GetFileFormat is supposed to have been replaced by cmSourceFile::GetLanguage and cmGeneratorTarget source classification logic that uses the tables like that in CMakeCXXCompiler. The only cmSystemTools::GetFileFormat call site I see left is in cmQtAutoGenerators::SetupSourceFiles, and that does not care about RESOURCE_FILE_FORMAT. In what context does your patch affect anything? 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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [patch] handle RC files as resources
i've came across, that .rc files are treated as windows resources, but not upper-case .RC files. attached patch tries to correct this. it is a functional change, though it brings the implementation in line with Modules/CMakeCXXCompiler.cmake.in and the like. would be great if someone could review and/or commit it. The cmSystemTools::GetFileFormat is supposed to have been replaced by cmSourceFile::GetLanguage and cmGeneratorTarget source classification logic that uses the tables like that in CMakeCXXCompiler. The only cmSystemTools::GetFileFormat call site I see left is in cmQtAutoGenerators::SetupSourceFiles, and that does not care about RESOURCE_FILE_FORMAT. In what context does your patch affect anything? hmmm, then this probably got shadowed in my project when setting the source file language directly :/ does this look better? (cannot test atm, as i'm on a different machine) thx, tim From e42b5ee3979c0b2e9b72d737c858830a865174ca Mon Sep 17 00:00:00 2001 From: Tim Blechmann t...@klingt.org Date: Fri, 6 Jun 2014 15:47:29 +0200 Subject: [PATCH] CMakeRCCompiler: handle RC as resource file format extension .RC files are not recorgnized as resource files by GetFileFormat, though the CMakeLangCompiler.cmake.in files list this file extension: Modules/CMakeCXXCompiler.cmake.in: set(CMAKE_CXX_IGNORE_EXTENSIONS inl;h;hpp;HPP;H;o;O;obj;OBJ;def;DEF;rc;RC) this patch resolve this inconsistency Signed-off-by: Tim Blechmann t...@klingt.org --- Modules/CMakeRCCompiler.cmake.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Modules/CMakeRCCompiler.cmake.in b/Modules/CMakeRCCompiler.cmake.in index 0fc3142..8257cd6 100644 --- a/Modules/CMakeRCCompiler.cmake.in +++ b/Modules/CMakeRCCompiler.cmake.in @@ -1,6 +1,6 @@ set(CMAKE_RC_COMPILER @CMAKE_RC_COMPILER@) set(CMAKE_RC_COMPILER_ARG1 @CMAKE_RC_COMPILER_ARG1@) set(CMAKE_RC_COMPILER_LOADED 1) -set(CMAKE_RC_SOURCE_FILE_EXTENSIONS rc) +set(CMAKE_RC_SOURCE_FILE_EXTENSIONS rc;RC) set(CMAKE_RC_OUTPUT_EXTENSION @CMAKE_RC_OUTPUT_EXTENSION@) set(CMAKE_RC_COMPILER_ENV_VAR RC) -- 2.0.0 -- 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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH 1/2] cmComputeLinkInformation: Don't add build dependencies on IMPORTED libraries
For IMPORTED libraries we treat those like INTERFACE libraries. The actual target for an IMPORTED library is not generated. This would have normally resulted in the passing of the path to the IMPORTED library as a dependency which works in some, but not all cases, because the path is not guaranteed to be absolute. In particular, it fails on the Ninja generator. The solution is just not to add dependencies on such libraries, as any dependencies of the IMPORTED target itself will be added as dependencies of targets depending on the IMPORTED target. Added ImportedExternalProjectLibrary, which builds a library in a sister subdirectory to an executable as an external project, the alternate sister subdirectory adding the library as an IMPORTED library depending on the external project and linking to it. Fixes #13574. --- Source/cmComputeLinkInformation.cxx | 4 ++-- Tests/CMakeLists.txt| 1 + Tests/ImportedExternalProjectLibrary/CMakeLists.txt | 5 + .../ImportedExternalProjectLibraryDir/CMakeLists.txt| 3 +++ .../ImportedExternalProjectLibrary.c| 6 ++ .../LibrarySubdir/CMakeLists.txt| 17 + .../ProjectWithImportedLibrary/CMakeLists.txt | 4 .../LibrarySubdir/ProjectWithImportedLibrary/library.c | 4 8 files changed, 42 insertions(+), 2 deletions(-) create mode 100644 Tests/ImportedExternalProjectLibrary/CMakeLists.txt create mode 100644 Tests/ImportedExternalProjectLibrary/ImportedExternalProjectLibraryDir/CMakeLists.txt create mode 100644 Tests/ImportedExternalProjectLibrary/ImportedExternalProjectLibraryDir/ImportedExternalProjectLibrary.c create mode 100644 Tests/ImportedExternalProjectLibrary/LibrarySubdir/CMakeLists.txt create mode 100644 Tests/ImportedExternalProjectLibrary/LibrarySubdir/ProjectWithImportedLibrary/CMakeLists.txt create mode 100644 Tests/ImportedExternalProjectLibrary/LibrarySubdir/ProjectWithImportedLibrary/library.c -- Sam Spilsbury 0001-cmComputeLinkInformation-Don-t-add-build-dependencie.patch Description: Binary data -- 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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH 2/2] Ninja: Fix failing CMakeLib.testRST test
Ninja was passing a relative path to the compiler which causes __FILE__ to use that same relative path. This was causing the test to fail, because Ninja is not a recursive generator and so __FILE__ differed between generators. For the sake of consistency, an absolute path should always be passed to the compiler on each generator, so that __FILE__ is always consistent. --- Source/cmNinjaTargetGenerator.cxx | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) -- Sam Spilsbury 0002-Ninja-Fix-failing-CMakeLib.testRST-test.patch Description: Binary data -- 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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [patch] handle RC files as resources
On 06/06/2014 09:48 AM, Tim Blechmann wrote: does this look better? Yes. Applied: CMakeRCCompiler: Handle uppercase 'RC' as resource file format extension http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=514c2e3d 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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 2/2] Ninja: Fix failing CMakeLib.testRST test
On 06/06/2014 10:12 AM, Sam Spilsbury wrote: Ninja was passing a relative path to the compiler which causes __FILE__ to use that same relative path. This was causing the test to fail, because Ninja is not a recursive generator and so __FILE__ differed between generators. For the sake of consistency, an absolute path should always be passed to the compiler on each generator, so that __FILE__ is always consistent. This is a larger debate for those that develop and use the Ninja generator. For now let's just fix the test to not depend on a full path to __FILE__: Tests: Fix CMakeLib.testRST for relative __FILE__ http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=218699eb -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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 2/2] Ninja: Fix failing CMakeLib.testRST test
On Fri, Jun 6, 2014 at 10:49 PM, Brad King brad.k...@kitware.com wrote: On 06/06/2014 10:12 AM, Sam Spilsbury wrote: Ninja was passing a relative path to the compiler which causes __FILE__ to use that same relative path. This was causing the test to fail, because Ninja is not a recursive generator and so __FILE__ differed between generators. For the sake of consistency, an absolute path should always be passed to the compiler on each generator, so that __FILE__ is always consistent. This is a larger debate for those that develop and use the Ninja generator. For now let's just fix the test to not depend on a full path to __FILE__: Are there any threads where I can read up on background information for this? Having consistency seems like a no-brainer to me, so perhaps I missed something? Briefly reading[1], it seems like the Chromium developers are preferring consistency between generator backends. Sam. [1] https://code.google.com/p/chromium/issues/detail?id=326030 Tests: Fix CMakeLib.testRST for relative __FILE__ http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=218699eb -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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Sam Spilsbury -- 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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 1/2] cmComputeLinkInformation: Don't add build dependencies on IMPORTED libraries
On 06/06/2014 10:11 AM, Sam Spilsbury wrote:
The solution is just not to add dependencies on such libraries, as any
dependencies of the IMPORTED target itself will be added as
dependencies of targets depending on the IMPORTED target.
There are no build rules for imported targets so they have no
dependencies anyway. The patch in question:
// Pass the full path to the target file.
std::string lib = tgt-GetFullPath(config, implib, true);
- if(!this-LinkDependsNoShared ||
- tgt-GetType() != cmTarget::SHARED_LIBRARY)
+ if((!this-LinkDependsNoShared ||
+ tgt-GetType() != cmTarget::SHARED_LIBRARY) !tgt-IsImported())
{
this-Depends.push_back(lib);
}
touches code used to generate dependencies on a link rule.
If link rules do not depend on imported libraries then they
will not re-link when those libraries change on disk. This
is incorrect.
Fixes #13574.
All generators except Ninja are able to deal with this correctly.
The place to fix it must be in the Ninja generator.
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:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja generator and __FILE__ (was: Ninja: Fix failing CMakeLib.testRST test)
On 06/06/2014 10:53 AM, Sam Spilsbury wrote: On Fri, Jun 6, 2014 at 10:49 PM, Brad King brad.k...@kitware.com wrote: On 06/06/2014 10:12 AM, Sam Spilsbury wrote: For the sake of consistency, an absolute path should always be passed to the compiler on each generator, so that __FILE__ is always consistent. This is a larger debate for those that develop and use the Ninja generator. Are there any threads where I can read up on background information for this? Having consistency seems like a no-brainer to me, so perhaps I missed something? Briefly reading[1], it seems like the Chromium developers are preferring consistency between generator backends. [1] https://code.google.com/p/chromium/issues/detail?id=326030 This appears to be a result of using command = ... -c $in as the compilation rule so that the dependency path and the path given to the compiler on the command line are the same. In order to always pass a full path to the compiler then either ninja would have to do it when constructing the command or the generated rule would have to separately pass in the path to the source. I'm not familiar enough with the ninja tool or the CMake Ninja generator to say more. -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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 1/2] cmComputeLinkInformation: Don't add build dependencies on IMPORTED libraries
On Fri, Jun 6, 2014 at 10:55 PM, Brad King brad.k...@kitware.com wrote:
On 06/06/2014 10:11 AM, Sam Spilsbury wrote:
The solution is just not to add dependencies on such libraries, as any
dependencies of the IMPORTED target itself will be added as
dependencies of targets depending on the IMPORTED target.
There are no build rules for imported targets so they have no
dependencies anyway. The patch in question:
// Pass the full path to the target file.
std::string lib = tgt-GetFullPath(config, implib, true);
- if(!this-LinkDependsNoShared ||
- tgt-GetType() != cmTarget::SHARED_LIBRARY)
+ if((!this-LinkDependsNoShared ||
+ tgt-GetType() != cmTarget::SHARED_LIBRARY) !tgt-IsImported())
{
this-Depends.push_back(lib);
}
touches code used to generate dependencies on a link rule.
If link rules do not depend on imported libraries then they
will not re-link when those libraries change on disk. This
is incorrect.
I'm confused as to what you mean by this. All this change does is
causes a dependency on an imported library not to be added. It doesn't
change the situation when imported libraries are not in use, as those
libraries will be added as dependencies.
The only potential side effect is that there will be no re-linking
where an imported library changes on disk outside the project. I can
see how this is potentially a bad thing, though I am not sure if it
was a design goal of imported libraries.
Fixes #13574.
All generators except Ninja are able to deal with this correctly.
The place to fix it must be in the Ninja generator.
It isn't clear to me how this can be fixed locally.
cmNinjaTargetGenerator::ComputeLinkDeps() gets a list of dependencies
from cmComputeLinkInformation directly. We can't query whether or not
a dependency was an imported target and should be disregarded because
it has already been converted to a string at that point.
Something that did occur to me while I was testing this was that
adding an IMPORTED library to something inside of an external project
inside the same subdirectory as the target seeking to depend on the
IMPORTED library didn't cause any problems for the generator, but
placing it in a sibling subdirectory with the IMPORTED library being
marked GLOBAL did cause the bug in question. Perhaps its a problem
with relative path usage? I'll have to continue investigating.
Sam.
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:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--
Sam Spilsbury
--
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:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 1/2] cmComputeLinkInformation: Don't add build dependencies on IMPORTED libraries
On 06/06/2014 11:09 AM, Sam Spilsbury wrote: The only potential side effect is that there will be no re-linking where an imported library changes on disk outside the project. I can see how this is potentially a bad thing, though I am not sure if it was a design goal of imported libraries. It would be a bad thing to drop such dependencies and they are an explicit design goal for imported libraries. It isn't clear to me how this can be fixed locally. cmNinjaTargetGenerator::ComputeLinkDeps() gets a list of dependencies from cmComputeLinkInformation directly. We can't query whether or not a dependency was an imported target and should be disregarded because it has already been converted to a string at that point. If a path comes out of cmComputeLinkInformation then the generator must provide a dependency on it. It is not up to the generator to decide whether a particular dependency is worthwhile or not. The VS, Xcode, and Makefile generators all work correctly. The Ninja generator must find a way to do it. It is undefined behavior for an IMPORTED_LOCATION to be a relative path, so all dependencies coming out of cmComputeLinkInformation should be full paths. -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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja generator and __FILE__ (was: Ninja: Fix failing CMakeLib.testRST test)
On Fri, Jun 6, 2014 at 11:05 PM, Brad King brad.k...@kitware.com wrote: On 06/06/2014 10:53 AM, Sam Spilsbury wrote: On Fri, Jun 6, 2014 at 10:49 PM, Brad King brad.k...@kitware.com wrote: On 06/06/2014 10:12 AM, Sam Spilsbury wrote: For the sake of consistency, an absolute path should always be passed to the compiler on each generator, so that __FILE__ is always consistent. This is a larger debate for those that develop and use the Ninja generator. Are there any threads where I can read up on background information for this? Having consistency seems like a no-brainer to me, so perhaps I missed something? Briefly reading[1], it seems like the Chromium developers are preferring consistency between generator backends. [1] https://code.google.com/p/chromium/issues/detail?id=326030 This appears to be a result of using command = ... -c $in as the compilation rule so that the dependency path and the path given to the compiler on the command line are the same. In order to always pass a full path to the compiler then either ninja would have to do it when constructing the command or the generated rule would have to separately pass in the path to the source. I'm not familiar enough with the ninja tool or the CMake Ninja generator to say more. -Brad Thanks for the pointers, It seems like the problem is that the dependency path can't be an absolute path, but the path passed to the compiler can be. Is there any problem with the dependency path being an absolute path? I suppose the trade-off is that you lose source-and-build-directory relocatability, but both the Makefile and Ninja generators don't appear to support that anyways (e.g., CMake is re-run on the old path to the source directory, which fails). Sam. -- Sam Spilsbury -- 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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] cmNinjaTargetGenerator: Create files to satisfy pending-creation imported libs
Ninja evaluates all dependencies before building any targets unlike other generators, so if a file forming part of a dependency rule does not exist then this is a fatal error for Ninja. These files might be created as part of the build process (and not custom commands) so if the user imports a library target with add_library (... IMPORTED) and the path to that target is within the build directory, then just touch the file and assume it will be created later. Added ImportedExternalProjectLibrary, which builds a library in a sister subdirectory to an executable as an external project, the alternate sister subdirectory adding the library as an IMPORTED library depending on the external project and linking to it. Fixes #13574. --- Source/cmNinjaTargetGenerator.cxx | 37 ++ Tests/CMakeLists.txt | 1 + .../ImportedExternalProjectLibrary/CMakeLists.txt | 5 +++ .../CMakeLists.txt | 3 ++ .../ImportedExternalProjectLibrary.c | 6 .../LibrarySubdir/CMakeLists.txt | 17 ++ .../ProjectWithImportedLibrary/CMakeLists.txt | 4 +++ .../ProjectWithImportedLibrary/library.c | 4 +++ 9 files changed, 79 insertions(+), 2 deletions(-) create mode 100644 Tests/ImportedExternalProjectLibrary/CMakeLists.txt create mode 100644 Tests/ImportedExternalProjectLibrary/ImportedExternalProjectLibraryDir/CMakeLists.txt create mode 100644 Tests/ImportedExternalProjectLibrary/ImportedExternalProjectLibraryDir/ImportedExternalProjectLibrary.c create mode 100644 Tests/ImportedExternalProjectLibrary/LibrarySubdir/CMakeLists.txt create mode 100644 Tests/ImportedExternalProjectLibrary/LibrarySubdir/ProjectWithImportedLibrary/CMakeLists.txt create mode 100644 Tests/ImportedExternalProjectLibrary/LibrarySubdir/ProjectWithImportedLibrary/library.c I'm not particularly keen on this implementation, but it was the best thing I can think of for now. The trade off is that marking a target as IMPORTED doesn't necessarily mean the user is generating it and we end up calling the linker against a plain-text file, which results in a rather cryptic error message. The problem here is that Ninja does all its dependency scanning before building any targets, unlike other generators which do it once the target is reached. Thus if an IMPORTED library is being created as part of using ExternalProject_Add, then the Ninja generator will get upset and refuse to run. Another solution is to create a utility rule to create the library, but then it needs to be attached to something anyways and you get the same problem if the library is never actually built before others link to it. Another solution would be to omit adding dependencies where the file does not exist. This is inconsistent between builds though - as the file will exist after the build has taken place. Broader context: This prevents me from using ExternalProject_Add with the Ninja generator generally. I use ExternalProject_Add for one of my other projects[1] and having Ninja support back would be really nice. [1] https://github.com/polysquare/gmock-cmake -- Sam Spilsbury 0001-cmNinjaTargetGenerator-Create-files-to-satisfy-pendi.patch Description: Binary data -- 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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja delayed dependency stat (was: cmNinjaTargetGenerator: Create files to satisfy pending-creation imported libs)
On 06/06/2014 12:33 PM, Sam Spilsbury wrote: I'm not particularly keen on this implementation, but it was the best thing I can think of for now. The trade off is that marking a target as IMPORTED doesn't necessarily mean the user is generating it and we end up calling the linker against a plain-text file, which results in a rather cryptic error message. The file this touches may very well be newer than all the real dependencies of the rule to build it in the external build system so it may never get replaced with the real file. The problem here is that Ninja does all its dependency scanning before building any targets, unlike other generators which do it once the target is reached. Thus if an IMPORTED library is being created as part of using ExternalProject_Add, then the Ninja generator will get upset and refuse to run. [snip] Broader context: This prevents me from using ExternalProject_Add with the Ninja generator generally. This has come up several times. Here are some more links that may be related for reference: http://www.cmake.org/Bug/view.php?id=13538 http://www.cmake.org/Bug/view.php?id=13574 http://www.cmake.org/Bug/view.php?id=14747 http://www.cmake.org/Bug/view.php?id=14771 https://github.com/Kitware/CMake/pull/68 The problem is that we want to be able to have a build rule that says bring that other rule up to date first, then stat my dependencies. AFAICT ninja has no way to express this. An issue has been reported upstream here: https://github.com/martine/ninja/issues/760 The fundamental problem is Ninja's stat-then-build design. They do have restat to declare that the output files should be re-checked after a rule is run. We need a way to say that a rule's input dependencies should be restat-ed after its order-only dependencies are satisfied and up to date. -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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Adding an Android platform module
Hi Folks, I've just added a commit for testing and review: Add basic Android platform module http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42f74df6 My goal for now is to get the basic platform information in place so that it is possible for a toolchain file to be written without using a custom CMAKE_MODULE_PATH to create a Platform/Android module. Previous related discussions: Android platform file http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9578 a goal for a simple android toolchain http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9729 Building executables as libraries http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9728 New no-soname-option topic for e.g. Android http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10185 Make it possible to disable SONAME generation for libraries http://www.cmake.org/Bug/view.php?id=14602 I resolved the SONAME issue by creating a way to set the soname ignoring VERSION/SOVERSION. There are other open issues in the discussions but I do not think they are so fundamental that they should prevent the basic platform file from being added. -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: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
