On 2015-04-28 14:22-0400 Brad King wrote:
On 04/27/2015 05:53 PM, Alan W. Irwin wrote:
Anybody here got a clue about what is going on?
Please strip it down to a minimal example. That will either find
the culprit or provide a test case we can use independently.
Hi Brad:
The problem is I
I'm trying to patch the CMakeLists.txt for openjpeg. Currently it does:
# Do not use ffast-math for all build, it would produce incorrect results,
only set for release:
SET(CMAKE_C_FLAGS_RELEASE -ffast-math ${CMAKE_C_FLAGS_RELEASE})
Unfortunately, CMAKE_C_FLAGS are also used in link
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 ce6e191ff8036edf510f5ee0ebb8e79d8ae054d2 (commit)
via
Hi,
I'm trying to get Apple's new shading language, Metal, to work with my CMake
project, but I am not having any luck.
Xcode will automagically compile .metal files that are part of the project, but
their Type (in the File Inspector in the right-hand Utilities pane) has to be
set to Default
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 ed9616928b88eef8d7ea7b7f7e02a994ea8b0e59 (commit)
via
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 cacf47a2354c547f40a0cbd6ad9aed248c216c0e (commit)
via
I will be giving a presentation at C++Now
http://cppnow.org
https://cppnow2015.sched.org
all things boost - which will touch upon CMake/CTest/CDash. I have
recommended CMake... for boost - like projects and would like to see it more
widely accepted. http://rrsd.com/blincubator.com/tools_cmak/
Le 28/04/15 12:23, Domen Vrankar a écrit :
Hi,
Sorry for not replying sooner.
Please find attached a patch for the reworked documentation. I tried to make
the doc more consistent with the CPackRPM (doc right after the variable
declaration and options afterwards).
I also put links for the
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 434c868fbb597a1b2694e4a2b25df6055c388035 (commit)
via
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 6e5d72779f4cfbad2ad281b458914b8c0f914116 (commit)
via
Why are we making the restriction more restrictive than it needs to be? We
only need this for multiple targets and not within a single target.
This is how I see it.
1. Using MAIN DEPENDENCY is a useful and desirable feature of FindCUDA.
2. A single input file can be used multiple time to
20150428)
+set(CMake_VERSION_PATCH 20150429)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15538
==
Reported By:Wolfgang
Assigned To:
Nils Gladitz wrote:
On 04/28/2015 09:30 AM, Alan W. Irwin wrote:
OK. Thanks, for pointing that out. Could you make that more obvious
in http://www.cmake.org/cmake/help/v3.2/policy/CMP0026.html, i.e.
change the summary line from
Disallow use of the LOCATION target property.
==
Disallow
Andrey Pokrovskiy wrote:
Hi,
I'm using cmake and CMAKE_TOOLCHAIN_FILE to build the project and it's
dependencies. Some toolchain files have additional options (like API
version, target architecture, linker type, etc.) which you need to
pass to cmake command with -D in addition to the
On 04/28/2015 02:22 PM, Daniel Schepler wrote:
As I understand it, configuration-specific properties are deprecated in favor
of generator expressions. For example:
target_compile_options(openjpeg PRIVATE
$$CONFIG:Release:-ffast-math)
Thanks, that helps. Perhaps not as simple as a
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 1102fd70366672c8e0f3842f095bebda5ccbc8e9 (commit)
via
As I understand it, configuration-specific properties are deprecated in favor
of generator expressions. For example:
target_compile_options(openjpeg PRIVATE
$$CONFIG:Release:-ffast-math)
--
Daniel Schepler
From: CMake [cmake-boun...@cmake.org] on
On 04/28/2015 04:15 PM, Alan W. Irwin wrote:
The problem is I am reporting the problem second-hand, and I don't
have access to a Cygwin platform myself. But from the report I
received the incorrect warning message occurs each time a different
compiler is enabled.
The patch to plplot below
On 2015-04-28 16:44-0400 Brad King wrote:
On 04/28/2015 04:15 PM, Alan W. Irwin wrote:
The problem is I am reporting the problem second-hand, and I don't
have access to a Cygwin platform myself. But from the report I
received the incorrect warning message occurs each time a different
compiler
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 dd4fb08a0bfc3179f8f7d1ff5c1e95a2101e04ac (commit)
via
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 f257a96641455634959ffef001040e03377e0282 (commit)
via
On 04/28/2015 09:30 AM, Alan W. Irwin wrote:
OK. Thanks, for pointing that out. Could you make that more obvious
in http://www.cmake.org/cmake/help/v3.2/policy/CMP0026.html, i.e.
change the summary line from
Disallow use of the LOCATION target property.
==
Disallow use of the LOCATION
May be more clean and efficient to use CMake property SOURCES:
For example:
add_library (MY_LIB src1.cpp src2.cpp)
get_target_property (lib_sources MY_LIB SOURCES)
And variable lib_sources now contains list of sources associated with target.
On 28/04/15 10:30, Roman Wüger
Hello guys,
I use multi-configuration generator (MSVC 2008) and I need to create
one solution containing two configurations for one library target N:
For build type Debug target N is compiled as static library
For build type Release target N is compiled as shared library
Something like this,
Hello Nils,
thank you for the pointers.
On 24/04/15 21:30, Nils Gladitz wrote:
On 24.04.2015 20:55, Gregor Jasny wrote:
Hello,
would it be possible to add generator expression support to CPack
so that I can use $CONFIG within CPACK_PACKAGE_FILE_NAME? I'm
using the CPack module from within my
On 04/28/2015 10:57 AM, Gregor Jasny wrote:
Unfortunately the CPACK_BUILD_CONFIG approach does only work for
multi-config generators. As far as I understand CPACK_BUILD_CONFIG gets
only set if the -C command line option was given to cpack. But this
option is only added conditionally and omitted
Hi Nils:
Thanks for your quick reply. More below in context.
On 2015-04-28 08:45+0200 Nils Gladitz wrote:
On 04/28/2015 08:00 AM, Alan W. Irwin wrote:
The Qt5 cmake documentation at
http://doc.qt.io/qt-5/cmake-manual.html which Steve has referred me
to before states you should use the
On 04/28/2015 09:30 AM, Alan W. Irwin wrote:
I don't understand exactly what you mean by configuration LOCATION
returns. From what you said that term means something different from
LOCATION_CONFIG and in any case is not relevant to my use case of
generating pkg-config *.pc files with our build
2015-04-28 10:57 GMT+02:00 Gregor Jasny gja...@googlemail.com:
Hello Nils,
thank you for the pointers.
On 24/04/15 21:30, Nils Gladitz wrote:
On 24.04.2015 20:55, Gregor Jasny wrote:
Hello,
would it be possible to add generator expression support to CPack
so that I can use $CONFIG
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 47b1c217da98c778d5fe74c7545a14290d752a81 (commit)
via
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 9de73d7ee51073841e0aea83096c187ea365532e (commit)
via
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 70d54b03fd4bae28fd2ff7fe9f3ede1dc50a994a (commit)
via
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 dd675d45faa10de5b9eb4be977e65eae9036bc48 (commit)
via
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 f0673c1022afdc9f9d91ea460efc6790b7aa6289 (commit)
via
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 248a58e790c57a6c8502e5acd0a42098c80fcfa4 (commit)
via
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 5b8c5a6c0bc072ebb79c77f30d2b073d7b9fe4ec (commit)
via
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 c0989eaf2afeebaedfdec4d42fdeb344b867c4f8 (commit)
via
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 4541d1ca9a44ee5d79b641673e79947b16b79642 (commit)
via
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 c82487f42eb97fcf0d0ed517f7724c8bc58cb082 (commit)
via
On 04/27/2015 05:53 PM, Alan W. Irwin wrote:
Anybody here got a clue about what is going on?
Please strip it down to a minimal example. That will either find
the culprit or provide a test case we can use independently.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages
On 2015-04-28 11:57+0200 Nils Gladitz wrote:
On 04/28/2015 11:43 AM, Alan W. Irwin wrote:
@Nils: the origin of the code right below If COMPONENTS... is not
clear. Is that code that should be supplied by a package creator or
code that
should be implemented by every find_package user? And if
The Qt5 cmake documentation at
http://doc.qt.io/qt-5/cmake-manual.html which Steve has referred me
to before states you should use the LOCATION property of targets to
determine the actual path to libraries. The PLplot build system
requires those locations so it can transform them into the -L and
On 04/28/2015 08:00 AM, Alan W. Irwin wrote:
The Qt5 cmake documentation at
http://doc.qt.io/qt-5/cmake-manual.html which Steve has referred me
to before states you should use the LOCATION property of targets to
determine the actual path to libraries. The PLplot build system
requires those
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 d70c4bfbee1754595bde4ee0cc2f0e4efb35cebb (commit)
via
On 04/28/2015 01:20 AM, Alan W. Irwin wrote:
On 2015-04-24 12:33-0700 Alan W. Irwin wrote:
This should be a pretty common issue on Linux since it is quite
typical there that downstream packaging splits up binary results into
different packages. Therefore, I assume there is a CMake solution to
On 04/27/2015 11:48 PM, James Bigler wrote:
The problem is the current detection only barfs (unless I missed
something - please correct if I'm wrong). What we need is detection and
adaptation. Rather than telling the user, DON'T DO THAT! we should be
helping the user out by saying, I know you
On 04/28/2015 11:57 AM, Nils Gladitz wrote:
install(TARGETS plplot1 EXPORT export_plplot1 ...)
install(EXPORT export_plplot1 DESTINATION ${LIB_DIR}/cmake/plplot)
[...]
install(TARGETS plplotN EXPORT export_plplotN ...)
install(EXPORT export_plplotN DESTINATION ${LIB_DIR}/cmake/plplot)
(i.e., N
Hi,
Sorry for not replying sooner.
Please find attached a patch for the reworked documentation. I tried to make
the doc more consistent with the CPackRPM (doc right after the variable
declaration and options afterwards).
I also put links for the variables and changed the formatting a bit.
I am having a look now at the changes you made on the first patch (say
75b0e1679c39ca824a4c49d9e1a2ae2b5f04ae06), file
RunCPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake
Instead of finding lintian and dpkg-deb in the check file
find_program(LINTIAN_EXECUTABLE
Hi,
Would you please add
set( CPACK_DEBIAN_PACKAGE_DEBUG ON)
to the file
MyLibCPackConfig-splitted-components-depend2.cmake.in
so that we also have the debug logs?
I currently don't have access to my computer so I'll send you that in
about a week.
BTW, I do not know what CPackDEB.cmake
Hi Cedric,
This is something that ExternalProject cannot really do for you in an
automatic/safe way. When you do a make clean, you wipe out all knowledge about
the installed package.
However, you can implement this yourself: Before you do the
ExternalProject_Add(eigen ...) call, you can call
On 04/28/2015 11:43 AM, Alan W. Irwin wrote:
@Nils: the origin of the code right below If COMPONENTS... is not
clear. Is that code that should be supplied by a package creator or
code that
should be implemented by every find_package user? And if it should be
supplied by a package creator, does
On 2015-04-28 08:56+0200 Nils Gladitz wrote:
On 04/28/2015 01:20 AM, Alan W. Irwin wrote:
On 2015-04-24 12:33-0700 Alan W. Irwin wrote:
This should be a pretty common issue on Linux since it is quite
typical there that downstream packaging splits up binary results into
different packages.
Hello!
No one knows how to avoid spurious installations with external projects?
Thank you,
Cédric
- Mail original -
De: Cedric Doucet cedric.dou...@inria.fr
À: cmake@cmake.org
Envoyé: Vendredi 24 Avril 2015 11:35:54
Objet: ExternalProject: how to avoid reinstalling after 'make
many places that you would use LOCATION you can use generator expressions
http://www.cmake.org/cmake/help/v3.0/manual/cmake-generator-expressions.7.html
$TARGET_FILE_DIR:targetname
On Tue, Apr 28, 2015 at 12:30 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca
wrote:
Hi Nils:
Thanks for your quick
If someone is interessted in this solution:
set(FilenameUsedFiles ${CMAKE_BINARY_DIR}/UsedFiles.lst)
file(WRITE ${FilenameUsedFiles} )
function (parseArguments)
set(options)
set(oneValueArgs)
set(multiValueArgs)
cmake_parse_arguments(CFG ${options}${oneValueArgs}
If someone is interessted in this solution:
set(FilenameUsedFiles ${CMAKE_BINARY_DIR}/UsedFiles.lst)
file(WRITE ${FilenameUsedFiles} )
function (parseArguments)
set(options)
set(oneValueArgs)
set(multiValueArgs)
cmake_parse_arguments(CFG ${options}${oneValueArgs}
58 matches
Mail list logo
