[cmake-developers] cmake-developers Digest, Vol 71, Issue 4
John Farrier
john.farrier at helleboreconsulting.com
Fri Jun 6 10:34:36 EDT 2014
Unsubscribe
(iPhone)
> On Jun 6, 2014, at 10:11, cmake-developers-request at cmake.org wrote:
>
> Send cmake-developers mailing list submissions to
> cmake-developers at cmake.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
> or, via email, send a message with subject or body 'help' to
> cmake-developers-request at cmake.org
>
> You can reach the person managing the list at
> cmake-developers-owner at cmake.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cmake-developers digest..."
>
>
> Today's Topics:
>
> 1. [CMake 0014961]: CMake doesn't warn about function
> redefinition (Mantis Bug Tracker)
> 2. [patch] handle RC files as resources (Tim Blechmann)
> 3. Re: [patch] handle RC files as resources (Brad King)
> 4. Re: [patch] handle RC files as resources (Tim Blechmann)
> 5. [PATCH 1/2] cmComputeLinkInformation: Don't add build
> dependencies on IMPORTED libraries (Sam Spilsbury)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 5 Jun 2014 16:58:14 -0400
> From: Mantis Bug Tracker <mantis at public.kitware.com>
> To: cmake-developers at cmake.org
> Subject: [cmake-developers] [CMake 0014961]: CMake doesn't warn about
> function redefinition
> Message-ID: <4a6e7d96a60cfbeabbe58e62e3cb3dab at www.cmake.org>
> Keywords: [CMake] (No Category)
> Content-Type: text/plain; charset="utf-8"
>
>
> The following issue has been SUBMITTED.
> ======================================================================
> http://www.cmake.org/Bug/view.php?id=14961
> ======================================================================
> Reported By: vitaut
> Assigned To:
> ======================================================================
> Project: CMake
> Issue ID: 14961
> Category: (No Category)
> Reproducibility: always
> Severity: minor
> Priority: normal
> Status: new
> ======================================================================
> Date Submitted: 2014-06-05 16:58 EDT
> Last Modified: 2014-06-05 16:58 EDT
> ======================================================================
> Summary: CMake doesn't warn about function redefinition
> Description:
> CMake doesn't prevent or produce a warning/error when redefining functions which
> is very error prone. For example introducing a conflicting function definition
> in a subproject can easily break the build of the main project.
>
> Steps to Reproduce:
> Consider the following test project:
>
> CMakeLists.txt:
>
> cmake_minimum_required(VERSION 2.8)
> function(test)
> message("parent")
> endfunction()
> add_subdirectory(sub)
> test()
>
> sub/CMakeLists.txt:
>
> function(test)
> message("sub")
> endfunction()
>
> Running cmake prints "sub" which means that the test function defined in
> sub/CMakeLists.txt is used and not in CMakeLists.txt. No warnings or error
> message is produced.
>
> ======================================================================
>
> Issue History
> Date Modified Username Field Change
> ======================================================================
> 2014-06-05 16:58 vitaut New Issue
> ======================================================================
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 06 Jun 2014 10:16:51 +0200
> From: Tim Blechmann <tim at klingt.org>
> To: cmake-developers at cmake.org
> Subject: [cmake-developers] [patch] handle RC files as resources
> Message-ID: <lmrtdj$fql$1 at ger.gmane.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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
> -------------- next part --------------
>> From 0e41cb7df9dcb2587d928504c042a8ed0b51bc39 Mon Sep 17 00:00:00 2001
> From: Tim Blechmann <tim at 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 <tim at 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
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 06 Jun 2014 08:42:27 -0400
> From: Brad King <brad.king at kitware.com>
> To: cmake-developers at cmake.org
> Subject: Re: [cmake-developers] [patch] handle RC files as resources
> Message-ID: <5391B733.8050600 at kitware.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
>> 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
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 06 Jun 2014 15:48:44 +0200
> From: Tim Blechmann <tim at klingt.org>
> To: cmake-developers at cmake.org
> Subject: Re: [cmake-developers] [patch] handle RC files as resources
> Message-ID: <lmsgrt$ruk$1 at ger.gmane.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
>>> 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
>
> -------------- next part --------------
>> From e42b5ee3979c0b2e9b72d737c858830a865174ca Mon Sep 17 00:00:00 2001
> From: Tim Blechmann <tim at 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 <tim at 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
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 6 Jun 2014 22:11:11 +0800
> From: Sam Spilsbury <smspillaz at gmail.com>
> To: cmake-developers at cmake.org
> Subject: [cmake-developers] [PATCH 1/2] cmComputeLinkInformation:
> Don't add build dependencies on IMPORTED libraries
> Message-ID:
> <CAL=SSHLcwQeSigHeLA4ft3tmX1btfwTfrghUBK0M2AvE1AiBKw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0001-cmComputeLinkInformation-Don-t-add-build-dependencie.patch
> Type: application/octet-stream
> Size: 7039 bytes
> Desc: not available
> URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140606/9cb6a385/attachment.obj>
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
>
> 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
>
> ------------------------------
>
> End of cmake-developers Digest, Vol 71, Issue 4
> ***********************************************
More information about the cmake-developers
mailing list