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
B
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
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(X
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
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=
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
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15144
==
Reported By:Sergey Kosarevsky
Assigned To:
> > 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 addition
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
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 "
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 th
> 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_
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}_CREAT
> 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
> St
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.
>
> > 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 ca
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
> 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.
18 matches
Mail list logo
