[cmake-developers] Modern cross-platform buildsystem design requirements
Hi, I saw the addition of the VS_WINRT_COMPONENT property. This seems to be an attribute to mark an executable specially so that it is built with appropriate flags for the WinRT platform. This reminds me of this thread: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9728 Building executables as libraries (2014-03-21) and I wonder again if a generic solution would be possible to design. I wonder what a cmake-based buildsystem would look like for a collection of executables/targets which should be built for multiple of these 'modern, extra attribute-requiring' platforms. Until a few years ago, add_library(foo foo.cpp) add_executable(myexe main.cpp) target_link_libraries(myexe foo) was all that was needed for what we then called 'cross-platform' - it is a sufficient description to generate buildsystems to generate a working library and executable on first-class targets Windows/Linux/Mac and also cross-compiling, given an appropriate toolchain file. Today, I think 'cross-platform' includes a few mobile platforms as first- class targets, and cross-compiling is part of what cross-platform means. So, I wonder what a cross-platform buildsystem necessarily looks like today, and whether it can be done better/abstracted with more first class features. I guess in addition to the above, there would need to be something like a wrapper macro around add_executable to set the appropriate target properties, and possibly use a platform-specific condition for whether to actually create an executable or a PIC shared library (as described in the above thread). Is there any known real-world project aiming to build for those varieties of platforms so we can see what abstraction is needed? According to http://www.cmake.org/Wiki/CMake_Cross_Compiling#FAQ.2FPotential_Problems "If you build software for PS3, you build software for two architectures, for the PowerPC and for the cells." That information seems to come from: http://www.cmake.org/pipermail/cmake/2008-January/018937.html I was reminded of the above by http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/50389 I don't know how common it is to use cmake in those industries/environments, but if multiple toolchains are needed, I'm reminded of the previous proposal for multiple toolchain use. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272 Partly that discussion was aborted because we already had the large topic of designing and implementing usage-requirements to deal with. As that is now complete as designed, it might be worthwhile to re-consider and discuss/design how multiple toolchains could be used at once, whether that would require or benefit from a new language for cmake (another orthogoal known possible future-direction for cmake) etc. [ The manual at Help/manual/cmake-toolchains.7.rst contains several sample toolchain files for Unix. It would be good to have some sample toolchain files using the new WinRT stuff, setting the toolset and CMAKE_GENERATOR_PLATFORM to see how that all fits together now with VisualStudio. ] Thanks, Steve. -- 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/mailman/listinfo/cmake-developers
[cmake-developers] Gold standard find module?
Everyone has been really helpful but I don't want to be a pest. Is there a specific find package module that one could point to that would be consider the gold standard of getting it right? One with sufficient complexity (not like the wiki example). Thanks, Richard -- 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] include(...) or find_package(...) within another Find module
On 09/09/2014 02:21 PM, Richard Shaw wrote:
> Should this be include(FindX11) as it shows or find_package(X11)?
>
> if(UNIX)
> include(FindX11)
> find_library(FLTK_MATH_LIBRARY m)
> set(FLTK_PLATFORM_DEPENDENT_LIBS ${X11_LIBRARIES} ${FLTK_MATH_LIBRARY})
> endif()
It should be find_package(X11).
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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] FindIce: Remove unneeded search path modification
On 09/09/2014 02:56 PM, Roger Leigh wrote: > I have attached a patch to do this. Thanks, applied: FindIce: Respect Ice_FIND_QUIETLY when printing messages http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2131aedd -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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] FindIce: Remove unneeded search path modification
On Tue, Sep 09, 2014 at 11:48:53AM -0400, Brad King wrote:
> On 09/09/2014 11:35 AM, Roger Leigh wrote:
> > I have attached a minor fix to the FindIce module added a couple of
> > weeks back.
>
> Applied, thanks:
>
> FindIce: Remove unneeded search path modification
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d5047ca1
>
> While reviewing I noticed that there are some message(STATUS) calls
> not protected by if(Ice_DEBUG) or checks of Ice_FIND_QUIETLY. The
> latter is needed to honor the QUIET option of find_package. Please
> revise in a follow-up patch.
I have attached a patch to do this.
Thanks,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
>From 50b40ca739ea9f7646ed2e9cef9a7023df000586 Mon Sep 17 00:00:00 2001
From: Roger Leigh
Date: Tue, 9 Sep 2014 18:48:28 +
Subject: [PATCH 2/2] FindIce: Respect Ice_FIND_QUIETLY when printing messages
---
Modules/FindIce.cmake | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/Modules/FindIce.cmake b/Modules/FindIce.cmake
index 50bc60e..60a4107 100644
--- a/Modules/FindIce.cmake
+++ b/Modules/FindIce.cmake
@@ -240,7 +240,9 @@ function(_Ice_FIND)
set(Ice_VERSION "${Ice_VERSION_SLICE2CPP_FULL}" PARENT_SCOPE)
endif()
- message(STATUS "Ice version: ${Ice_VERSION_SLICE2CPP_FULL}")
+ if(NOT Ice_FIND_QUIETLY)
+message(STATUS "Ice version: ${Ice_VERSION_SLICE2CPP_FULL}")
+ endif()
# Find include directory
find_path(Ice_INCLUDE_DIR
@@ -305,17 +307,19 @@ function(_Ice_FIND)
set(_Ice_REQUIRED_LIBS_FOUND "${Ice_REQUIRED_LIBS_FOUND}" PARENT_SCOPE)
set(Ice_LIBRARY "${Ice_LIBRARY}" PARENT_SCOPE)
- if(Ice_LIBS_FOUND)
-message(STATUS "Found the following Ice libraries:")
-foreach(found ${Ice_LIBS_FOUND})
- message(STATUS " ${found}")
-endforeach()
- endif()
- if(Ice_LIBS_NOTFOUND)
-message(STATUS "The following Ice libraries were not found:")
-foreach(notfound ${Ice_LIBS_NOTFOUND})
- message(STATUS " ${notfound}")
-endforeach()
+ if(NOT Ice_FIND_QUIETLY)
+if(Ice_LIBS_FOUND)
+ message(STATUS "Found the following Ice libraries:")
+ foreach(found ${Ice_LIBS_FOUND})
+message(STATUS " ${found}")
+ endforeach()
+endif()
+if(Ice_LIBS_NOTFOUND)
+ message(STATUS "The following Ice libraries were not found:")
+ foreach(notfound ${Ice_LIBS_NOTFOUND})
+message(STATUS " ${notfound}")
+ endforeach()
+endif()
endif()
if(Ice_DEBUG)
--
1.9.4.msysgit.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/mailman/listinfo/cmake-developers
[cmake-developers] include(...) or find_package(...) within another Find module
I'm working on trying to modernize the FindFLTK module but also stuck with
making sure I don't break the established behavior. The problems with the
module are extensive so I'm breaking them up into individual emails where
possible.
The part I'm questioning in this email is: Should this be include(FindX11)
as it shows or find_package(X11)?
if(UNIX)
include(FindX11)
find_library(FLTK_MATH_LIBRARY m)
set(FLTK_PLATFORM_DEPENDENT_LIBS ${X11_LIBRARIES} ${FLTK_MATH_LIBRARY})
endif()
Thanks,
Richard
--
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/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015144]: CMake is unable to locate FreeType within the XQuartz installation
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15144
==
Reported By:Sergey Kosarevsky
Assigned To:
==
Project:CMake
Issue ID: 15144
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-09-09 12:58 EDT
Last Modified: 2014-09-09 12:58 EDT
==
Summary:CMake is unable to locate FreeType within the
XQuartz installation
Description:
XQuartz-2.7.7.dmg is installed.
The FreeType library is located in /opt/X11/include/freetype2
The CMake output is on the attached screenshot.
Steps to Reproduce:
CMakeLists.txt:
IF(WITH_FREETYPE)
FIND_PACKAGE(Freetype REQUIRED)
ADD_DEFINITIONS(-DUSEFREETYPE)
INCLUDE_DIRECTORIES(${FREETYPE_INCLUDE_DIRS})
SET(wcm_LIBS ${wcm_LIBS} ${FREETYPE_LIBRARIES})
ENDIF(WITH_FREETYPE)
==
Issue History
Date ModifiedUsername FieldChange
==
2014-09-09 12:58 Sergey KosarevskyNew Issue
2014-09-09 12:58 Sergey KosarevskyFile Added:
29efc2ec-37b0-11e4-9a95-e78996c79ba3.jpg
==
--
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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case
> > At first I tought the way things work was:
> > Windows-MSVC.cmake and Co construct a commandline with the required
> flags.
> > The VS generator parses this command line and uses the cmVS7FlagTable
> to
> > translate the known flags to XML elements.
> > (Unknown arguments get passed as additional arguments).
>
> This is done for a subset of the sources of flags, specifically
> those settable by users and project code. We can't use a complete
> command line like that in CMAKE_${lang}_CREATE_SHARED_LIBRARY
> because that will contain a lot of pieces besides the flags.
> Also multi-configuration is an issue as you point out.
>
> You would need to create new variables in Windows-MSVC to hold
> the flags to be scanned by the VS generators. Then re-use the
> flags in constructing the other rule variables with command-lines
> used by the Makefile and Ninja generators.
Looks like a bigger refactoring would be needed.
Maybe for the moment it is better to implement it analogous to WindowsPhone
and then later refactor the whole thing.
Pascal
--
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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] FindIce: Remove unneeded search path modification
On 09/09/2014 11:35 AM, Roger Leigh wrote: > I have attached a minor fix to the FindIce module added a couple of > weeks back. Applied, thanks: FindIce: Remove unneeded search path modification http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d5047ca1 While reviewing I noticed that there are some message(STATUS) calls not protected by if(Ice_DEBUG) or checks of Ice_FIND_QUIETLY. The latter is needed to honor the QUIET option of find_package. Please revise in a follow-up patch. 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/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] FindIce: Remove unneeded search path modification
Hi,
I have attached a minor fix to the FindIce module added a couple of
weeks back. This can override the user's intended search path and
was made unnecessary by the changes you requested prior to merging
(the paths being added are already added as fallbacks via the
list(APPEND ice_roots "/opt/Ice-${ice_version}")
line earlier in the script), so the removal simply makes the
behaviour consistent.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
>From e73f31183fb392769091877ee8aedffbe7de2f88 Mon Sep 17 00:00:00 2001
From: Roger Leigh
Date: Tue, 9 Sep 2014 16:28:11 +0100
Subject: [PATCH] FindIce: Remove unneeded search path modification
---
Modules/FindIce.cmake | 7 ---
1 file changed, 7 deletions(-)
diff --git a/Modules/FindIce.cmake b/Modules/FindIce.cmake
index c437a40..50bc60e 100644
--- a/Modules/FindIce.cmake
+++ b/Modules/FindIce.cmake
@@ -242,13 +242,6 @@ function(_Ice_FIND)
message(STATUS "Ice version: ${Ice_VERSION_SLICE2CPP_FULL}")
- # The following searches prefer the version found; note reverse
- # order due to prepending.
- if(NOT MSVC)
-list(INSERT ice_roots 0 "/opt/Ice-${Ice_VERSION_SLICE2CPP_SHORT}")
-list(INSERT ice_roots 0 "/opt/Ice-${Ice_VERSION_SLICE2CPP_FULL}")
- endif()
-
# Find include directory
find_path(Ice_INCLUDE_DIR
NAMES "Ice/Ice.h"
--
1.9.1
--
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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case
On 09/09/2014 11:02 AM, Bach, Pascal wrote:
> I don't understand the purpose of the flag tables [1].
> Aren't they there to map from command line to XML files?
Yes, but they were created originally to support flags specified
by users in CMAKE_C_FLAGS and a few other places.
> At first I tought the way things work was:
> Windows-MSVC.cmake and Co construct a commandline with the required flags.
> The VS generator parses this command line and uses the cmVS7FlagTable to
> translate the known flags to XML elements.
> (Unknown arguments get passed as additional arguments).
This is done for a subset of the sources of flags, specifically
those settable by users and project code. We can't use a complete
command line like that in CMAKE_${lang}_CREATE_SHARED_LIBRARY
because that will contain a lot of pieces besides the flags.
Also multi-configuration is an issue as you point out.
You would need to create new variables in Windows-MSVC to hold
the flags to be scanned by the VS generators. Then re-use the
flags in constructing the other rule variables with command-lines
used by the Makefile and Ninja generators.
-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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case
> On 09/09/2014 10:19 AM, Bach, Pascal wrote:
> > Wouldn't it make sense to use the same variables in the VS10+ Generator
> too?
> > It seems redundant to have the same information again. What's the reason
> it is hardcoded?
>
> That's just the way it was written. The rule variables like
> CMAKE_${lang}_CREATE_SHARED_LIBRARY contain command lines in
> which the Makefile and Ninja generators substitute for some
> placeholders. The VS generators do not have a command line
> because they just put the declarative information into the
> project file and let VS build the command line.
I don't understand the purpose of the flag tables [1]. Aren't they there to map
from command line to XML files?
At first I tought the way things work was:
Windows-MSVC.cmake and Co construct a commandline with the required flags. ==>
The VS generator parses this command line and uses the cmVS7FlagTable to
translate the known flags to XML elements. (Unknown arguments get passed as
additional arguments).
But it might be that this doesn't work because multi configuration or something
else.
[1]
https://github.com/Kitware/CMake/blob/6ae98ee18f6c35b93556a66dc0ce909d84aec18b/Source/cmVS10LinkFlagTable.h
>
> If you want to refactor things to create more independent
> flag-holding variables that are used to construct
> CMAKE_${lang}_CREATE_SHARED_LIBRARY and also read by the
> VS generators and sent through the flag map, that's fine
> with me. Please also update the VS 7-9 generators to use
> the same information variables if possible.
If I refactor I would change it to the way described above.
Pascal
--
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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case
On 09/09/2014 10:19 AM, Bach, Pascal wrote:
> Wouldn't it make sense to use the same variables in the VS10+ Generator too?
> It seems redundant to have the same information again. What's the reason it
> is hardcoded?
That's just the way it was written. The rule variables like
CMAKE_${lang}_CREATE_SHARED_LIBRARY contain command lines in
which the Makefile and Ninja generators substitute for some
placeholders. The VS generators do not have a command line
because they just put the declarative information into the
project file and let VS build the command line.
If you want to refactor things to create more independent
flag-holding variables that are used to construct
CMAKE_${lang}_CREATE_SHARED_LIBRARY and also read by the
VS generators and sent through the flag map, that's fine
with me. Please also update the VS 7-9 generators to use
the same information variables if possible.
-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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case
> Those are all for the Makefile and Ninja generators, as are > CMAKE_CREATE_WIN32_EXE and CMAKE_CREATE_CONSOLE_EXE. For VS > generators the knowledge has always been hard-coded, with a > special case for Windows CE: > > > http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalVisual > Studio7Generator.cxx;hb=v3.0.1#l1122 > > The cmVisualStudio10TargetGenerator could be taught this > similarly. Wouldn't it make sense to use the same variables in the VS10+ Generator too? It seems redundant to have the same information again. What's the reason it is hardcoded? Pascal -- 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case
On 09/09/2014 09:48 AM, Bach, Pascal wrote:
> The values added to _PLATFORM_LINK_FLAGS do never end up in the .vcxproj file.
> The go into CMAKE_${lang}_CREATE_SHARED_LIBRARY [1] and
> CMAKE_${lang}_LINK_EXECUTABLE [2]
> However I can't see how this variables should end up in the VS generator.
>
> Any ideas?
Those are all for the Makefile and Ninja generators, as are
CMAKE_CREATE_WIN32_EXE and CMAKE_CREATE_CONSOLE_EXE. For VS
generators the knowledge has always been hard-coded, with a
special case for Windows CE:
http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalVisualStudio7Generator.cxx;hb=v3.0.1#l1122
The cmVisualStudio10TargetGenerator could be taught this
similarly.
-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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case
> > Maybe a better solution would be to do this matching in a case insensitive
> way,
> > this way it would work in any case even with user passed flags in lower
> case.
>
> I'm saying that some flags are case sensitive and others are not.
> We cannot blindly match all "cl" flags insensitive to case, for
> example. Anyway, I think just matching the case is good enough
> for now.
Ok I didn't know that cl does care about casing for some flags.
> > - set(CMAKE_CREATE_WIN32_EXE "/entry:WinMainCRTStartup")
> > - set(CMAKE_CREATE_CONSOLE_EXE "/entry:mainACRTStartup")
> > - set(_PLATFORM_LINK_FLAGS " /subsystem:windowsce")
> > + set(CMAKE_CREATE_WIN32_EXE "/SUBSYSTEM:WINDOWSCE
> /ENTRY:WinMainCRTStartup")
> > + set(CMAKE_CREATE_CONSOLE_EXE "/SUBSYSTEM:WINDOWSCE
> /ENTRY:mainACRTStartup")
> > + set(_PLATFORM_LINK_FLAGS "")
>
> That appears to un-do this recent fix:
>
> MSVC: Fix linking of DLLs on WinCE (#15013)
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e1283e4
> http://www.cmake.org/Bug/view.php?id=15013
>
> that introduced _PLATFORM_LINK_FLAGS in the first place.
The values added to _PLATFORM_LINK_FLAGS do never end up in the .vcxproj file.
The go into CMAKE_${lang}_CREATE_SHARED_LIBRARY [1] and
CMAKE_${lang}_LINK_EXECUTABLE [2]
However I can't see how this variables should end up in the VS generator.
Any ideas?
[1]
https://github.com/Kitware/CMake/blob/6ae98ee18f6c35b93556a66dc0ce909d84aec18b/Modules/Platform/Windows-MSVC.cmake#L242
[2]
https://github.com/Kitware/CMake/blob/6ae98ee18f6c35b93556a66dc0ce909d84aec18b/Modules/Platform/Windows-MSVC.cmake#L256
--
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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case
On 09/09/2014 05:31 AM, Bach, Pascal wrote: > Maybe a better solution would be to do this matching in a case insensitive > way, > this way it would work in any case even with user passed flags in lower case. I'm saying that some flags are case sensitive and others are not. We cannot blindly match all "cl" flags insensitive to case, for example. Anyway, I think just matching the case is good enough for now. 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/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case
> On 09/08/2014 05:35 AM, Pascal Bach wrote:
> > Even better would be to make the search case insensitive.
>
> How do we know which flags are sensitive to case?
It has nothing to do with Visual Studio as it doesn't care about the casing.
The problem is in the CMake generator. The tables in (eg.
Source/cmVS10LinkFlagTable.h) map from linker flags to XML elements in the
resulting .vcxproj file.
One such example is the entry:
{"SubSystem", "SUBSYSTEM:WINDOWSCE",
"WindowsCE", "WindowsCE", 0},
This maps a flag
/SUBSYSTEM:WINDOWSCE
to
WindowsCE
As you can see the entries in the table are in upper case. And the mapping does
only work if the flags are uppercase to.
Maybe a better solution would be to do this matching in a case in sensitive
way, this way it would work in any case even with user passed flags in lower
case.
>
> > - set(CMAKE_CREATE_WIN32_EXE "/entry:WinMainCRTStartup")
> > - set(CMAKE_CREATE_CONSOLE_EXE "/entry:mainACRTStartup")
> > - set(_PLATFORM_LINK_FLAGS " /subsystem:windowsce")
> > + set(CMAKE_CREATE_WIN32_EXE "/SUBSYSTEM:WINDOWSCE
> /ENTRY:WinMainCRTStartup")
> > + set(CMAKE_CREATE_CONSOLE_EXE "/SUBSYSTEM:WINDOWSCE
> /ENTRY:mainACRTStartup")
> > + set(_PLATFORM_LINK_FLAGS "")
>
> That appears to un-do this recent fix:
>
> MSVC: Fix linking of DLLs on WinCE (#15013)
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e1283e4
> http://www.cmake.org/Bug/view.php?id=15013
>
> that introduced _PLATFORM_LINK_FLAGS in the first place.
Rith I think I had a too simplistic view here. But even the old fix doesn't
seem to work with VS. I think the /ENTRY point also needs to be set for the
DLLs, I will try if I can find out how to set this.
Pascal
PS: Forgot to add the mailinglist.
--
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/mailman/listinfo/cmake-developers
