[cmake-developers] [CMake 0012589]: add_test() BROKEN: docs say target allowed, yet fails to evaluate properties (e.g. custom CMAKE_RUNTIME_OUTPUT_DIRECTORY)

2011-11-23 Thread Mantis Bug Tracker
The following issue has been SUBMITTED. == http://www.itk.org/Bug/view.php?id=12589 == Reported By:Andreas Mohr Assigned To:

Re: [cmake-developers] [PATCH 0/3] The CMake Ninja generator.

2011-11-23 Thread Nicolas Desprès
2011/11/22 Peter Collingbourne pe...@pcc.me.uk On Fri, Nov 18, 2011 at 10:02:54AM +0100, Nicolas Desprès wrote: On Wed, Nov 16, 2011 at 3:05 PM, OKUMURA Yuki m...@cltn.org wrote: (Sorry Bill, i repost here..) 2011/11/16 Bill Hoffman bill.hoff...@kitware.com: - snip - What

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread Bill Hoffman
On 11/22/2011 4:39 PM, Brad King wrote: It is tempting to always require explicit requests for new TRE behavior, such as using TRE instead of REGEX in keyword locations, but one advantage of using a policy is that over time the old behavior will disappear completely from usage. I am pretty

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread James Bigler
On Wed, Nov 23, 2011 at 8:36 AM, Bill Hoffman bill.hoff...@kitware.comwrote: On 11/22/2011 4:39 PM, Brad King wrote: It is tempting to always require explicit requests for new TRE behavior, such as using TRE instead of REGEX in keyword locations, but one advantage of using a policy is that

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread Bill Hoffman
On 11/23/2011 11:43 AM, James Bigler wrote: Why can't this be solved with a policy? One problem of using an explicit TRE command is that if you want to write code that *could* be used in an older version of CMake you won't be able to use it. It could be, but that will not come without pain.

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread Brad King
On 11/23/2011 12:06 PM, Bill Hoffman wrote: On 11/23/2011 11:43 AM, James Bigler wrote: Why can't this be solved with a policy? One problem of using an explicit TRE command is that if you want to write code that *could* be used in an older version of CMake you won't be able to use it. It

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread Alexandru Ciobanu
Hi Bill, On 2011-11-23, at 10:36 AM, Bill Hoffman wrote: I am pretty sure the last time we talked about adding a new regex we talked about requiring explicit requests. I think this would be a much safer approach. I am really scared that this regex will not be compatible with the old

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread Brad King
On 11/23/2011 12:20 PM, Alexandru Ciobanu wrote: to compile ITK using CMake+TRE. And there was at least one regex that TRE refused to compile. What was it, and where in the ITK code is it? Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread Alexandru Ciobanu
On 2011-11-23, at 12:24 PM, Brad King wrote: On 11/23/2011 12:20 PM, Alexandru Ciobanu wrote: to compile ITK using CMake+TRE. And there was at least one regex that TRE refused to compile. What was it, and where in the ITK code is it? The regex in question is: ^[^][:/*?]+\$ And it

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread Brad King
On 11/23/2011 12:34 PM, Alexandru Ciobanu wrote: The regex in question is: ^[^][:/*?]+\$ And it appears at this location in the ITK source tree: CMake/ExternalData.cmake:347 And the expression is correct, because you're allowed to have the ] metacharacter inside a [^xyz] class if

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread Brad King
On 11/23/2011 12:43 PM, Brad King wrote: On 11/23/2011 12:34 PM, Alexandru Ciobanu wrote: The regex in question is: ^[^][:/*?]+\$ And it appears at this location in the ITK source tree: CMake/ExternalData.cmake:347 And the expression is correct, because you're allowed to have the

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread Brad King
On 11/23/2011 12:48 PM, Brad King wrote: On 11/23/2011 12:43 PM, Brad King wrote: On 11/23/2011 12:34 PM, Alexandru Ciobanu wrote: The regex in question is: ^[^][:/*?]+\$ To include a literal ] in the list, make it either the first item It must be the [: in this regex that TRE sees as

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread Bill Hoffman
On 11/23/2011 12:51 PM, Brad King wrote: On 11/23/2011 12:48 PM, Brad King wrote: On 11/23/2011 12:43 PM, Brad King wrote: On 11/23/2011 12:34 PM, Alexandru Ciobanu wrote: The regex in question is: ^[^][:/*?]+\$ To include a literal ] in the list, make it either the first item It

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread David Cole
On Wed, Nov 23, 2011 at 2:03 PM, Bill Hoffman bill.hoff...@kitware.com wrote: On 11/23/2011 12:51 PM, Brad King wrote: On 11/23/2011 12:48 PM, Brad King wrote: On 11/23/2011 12:43 PM, Brad King wrote: On 11/23/2011 12:34 PM, Alexandru Ciobanu wrote: The regex in question is:    

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread Marcus D. Hanwell
On Wed, Nov 23, 2011 at 2:03 PM, Bill Hoffman bill.hoff...@kitware.com wrote: On 11/23/2011 12:51 PM, Brad King wrote: On 11/23/2011 12:48 PM, Brad King wrote: On 11/23/2011 12:43 PM, Brad King wrote: On 11/23/2011 12:34 PM, Alexandru Ciobanu wrote: The regex in question is:    

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread David Cole
On Wed, Nov 23, 2011 at 2:09 PM, David Cole david.c...@kitware.com wrote: On Wed, Nov 23, 2011 at 2:03 PM, Bill Hoffman bill.hoff...@kitware.com wrote: On 11/23/2011 12:51 PM, Brad King wrote: On 11/23/2011 12:48 PM, Brad King wrote: On 11/23/2011 12:43 PM, Brad King wrote: On 11/23/2011

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread Bill Hoffman
On Wed, Nov 23, 2011 at 3:24 PM, Sean McBride s...@rogue-research.com wrote: On Wed, 23 Nov 2011 14:03:20 -0500, Bill Hoffman said: For 99% of folks the current regex is just fine. AFAICT, this performance bug affects 100% of Xcode generator users.  Even looking at CMake's dashboard, you can

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread Brad King
On 11/23/2011 5:43 PM, Brad King wrote: On 11/23/2011 12:44 PM, Brad King wrote: However, the above does not need to stand in the way of solving the problem you're addressing. We can simply set that goal aside for now by not exposing TRE in the CMake language anywhere. Use it just for

Re: [cmake-developers] slow regex implementation in RegularExpression

2011-11-23 Thread Michael Wild
On 11/24/2011 12:34 AM, Brad King wrote: On 11/23/2011 5:43 PM, Brad King wrote: On 11/23/2011 12:44 PM, Brad King wrote: However, the above does not need to stand in the way of solving the problem you're addressing. We can simply set that goal aside for now by not exposing TRE in the CMake

[CMake] Bad documentation of the LINK_INTERFACE_LIBRARIES property and other transitive linking topics

2011-11-23 Thread Alan W. Irwin
cmake-2.8.6 has the following documentation of the LINK_INTERFACE_LIBRARIES property for targets: LINK_INTERFACE_LIBRARIES List public interface libraries for a shared library or executable. By default linking to a shared library target transitively links to targets with

Re: [CMake] Bad documentation of the LINK_INTERFACE_LIBRARIES property and other transitive linking topics

2011-11-23 Thread Michael Wild
On 11/23/2011 10:25 AM, Alan W. Irwin wrote: cmake-2.8.6 has the following documentation of the LINK_INTERFACE_LIBRARIES property for targets: LINK_INTERFACE_LIBRARIES List public interface libraries for a shared library or executable. By default linking to a shared

Re: [CMake] Bad documentation of the LINK_INTERFACE_LIBRARIES property and other transitive linking topics

2011-11-23 Thread Rolf Eike Beer
On 11/23/2011 10:25 AM, Alan W. Irwin wrote: In sum, from this experiment it looks like I will have to set LINK_INTERFACE_LIBRARIES to empty for all PLplot library targets that depend on other library targets (e.g., B, C, D, and E, above, but _not_ main or A) created by our build system to

[CMake] Call to QTextStream(stdin) crashes the program built by CMake and Visual Studio

2011-11-23 Thread Yegor Derevenets
Hi All, The following Qt program crashes with access violation when being built on Windows by Microsoft Visual Studio 2010 using cmake 2.8.6 and doesn't crash when being built using qmake: #include cstdio #include QTextStream int main(int argc, char *argv[]) { QTextStream qin(stdin,

Re: [CMake] Call to QTextStream(stdin) crashes the program built by CMake and Visual Studio

2011-11-23 Thread John Drescher
On Wed, Nov 23, 2011 at 8:53 AM, Yegor Derevenets yegor.dereven...@gmail.com wrote: Hi All, The following Qt program crashes with access violation when being built on Windows by Microsoft Visual Studio 2010 using cmake 2.8.6 and doesn't crash when being built using qmake: #include cstdio

Re: [CMake] CMake, Qt4, Ubuntu and Phonon

2011-11-23 Thread Félix C . Morency
Clinton, I did a small test and it works with qmake because phonon is the standard search paths. It justs add -lphonon to the compiler command line. If not patched, there should be a note in the CMake FindQt4 documentation about the fact that it doesn't support finding phonon as a 3rd party

[CMake] Don't export symbols but the one I want

2011-11-23 Thread David Demelier
Hello, I'm creating a library that use a lot of internal code (not static because it should be visible by other compilation units) so I would like to don't export any symbols but only the one I want. Usually you use __declspec(dllexport) for windows but on unix and gcc everything is

Re: [CMake] Don't export symbols but the one I want

2011-11-23 Thread Pau Garcia i Quiles
Hi, gcc supports symbol visibility also. Check http://gcc.gnu.org/wiki/Visibility On Wed, Nov 23, 2011 at 5:52 PM, David Demelier demelier.da...@gmail.com wrote: Hello, I'm creating a library that use a lot of internal code (not static because it should be visible by other compilation

Re: [CMake] Don't export symbols but the one I want

2011-11-23 Thread Stephen Kelly
David Demelier wrote: Hello, I'm creating a library that use a lot of internal code (not static because it should be visible by other compilation units) so I would like to don't export any symbols but only the one I want. Usually you use __declspec(dllexport) for windows but on unix and

Re: [CMake] Don't export symbols but the one I want

2011-11-23 Thread John Drescher
On Wed, Nov 23, 2011 at 12:30 PM, Stephen Kelly steve...@gmail.com wrote: David Demelier wrote: Hello, I'm creating a library that use a lot of internal code (not static because it should be visible by other compilation units) so I would like to don't export any symbols but only the one I

Re: [CMake] Don't export symbols but the one I want

2011-11-23 Thread David Cole
On Wed, Nov 23, 2011 at 1:26 PM, John Drescher dresche...@gmail.com wrote: On Wed, Nov 23, 2011 at 12:30 PM, Stephen Kelly steve...@gmail.com wrote: David Demelier wrote: Hello, I'm creating a library that use a lot of internal code (not static because it should be visible by other

Re: [CMake] Cmake with cminpack

2011-11-23 Thread Fabian Torres
Hi I'm trying to use cminpack. I've downloaded cminpack 1.1.3 and configure it with cmake to create a Xcode 3.2 project. After building the xcode project successfully I found that it generates a debug directory which contains the library or if the shared_libs option in cmake was on or off

Re: [CMake] transitive linking topics

2011-11-23 Thread Alan W. Irwin
On 2011-11-23 10:44+0100 Michael Wild wrote: On 11/23/2011 10:25 AM, Alan W. Irwin wrote: cmake-2.8.6 has the following documentation of the LINK_INTERFACE_LIBRARIES property for targets: LINK_INTERFACE_LIBRARIES List public interface libraries for a shared library or executable.

[CMake] Path problem using custom compiler and MinGW generator

2011-11-23 Thread Dmitri Kourennyi
Hi, I'm working on an embedded project using a Microchip microcontroller. I want to use Cmake to do the configuration so that I can store the project and build settings under change control, as well as have the configuration compatible with development windows machines, and an automated

Re: [CMake] Bad documentation of the LINK_INTERFACE_LIBRARIES property and other transitive linking topics

2011-11-23 Thread Michael Wild
On 11/23/2011 11:11 AM, Rolf Eike Beer wrote: On 11/23/2011 10:25 AM, Alan W. Irwin wrote: In sum, from this experiment it looks like I will have to set LINK_INTERFACE_LIBRARIES to empty for all PLplot library targets that depend on other library targets (e.g., B, C, D, and E, above, but

[CMake] link_directories issue, cmake 2.8.5

2011-11-23 Thread Vladimir Chebotarev
Hello. I've just found an issue with link_directories and cmake 2.8.5. If I give an absolute but not normalized path like c:/bla-bla-bla/../bla/bla as its argument (with default CMP0015), cmake thinks it is relative path and shows a warning about explicitly undefined policy. Also it normalizes

Re: [CMake] other transitive linking topics

2011-11-23 Thread Alan W. Irwin
On 2011-11-23 11:11+0100 Rolf Eike Beer wrote: On 11/23/2011 10:25 AM, Alan W. Irwin wrote: In sum, from this experiment it looks like I will have to set LINK_INTERFACE_LIBRARIES to empty for all PLplot library targets that depend on other library targets (e.g., B, C, D, and E, above, but

[CMake] Do not build/install import library

2011-11-23 Thread Matthias Gehre
Hi, thanks for this very nice cmake. I switched just recently to get lightspark (lightspark.github.com) crossplatform, and it worked really smooth. One question, though: I cannot seem to find a way to _not_ build/install the import libraries (foobar.dll.a) on win32. I do not need them, because

Re: [CMake] Bad documentation of the LINK_INTERFACE_LIBRARIES property and other transitive linking topics

2011-11-23 Thread Michael Hertling
On 11/23/2011 10:25 AM, Alan W. Irwin wrote: cmake-2.8.6 has the following documentation of the LINK_INTERFACE_LIBRARIES property for targets: LINK_INTERFACE_LIBRARIES List public interface libraries for a shared library or executable. By default linking to a shared

Re: [CMake] transitive linking topics

2011-11-23 Thread Alan W. Irwin
On 2011-11-23 22:35+0100 Michael Hertling wrote: All this to quiet rpmlint warnings Out of curiosity - I have not worked with RPM for ages: Are these warnings and the related overlinking due to transitive dependencies really an issue or just an inconvenience? Personally, I distinguish

Re: [CMake] ccmake was not created

2011-11-23 Thread Mikhail Artemiev
Hi all! Good news - ccmake was created, but for the previous stable version (2.6.4). I still didn't understand what is the problem with ccmake in the last version (2.8.6). Best regards, Mikhail -- Powered by www.kitware.com Visit other Kitware open-source projects at

Re: [CMake] Bad documentation of the LINK_INTERFACE_LIBRARIES property and other transitive linking topics

2011-11-23 Thread Hendrik Sattler
Am 23.11.2011 22:35, schrieb Michael Hertling: Out of curiosity - I have not worked with RPM for ages: Are these warnings and the related overlinking due to transitive dependencies really an issue or just an inconvenience? Personally, I distinguish between real overlinking, i.e. pulling in

[Cmake-commits] CMake branch, master, updated. v2.8.6-265-g57a8523

2011-11-23 Thread KWSys Robot
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 57a85237ac8ebc429ebe442897169bc9369e0380 (commit) from

[Cmake-commits] CMake branch, master, updated. v2.8.6-270-g1ec3801

2011-11-23 Thread David Cole
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 1ec3801a3ae3969b9530163b79209df26dd1bb45 (commit) via

[Cmake-commits] CMake branch, next, updated. v2.8.6-2022-g8129c32

2011-11-23 Thread David Cole
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 8129c3296c615adab5538dbc171c5364a04d50f5 (commit) via

[Cmake-commits] CMake branch, next, updated. v2.8.6-2025-g9e7fde5

2011-11-23 Thread Brad King
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 9e7fde55127cb2bd1e9ab52d97b43db09ad89a16 (commit) via