[cmake-developers] [CMake 0014640]: PRIVATE linking with target_link_libraries propagates usage requirements for static libraries
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14640 == Reported By:Arunmozhi Assigned To: == Project:CMake Issue ID: 14640 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-12-09 08:59 EST Last Modified: 2013-12-09 08:59 EST == Summary:PRIVATE linking with target_link_libraries propagates usage requirements for static libraries Description: I have projects in the structure shown below module (EXECUTABLE) | \-- submodule (STATIC_LIBRARY) | \-- subsubmodule (STATIC_LIBRARY) 'submodule' links with 'subsubmodule' using PRIVATE linking as below target_link_libraries(submodule PRIVATE subsubmodule) 'module' links with 'submodule'. It is expected that the 'module' does not get the public include directories of 'subsubmod'. However we see this happening in cmake 2.8.12. It is understood that the libraries linked with 'subsubmodule' are propagated to 'module' since 'subsubmodule' and 'submodule' are STATIC libraries. However this does not apply to the INCLUDE directories and COMPILE definitions. We also note that for SHARED libraries, the PRIVATE linking works fine. == Issue History Date ModifiedUsername FieldChange == 2013-12-09 08:59 Arunmozhi New Issue 2013-12-09 08:59 Arunmozhi File Added: example.tar == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Converting cmake_parse_arguments to a builtin command
On 12/06/2013 04:42 PM, Matthew Woehlke wrote: An advantage of keeping the name is that existing callers get the speed-up immediately. Furthermore there will be less code left in the old module to maintain. I think that is still true if the module just wraps the new function? Yes, I think so. Be sure that the wrapper forwards empty arguments correctly or the compatibility policy will not be meaningful ;) Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Review Request: Topic ExternalProject-independent-step-targets
On 12/09/2013 07:51 AM, Daniele E. Domenichelli wrote:
And then adding an explicit dependency for each project that requires it
add_dependency(${proj}-download SetupLocalXXXRepository)
...but again this requires the existing cases to be modified and
no longer tests that they work without this extra configuration.
By moving the new property test into a subdirectory or otherwise
making it not apply to the existing cases then that is not a problem.
However, the trouble you're having with Ninja still needs to be
solved because it could affect user projects (and a representative
case needs to be in the test too).
AFAIK this should wait for SetupLocalXXXRepository to be finished
before starting ${proj}-download
If both are logical CMake target names then that is the expected
behavior, yes. The Makefile, VS, and Xcode generators all work
by grouping individual shell actions and their dependencies into
separate logical targets that have high-level ordering dependencies.
The Ninja generator (by design) tries to have monolithic dependencies
for all the low-level rules because it is more efficient at build time.
IIUC it tries to connect up all the low-level rule dependencies to
simulate the target-ordering dependencies that CMake defines. Perhaps
that is not working here. I'm not intimately familiar with it though.
Can you reproduce the dependency ordering failure with a few simple
add_custom_command and add_custom_target calls and no ExternalProject
module? That will make it much easier to pin down, and the result
can be added to the general test suite (e.g. CustomCommand test) too.
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] [CMAKE] Getting compilation date through CMake
BTW, just for other newbies, I think my mistake was that I took another
external command example literally:
EXECUTE_PROCESS(
COMMAND
svnversion -nc ${sourceDir}
OUTPUT_VARIABLE _out_svnversion
)
Now I guess the above works (without invoking the command prompt) because a
FindSubversion.cmake exists in CMake, and there is an svnversion.exe
somewhere in my SVN install.
HTH,
JON HAITZ
On 9 December 2013 08:53, Jon Haitz Legarreta jhlegarr...@vicomtech.orgwrote:
Dear Fraser and Matthew,
yes, both approaches work. Thank you.
There seems to be a trailing endline in the response given by
$ENV{COMSPEC} /c date /t, so the following regex helps deleting it:
STRING(REGEX REPLACE (\r?\n)+$ _date ${_date})
Thanks again,
JON HAITZ
On 5 December 2013 22:34, Matthew Woehlke matthew.woeh...@kitware.comwrote:
On 2013-12-05 15:46, Fraser Hutchison wrote:
If you can specify CMake version 2.8.11 as a minimum, you could use
the string(TIMESTAMP ...) command instead:
string(TIMESTAMP _output %d/%m/%Y)
Bear in mind that these only execute when CMake runs (i.e. at configure
time)
rather than at build time, so strictly-speaking you're not actually
grabbing the
compile date.
Of course you could put that in a CMake script and execute it with e.g.
'${CMAKE_COMMAND} -p ${CMAKE_CURRENT_SOURCE_DIR}/get_date.cmake' in a
custom command :-). Then it would truly be the compile date. (Needless to
say, the script would need to write the date into some generated source
file, e.g. with configure_file.)
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [CMAKE] Getting compilation date through CMake
Hi,
I only wanted to warn you, that windows date command output is
locale-specific, so you may get into trouble if you want to use it as anything
else than a string literal.
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Jon
Haitz Legarreta
Sent: Montag, 9. Dezember 2013 09:01
To: Matthew Woehlke
Cc: cmake@cmake.org
Subject: Re: [CMake] [CMAKE] Getting compilation date through CMake
BTW, just for other newbies, I think my mistake was that I took another
external command example literally:
EXECUTE_PROCESS(
COMMAND
svnversion -nc ${sourceDir}
OUTPUT_VARIABLE _out_svnversion
)
Now I guess the above works (without invoking the command prompt) because a
FindSubversion.cmake exists in CMake, and there is an svnversion.exe somewhere
in my SVN install.
HTH,
JON HAITZ
On 9 December 2013 08:53, Jon Haitz Legarreta jhlegarr...@vicomtech.org wrote:
Dear Fraser and Matthew,
yes, both approaches work. Thank you.
There seems to be a trailing endline in the response given by $ENV{COMSPEC} /c
date /t, so the following regex helps deleting it:
STRING(REGEX REPLACE (\r?\n)+$ _date ${_date})
Thanks again,
JON HAITZ
On 5 December 2013 22:34, Matthew Woehlke matthew.woeh...@kitware.com wrote:
On 2013-12-05 15:46, Fraser Hutchison wrote:
If you can specify CMake version 2.8.11 as a minimum, you could use
the string(TIMESTAMP ...) command instead:
string(TIMESTAMP _output %d/%m/%Y)
Bear in mind that these only execute when CMake runs (i.e. at configure time)
rather than at build time, so strictly-speaking you're not actually grabbing the
compile date.
Of course you could put that in a CMake script and execute it with e.g.
'${CMAKE_COMMAND} -p ${CMAKE_CURRENT_SOURCE_DIR}/get_date.cmake' in a custom
command :-). Then it would truly be the compile date. (Needless to say, the
script would need to write the date into some generated source file, e.g. with
configure_file.)
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [CMAKE] Getting compilation date through CMake
Thanks for the tip Jakub.
BTW, I just realized that the
[OUTPUT_STRIP_TRAILING_WHITESPACE]
option of EXECUTE_PROCESS has the same effect of the regex I wrote to strip
the trailing linebreaks.
Regards,
JON HAITZ
On 9 December 2013 09:46, Jakub Zakrzewski jzakrzew...@e2e.ch wrote:
Hi,
I only wanted to warn you, that windows date command output is
locale-specific, so you may get into trouble if you want to use it as
anything else than a string literal.
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Jon Haitz Legarreta
Sent: Montag, 9. Dezember 2013 09:01
To: Matthew Woehlke
Cc: cmake@cmake.org
Subject: Re: [CMake] [CMAKE] Getting compilation date through CMake
BTW, just for other newbies, I think my mistake was that I took another
external command example literally:
EXECUTE_PROCESS(
COMMAND
svnversion -nc ${sourceDir}
OUTPUT_VARIABLE _out_svnversion
)
Now I guess the above works (without invoking the command prompt) because
a FindSubversion.cmake exists in CMake, and there is an svnversion.exe
somewhere in my SVN install.
HTH,
JON HAITZ
On 9 December 2013 08:53, Jon Haitz Legarreta jhlegarr...@vicomtech.org
wrote:
Dear Fraser and Matthew,
yes, both approaches work. Thank you.
There seems to be a trailing endline in the response given by
$ENV{COMSPEC} /c date /t, so the following regex helps deleting it:
STRING(REGEX REPLACE (\r?\n)+$ _date ${_date})
Thanks again,
JON HAITZ
On 5 December 2013 22:34, Matthew Woehlke matthew.woeh...@kitware.com
wrote:
On 2013-12-05 15:46, Fraser Hutchison wrote:
If you can specify CMake version 2.8.11 as a minimum, you could use
the string(TIMESTAMP ...) command instead:
string(TIMESTAMP _output %d/%m/%Y)
Bear in mind that these only execute when CMake runs (i.e. at configure
time)
rather than at build time, so strictly-speaking you're not actually
grabbing the
compile date.
Of course you could put that in a CMake script and execute it with e.g.
'${CMAKE_COMMAND} -p ${CMAKE_CURRENT_SOURCE_DIR}/get_date.cmake' in a
custom command :-). Then it would truly be the compile date. (Needless to
say, the script would need to write the date into some generated source
file, e.g. with configure_file.)
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
--
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://www.cmake.org/mailman/listinfo/cmake
[CMake] 32/64 bit flag
Dear CMakers, I have to build cmake files for a Fortran project using ifort compiler on Windows, linux and macos platform. That project will be linked to Winteracter Fortran library whose installation paths are different depending on the 32 or 64 bit versions. Is there a way to automatically detect whether the build is a 32 bit or 64 bit one in order to define the correct path for Winteracter library ? Up to now, the only way I found to do this was by introducing a cmake option to my build (ON for 64bit build and OFF for a 32 one). I also saw the CMAKE_CL_64 flag that could have been interesting but unfortunately it is only for microsoft. thanks for your help Eric -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 32/64 bit flag
2013/12/9 pellegrini pellegr...@ill.fr:
Dear CMakers,
I have to build cmake files for a Fortran project using ifort compiler on
Windows, linux and macos platform.
That project will be linked to Winteracter Fortran library whose
installation paths are different depending on the 32
or 64 bit versions. Is there a way to automatically detect whether the build
is a 32 bit or 64 bit one in order to define
the correct path for Winteracter library ? Up to now, the only way I found
to do this was by introducing a cmake
option to my build (ON for 64bit build and OFF for a 32 one). I also saw the
CMAKE_CL_64 flag that could have been
interesting but unfortunately it is only for microsoft.
Usually you chekc the value of CMAKE_SIZEOF_VOID_P
which will be 8 on 64 bits system and 4 on 32 bits ones.
e.g. here is what I use:
# Test 32/64 bits
if(${CMAKE_SIZEOF_VOID_P} EQUAL 8)
message(STATUS Target is 64 bits)
if (WIN32)
set(WINXXBITS Win64)
endif(WIN32)
else(${CMAKE_SIZEOF_VOID_P} EQUAL 8)
message(STATUS Target is 32 bits)
if (WIN32)
set(WINXXBITS Win32)
endif(WIN32)
endif(${CMAKE_SIZEOF_VOID_P} EQUAL 8)
See:
http://www.cmake.org/pipermail/cmake/2011-February/042752.html
or
cmake --help-variable CMAKE_SIZEOF_VOID_P
thanks for your help
Eric
--
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://www.cmake.org/mailman/listinfo/cmake
--
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 32/64 bit flag
On 12/9/2013 1:26 PM, Eric Noulard wrote:
2013/12/9 pellegrini pellegr...@ill.fr:
Dear CMakers,
I have to build cmake files for a Fortran project using ifort compiler on
Windows, linux and macos platform.
That project will be linked to Winteracter Fortran library whose
installation paths are different depending on the 32
or 64 bit versions. Is there a way to automatically detect whether the build
is a 32 bit or 64 bit one in order to define
the correct path for Winteracter library ? Up to now, the only way I found
to do this was by introducing a cmake
option to my build (ON for 64bit build and OFF for a 32 one). I also saw the
CMAKE_CL_64 flag that could have been
interesting but unfortunately it is only for microsoft.
Usually you chekc the value of CMAKE_SIZEOF_VOID_P
which will be 8 on 64 bits system and 4 on 32 bits ones.
e.g. here is what I use:
# Test 32/64 bits
if(${CMAKE_SIZEOF_VOID_P} EQUAL 8)
message(STATUS Target is 64 bits)
if (WIN32)
set(WINXXBITS Win64)
endif(WIN32)
else(${CMAKE_SIZEOF_VOID_P} EQUAL 8)
message(STATUS Target is 32 bits)
if (WIN32)
set(WINXXBITS Win32)
endif(WIN32)
endif(${CMAKE_SIZEOF_VOID_P} EQUAL 8)
See:
http://www.cmake.org/pipermail/cmake/2011-February/042752.html
or
cmake --help-variable CMAKE_SIZEOF_VOID_P
thanks for your help
Eric
--
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://www.cmake.org/mailman/listinfo/cmake
Thanks Eric for the hint.
I read some time ago some stuffs about the CMAKE_SIZEOF_VOID_P variable
but unfortunately, in the present case,
the problem is a bit different. It can be for example that on a 64 bit
machine, I would like to use the 32 bit
ifort version because the only version of Winteracter library I have is
the 32 bit one. That's why I came to the point
that the only way to proceed was through a cmake option. I could also
try to guess the kind of build I would like from
the path of my compiler but this approach seems quite restrictive and
especially hazardous ...
Eric
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 32/64 bit flag
2013/12/9 pellegrini pellegr...@ill.fr: Thanks Eric for the hint. I read some time ago some stuffs about the CMAKE_SIZEOF_VOID_P variable but unfortunately, in the present case, the problem is a bit different. It can be for example that on a 64 bit machine, I would like to use the 32 bit ifort version because the only version of Winteracter library I have is the 32 bit one. That's why I came to the point that the only way to proceed was through a cmake option. I could also try to guess the kind of build I would like from the path of my compiler but this approach seems quite restrictive and especially hazardous ... This shouldn't be true. the value of CMAKE_SIZEOF_VOID_P should follow the capacity of the **compiler** used and not the capacity of the host. It works for cross-compiling as well. e.g. when I cross compile to Win32 on my Linux 64 bits host CMAKE_SIZEOF_VOID_P is equal to 4 i.e. 32 bits. In your case you are on 64 bit Windows host but you compile your program using a 32 bits compiler, this should work. The easiest way to check what happen is to try to print the value of CMAKE_SIZEOF_VOID_P in yor case. -- Erk L'élection n'est pas la démocratie -- http://www.le-message.org -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 32/64 bit flag - solved
On 12/9/2013 2:34 PM, Eric Noulard wrote: 2013/12/9 pellegrini pellegr...@ill.fr: Thanks Eric for the hint. I read some time ago some stuffs about the CMAKE_SIZEOF_VOID_P variable but unfortunately, in the present case, the problem is a bit different. It can be for example that on a 64 bit machine, I would like to use the 32 bit ifort version because the only version of Winteracter library I have is the 32 bit one. That's why I came to the point that the only way to proceed was through a cmake option. I could also try to guess the kind of build I would like from the path of my compiler but this approach seems quite restrictive and especially hazardous ... This shouldn't be true. the value of CMAKE_SIZEOF_VOID_P should follow the capacity of the **compiler** used and not the capacity of the host. It works for cross-compiling as well. e.g. when I cross compile to Win32 on my Linux 64 bits host CMAKE_SIZEOF_VOID_P is equal to 4 i.e. 32 bits. In your case you are on 64 bit Windows host but you compile your program using a 32 bits compiler, this should work. The easiest way to check what happen is to try to print the value of CMAKE_SIZEOF_VOID_P in yor case. Hi Eric, just put your snippet in a macros and everything worked fine: I could guess the architecture properly. That's for sure from far the best way to get rid of my architecture problem. thanks a lot Eric -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Proper behaviour and use of CMAKE_INSTALL_* variables
Dear list members, I often like or need to install two versions of the same software. Ideally the software should put its files by default to $prefix/include/$NAME/*.h $prefix/lib/$NAME/*.dylib ... ($prefix = $CMAKE_INSTALL_PREFIX) and in order to be able to install multiple versions side-by-side I would like to be able to specify something like -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION -DCMAKE_INSTALL_LIBDIR=lib/$NAME/$VERSION to end up with $prefix/include/$NAME/$VERSION/*.h $prefix/lib/$NAME/$VERSION/*.dylib instead of default paths. The problem is that in this case either of the two options must be true: a) Software sets CMAKE_INSTALL_INCLUDEDIR to include/$NAME rather than to include by default which violates the convention from http://www.cmake.org/cmake/help/v2.8.12/cmake.html#module:GNUInstallDirs, but leads to the desired behaviour. b) Software sets CMAKE_INSTALL_INCLUDEDIR to include by default and automatically adds $NAME to an internal variable when installing the files. The drawback of this approach is that -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION results in files being installed to $prefix/include/$NAME/$VERSION/$NAME/*.h and there is absolutely no way to change that. What approach would you suggest to achieve the desired behaviour without violating the conventions? Thank you very much, Mojca -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Proper behaviour and use of CMAKE_INSTALL_* variables
Hi, On Mon, Dec 9, 2013 at 3:50 PM, Mojca Miklavec mojca.miklavec.li...@gmail.com wrote: Dear list members, I often like or need to install two versions of the same software. Ideally the software should put its files by default to $prefix/include/$NAME/*.h $prefix/lib/$NAME/*.dylib ... ($prefix = $CMAKE_INSTALL_PREFIX) and in order to be able to install multiple versions side-by-side I would like to be able to specify something like -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION -DCMAKE_INSTALL_LIBDIR=lib/$NAME/$VERSION to end up with $prefix/include/$NAME/$VERSION/*.h $prefix/lib/$NAME/$VERSION/*.dylib instead of default paths. Do you have any reasons that speak against using separate prefixes for each version of that software? In particular since such a setup will make your life harder when you want to use the installed software in some cmake-based project. In that case you'd have to manually specify include-dir and lib-dir when configuring the project since many find-modules simply expect a 'standard' unix-like layout below the prefix under which they should search for a given software. So they don't look into include/version or lib/version so you'd need to specify that manually. Compared with the ease of just specifying CMAKE_PREFIX_PATH to the installation directory for the version you want thats a lot more effort each time you setup a build directory. Andreas -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Proper behaviour and use of CMAKE_INSTALL_* variables
On Mon, Dec 9, 2013 at 4:52 PM, Andreas Pakulat wrote: Hi, On Mon, Dec 9, 2013 at 3:50 PM, Mojca Miklavec wrote: Dear list members, I often like or need to install two versions of the same software. Ideally the software should put its files by default to $prefix/include/$NAME/*.h $prefix/lib/$NAME/*.dylib ... ($prefix = $CMAKE_INSTALL_PREFIX) and in order to be able to install multiple versions side-by-side I would like to be able to specify something like -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION -DCMAKE_INSTALL_LIBDIR=lib/$NAME/$VERSION to end up with $prefix/include/$NAME/$VERSION/*.h $prefix/lib/$NAME/$VERSION/*.dylib instead of default paths. Do you have any reasons that speak against using separate prefixes for each version of that software? First, both versions of the software *have to* to be installed under $prefix (in my case that is usually /opt/local) because that is the location where all the packages installed by a specific package manager (MacPorts) need to end up. What I could do is to install the two versions under CMAKE_INSTALL_PREFIX=$prefix/Library/Frameworks/$NAME.framework/Versions/$VERSION/ even if the software doesn't really satisfy the layout of a framework, but that layout doesn't really simplify that much other than no need to specify 5 separate variables to change include, lib, man, doc, ... In particular since such a setup will make your life harder when you want to use the installed software in some cmake-based project. That's not a really good argument. Life is already hard. For FindX11 I need to manually specify about 20 different variables to be able to get rid of searching in /usr/X11R6 (Mac OS X) for example and use the libraries from /opt/local instead. For almost any given library I usually need to specify 2-5 variables (one for includes and several for each single dylib) and a lot of FindWhatever.cmake are simply too stupid to allow easy configuration. The pkg-config approach works a whole lot better in a lot of cases. I would really like to avoid searching in some prefixes (for example I would like to avoid searching for libraries in /usr/local and only search in /opt/local), but I don't know any elegant way to do so. And in case of some specific software I have in mind, the software itself provides its own CMake configuration file, so all dependent packages/software need to do is to find that configuration file, nothing else. In that case you'd have to manually specify include-dir and lib-dir when configuring the project since many find-modules simply expect a 'standard' unix-like layout below the prefix under which they should search for a given software. So they don't look into include/version or lib/version so you'd need to specify that manually. Compared with the ease of just specifying CMAKE_PREFIX_PATH to the installation directory for the version you want thats a lot more effort each time you setup a build directory. I'm still interested in the answer to my original question and would like to avoid discussion about why not specifying a different $prefix. There are surely many pros and contras to each approach and it makes no sense to get off-topic with a different discussion. (I could surely write an essay about pros of my approach, but that wouldn't help me answer my question. I can open a new thread about that if needed, but let's stick to the original question here.) Mojca -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Building Matlab MEX files - a solution?
I've been working on a project which requires building. After coming up
with a brittle, overcomplicated way to use Matlab's MEX script to compile
mex files, it occurred to me that I could simplify things by using the
output of the MEX script.
To that end, I wrote this. It seems to work great on Linux and OS X. I
don't have an easy way to try it on Windows; I'd love to hear from someone
who could try it. This only works with a customized
version of FindMatlab.cmake, also included here.
BuildMex.cmake-
# BuildMex.cmake
# Author: Kent Williams norman-k-willi...@uiowa.edu
include(CMakeParseArguments)
if(NOT MATLAB_FOUND)
find_package(MATLAB REQUIRED)
endif()
# CMake 2.8.12 earlier apparently don't define the
# Mex script path, so find it.
if(NOT MATLAB_MEX_PATH)
find_program( MATLAB_MEX_PATH mex
HINTS ${MATLAB_ROOT}/bin
PATHS ${MATLAB_ROOT}/bin
DOC The mex program path
)
if(NOT MATLAB_MEX_PATH)
message(FATAL_ERROR Can't find Matlab MEX compiler)
endif()
endif()
include_directories(${MATLAB_INCLUDE_DIR})
#
# mex -v outputs all the settings used for building MEX files, so it
# we can use it to grab the important variables needed to generate
# a well formed mex file.
execute_process(COMMAND ${MATLAB_MEX_PATH} -v
OUTPUT_VARIABLE mexOut
ERROR_VARIABLE mexErr)
# parse mex output line by line by turning file into CMake list of lines
string(REGEX REPLACE \r?\n ; _mexOut ${mexOut})
foreach(line ${_mexOut}) if(${line} MATCHES CXXFLAGS *=)
string(REGEX REPLACE *CXXFLAGS *= * mexCxxFlags ${line})
elseif(${line} MATCHES CXXLIBS *=)
string(REGEX REPLACE *CXXLIBS *= * mexCxxLibs ${line})
elseif(${line} MATCHES LDFLAGS *=)
string(REGEX REPLACE *LDFLAGS *= * mexLdFlags ${line})
elseif(${line} MATCHES LDEXTENSION *=)
string(REGEX REPLACE *LDEXTENSION *= * mexLdExtension ${line})
endif()
endforeach()
list(APPEND mexCxxFlags -DMATLAB_MEX_FILE)
#
# BuildMex -- arguments
# MEXNAME = root of mex library name
# TARGETDIR = location for the mex library files to be created
# SOURCE = list of source files
# LIBRARIES = libraries needed to link mex library
macro(BuildMex)
set(oneValueArgs MEXNAME TARGETDIR)
set(multiValueArgs SOURCE LIBRARIES)
cmake_parse_arguments(BuildMex ${oneValueArgs} ${multiValueArgs}
${ARGN})
set_source_files_properties(${BuildMex_SOURCE}COMPILE_DEFINITIONS
${mexCxxFlags}
)
add_library(${BuildMex_MEXNAME} SHARED ${BuildMex_SOURCE})
set_target_properties(${BuildMex_MEXNAME} PROPERTIES
SUFFIX ${mexLdExtension}
RUNTIME_OUTPUT_DIRECTORY ${BuildMex_TARGETDIR}
ARCHIVE_OUTPUT_DIRECTORY ${BuildMex_TARGETDIR}
LIBRARY_OUTPUT_DIRECTORY ${BuildMex_TARGETDIR}
)
target_link_libraries(${BuildMex_MEXNAME} ${BuildMex_LIBRARIES}
${mexCxxLibs})
endmacro(BuildMex)
FindMatlab.cmake
# - this module looks for Matlab
# Defines:
# MATLAB_INCLUDE_DIR: include path for mex.h, engine.h
# MATLAB_LIBRARIES: required libraries: libmex, etc
# MATLAB_MEX_LIBRARY: path to libmex.lib
# MATLAB_MX_LIBRARY: path to libmx.lib
# MATLAB_MAT_LIBRARY: path to libmat.lib # added
# MATLAB_ENG_LIBRARY: path to libeng.lib
# MATLAB_ROOT: path to Matlab's root directory
# This file is part of Gerardus
#
# This is a derivative work of file FindMatlab.cmake released with
# CMake v2.8, because the original seems to be a bit outdated and
# doesn't work with my Windows XP and Visual Studio 10 install
#
# (Note that the original file does work for Ubuntu Natty)
#
# Author: Ramon Casero rcas...@gmail.com, Tom Doel
# Version: 0.2.3
# $Rev$
# $Date$
#
# The original file was copied from an Ubuntu Linux install
# /usr/share/cmake-2.8/Modules/FindMatlab.cmake
#==
===
# Copyright 2005-2009 Kitware, Inc.
#
# Distributed under the OSI-approved BSD License (the License);
# see accompanying file Copyright.txt for details.
#
# This software is distributed WITHOUT ANY WARRANTY; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the License for more information.
#==
===
# (To distribute this file outside of CMake, substitute the full
# License text for the above reference.)
set(MATLAB_FOUND 0)
if(WIN32)
# Search for a version of Matlab available, starting from the most
modern one to older versions
foreach(MATVER 7.14 7.11 7.10 7.9 7.8 7.7 7.6 7.5 7.4)
if((NOT DEFINED MATLAB_ROOT)
OR (${MATLAB_ROOT} STREQUAL )
OR (${MATLAB_ROOT} STREQUAL /registry))
get_filename_component(MATLAB_ROOT
[HKEY_LOCAL_MACHINE\\SOFTWARE\\MathWorks\\MATLAB\\${MATVER};MATLABROOT]
ABSOLUTE)
set(MATLAB_VERSION ${MATVER})
endif()
endforeach()
# Directory name depending on whether the Windows architecture
Re: [CMake] Windows XP + CMake + VS2013
Hi Stefan, You should add CMake command option *-T vc120_xp* BR, Andrey Upadyshev On Sun, Dec 8, 2013 at 7:22 PM, Stefan Fendt ste...@sfendt.de wrote: Hi, I'm using CMake 2.8.12 together with MSVC 2013 and need to produce a binary which is (still) compatible with Windows XP SP3. If I'm right, then I need to change the compiler toolchain to 120_xp to make this work (I get the message that the binary isn't a valid WIN32-application on the XP machine otherwise). How am I supposed to tell CMake to use this compiler toolchain? With best regards, Stefan -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -- 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://www.cmake.org/mailman/listinfo/cmake -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to find/run external host executables when using cross compiling
On 12/4/13, Eric Wing ewmail...@gmail.com wrote: I'm currently trying to port a rather large, complex project to Android. It has an existing CMake project so I'm trying to leverage that. I've taken and enhanced one of the Android-CMake toolchains I've found. This particular project I'm porting has unfortunate dependencies on running the host system's Perl, Python, and Ruby interpreters to do various kinds of on-the-fly code generation. The problem I'm having is that with the cross-compilation toolchain, none of these (host) dependencies are found with CMake (I think it uses FindPackage) because the cross-compilation toolchain has sandboxed off everything to look in the target toolchain which won't have Perl/Python/Ruby (which is completely reasonable; I'm not complaining). But I need to solve this problem and figure out how to find/invoke the host Perl/Python/Ruby/etc so my cross-compile can work. Can anybody give me suggestions on how I should approach this? Bump. I have a temporary workaround in place where I comment out the find_package calls for Perl/Python/Ruby, and then use -D switches with CMake to pre-populate the correct values for my host system. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ -- 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://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6113-gebe82f4
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via ebe82f456fb79bc321aee307ee24da4b735095f2 (commit) via 7435ae7c97590a0713d86b63add761d5e1607ec1 (commit) via 0ea589fdfcd9082122829d4959adc842cacbc558 (commit) via 68963b04690f1821a19fc4f888d947b725d2b53c (commit) via 6f6eec1ff69ef9521710a30c749bfb0286752d59 (commit) from 8d76948d996fc656a3f2b8982cc36a4b8457a9f0 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ebe82f456fb79bc321aee307ee24da4b735095f2 commit ebe82f456fb79bc321aee307ee24da4b735095f2 Merge: 8d76948 7435ae7 Author: Daniele E. Domenichelli daniele.domeniche...@gmail.com AuthorDate: Mon Dec 9 07:25:30 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Dec 9 07:25:30 2013 -0500 Merge topic 'FindFreetype-2.5' into next 7435ae7 FindFreetype: Find ftheader.h with Freetype 2.5 0ea589f CMake Nightly Date Stamp 68963b0 CMake Nightly Date Stamp 6f6eec1 CMake Nightly Date Stamp http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7435ae7c97590a0713d86b63add761d5e1607ec1 commit 7435ae7c97590a0713d86b63add761d5e1607ec1 Author: Daniele E. Domenichelli daniele.domeniche...@iit.it AuthorDate: Mon Dec 9 13:24:28 2013 +0100 Commit: Daniele E. Domenichelli daniele.domeniche...@iit.it CommitDate: Mon Dec 9 13:24:28 2013 +0100 FindFreetype: Find ftheader.h with Freetype 2.5 diff --git a/Modules/FindFreetype.cmake b/Modules/FindFreetype.cmake index 179dc00..9520f7d 100644 --- a/Modules/FindFreetype.cmake +++ b/Modules/FindFreetype.cmake @@ -65,7 +65,10 @@ find_path(FREETYPE_INCLUDE_DIR_ft2build ft2build.h PATH_SUFFIXES include/freetype2 include ) -find_path(FREETYPE_INCLUDE_DIR_freetype2 freetype/config/ftheader.h +find_path(FREETYPE_INCLUDE_DIR_freetype2 + NAMES +freetype/config/ftheader.h +config/ftheader.h HINTS ENV FREETYPE_DIR PATHS --- Summary of changes: Modules/FindFreetype.cmake |5 - Source/CMakeVersion.cmake |2 +- 2 files changed, 5 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6115-gd85206a
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via d85206a21fcdeec9995d92530f5c66cf9ffd601b (commit)
via ca9e11727b697be364200b5fd8b45bf7ad6f6f7b (commit)
from ebe82f456fb79bc321aee307ee24da4b735095f2 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d85206a21fcdeec9995d92530f5c66cf9ffd601b
commit d85206a21fcdeec9995d92530f5c66cf9ffd601b
Merge: ebe82f4 ca9e117
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Dec 9 10:28:09 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 9 10:28:09 2013 -0500
Merge topic 'vtk-contract' into next
ca9e117 Tests/Contracts: Fix failing VTK Contract test
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ca9e11727b697be364200b5fd8b45bf7ad6f6f7b
commit ca9e11727b697be364200b5fd8b45bf7ad6f6f7b
Author: Zack Galbreath zack.galbre...@kitware.com
AuthorDate: Fri Dec 6 17:02:56 2013 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Dec 9 10:27:55 2013 -0500
Tests/Contracts: Fix failing VTK Contract test
This test was failing because it was attempting to build VTK in the
wrong directory.
diff --git a/Tests/Contracts/VTK/CMakeLists.txt
b/Tests/Contracts/VTK/CMakeLists.txt
index 5b19f01..ef19325 100644
--- a/Tests/Contracts/VTK/CMakeLists.txt
+++ b/Tests/Contracts/VTK/CMakeLists.txt
@@ -25,7 +25,6 @@ if(NOT DEFINED HOME)
endif()
set(base_dir ${HOME}/.cmake/Contracts/VTK)
-set(stamp_dir ${base_dir}/stamp)
if(NOT DEFINED SITE)
site_name(SITE)
@@ -41,7 +40,7 @@ configure_file(
ExternalProject_Add(${PROJECT_NAME}
GIT_REPOSITORY git://vtk.org/VTK.git
GIT_TAG release
- STAMP_DIR ${stamp_dir}
+ PREFIX ${base_dir}
CONFIGURE_COMMAND
BUILD_COMMAND ${CMAKE_CTEST_COMMAND} -S ${base_dir}/Dashboard.cmake
INSTALL_COMMAND
diff --git a/Tests/Contracts/VTK/Dashboard.cmake.in
b/Tests/Contracts/VTK/Dashboard.cmake.in
index b10f384..e33a2de 100644
--- a/Tests/Contracts/VTK/Dashboard.cmake.in
+++ b/Tests/Contracts/VTK/Dashboard.cmake.in
@@ -1,7 +1,7 @@
set(CTEST_SITE @SITE@)
set(CTEST_BUILD_NAME Contracts.VTK)
set(CTEST_DASHBOARD_ROOT @base_dir@)
-set(CTEST_SOURCE_DIRECTORY ${CTEST_DASHBOARD_ROOT}/VTK)
+set(CTEST_SOURCE_DIRECTORY ${CTEST_DASHBOARD_ROOT}/src/VTK)
set(CTEST_BINARY_DIRECTORY ${CTEST_DASHBOARD_ROOT}/VTK-build)
set(CTEST_CMAKE_GENERATOR @CMAKE_GENERATOR@)
@@ -24,5 +24,5 @@ file(WRITE ${CTEST_BINARY_DIRECTORY}/CMakeCache.txt
ctest_start(Nightly)
ctest_configure(BUILD ${CTEST_BINARY_DIRECTORY})
ctest_build(BUILD ${CTEST_BINARY_DIRECTORY})
-ctest_TEST(BUILD ${CTEST_BINARY_DIRECTORY} INCLUDE PythonSmoke)
+ctest_test(BUILD ${CTEST_BINARY_DIRECTORY} INCLUDE PythonSmoke)
ctest_submit(BUILD ${CTEST_BINARY_DIRECTORY})
---
Summary of changes:
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6117-gac10554
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via ac1055496fd2a905bb7b273d4bd44d7587958082 (commit)
via 0b9906c2fba3fa7d2aebc5e217da31cd129b2bfc (commit)
from d85206a21fcdeec9995d92530f5c66cf9ffd601b (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ac1055496fd2a905bb7b273d4bd44d7587958082
commit ac1055496fd2a905bb7b273d4bd44d7587958082
Merge: d85206a 0b9906c
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Dec 9 10:32:05 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 9 10:32:05 2013 -0500
Merge topic 'unicode-win32-apis' into next
0b9906c Windows: Use wide-character system APIs
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0b9906c2fba3fa7d2aebc5e217da31cd129b2bfc
commit 0b9906c2fba3fa7d2aebc5e217da31cd129b2bfc
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Wed Dec 4 22:17:24 2013 -0700
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Dec 9 10:29:43 2013 -0500
Windows: Use wide-character system APIs
Make CMake compile with -DUNICODE. Make it possible for the 8 bit
encoding to eventually be UTF-8 instead ANSI.
diff --git a/Source/CPack/WiX/cmCPackWIXGenerator.cxx
b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
index 91701c2..1b9b20a 100644
--- a/Source/CPack/WiX/cmCPackWIXGenerator.cxx
+++ b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
@@ -23,6 +23,7 @@
#include cmsys/SystemTools.hxx
#include cmsys/Directory.hxx
+#include cmsys/Encoding.hxx
#include rpc.h // for GUID generation
@@ -954,11 +955,12 @@ std::string cmCPackWIXGenerator::GenerateGUID()
UUID guid;
UuidCreate(guid);
- unsigned char *tmp = 0;
- UuidToString(guid, tmp);
+ unsigned short *tmp = 0;
+ UuidToStringW(guid, tmp);
- std::string result(reinterpret_castchar*(tmp));
- RpcStringFree(tmp);
+ std::string result =
+cmsys::Encoding::ToNarrow(reinterpret_castwchar_t*(tmp));
+ RpcStringFreeW(tmp);
return cmSystemTools::UpperCase(result);
}
diff --git a/Source/cmExportCommand.cxx b/Source/cmExportCommand.cxx
index 3f6bc2e..0a67ccf 100644
--- a/Source/cmExportCommand.cxx
+++ b/Source/cmExportCommand.cxx
@@ -16,6 +16,7 @@
#include cmake.h
#include cmsys/RegularExpression.hxx
+#include cmsys/Encoding.hxx
#include cmExportBuildFileGenerator.h
@@ -252,14 +253,14 @@ void cmExportCommand::ReportRegistryError(std::string
const msg,
cmOStringStream e;
e msg \n
HKEY_CURRENT_USER\\ key \n;
- char winmsg[1024];
- if(FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM |
+ wchar_t winmsg[1024];
+ if(FormatMessageW(FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS, 0, err,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
winmsg, 1024, 0) 0)
{
e Windows reported:\n
- winmsg;
+ cmsys::Encoding::ToNarrow(winmsg);
}
this-Makefile-IssueMessage(cmake::WARNING, e.str());
}
@@ -272,8 +273,9 @@ void cmExportCommand::StorePackageRegistryWin(std::string
const package,
std::string key = Software\\Kitware\\CMake\\Packages\\;
key += package;
HKEY hKey;
- LONG err = RegCreateKeyEx(HKEY_CURRENT_USER,
-key.c_str(), 0, 0, REG_OPTION_NON_VOLATILE,
+ LONG err = RegCreateKeyExW(HKEY_CURRENT_USER,
+cmsys::Encoding::ToWide(key).c_str(),
+0, 0, REG_OPTION_NON_VOLATILE,
KEY_SET_VALUE, 0, hKey, 0);
if(err != ERROR_SUCCESS)
{
@@ -281,8 +283,11 @@ void cmExportCommand::StorePackageRegistryWin(std::string
const package,
Cannot create/open registry key, key, err);
return;
}
- err = RegSetValueEx(hKey, hash, 0, REG_SZ, (BYTE const*)content,
- static_castDWORD(strlen(content)+1));
+
+ std::wstring wcontent = cmsys::Encoding::ToWide(content);
+ err = RegSetValueExW(hKey, cmsys::Encoding::ToWide(hash).c_str(),
+ 0, REG_SZ, (BYTE const*)wcontent.c_str(),
+ static_castDWORD(wcontent.size()+1)*sizeof(wchar_t));
RegCloseKey(hKey);
if(err != ERROR_SUCCESS)
{
diff --git a/Source/cmFileTimeComparison.cxx b/Source/cmFileTimeComparison.cxx
index 3167be4..02f10c0 100644
--- a/Source/cmFileTimeComparison.cxx
+++ b/Source/cmFileTimeComparison.cxx
@@ -16,6 +16,8 @@
# include cmsys/hash_map.hxx
#endif
+#include cmsys/Encoding.hxx
+
// Use a platform-specific API to get file times efficiently.
#if !defined(_WIN32) || defined(__CYGWIN__)
# define cmFileTimeComparison_Type struct stat
@@ -86,7 +88,8 @@ bool
[Cmake-commits] CMake branch, master, updated. v2.8.12.1-902-g5026696
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 5026696fcc79e1ec4b1f40069566614852b4c312 (commit)
via 77f3772784152701ff0eee5e4a19177996c03c0e (commit)
via 2e60b5fcf7929232c2e731f21e1ab9a889949fa3 (commit)
from 1ab140ef8f4be77503f59f25d6e2a036d0f44ca2 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5026696fcc79e1ec4b1f40069566614852b4c312
commit 5026696fcc79e1ec4b1f40069566614852b4c312
Merge: 1ab140e 77f3772
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Dec 9 10:33:30 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 9 10:33:30 2013 -0500
Merge topic 'INTERFACE_AUTOUIC_OPTIONS'
77f3772 cmTarget: Require a compatible INTERFACE_AUTOUIC_OPTIONS from
dependencies.
2e60b5f cmTarget: Report origin of COMPATIBLE_INTERFACE properties.
---
Summary of changes:
Source/cmTarget.cxx| 292 ++--
Source/cmTarget.h |7 +-
Tests/CompatibleInterface/CMakeLists.txt |7 +
Tests/RunCMake/CMakeLists.txt |3 +
.../AutoUic-result.txt}|0
.../CompatibleInterface/AutoUic-stderr.txt | 11 +
Tests/RunCMake/CompatibleInterface/AutoUic.cmake | 22 ++
.../DebugProperties-result.txt}|0
.../CompatibleInterface/DebugProperties-stderr.txt | 73 +
.../CompatibleInterface/DebugProperties.cmake | 60
.../CompatibleInterface/RunCMakeTest.cmake |6 +
Tests/{ = RunCMake}/CompatibleInterface/empty.cpp |0
.../Debug-result.txt} |0
.../PositionIndependentCode/Debug-stderr.txt |6 +
Tests/RunCMake/PositionIndependentCode/Debug.cmake |8 +
.../PositionIndependentCode/RunCMakeTest.cmake |1 +
16 files changed, 356 insertions(+), 140 deletions(-)
copy Tests/RunCMake/{CMP0004/CMP0004-NEW-result.txt =
CompatibleInterface/AutoUic-result.txt} (100%)
create mode 100644 Tests/RunCMake/CompatibleInterface/AutoUic-stderr.txt
create mode 100644 Tests/RunCMake/CompatibleInterface/AutoUic.cmake
copy Tests/RunCMake/{CMP0022/CMP0022-WARN-empty-old-result.txt =
CompatibleInterface/DebugProperties-result.txt} (100%)
create mode 100644
Tests/RunCMake/CompatibleInterface/DebugProperties-stderr.txt
create mode 100644 Tests/RunCMake/CompatibleInterface/DebugProperties.cmake
copy Tests/{ = RunCMake}/CompatibleInterface/empty.cpp (100%)
copy Tests/RunCMake/{CMP0022/CMP0022-WARN-empty-old-result.txt =
PositionIndependentCode/Debug-result.txt} (100%)
create mode 100644 Tests/RunCMake/PositionIndependentCode/Debug-stderr.txt
create mode 100644 Tests/RunCMake/PositionIndependentCode/Debug.cmake
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12.1-895-gcedf03b
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via cedf03b30711a1d93f00eaed0b92dc3538ec660d (commit) via 5da1580adaa0b7ccf5f3a6afac5e9cae615ca163 (commit) from 0ea589fdfcd9082122829d4959adc842cacbc558 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cedf03b30711a1d93f00eaed0b92dc3538ec660d commit cedf03b30711a1d93f00eaed0b92dc3538ec660d Merge: 0ea589f 5da1580 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Dec 9 10:33:08 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Dec 9 10:33:08 2013 -0500 Merge topic 'mingw-gfortran-sizeof-dptr' 5da1580 Fortran: Improve pointer size detection in gfortran on MinGW --- Summary of changes: Modules/CMakeFortranCompilerABI.F |4 1 files changed, 4 insertions(+), 0 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12.1-897-g1c95ec6
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 1c95ec6316e5f8b411abf79dbf5d4c6f85faf2f2 (commit) via 05c518b3dee430b56a090e34b55c3f8dbfd034d4 (commit) from cedf03b30711a1d93f00eaed0b92dc3538ec660d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c95ec6316e5f8b411abf79dbf5d4c6f85faf2f2 commit 1c95ec6316e5f8b411abf79dbf5d4c6f85faf2f2 Merge: cedf03b 05c518b Author: Brad King brad.k...@kitware.com AuthorDate: Mon Dec 9 10:33:11 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Dec 9 10:33:11 2013 -0500 Merge topic 'qt4-qmake-exe' 05c518b FindQt4: Restore ability to handle a changed QT_QMAKE_EXECUTABLE properly. --- Summary of changes: Modules/FindQt4.cmake |5 + 1 files changed, 5 insertions(+), 0 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12.1-899-g1ab140e
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 1ab140ef8f4be77503f59f25d6e2a036d0f44ca2 (commit) via 0b9906c2fba3fa7d2aebc5e217da31cd129b2bfc (commit) from 1c95ec6316e5f8b411abf79dbf5d4c6f85faf2f2 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1ab140ef8f4be77503f59f25d6e2a036d0f44ca2 commit 1ab140ef8f4be77503f59f25d6e2a036d0f44ca2 Merge: 1c95ec6 0b9906c Author: Brad King brad.k...@kitware.com AuthorDate: Mon Dec 9 10:33:24 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Dec 9 10:33:24 2013 -0500 Merge topic 'unicode-win32-apis' 0b9906c Windows: Use wide-character system APIs --- Summary of changes: Source/CPack/WiX/cmCPackWIXGenerator.cxx | 10 ++-- Source/cmExportCommand.cxx| 19 +--- Source/cmFileTimeComparison.cxx |5 ++- Source/cmFindPackageCommand.cxx | 29 ++-- Source/cmGlobalVisualStudio7Generator.cxx |9 ++-- Source/cmGlobalVisualStudioGenerator.cxx | 72 +++- Source/cmLocalVisualStudio7Generator.cxx |2 +- Source/cmSystemTools.cxx | 32 Source/cmcldeps.cxx |7 ++- 9 files changed, 107 insertions(+), 78 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12.1-904-g330af68
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 330af68ed4eca375160b31aefd71bd6ea11b586f (commit) via ca9e11727b697be364200b5fd8b45bf7ad6f6f7b (commit) from 5026696fcc79e1ec4b1f40069566614852b4c312 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=330af68ed4eca375160b31aefd71bd6ea11b586f commit 330af68ed4eca375160b31aefd71bd6ea11b586f Merge: 5026696 ca9e117 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Dec 9 10:35:58 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Dec 9 10:35:58 2013 -0500 Merge topic 'vtk-contract' ca9e117 Tests/Contracts: Fix failing VTK Contract test --- Summary of changes: Tests/Contracts/VTK/CMakeLists.txt |3 +-- Tests/Contracts/VTK/Dashboard.cmake.in |4 ++-- 2 files changed, 3 insertions(+), 4 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6125-gc32326c
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via c32326caa94bfe3ae5910270c62740f891201f1f (commit)
via 65ee85d0c5b0ef4c84c3cf390c0af17ef29e1504 (commit)
from 5b66514165284f395f6f694b12c4c79b268c2600 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c32326caa94bfe3ae5910270c62740f891201f1f
commit c32326caa94bfe3ae5910270c62740f891201f1f
Merge: 5b66514 65ee85d
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Dec 9 10:41:34 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 9 10:41:34 2013 -0500
Merge topic 'xcode-5.1' into next
65ee85d CMakeDetermineCompilerId: Fix compiler line match for Xcode 5.1
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=65ee85d0c5b0ef4c84c3cf390c0af17ef29e1504
commit 65ee85d0c5b0ef4c84c3cf390c0af17ef29e1504
Author: Ted Kremenek kreme...@apple.com
AuthorDate: Mon Dec 9 10:20:47 2013 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Dec 9 10:40:42 2013 -0500
CMakeDetermineCompilerId: Fix compiler line match for Xcode 5.1
Xcode 5.1 output no longer puts ./ in the path to the linker output
for the CompilerId test binary. Update our regex to match the path
with or without the component.
diff --git a/Modules/CMakeDetermineCompilerId.cmake
b/Modules/CMakeDetermineCompilerId.cmake
index 8ca5334..dd0c2bd 100644
--- a/Modules/CMakeDetermineCompilerId.cmake
+++ b/Modules/CMakeDetermineCompilerId.cmake
@@ -209,7 +209,7 @@ Id flags: ${testflags}
# ...
# /path/to/cc ...CompilerId${lang}/...
# to extract the compiler front-end for the language.
-if(${CMAKE_${lang}_COMPILER_ID_OUTPUT} MATCHES \nLd[^\n]*(\n[
\t]+[^\n]*)*\n[ \t]+([^
\t\r\n]+)[^\r\n]*-o[^\r\n]*CompilerId${lang}/\\./CompilerId${lang}[ \t\n\\\])
+if(${CMAKE_${lang}_COMPILER_ID_OUTPUT} MATCHES \nLd[^\n]*(\n[
\t]+[^\n]*)*\n[ \t]+([^
\t\r\n]+)[^\r\n]*-o[^\r\n]*CompilerId${lang}/(\\./)?CompilerId${lang}[
\t\n\\\])
set(_comp ${CMAKE_MATCH_2})
if(EXISTS ${_comp})
set(CMAKE_${lang}_COMPILER_ID_TOOL ${_comp} PARENT_SCOPE)
---
Summary of changes:
Modules/CMakeDetermineCompilerId.cmake |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6123-g5b66514
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 5b66514165284f395f6f694b12c4c79b268c2600 (commit) via 330af68ed4eca375160b31aefd71bd6ea11b586f (commit) via 5026696fcc79e1ec4b1f40069566614852b4c312 (commit) via 1ab140ef8f4be77503f59f25d6e2a036d0f44ca2 (commit) via 1c95ec6316e5f8b411abf79dbf5d4c6f85faf2f2 (commit) via cedf03b30711a1d93f00eaed0b92dc3538ec660d (commit) from ac1055496fd2a905bb7b273d4bd44d7587958082 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5b66514165284f395f6f694b12c4c79b268c2600 commit 5b66514165284f395f6f694b12c4c79b268c2600 Merge: ac10554 330af68 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Dec 9 10:36:29 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Dec 9 10:36:29 2013 -0500 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6127-gaa8e2a9
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via aa8e2a9bd9cd4f227602798f77a8452252f47b7b (commit)
via 61b39af353c401e1c188ab33c23ee06698f4fc30 (commit)
from c32326caa94bfe3ae5910270c62740f891201f1f (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aa8e2a9bd9cd4f227602798f77a8452252f47b7b
commit aa8e2a9bd9cd4f227602798f77a8452252f47b7b
Merge: c32326c 61b39af
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Dec 9 13:01:08 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 9 13:01:08 2013 -0500
Merge topic 'libarchive-left-shift-fix' into next
61b39af libarchive: Port upstream issue 320 second fix
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61b39af353c401e1c188ab33c23ee06698f4fc30
commit 61b39af353c401e1c188ab33c23ee06698f4fc30
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 25 11:16:45 2013 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Dec 9 12:55:21 2013 -0500
libarchive: Port upstream issue 320 second fix
Port upstream commit 6cf33c93 (Issue 320: Rewrite (again) to avoid
the left shift that CLang dislikes so much, 2013-12-07) into CMake.
Inspired-by: Tim Kientzle kient...@freebsd.org
diff --git
a/Utilities/cmlibarchive/libarchive/archive_read_support_format_tar.c
b/Utilities/cmlibarchive/libarchive/archive_read_support_format_tar.c
index a4dc710..bb9d533 100644
--- a/Utilities/cmlibarchive/libarchive/archive_read_support_format_tar.c
+++ b/Utilities/cmlibarchive/libarchive/archive_read_support_format_tar.c
@@ -2412,9 +2412,10 @@ tar_atol(const char *p, size_t char_cnt)
static int64_t
tar_atol_base_n(const char *p, size_t char_cnt, int base)
{
- int64_t l, limit, last_digit_limit;
+ int64_t l, maxval, limit, last_digit_limit;
int digit, sign;
+ maxval = INT64_MAX;
limit = INT64_MAX / base;
last_digit_limit = INT64_MAX % base;
@@ -2431,6 +2432,10 @@ tar_atol_base_n(const char *p, size_t char_cnt, int base)
sign = -1;
p++;
char_cnt--;
+
+ maxval = INT64_MIN;
+ limit = -(INT64_MIN / base);
+ last_digit_limit = INT64_MIN % base;
}
l = 0;
@@ -2438,8 +2443,7 @@ tar_atol_base_n(const char *p, size_t char_cnt, int base)
digit = *p - '0';
while (digit = 0 digit base char_cnt != 0) {
if (llimit || (l == limit digit
last_digit_limit)) {
- l = INT64_MAX; /* Truncate on overflow. */
- break;
+ return maxval; /* Truncate on overflow. */
}
l = (l * base) + digit;
digit = *++p - '0';
@@ -2462,32 +2466,56 @@ tar_atol10(const char *p, size_t char_cnt)
}
/*
- * Parse a base-256 integer. This is just a straight signed binary
- * value in big-endian order, except that the high-order bit is
- * ignored.
+ * Parse a base-256 integer. This is just a variable-length
+ * twos-complement signed binary value in big-endian order, except
+ * that the high-order bit is ignored. The values here can be up to
+ * 12 bytes, so we need to be careful about overflowing 64-bit
+ * (8-byte) integers.
+ *
+ * This code unashamedly assumes that the local machine uses 8-bit
+ * bytes and twos-complement arithmetic.
*/
static int64_t
tar_atol256(const char *_p, size_t char_cnt)
{
- int64_t l, upper_limit, lower_limit;
+ uint64_t l;
const unsigned char *p = (const unsigned char *)_p;
+ unsigned char c, neg;
+
+ /* Extend 7-bit 2s-comp to 8-bit 2s-comp, decide sign. */
+ c = *p;
+ if (c 0x40) {
+ neg = 0xff;
+ c |= 0x80;
+ l = ~0ULL;
+ } else {
+ neg = 0;
+ c = 0x7f;
+ l = 0;
+ }
- upper_limit = INT64_MAX / 256;
- lower_limit = INT64_MIN / 256;
+ /* If more than 8 bytes, check that we can ignore
+* high-order bits without overflow. */
+ while (char_cnt sizeof(int64_t)) {
+ --char_cnt;
+ if (c != neg)
+ return neg ? INT64_MIN : INT64_MAX;
+ c = *++p;
+ }
- /* Sign-extend the 7-bit value to 64 bits. */
- if ((0x40 *p) == 0x40)
- l = ~((int64_t)0x3f) | *p++;
- else
- l = 0x3f *p++;
+ /* c is first byte that fits; if sign mismatch,
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6129-g2d35d00
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 2d35d005e98784eafb2e530e528e08da3733ec46 (commit)
via 31ca983c5b518efe0aeef79c1890f4faaadc3855 (commit)
from aa8e2a9bd9cd4f227602798f77a8452252f47b7b (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2d35d005e98784eafb2e530e528e08da3733ec46
commit 2d35d005e98784eafb2e530e528e08da3733ec46
Merge: aa8e2a9 31ca983
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Dec 9 13:33:02 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 9 13:33:02 2013 -0500
Merge topic 'fix-INTERFACE-mapped-config' into next
31ca983 Don't search for IMPORTED_LOCATION of INTERFACE_LIBRARY (14636)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=31ca983c5b518efe0aeef79c1890f4faaadc3855
commit 31ca983c5b518efe0aeef79c1890f4faaadc3855
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Dec 9 19:12:57 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Mon Dec 9 19:30:49 2013 +0100
Don't search for IMPORTED_LOCATION of INTERFACE_LIBRARY (14636)
The INTERFACE_LIBRARY type does not have any LOCATION at all, so
return early from GetMappedConfig. GetMappedConfig is called from
two locations, one of which already pre-checks the INTERFACE_LIBRARY
case. Remove that pre-check and handle that case inside the method
instead.
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 38fe945..51ee31a 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -4860,6 +4860,15 @@ bool cmTarget::GetMappedConfig(std::string const
desired_config,
const char** imp,
std::string suffix) const
{
+ if (this-GetType() == INTERFACE_LIBRARY)
+{
+// This method attempts to find a config-specific LOCATION for the
+// IMPORTED library. In the case of INTERFACE_LIBRARY, there is no
+// LOCATION at all, so leaving *loc and *imp unchanged is the appropriate
+// and valid response.
+return true;
+}
+
// Track the configuration-specific property suffix.
suffix = _;
suffix += desired_config;
@@ -4992,8 +5001,7 @@ void cmTarget::ComputeImportInfo(std::string const
desired_config,
const char* loc = 0;
const char* imp = 0;
std::string suffix;
- if (this-GetType() != INTERFACE_LIBRARY
- !this-GetMappedConfig(desired_config, loc, imp, suffix))
+ if (!this-GetMappedConfig(desired_config, loc, imp, suffix))
{
return;
}
---
Summary of changes:
Source/cmTarget.cxx | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6131-gf3ccb10
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via f3ccb10eee8f1ac0ad2d9f88c93d7eddbdf02172 (commit)
via bc49d820a276243324003bc34d92a69194938adf (commit)
from 2d35d005e98784eafb2e530e528e08da3733ec46 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f3ccb10eee8f1ac0ad2d9f88c93d7eddbdf02172
commit f3ccb10eee8f1ac0ad2d9f88c93d7eddbdf02172
Merge: 2d35d00 bc49d82
Author: Daniele E. Domenichelli daniele.domeniche...@gmail.com
AuthorDate: Mon Dec 9 13:34:12 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 9 13:34:12 2013 -0500
Merge topic 'FindFreetype-2.5' into next
bc49d82 FindFreetype: Detect version string with Freetype 2.5
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bc49d820a276243324003bc34d92a69194938adf
commit bc49d820a276243324003bc34d92a69194938adf
Author: Daniele E. Domenichelli daniele.domeniche...@iit.it
AuthorDate: Mon Dec 9 19:33:42 2013 +0100
Commit: Daniele E. Domenichelli daniele.domeniche...@iit.it
CommitDate: Mon Dec 9 19:33:42 2013 +0100
FindFreetype: Detect version string with Freetype 2.5
diff --git a/Modules/FindFreetype.cmake b/Modules/FindFreetype.cmake
index 9520f7d..1f12ba6 100644
--- a/Modules/FindFreetype.cmake
+++ b/Modules/FindFreetype.cmake
@@ -103,8 +103,14 @@ if(FREETYPE_INCLUDE_DIR_ft2build AND
FREETYPE_INCLUDE_DIR_freetype2)
endif()
set(FREETYPE_LIBRARIES ${FREETYPE_LIBRARY})
-if(FREETYPE_INCLUDE_DIR_freetype2 AND EXISTS
${FREETYPE_INCLUDE_DIR_freetype2}/freetype/freetype.h)
-file(STRINGS ${FREETYPE_INCLUDE_DIR_freetype2}/freetype/freetype.h
freetype_version_str
+if(EXISTS ${FREETYPE_INCLUDE_DIR_freetype2}/freetype/freetype.h)
+ set(FREETYPE_H ${FREETYPE_INCLUDE_DIR_freetype2}/freetype/freetype.h)
+elseif(EXISTS ${FREETYPE_INCLUDE_DIR_freetype2}/freetype.h)
+ set(FREETYPE_H ${FREETYPE_INCLUDE_DIR_freetype2}/freetype.h)
+endif()
+
+if(FREETYPE_INCLUDE_DIR_freetype2 AND FREETYPE_H)
+file(STRINGS ${FREETYPE_H} freetype_version_str
REGEX ^#[\t ]*define[\t ]+FREETYPE_(MAJOR|MINOR|PATCH)[\t ]+[0-9]+$)
unset(FREETYPE_VERSION_STRING)
---
Summary of changes:
Modules/FindFreetype.cmake | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6133-g4213f09
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 4213f09b7f048e906a4eca2f623416533ef3c046 (commit)
via 9b08e3f5993eb004e3eb0d9ae8b593f553989f89 (commit)
from f3ccb10eee8f1ac0ad2d9f88c93d7eddbdf02172 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4213f09b7f048e906a4eca2f623416533ef3c046
commit 4213f09b7f048e906a4eca2f623416533ef3c046
Merge: f3ccb10 9b08e3f
Author: Daniele E. Domenichelli daniele.domeniche...@gmail.com
AuthorDate: Mon Dec 9 13:39:55 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 9 13:39:55 2013 -0500
Merge topic 'FindFreetype-2.5' into next
9b08e3f FindFreetype: Remove duplicates in FREETYPE_INCLUDE_DIRS
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9b08e3f5993eb004e3eb0d9ae8b593f553989f89
commit 9b08e3f5993eb004e3eb0d9ae8b593f553989f89
Author: Daniele E. Domenichelli daniele.domeniche...@iit.it
AuthorDate: Mon Dec 9 19:39:23 2013 +0100
Commit: Daniele E. Domenichelli daniele.domeniche...@iit.it
CommitDate: Mon Dec 9 19:39:28 2013 +0100
FindFreetype: Remove duplicates in FREETYPE_INCLUDE_DIRS
In Freetype 2.5 the paths for FREETYPE_INCLUDE_DIR_ft2build and
FREETYPE_INCLUDE_DIR_freetype2 are the same
diff --git a/Modules/FindFreetype.cmake b/Modules/FindFreetype.cmake
index 1f12ba6..6f03c86 100644
--- a/Modules/FindFreetype.cmake
+++ b/Modules/FindFreetype.cmake
@@ -100,6 +100,7 @@ find_library(FREETYPE_LIBRARY
# set the user variables
if(FREETYPE_INCLUDE_DIR_ft2build AND FREETYPE_INCLUDE_DIR_freetype2)
set(FREETYPE_INCLUDE_DIRS
${FREETYPE_INCLUDE_DIR_ft2build};${FREETYPE_INCLUDE_DIR_freetype2})
+ list(REMOVE_DUPLICATES FREETYPE_INCLUDE_DIRS)
endif()
set(FREETYPE_LIBRARIES ${FREETYPE_LIBRARY})
---
Summary of changes:
Modules/FindFreetype.cmake |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6135-g77a2987
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 77a2987069bd75b79eef1b6a611da14c4161dd96 (commit)
via d1e33b21b3a4564a1008784c59dfb1f52fbaba6b (commit)
from 4213f09b7f048e906a4eca2f623416533ef3c046 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=77a2987069bd75b79eef1b6a611da14c4161dd96
commit 77a2987069bd75b79eef1b6a611da14c4161dd96
Merge: 4213f09 d1e33b2
Author: Zack Galbreath zack.galbre...@kitware.com
AuthorDate: Mon Dec 9 14:04:04 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 9 14:04:04 2013 -0500
Merge topic 'vtk-contract' into next
d1e33b2 add notes to VTK Contract build
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1e33b21b3a4564a1008784c59dfb1f52fbaba6b
commit d1e33b21b3a4564a1008784c59dfb1f52fbaba6b
Author: Zack Galbreath zack.galbre...@kitware.com
AuthorDate: Mon Dec 9 14:02:35 2013 -0500
Commit: Zack Galbreath zack.galbre...@kitware.com
CommitDate: Mon Dec 9 14:02:35 2013 -0500
add notes to VTK Contract build
Submit the configured Dashboard script as as Notes file to CDash.
Also add comments about the origin purpose of this test.
diff --git a/Tests/Contracts/VTK/Dashboard.cmake.in
b/Tests/Contracts/VTK/Dashboard.cmake.in
index e33a2de..c3d10f4 100644
--- a/Tests/Contracts/VTK/Dashboard.cmake.in
+++ b/Tests/Contracts/VTK/Dashboard.cmake.in
@@ -1,3 +1,11 @@
+# This submission's role is to test leading edge of cmake development
+# against VTK release
+#
+# Maintainer: Zack Galbreath zack.galbre...@kitware.com
+#
+# This file was generated as part of the CMake/VTK Contracts test.
+# See CMake-src/Tests/Contracts/VTK/ for more information
+
set(CTEST_SITE @SITE@)
set(CTEST_BUILD_NAME Contracts.VTK)
set(CTEST_DASHBOARD_ROOT @base_dir@)
@@ -6,6 +14,7 @@ set(CTEST_BINARY_DIRECTORY ${CTEST_DASHBOARD_ROOT}/VTK-build)
set(CTEST_CMAKE_GENERATOR @CMAKE_GENERATOR@)
set(CTEST_CONFIGURATION_TYPE Debug)
+set(CTEST_NOTES_FILES ${CTEST_SCRIPT_DIRECTORY}/${CTEST_SCRIPT_NAME})
# Assume a Linux build, with a make that supports -j9. Modify this script if
# assumption is ever invalid.
---
Summary of changes:
Tests/Contracts/VTK/Dashboard.cmake.in |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6137-g8542dd9
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 8542dd9c468d2ca6171b033e69320f1bd6c0efdd (commit)
via 0bff4df5f64372260fc4cd0f648f5a19310141a0 (commit)
from 77a2987069bd75b79eef1b6a611da14c4161dd96 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8542dd9c468d2ca6171b033e69320f1bd6c0efdd
commit 8542dd9c468d2ca6171b033e69320f1bd6c0efdd
Merge: 77a2987 0bff4df
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Dec 9 14:05:15 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 9 14:05:15 2013 -0500
Merge topic 'libarchive-left-shift-fix' into next
0bff4df libarchive: Use ARCHIVE_LITERAL_ULL to add ULL integer suffix
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0bff4df5f64372260fc4cd0f648f5a19310141a0
commit 0bff4df5f64372260fc4cd0f648f5a19310141a0
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Dec 9 14:03:43 2013 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Dec 9 14:04:24 2013 -0500
libarchive: Use ARCHIVE_LITERAL_ULL to add ULL integer suffix
The macro maps to an implementation that works on older compilers
when necessary.
diff --git
a/Utilities/cmlibarchive/libarchive/archive_read_support_format_tar.c
b/Utilities/cmlibarchive/libarchive/archive_read_support_format_tar.c
index bb9d533..c7c808f 100644
--- a/Utilities/cmlibarchive/libarchive/archive_read_support_format_tar.c
+++ b/Utilities/cmlibarchive/libarchive/archive_read_support_format_tar.c
@@ -2487,7 +2487,7 @@ tar_atol256(const char *_p, size_t char_cnt)
if (c 0x40) {
neg = 0xff;
c |= 0x80;
- l = ~0ULL;
+ l = ~ARCHIVE_LITERAL_ULL(0);
} else {
neg = 0;
c = 0x7f;
---
Summary of changes:
.../libarchive/archive_read_support_format_tar.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6139-g675d9d1
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 675d9d1ae559a4582c3f2759555f4f1368b638ff (commit)
via 08ebb44e3db459c964a841357fb7860e66c6bad8 (commit)
from 8542dd9c468d2ca6171b033e69320f1bd6c0efdd (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=675d9d1ae559a4582c3f2759555f4f1368b638ff
commit 675d9d1ae559a4582c3f2759555f4f1368b638ff
Merge: 8542dd9 08ebb44
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Dec 9 14:52:08 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 9 14:52:08 2013 -0500
Merge topic 'fix-INTERFACE-mapped-config' into next
08ebb44 Add test.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=08ebb44e3db459c964a841357fb7860e66c6bad8
commit 08ebb44e3db459c964a841357fb7860e66c6bad8
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Dec 9 20:51:33 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Mon Dec 9 20:51:33 2013 +0100
Add test.
diff --git a/Tests/RunCMake/interface_library/RunCMakeTest.cmake
b/Tests/RunCMake/interface_library/RunCMakeTest.cmake
index e257fb3..0d00b71 100644
--- a/Tests/RunCMake/interface_library/RunCMakeTest.cmake
+++ b/Tests/RunCMake/interface_library/RunCMakeTest.cmake
@@ -4,3 +4,4 @@ run_cmake(invalid_name)
run_cmake(target_commands)
run_cmake(no_shared_libs)
run_cmake(whitelist)
+run_cmake(genex_link)
diff --git a/Tests/RunCMake/interface_library/genex_link-result.txt
b/Tests/RunCMake/interface_library/genex_link-result.txt
new file mode 100644
index 000..573541a
--- /dev/null
+++ b/Tests/RunCMake/interface_library/genex_link-result.txt
@@ -0,0 +1 @@
+0
diff --git a/Tests/RunCMake/interface_library/genex_link-stderr.txt
b/Tests/RunCMake/interface_library/genex_link-stderr.txt
new file mode 100644
index 000..10f3293
--- /dev/null
+++ b/Tests/RunCMake/interface_library/genex_link-stderr.txt
@@ -0,0 +1 @@
+^$
diff --git a/Tests/RunCMake/interface_library/genex_link.cmake
b/Tests/RunCMake/interface_library/genex_link.cmake
new file mode 100644
index 000..0dbf029
--- /dev/null
+++ b/Tests/RunCMake/interface_library/genex_link.cmake
@@ -0,0 +1,22 @@
+
+cmake_minimum_required(VERSION 2.8.12.20131125 FATAL_ERROR)
+
+project(genex_link)
+
+set(_main_cpp ${CMAKE_CURRENT_BINARY_DIR}/main.cpp)
+file(WRITE ${_main_cpp}
+ int main(int argc, char** argv) { return 0; }\n
+)
+
+add_library(foo::bar INTERFACE IMPORTED)
+set_target_properties(foo::bar
+ PROPERTIES
+INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_CURRENT_SOURCE_DIR}
+# When not using a generator expression here, no error is generated
+INTERFACE_LINK_LIBRARIES $$NOT:$CONFIG:DEBUG:foo_bar.lib
+)
+
+add_executable(main ${_main_cpp})
+target_include_directories(main PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})
+
+target_link_libraries(main foo::bar)
---
Summary of changes:
.../RunCMake/interface_library/RunCMakeTest.cmake |1 +
.../genex_link-result.txt} |0
.../genex_link-stderr.txt} |0
Tests/RunCMake/interface_library/genex_link.cmake | 22
4 files changed, 23 insertions(+), 0 deletions(-)
copy Tests/RunCMake/{CMP0022/CMP0022-WARN-empty-old-result.txt =
interface_library/genex_link-result.txt} (100%)
copy Tests/RunCMake/{CMP0022/CMP0022-NOWARN-exe-stderr.txt =
interface_library/genex_link-stderr.txt} (100%)
create mode 100644 Tests/RunCMake/interface_library/genex_link.cmake
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12.1-905-ga2489ce
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via a2489ce49c0cbf5582a29ef8c4a0d9728994f465 (commit) from 330af68ed4eca375160b31aefd71bd6ea11b586f (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a2489ce49c0cbf5582a29ef8c4a0d9728994f465 commit a2489ce49c0cbf5582a29ef8c4a0d9728994f465 Author: Kitware Robot kwro...@kitware.com AuthorDate: Tue Dec 10 00:01:08 2013 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Tue Dec 10 00:01:08 2013 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 8cd4750..ec3aadd 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 12) -set(CMake_VERSION_TWEAK 20131209) +set(CMake_VERSION_TWEAK 20131210) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
