On 30/07/2015 18:34, Brad King wrote:
On 07/30/2015 11:23 AM, Roger Leigh wrote:
foo_EXPORT_TEMPLATE template class foo_EXPORT std::allocator;
[snip]
#ifdef @EXPORT_IMPORT_CONDITION@
/* We are building this library */
# define @EXPORT_MACRO_NAME@ @DEFINE_EXPORT@
+#
On 07/30/2015 11:57 AM, James Johnston wrote:
> Very minor documentation update clarifying what happens if string(FIND)
> doesn't find a match. I had to make a CMake test script and/or check CMake
> source code to find the answer.
Applied, thanks:
Help: Document string(FIND) return value when n
On 07/30/2015 11:23 AM, Roger Leigh wrote:
> foo_EXPORT_TEMPLATE template class foo_EXPORT std::allocator;
[snip]
> #ifdef @EXPORT_IMPORT_CONDITION@
> /* We are building this library */
> # define @EXPORT_MACRO_NAME@ @DEFINE_EXPORT@
> +# define @EXPORT_MACRO_NAME@_TEMPLATE
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15674
==
Reported By:Christian Maaser
Assigned To:
See attached patch.
This is following the recommendations here:
https://support.microsoft.com/en-us/kb/168958
While the existing foo_EXPORT provided by GenerateExportHeader is fine
for use in exporting functions and classes, it isn't apparently
sufficient for template export. This is needed
Hi,
I need to get the linked libraries of a target. I was moving the code
away from get_target_property to generator expressions that should get
into a generated file, although I haven't managed yet.
Is there any possibility to do that already?
I've been thinking of adding something like a map fu
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15673
==
Reported By:Xan López
Assigned To:
==
Very minor documentation update clarifying what happens if string(FIND)
doesn't find a match. I had to make a CMake test script and/or check CMake
source code to find the answer.
Best regards,
James Johnston
0001-string-State-return-value-if-string-FIND-doesn-t-fin.patch
Description: Binary d
On Thursday, July 30, 2015 10:56:02 AM Brad King wrote:
> On 07/30/2015 09:29 AM, Pascal Bach wrote:
> > CMAKE_FIND_ROOT_PATH_MODE would then need to be extended to support
> > something like NATIVE and TARGET that one could use to choose where
> > to look for files.
> > This way every find_* call
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15672
==
Reported By:A. Klitzing
Assigned To:
On 07/29/2015 12:51 PM, Bill Somerville wrote:
> Revised patches attached.
Thanks! Applied:
GetPrerequisites: Add error checks for execute_process() calls
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=35626e57
GetPrerequisites: Optionally filter "objdump" output for speed
http://cmake.
On 07/30/2015 09:29 AM, Pascal Bach wrote:
> CMAKE_FIND_ROOT_PATH_MODE would then need to be extended to support
> something like NATIVE and TARGET that one could use to choose where
> to look for files.
> This way every find_* call could explicitly tell if it wants a host
> or a target version.
A
On 07/30/2015 09:55 AM, CHEVRIER, Marc wrote:
> here is the correct version.
Thanks. The component name "Extra" sounds too generic and we won't
be able to extend it in the future with other "extra" parts for the
same reason these tools could not be made part of Development.
Perhaps instead we sho
On 07/30/2015 07:38 AM, Gregor Jasny via cmake-developers wrote:
> Do you have a better idea to detect the usage of iphone/simulator SDK?
> Maybe we should handle this in the platform Darwin modules?
This occurs when cross-compiling to iOS, so should we check for
CMAKE_SYSTEM_NAME set to "iOS"? T
I just detected a small error introduced in patch 0001, here is the correct
version.
Sorry for the noise...
On 30/07/15 11:32, "cmake-developers on behalf of CHEVRIER, Marc"
wrote:
>
>New version of patches taking into account Brad’ remarks.
>
>Marc
>
>
>
>
>On 29/07/15 15:47, "Brad King"
On 07/30/2015 03:28 PM, Brad King wrote:
On 07/30/2015 08:45 AM, Nils Gladitz wrote:
Am I missing something obvious?
It can only work for the configurations that CMake knows about.
For single-config generators (Makefiles, Ninja) this is the
value of CMAKE_BUILD_TYPE. For multi-config generato
We are pleased to announce that CMake 3.2.2 is now available for download.
Please use the latest release from our download page:
http://www.cmake.org/download/
Thanks for your support!
-
Changes in 3.2.2 since 3.2.1:
Bets
Dear CMake devs/users,
I wanted to ask your opinion on something that has been troubling me since…
well, ever since I started using CMake. I have not found a single person alive
who would have said:
“The script language of CMake is nice, intuitive and productive. Authoring
scripts is easy, a
Hi again
Am 30.07.2015 um 10:54 schrieb Pascal Bach:
> Hi Clint, Hi Brad
>> What I want to avoid is users thinking that what you are proposing overrides
>> any other way of finding Qt when cross compiling.
>>
>> The wording you propose is "To find Qt in a cross compile environment set
>> the
>>
On 07/30/2015 08:45 AM, Nils Gladitz wrote:
> Am I missing something obvious?
It can only work for the configurations that CMake knows about.
For single-config generators (Makefiles, Ninja) this is the
value of CMAKE_BUILD_TYPE. For multi-config generators they
are listed in CMAKE_CONFIGURATION_T
On 07/29/2015 03:58 PM, Alex Merry wrote:
> This is intended to be used from a "settings file" which is applied to a
> group of CMake projects. This allows the file to control which policies
> means that users of the settings file are not forced to use NO_POLICY_SCOPE
> (particularly important if t
I tried using
http://www.cmake.org/cmake/help/v3.3/variable/CMAKE_MAP_IMPORTED_CONFIG_CONFIG.html
in the following example:
cmake_minimum_required(VERSION 3.3)
project(Foo CXX)
set(CMAKE_MAP_IMPORTED_CONFIG_RELWITHDEBINFO "Release")
add_library(foo SHARED IMPORTED)
get_property(VA
Hello,
On 29/07/15 14:07, Mantis Bug Tracker wrote:
==
http://www.cmake.org/Bug/view.php?id=15669
==
this bug caused by different App Bundle layout in MacOSX
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15671
==
Reported By:beckmi
Assigned To:
New version of patches taking into account Brad’ remarks.
Marc
On 29/07/15 15:47, "Brad King" wrote:
>On 07/29/2015 04:01 AM, CHEVRIER, Marc wrote:
>> here is an updated list of patches.
>
>Great.
>
>>find_package_handle_standard_args(Java
>> REQUIRED_VARS Java_JAVA_EXECUTABLE Java
Hi Clint, Hi Brad
> What I want to avoid is users thinking that what you are proposing overrides
> any other way of finding Qt when cross compiling.
>
> The wording you propose is "To find Qt in a cross compile environment set the
> following variables"
> However there are users for which setting
26 matches
Mail list logo
