Re: [CMake] What is the default build type?

[Marcus D. Hanwell]

On Wed, Aug 2, 2017 at 4:18 PM, J Decker <d3c...@gmail.com> wrote:
>
> On Wed, Aug 2, 2017 at 8:55 AM, Marcus D. Hanwell 
> <marcus.hanw...@kitware.com> wrote:
>>
>> On Wed, Aug 2, 2017 at 3:03 AM, Bo Zhou <bo.schwarzst...@gmail.com> wrote:
>>>
>>> It depends on the Generator.
>>>
>>> To the Makefile, the actual type was controlled by the compiler options. If 
>>> you don't specific any type, usually it means non-debug and 
>>> non-optimization because the CMAKE_CXX_FLAGS is empty as default. This is 
>>> critical, so usually people should specific the actual type they want to 
>>> build.
>>>
>>> To the generator of the IDE, such as Visual Studio and Xcode, the 
>>> CMAKE_BUILD_TYPE doesn't make sense but we have to use 
>>> CMAKE_CONFIGURATION_TYPES, then CMake will create the several configuration 
>>> sets for the IDE from the CMAKE_C|CXX_FLAGS_{CONFIG} .
>>
>>
>> This thread inspired me to write up how we have been doing it in some of the 
>> projects I work on for quite a while now,
>>
>> https://blog.kitware.com/cmake-and-the-default-build-type/
>>
> These should use lower case 'debug' 'release' etc.  Because if it's not VS, 
> it's probably also not windows, and case matters.
>
No, camel case works just fine. I took a quick look and lowercase will
work, as well as all caps. I have used this for many years on Linux
builds with Makefile/Ninja without issue.
-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] What is the default build type?

[Marcus D. Hanwell]

On Wed, Aug 2, 2017 at 2:50 PM, David Cole  wrote:
> Yes, your code is a good example Marcus. It was one of the previous
> suggestions on this thread which had example code setting
> CMAKE_CONFIGURATION_TYPES.
>
> I would recommend against setting this variable because in some places
> in CMake code, it is used as an approximate proxy for whether or not a
> multi-configuration generator is being used.
>
Ah, thanks for clearing that up, it was unclear if there were issues
you spotted with what I posted, now I reread it I see. I thought I had
been pretty careful not to pollute variables meant for
multi-configuration generators :-) I may have even asked you about
this many moons ago, and possibly got the enum-style list from
something you posted.
-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] What is the default build type?

[Marcus D. Hanwell]

On Wed, Aug 2, 2017 at 1:32 PM, David Cole  wrote:
> Very cool, Marcus. Thanks for the blog post.
>
> Florian, when you "message(${CMAKE_CONFIGURATION_TYPES})" it is empty
> because you are using a single-configuration CMake generator. Only
> Visual Studio and Xcode (and possibly other) **multi** config
> generators have a list of values in CMAKE_CONFIGURATION_TYPES.
> Contrary to the previous recommendation, I would NOT recommend setting
> it to a list in a single configuration generator. If you're using a
> multi-config generator, you can set up a subset for it to use with
> this, but in a single config generator, this variable SHOULD be empty,
> and you should not give it contents in that case.
>
Terrible English, try number two... Why would you not recommend
setting it, and what do you mean by it? I was not setting
CMAKE_CONFIGURATION_TYPES to anything, but the CMAKE_BUILD_TYPE
property is manipulated to offer the list, and then the
CMAKE_BUILD_TYPE variable is populated if it is empty in my example.
-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] What is the default build type?

[Marcus D. Hanwell]

On Wed, Aug 2, 2017 at 1:32 PM, David Cole  wrote:
>
> Very cool, Marcus. Thanks for the blog post.
>
> Florian, when you "message(${CMAKE_CONFIGURATION_TYPES})" it is empty
> because you are using a single-configuration CMake generator. Only
> Visual Studio and Xcode (and possibly other) **multi** config
> generators have a list of values in CMAKE_CONFIGURATION_TYPES.
> Contrary to the previous recommendation, I would NOT recommend setting
> it to a list in a single configuration generator. If you're using a
> multi-config generator, you can set up a subset for it to use with
> this, but in a single config generator, this variable SHOULD be empty,
> and you should not give it contents in that case.
>
Why you would not recommend setting it to a list for a single
configuration generator.
-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] What is the default build type?

[Marcus D. Hanwell]

On Wed, Aug 2, 2017 at 3:03 AM, Bo Zhou  wrote:

> It depends on the Generator.
>
> To the Makefile, the actual type was controlled by the compiler options.
> If you don't specific any type, usually it means non-debug and
> non-optimization because the CMAKE_CXX_FLAGS is empty as default. This is
> critical, so usually people should specific the actual type they want to
> build.
>
> To the generator of the IDE, such as Visual Studio and Xcode, the
> CMAKE_BUILD_TYPE doesn't make sense but we have to use
> CMAKE_CONFIGURATION_TYPES, then CMake will create the several configuration
> sets for the IDE from the CMAKE_C|CXX_FLAGS_{CONFIG} .
>

This thread inspired me to write up how we have been doing it in some of
the projects I work on for quite a while now,

https://blog.kitware.com/cmake-and-the-default-build-type/

It certainly isn't the only way, but it provides an easy path to ensure
things show up in the GUIs, respect build types passed in, etc.
-- 

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://public.kitware.com/mailman/listinfo/cmake

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc2-866-g23378e8

[Marcus D . Hanwell]

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  23378e88aca447aacce995fb6433cb25ba958c9a (commit)
   via  ecc74c41abd21ef2c0c8d34124a29f9201f06927 (commit)
  from  e0af67b4fc05970cea3007f0ae4b97d5e3f512d4 (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23378e88aca447aacce995fb6433cb25ba958c9a
commit 23378e88aca447aacce995fb6433cb25ba958c9a
Merge: e0af67b ecc74c4
Author:     Marcus D. Hanwell <marcus.hanw...@kitware.com>
AuthorDate: Tue Nov 1 13:41:25 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Nov 1 13:41:25 2016 -0400

Merge topic 'find-qt5-docs' into next

ecc74c41 Update Qt 5 find_package call to use COMPONENTS


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ecc74c41abd21ef2c0c8d34124a29f9201f06927
commit ecc74c41abd21ef2c0c8d34124a29f9201f06927
Author: Marcus D. Hanwell <marcus.hanw...@kitware.com>
AuthorDate: Tue Nov 1 12:44:34 2016 -0400
Commit: Marcus D. Hanwell <marcus.hanw...@kitware.com>
CommitDate: Tue Nov 1 12:44:34 2016 -0400

Update Qt 5 find_package call to use COMPONENTS

diff --git a/Help/manual/cmake-qt.7.rst b/Help/manual/cmake-qt.7.rst
index e8a2c1e..bd0a984 100644
--- a/Help/manual/cmake-qt.7.rst
+++ b/Help/manual/cmake-qt.7.rst
@@ -29,7 +29,7 @@ Qt 4 and Qt 5 may be used together in the same
   set(CMAKE_AUTOMOC ON)
   set(CMAKE_INCLUDE_CURRENT_DIR ON)
 
-  find_package(Qt5Widgets REQUIRED)
+  find_package(Qt5 COMPONENTS Widgets REQUIRED)
   add_executable(publisher publisher.cpp)
   target_link_libraries(publisher Qt5::Widgets Qt5::DBus)
 

---

Summary of changes:
 Help/manual/cmake-qt.7.rst |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] default release build flags

[Marcus D. Hanwell]

On Thu, Apr 28, 2016 at 2:21 PM, Burlen Loring  wrote:
> Hi Guys,
>
> I'd like to discuss changing the defaults of CMAKE_C/CXX_FLAGS_RELEASE on
> gcc, and potentially gcc like compilers such as clang and intel.
>
> Currently the default is "-O3 -DNDEBUG". I would like to discuss changing
> this to "-O3 -march=native -mtune=native -DNDEBUG". This change will enable
> numerous optimizations and produce faster code targeted for the cpu in use
> during the compilation.
>
As someone who was bitten by a project enabling -march=native in their
CMake-based build system, and the days of debugging as this was a
nested dependency built in a superbuild to create a package I hope we
never make that a default.

As a former Gentoo developer who has seen that -O3 is often not the
best default flag for optimized builds I would actually suggest
changing the default to "-O2 -DNDEBUG". The binaries are normally
smaller, compile times faster, and the resulting code faster. Quoting
from the wiki (https://wiki.gentoo.org/wiki/GCC_optimization):

'-O3: the highest level of optimization possible. It enables
optimizations that are expensive in terms of compile time and memory
usage. Compiling with -O3 is not a guaranteed way to improve
performance, and in fact, in many cases, can slow down a system due to
larger binaries and increased memory usage. -O3 is also known to break
several packages. Using -O3 is not recommended.'

I think adding a RelWithNative or RelAgressiveOpt might be an option,
but there are a number of things like distcc that makes applying
-march=native undesirable. For those that know what they are doing
certainly, but there are side effects and debugging can be tricky for
the poor packagers too (who often have limited resources, and do not
expect this).

My $0.03 cents as someone who may have lost a little hair over this ;-)

Marcus
-- 

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://public.kitware.com/mailman/listinfo/cmake

[cmake-developers] Adding source files not built by targets to CMake project

[Marcus D. Hanwell]

Hi,

As far as I know this is not possible, but I would love for someone to
point out the CMake invocation I missed. More and more we use a
mixture of languages in projects, such as in VTK where we have Python
wrapping, and tomviz where we have a number of algorithms implemented
in Python (and I am looking at adding some metadata files that are
JSON, others are using XML).

I would like to see these files listed in Qt Creator (or insert your
IDE of choice here). Is there anyway to do this, knowing that these
files are not going to be built for a target (or compiled in any way).
Any trick I am missing to make this work? When I include a .cmake file
I see it is added, so I feel like there is some plumbing already in
place to feed through these source files that are not built by
targets.

Sorry if this came up already, my Google skills couldn't find anything...

Thanks,

Marcus
-- 

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://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding source files not built by targets to CMake project

[Marcus D. Hanwell]

On Fri, Nov 20, 2015 at 10:46 AM, Nils Gladitz <nilsglad...@gmail.com> wrote:
> On 11/20/2015 04:43 PM, Marcus D. Hanwell wrote:
>>
>> I would like to see these files listed in Qt Creator (or insert your
>> IDE of choice here). Is there anyway to do this, knowing that these
>> files are not going to be built for a target (or compiled in any way).
>> Any trick I am missing to make this work? When I include a .cmake file
>> I see it is added, so I feel like there is some plumbing already in
>> place to feed through these source files that are not built by
>> targets.
>
>
> If they are related to an existing build target
> (add_executable()/add_library()) you can list them there with your regular
> sources.
> Otherwise e.g. add_custom_target(my_custom_target SOURCES foo.py bar.json
> ...) should work.
>
Thanks, the add_custom_target works great. I hadn't thought of trying
that, glad the answer was so simple.

Marcus
-- 

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://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] DeployQt5/generalizing DeployQt4 for Qt5

[Marcus D. Hanwell]

On Sun, Feb 16, 2014 at 6:57 PM, Stephen Kelly steve...@gmail.com wrote:
 Marcus D. Hanwell wrote:

 On Sun, Feb 16, 2014 at 4:30 PM, Stephen Kelly
 steve...@gmail.com wrote:
 Marcus D. Hanwell wrote:

 Hi,

 Is anyone working on, or have, a DeployQt5 or a generalized DeployQt4?
 We use it in our packaging process, and it is one of the last things I
 need to switch to Qt 5. If not, I was going to take a look at this,
 and see what I can put together.

 I've never used DeployQt4 or BundleUtilities, and I don't know much about
 Mac (which BundleUtilities seems to strongly relate to somehow), so I
 don't know what is needed from a DeployQt5, which is why I haven't
 written such a thing yet. It seems like something that should be
 versioned with and shipped with Qt 5.

 It was contributed by Mike McQuaid (from KDAB too I think).

 I think he first contributed it before joining KDAB, but now he's at Github:

  https://github.com/blog/1711-mike-mcquaid-is-a-githubber

I even read that, but didn't put it together in this context ;-)

 How are
 you currently packaging Qt application binaries on Windows, Linux and
 Mac?

 Generally it's not me personally doing that stuff, but colleagues. Those
 colleagues don't have 'make it pure' as a goal, are not interested in cmake
 generally, but just need to get that part done, and need to do something
 else instead.

Fair enough, we are really aiming for the simplest way to reliably
package on all three platforms and this has been working pretty well.

 * It seems to have macros related to plugins. When using a statically
 built Qt, plugins are also relevant in the buildsystem because I need to
 compile them into my application. Should there be one generic interface
 in CMake for both this kind of thing and what DeployQt4 is doing?

 Perhaps, but I am most concerned at this point with the simplest way
 of porting the remaining part of the build system.

 Yes, I understand that.

  http://cmake.3232098.n2.nabble.com/DeployQt5-cmake-td7585218.html

 shows that it can be done in a straightforward way.

I missed that in my searches - thanks for pointing it out.

 I would prefer
 something like DeployQt4 for simplicity, and not requiring me to bump
 my Qt dependency to 5.3 for packaging, so in the short term at least I
 would like to offer similar functionality for Qt 5 in a CMake helper.

 It seems that you can do something simple for your current need and get
 something modern into Qt 5.3, if it makes sense to do something different
 from 'something simple'.

 The new Qt 5 CMake support seems really strong, but I was left
 wondering what I should do for packaging.

 Yes. The intersection of experience, knowledge, time etc hasn't appeared to
 add something that makes sense yet.

I would be happy to help here if I can, I want to ensure Qt 5 is at
least as simple as Qt 4 was to create packages using CMake.

 I know that Digia are working on some deployment stuff with unification of
 concepts particularly with regard to embedded systems deployment in mind. I
 don't want to create too many diverging concepts there, and would prefer to
 see what comes out of that, or at least understand the thing fully, before
 committing to something in the cmake files shipped with Qt 5.

Agreed, I will keep an eye out for this. In the short term is would
seem an adaptation of DeployQt4 is reasonable, unless I hear from
someone else that they have something way better working already.

Thanks,

Marcus
-- 

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

[cmake-developers] DeployQt5/generalizing DeployQt4 for Qt5

[Marcus D. Hanwell]

Hi,

Is anyone working on, or have, a DeployQt5 or a generalized DeployQt4?
We use it in our packaging process, and it is one of the last things I
need to switch to Qt 5. If not, I was going to take a look at this,
and see what I can put together.

Thanks,

Marcus
-- 

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] DeployQt5/generalizing DeployQt4 for Qt5

[Marcus D. Hanwell]

On Sun, Feb 16, 2014 at 4:30 PM, Stephen Kelly steve...@gmail.com wrote:
 Marcus D. Hanwell wrote:

 Hi,

 Is anyone working on, or have, a DeployQt5 or a generalized DeployQt4?
 We use it in our packaging process, and it is one of the last things I
 need to switch to Qt 5. If not, I was going to take a look at this,
 and see what I can put together.

 I've never used DeployQt4 or BundleUtilities, and I don't know much about
 Mac (which BundleUtilities seems to strongly relate to somehow), so I don't
 know what is needed from a DeployQt5, which is why I haven't written such a
 thing yet. It seems like something that should be versioned with and shipped
 with Qt 5.

It was contributed by Mike McQuaid (from KDAB too I think). How are
you currently packaging Qt application binaries on Windows, Linux and
Mac?

 The intersection of people who know a lot/enough about CMake, packages, and
 DeployQt4, and Qt 5 is a small set. Please help me with these questions:

Sure, David Cole actually wrote a lot of the packaging code that uses
DeployQt4, but I will do my best (he will hopefully correct me if I
miss anything).

 * What is so special about Qt deployment that it needs special handling in
 CMake? Why is there no (to pick some random examples) DeployLibLZMA,
 DeployMPEG, DeployVTK etc? Is it really mostly just the path adjustment
 stuff and the qt.conf?

Path adjustment, qt.conf, locations of binaries for release/debug on
Windows, Qt is different enough that packaging it needs some simple
helpers. Using it with bundle utilities helps to track down all of the
necessary dependencies that should be put in a binary package, and
avoids attempting to copy system files by going too far.

 * How is it used in real-life? How does it intersect to cpack related code?

The MoleQueue application is perhaps one of the simpler ones where we
use it with CPack to create Windows and Mac installers automatically.

 * It was written in a different era of CMake design. How do things like
 guaranteed use of IMPORTED targets (as Qt 5 ensures), listing of the
 libraries in INTERFACE_LINK_LIBRARIES, or other modern features of CMake
 affect the design of DeployQt5?

I think it would still need the same kind of logic to bring in libs
that Qt libraries link to, Qt plugins, etc. Knowing which libraries
are linked to and their location was always the simpler piece, putting
the qt.conf file in the correct location, bringing along the correct
Qt plugins, etc, fixing up the paths of the binaries to only reference
the bundled Qt are all taken care of for us with this helper.

 * It seems to have macros related to plugins. When using a statically built
 Qt, plugins are also relevant in the buildsystem because I need to compile
 them into my application. Should there be one generic interface in CMake for
 both this kind of thing and what DeployQt4 is doing?

Perhaps, but I am most concerned at this point with the simplest way
of porting the remaining part of the build system. I would prefer
something like DeployQt4 for simplicity, and not requiring me to bump
my Qt dependency to 5.3 for packaging, so in the short term at least I
would like to offer similar functionality for Qt 5 in a CMake helper.

 * How should the parameters of the functions be changed? They seem to not
 use MacroParseArguments.

I have no strong opinions, I am happy to show you how we currently use
it. The new Qt 5 CMake support seems really strong, but I was left
wondering what I should do for packaging. I would like something that
would work with Qt 5.0+, I am not overly tied to DeployQt4 if there is
a better way to do this, but hope to get something that is similarly
robust once it is up and running in our projects.

Thanks,

Marcus
-- 

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] CMake master, Qt dialog and Qt4/5 installed has problems

[Marcus D. Hanwell]

On Mon, Apr 8, 2013 at 10:04 AM, Brad King brad.k...@kitware.com wrote:
 On 04/07/2013 06:29 AM, Stephen Kelly wrote:
 Brad King wrote:
  http://open.cdash.org/viewBuildError.php?buildid=2865930

 because there is no //bin/moc.

 Interesting. Can you say more about what happens? The point of the patch is
 that because there is no //bin/moc, the else branch should be entered and
 Qt 4 should be found and used. If that's not happening, it's not working as
 expected.

 Marcus, can you dig into this on londinium?

I will take a look, hopefully tomorrow as I have a lot to finish up today.

Marcus
--

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] CMake master, Qt dialog and Qt4/5 installed has problems

[Marcus D. Hanwell]

On Thu, Apr 4, 2013 at 6:36 AM, Stephen Kelly steve...@gmail.com wrote:
 Stephen Kelly wrote:

 Marcus D. Hanwell wrote:

 Hi,

 I was updating my machine earlier today, and wanted to build the
 latest CMake master (00ef90). I am using Arch Linux with Qt 4 and Qt 5
 installed. If I compile with qmake-qt4 then I see the following
 compile failure,


 Please also try the workaround-usr-move-qt5 branch on stage.

My other question is - are we forcing Qt 5 when available over Qt 4
for the CMake Qt dialog? I will try to take a look at the branch in
the next few days, until then the dashboard submission will continue
to fail until this is fixed,

http://open.cdash.org/viewBuildError.php?buildid=2864935

That is built with cmake master as of yesterday, and I can continue to
block out the Qt 5 code until this is fixed when building CMake.

Marcus
--

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

[cmake-developers] CMake master, Qt dialog and Qt4/5 installed has problems

[Marcus D. Hanwell]

Hi,

I was updating my machine earlier today, and wanted to build the
latest CMake master (00ef90). I am using Arch Linux with Qt 4 and Qt 5
installed. If I compile with qmake-qt4 then I see the following
compile failure,

[ 88%] Generating qrc_CMakeSetup.cpp
/bin/sh: //bin/rcc: No such file or directory
make[2]: *** [Source/QtDialog/qrc_CMakeSetup.cpp] Error 127
make[1]: *** [Source/QtDialog/CMakeFiles/cmake-gui.dir/all] Error 2
make: *** [all] Error 2

Making the following changed allowed me to compile the Qt dialog with Qt 4,

diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt
index 1684fb2..2966082 100644
--- a/Source/QtDialog/CMakeLists.txt
+++ b/Source/QtDialog/CMakeLists.txt
@@ -12,7 +12,7 @@

 project(QtDialog)
 find_package(Qt5Widgets QUIET)
-if (Qt5Widgets_FOUND)
+if (Qt5Widgets_FOUND AND FALSE)
   include_directories(${Qt5Widgets_INCLUDE_DIRS})
   add_definitions(${Qt5Widgets_DEFINITONS})
   macro(qt4_wrap_ui)

It seems like even when not using Qt 5 it is attempting to use it, but
failing here at least. I didn't look into it too deeply - is the new
behavior to force Qt 5 if available? I haven't been following master
in the last couple of weeks, but it would be nice to resolve the issue
before the next release.

Marcus
--

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] Qt 4 and 5 on the same system - qmake binary name priority

[Marcus D. Hanwell]

On Mon, Mar 11, 2013 at 12:45 PM, Brad King brad.k...@kitware.com wrote:
 On 03/11/2013 12:34 PM, Clinton Stimpson wrote:
 I fixed a few bugs with that patch, and it is now merged with next.

 Great, thanks for taking care of this.

I verified that next finds the correct qmake for me too, thanks for
getting this in for the next release!

Marcus
--

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

[cmake-developers] Qt 4 and 5 on the same system - qmake binary name priority

[Marcus D. Hanwell]

Hi,

I notice that Arch has already patched this, but CMake master as of
aa027af9 still finds /usr/bin/qmake when a /usr/bin/qmake-qt4 is
available. This bug is reported here,

http://public.kitware.com/Bug/view.php?id=13985

Is there any issue with changing the order so that if qmake-qt4 is
found that is used preferentially over qmake which it seems will tend
to be the Qt 5 qmake? Stephen mentions qtchooser but it isn't clear
how relevant that is to making the find module prefer a qt4 specific
suffix if one is found. I didn't look at the proposed patch that
closely, but would like to understand any constraints on changing the
binary name search order before proposing anything.

Thanks,

Marcus
--

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] Qt 4 and 5 on the same system - qmake binary name priority

[Marcus D. Hanwell]

On Fri, Mar 8, 2013 at 2:52 PM, Clinton Stimpson clin...@elemtech.com wrote:
 On Friday, March 08, 2013 02:35:53 PM Marcus D. Hanwell wrote:
 I notice that Arch has already patched this, but CMake master as of
 aa027af9 still finds /usr/bin/qmake when a /usr/bin/qmake-qt4 is
 available. This bug is reported here,

 http://public.kitware.com/Bug/view.php?id=13985

 Is there any issue with changing the order so that if qmake-qt4 is
 found that is used preferentially over qmake which it seems will tend
 to be the Qt 5 qmake? Stephen mentions qtchooser but it isn't clear
 how relevant that is to making the find module prefer a qt4 specific
 suffix if one is found. I didn't look at the proposed patch that
 closely, but would like to understand any constraints on changing the
 binary name search order before proposing anything.

 Its not as simple as changing the order.
 If I have my own build of Qt4, and if FindQt4.cmake had this:
 find_program(QT_QMAKE_EXECUTABLE NAMES qmake4 qmake-qt4 qmake-mac qmake ...)
 and I try to use my build of Qt
 CMAKE_PREFIX_PATH=/home/me/qt/qt-4.7.2 cmake ../
 It finds /usr/bin/qmake-qt4 instead, because it searched for qmake-qt4 in all
 possible paths before searching for qmake.

 Currently, I think we need to keep qmake first.

 The proposed patch does improve the situation by making a separate
 find_program() call for each executable name.  It also verifies the results of
 each find_program().

Yeah, I didn't notice that (and hadn't thought about interaction with
prefix path). It is a shame upstream couldn't agree on alternative
names for the Qt 5 versions so that a consistent scheme could be used
across distros. I can of course specify the full qmake path and all is
well (or use the Arch patched FindQt4 module). What made me think this
might work is all the subsequent calls for QT_*_EXECUTABLE but now I
notice they use QT_BINARY_DIR.

Thanks,

Marcus
--

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] How to specify LD_LIBRARY_PATH for a test?

[Marcus D. Hanwell]

On Tue, Feb 26, 2013 at 2:15 PM, Orion Poplawski or...@cora.nwra.com wrote:
 On 02/26/2013 12:06 PM, Alexander Neundorf wrote:

 On Tuesday 26 February 2013, Orion Poplawski wrote:

 We have some tests that load libraries at run time.  How can we specify
 that LD_LIBRARY_PATH needs to be set?

 file(WRITE ${CMAKE_SOURCE_DIR}/testsuite/launchtest.c ${LAUNCH})
 add_executable(launchtest EXCLUDE_FROM_ALL
 ${CMAKE_SOURCE_DIR}/testsuite/launchtest.c)
 add_library(test_ce SHARED EXCLUDE_FROM_ALL libtest_ce.cpp)
 add_custom_target(check COMMAND ${CMAKE_BUILD_TOOL} test DEPENDS
 launchtest
 test_ce)
 get_target_property(LAUNCHTESTLOCATION launchtest LOCATION)
 execute_process(
 COMMAND fgrep .pro ${BASE_SOURCE}/testsuite/Makefile.am
 COMMAND awk {printf(\%s;\,$1)}
 OUTPUT_VARIABLE TESTS)
 foreach(TEST ${TESTS})
   add_test(${TEST} ${LAUNCHTESTLOCATION} ${TEST})
 endforeach(TEST TESTS)

 The test needs to be able to load the test_ce library at run-time.


 If you didn't explicitely disable it, cmake builds the executables by
 default
 with the complete RPATH to all used libraries (the build RPATH).
 This is replaced during make install by the install RPATH, which is by
 default empty.
 So it should actually just work.

 Alex


 The tests are not being linked to the library.  The tests are dlopening them
 at run time.

You can set pretty much anything in the environment for a test. For example,

set_tests_properties(avogadro-${name} PROPERTIES
ENVIRONMENT AVOGADRO_PLUGIN_DIR=${AvogadroLibs_INSTALL_PREFIX})

would set AVOGADRO_PLUGIN_DIR for a test. To see a full example,

https://github.com/OpenChemistry/avogadroapp/blob/master/tests/CMakeLists.txt

I think you could use that approach for LD_LIBRARY_PATH, or to tell
the dlopen call where to look on disk (as we do there).

Marcus
--

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] ctest git submodules

[Marcus D. Hanwell]

On Tue, Feb 26, 2013 at 2:36 PM, Clinton Stimpson clin...@elemtech.com wrote:

 Thanks.  I may have to do that for now.

 However, it seems to me that ctest already does a
 git submodule update --recurse
 but its missing the --init flag to deal with changes to the .gitmodules file.

It also misses git submodule sync to deal with changes in git
submodule URL, and reset --hard etc. We have just been dealing with a
few of these issues and currently call git directly to sync, init, and
then use submodule foreach to reset and clean all submodules before
updating.

I wonder if any of these are good candidates for adding to ctest in the future.

Marcus
--

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] ctest git submodules

[Marcus D. Hanwell]

On Tue, Feb 26, 2013 at 4:50 PM, Brad King brad.k...@kitware.com wrote:
 On 2/26/2013 2:52 PM, Jean-Christophe Fillion-Robin wrote:
 +1 to add these into CTest :) What would be the argument against it ?

 Not every project wants every submodule checked out all the time.
 A major use case for them is to have an umbrella project with many
 submodules and the developer may only checkout and work on some.
 Some may even be proprietary and inaccessible to some machines.

Agreed, there are different uses for submodules but it seems like we
are also neglecting a common use case.

  However, it seems to me that ctest already does a
  git submodule update --recurse

 This is the proper command to update everything that is already
 to configured to checkout in the source tree.

  but its missing the --init flag to deal with changes to the
  .gitmodules file.
 It also misses git submodule sync to deal with changes in git
 submodule URL,

 These are all intentionally missing for the above reason.  We
 should honor the user's configuration.  Maybe they intentionally
 use a custom url for a submodule for the branch they test.  We
 should not blow away their configuration by default.

 and reset --hard etc.

 We do a reset --hard at the top level but I do not think we
 do it in the submodules.  That may be worth adding, perhaps
 with git submodule foreach.

This would be very helpful, and is a big inconsistency in the current behavior.

 We have just been dealing with a
 few of these issues and currently call git directly to sync, init, and
 then use submodule foreach to reset and clean all submodules before
 updating.

 That is the expected way to deal with it.  The local dashboard
 script knows if it needs to preserve the user config or not.

 We could also consider adding options for ctest_update to
 tell it to init, sync, etc., but it should not be the default.

I think adding an option would be totally fine, keep the current
default. It can be difficult getting the order right when scripting
and adding a few options to the update command could make the scripts
quite a bit simpler. If this seems like a reasonable path forward
maybe we could sketch out what those options should look like and we
might be able to put a patch together.

Our most common dashboard use case just wants a pristine clone, using
the latest submodule URLs and ideally should clean out any local
changes. We seem to spend quite a bit of time ensuring this all
happens in the right order, as I think others do.

Marcus
--

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://www.cmake.org/mailman/listinfo/cmake

[cmake-developers] Generate export header - remove some warnings for old compilers

[Marcus D. Hanwell]

Hi,

I just pushed generate-export-header-warnings to the stage, this
removes the warnings emitted when the compiler is old. When making
extensive use of generate export headers these warnings only serve to
obscure real warnings, when in my opinion generate export header is
doing precisely what it should - degrade gracefully.

Are there any objections to me merging this to next? Any chance it
could make it into the next release? It has been a while since I did
anything in CMake, happy to fix up the commit a little after review
but I would like to get this merged into next soon if it looks good.

Thanks,

Marcus
--

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

[Cmake-commits] CMake branch, next, updated. v2.8.10.2-2256-g2bb5dd1

[Marcus D . Hanwell]

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  2bb5dd19d2d2134efd6b0396daee5c462d7a9bed (commit)
   via  1e0891e28ac8d595a7bdab6dc2ac5c3d76061233 (commit)
  from  7487a8f9b09bd683c34da4db1c969b6cff45e9e9 (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=2bb5dd19d2d2134efd6b0396daee5c462d7a9bed
commit 2bb5dd19d2d2134efd6b0396daee5c462d7a9bed
Merge: 7487a8f 1e0891e
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Wed Feb 20 22:36:08 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Feb 20 22:36:08 2013 -0500

Merge topic 'generate-export-header-warnings' into next

1e0891e Removed GenerateExportHeader warnings about old compilers


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1e0891e28ac8d595a7bdab6dc2ac5c3d76061233
commit 1e0891e28ac8d595a7bdab6dc2ac5c3d76061233
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Wed Feb 20 11:48:12 2013 -0500
Commit: Marcus D. Hanwell marcus.hanw...@kitware.com
CommitDate: Wed Feb 20 11:48:12 2013 -0500

Removed GenerateExportHeader warnings about old compilers

These warnings tend to flood the dashboard submissions, and it is doing
what it should (degrade gracefully with older compilers).

diff --git a/Modules/GenerateExportHeader.cmake 
b/Modules/GenerateExportHeader.cmake
index ce23d5d..c88a3a2 100644
--- a/Modules/GenerateExportHeader.cmake
+++ b/Modules/GenerateExportHeader.cmake
@@ -156,16 +156,12 @@ macro(_test_compiler_hidden_visibility)
 
   if(CMAKE_COMPILER_IS_GNUCXX AND CMAKE_CXX_COMPILER_VERSION VERSION_LESS 
4.2)
 set(GCC_TOO_OLD TRUE)
-message(WARNING GCC version older than 4.2)
   elseif(CMAKE_COMPILER_IS_GNUC AND CMAKE_C_COMPILER_VERSION VERSION_LESS 
4.2)
 set(GCC_TOO_OLD TRUE)
-message(WARNING GCC version older than 4.2)
   elseif(CMAKE_CXX_COMPILER_ID MATCHES Intel AND CMAKE_CXX_COMPILER_VERSION 
VERSION_LESS 12.0)
 set(_INTEL_TOO_OLD TRUE)
-message(WARNING Intel compiler older than 12.0)
   endif()
 
-
   # Exclude XL here because it misinterprets -fvisibility=hidden even though
   # the check_cxx_compiler_flag passes
   # http://www.cdash.org/CDash/testDetails.php?test=109109951build=1419259

---

Summary of changes:
 Modules/GenerateExportHeader.cmake |4 
 1 files changed, 0 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

Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc?

[Marcus D. Hanwell]

On Wed, Feb 6, 2013 at 8:21 AM, David Cole dlrd...@aol.com wrote:
 -Original Message-
 From: Stephen Kelly steve...@gmail.com
 To: cmake-developers cmake-developers@cmake.org
 Sent: Wed, Feb 6, 2013 8:17 am
 Subject: Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc?

 David Cole wrote:

 I agree with Marcus. There's no reason to deprecate these (other than
 deprecating Qt4 entirely, but not yet) unless there's a significant code
 clarity advantage.

 I think in the case of the qt4_automoc macro at least, there's some
 technical issue with changes in dependencies. Alex knows more.

 What does it buy us to deprecate these things now?

 Good advice in documentation I guess, if there's technical reasons not to
 use them. From a porting point of view (in terms of porting to newer cmake
 or newer Qt), it might be easier if they are not used (provided a new enough
 cmake version is used).

 It's never too early to have one eye on porting, and if the documentation
 tells you that using a macro makes porting harder, you can take note :).
 Also, if starting a new project, it makes sense to not use stuff (from the
 beginning) that will not be available/is not recommended/has disadvantages.
 For that though, there needs to be some indication of what is deprecated.


 OK, sure. If something's not recommended moving forward, by all means
 document it that way.

 Deprecation to me means more of an active warning against using something
 at runtime, or producing an error if something is used that is not
 recommended.

 But if you are advising just updating docs, then go for it.

I entirely echo Dave's words here - I thought you meant more of an
active warning against using it at runtime/producing errors. If all
you mean is updating the documentation I think that is a great idea,
and it certainly seems like the right way to go here.

Marcus
--

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] Deprecating qt4_use_modules and qt4_automoc?

[Marcus D. Hanwell]

On Wed, Feb 6, 2013 at 5:46 AM, Stephen Kelly steve...@gmail.com wrote:

 Hi there,

 The qt4_use_modules is now mostly obsoleted by tll in CMake 2.8.11. The main
 difference is that qt4_use_modules does not require the use of imported
 targets.

 I think we should deprecate it in favor of using tll() with imported targets
 (using the imported targets is independent of the QT_USE_IMPORTED_TARGETS
 setting, which determines what is in the QT_QTGUI_LIBRARIES and similar
 variables). So we should document

  target_link_libraries(foo PRIVATE Qt4::QtGui)

 and similar as the primary way to use Qt 4.

 The qt4_automoc macro is obsoleted by the CMAKE_AUTOMOC feature. There is no
 equivalent in the Qt 5 cmake macro offering. So, I think we should deprecate
 it too.

What do you mean by deprecate it? We have projects that don't require
a recent CMake, and I would rather not add two ways of doing things to
the CMake code. I will certainly use this in newer projects that
require a recent CMake. It would be irritating to see deprecation
notices popping up in our dashboards too, so I would rather see them
continue to be supported.

As there will be no more Qt 4 releases, wouldn't there be a natural
deprecation path as projects move over to Qt 5?

Marcus
--

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] Passing CMAKE_TOOLCHAIN_FILE on command line causes CMake warning

[Marcus D. Hanwell]

On Wed, Feb 6, 2013 at 5:59 AM, Pat Marion pat.mar...@kitware.com wrote:
 Hi,

 I'm emailing about bug 13093 in the backlog.  I found comments by Brad that
 suggest it's a legitimate warning, but I'm not sure how a project could
 avoid the warning.  Maybe cmake could send a fatal error if the toolchain
 filename differs from the filename that was used originally to generate the
 build tree, but otherwise suppress the warning?  I'm happy to try fixing the
 issue myself, but maybe a cmake developer can revisit the bug report and let
 me know what they think.  Thanks!

In the context of external project you can simply switch to
CMAKE_CACHE_ARGS rather than CMAKE_ARGS. You get around argument
length limitations on the more brain dead platforms and will never see
these warnings.

I like the feature they added, but wish they had defaulted it to off
(as was previous behavior) so that we saw it when debugging/checking a
project just like we turn on the warnings with compiler flags...

Marcus
--

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://www.cmake.org/mailman/listinfo/cmake

[cmake-developers] Ninja and optional support for Fortran

[Marcus D. Hanwell]

Hi,

We use Eigen in a few projects, and it has optional support for
Fortran. It seems that the way it probes for a working Fortran
compiler causes the Ninja generator to error out.

CMake Error: The Ninja generator does not support the language Fortran yet.
-- The Fortran compiler identification is unknown
CMake Error at /usr/share/cmake-2.8/Modules/CMakeFortranInformation.cmake:27
(GET_FILENAME_COMPONENT):
  get_filename_component called with incorrect number of arguments
Call Stack (most recent call first):
  blas/CMakeLists.txt:9 (enable_language)


CMake Error: The Ninja generator does not support the language Fortran yet.
CMake Error at /usr/share/cmake-2.8/Modules/CMakeFortranInformation.cmake:27
(GET_FILENAME_COMPONENT):
  get_filename_component called with incorrect number of arguments
Call Stack (most recent call first):
  lapack/CMakeLists.txt:9 (enable_language)

I could suggest a new option for the project, but I was wondering if
anyone involved in the Ninja generator has thoughts on when (if)
Fortran will be supported, and more generally if there is a good way
to test for a language, such as Fortran, when building a project. I
haven't looked too deeply at their approach, but this is the only
thing that seems to be a problem for us in using Eigen (which is a C++
meta-template library with some optional Fortran code compiled and
wrapped when a working compiler is available).

Thanks,

Marcus
--

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] file( DOWNLOAD ) problem

[Marcus D. Hanwell]

On Fri, Sep 28, 2012 at 4:42 PM, Robert Dailey rcdailey.li...@gmail.com wrote:
 On Fri, Sep 28, 2012 at 2:58 PM, David Cole david.c...@kitware.com wrote:
 On Fri, Sep 28, 2012 at 3:30 PM, Robert Dailey rcdailey.li...@gmail.com
 wrote:

 CMake downloads our third party libraries from a central repository
 and we have a manifest.cmake module where we define the following:

 - Library alias (the library's base name, such as boost, bdb,
 openssl)
 - Library version (e.g. 2.1.5)
 - Library iteration (A counter that is incremented if a library
 changes remotely without version # increasing (such as if we rebuild
 the same version of the library and it must be re-served))

 My third party download logic knows to download the following files:

 repo/alias/version/include.7z
 repo/alias/version/platform.7z

 In this case, platform will represent the toolchain -- such as
 vc9sp1.7z for the lib  bin files for visual studio 2008 SP1.

 I have 2 files here, so I'd need 2 MD5 values recorded in my manifest
 somewhere, but since I have 1 line per library (not per file that
 will be downloaded) it wouldn't work out very well.

 I want to keep my manifest simple and easy to look at and modify,
 adding a bunch of MD5 values will make it messy and harder to upgrade
 libraries (right now I just drop files on a server and add or modify a
 line in the manifest. Having MD5s would mean I would have to run
 another tool to calculate the MD5 and then stuff it somewhere in the
 manifest module)

 If you have some ideas on how to make this fit well into my system I'm
 all for that, but I guess if not then I'll have to rely on assumptions
 :(

 However I strongly believe that CMake's file DOWNLOAD should do more
 checks to make sure that the data received is valid. I will look at
 the code later to see if there is more that can be done.

 On Wed, Sep 26, 2012 at 11:20 PM, David Cole david.c...@kitware.com
 wrote:
  On Wed, Sep 26, 2012 at 7:32 PM, Robert Dailey
  rcdailey.li...@gmail.com wrote:
  To do MD5 checks, I need to somehow record the expected MD5 somewhere,
  which isn't very maintainable.
 
  I provide a list of third party libraries that CMake should download
  from a central third party repository here at work. It is a trusted
  source, because we know it is, so we don't need to verify the MD5.
  However, if I could request the MD5 first, and then download, then
  compare the MD5 the server gave me with what I actually downloaded,
  that would certainly work just to verify the complete file was
  downloaded.
 
  Other than that, I'll have to rely on the status of the operation...
  but I don't like that the destination file is created prior to any
  writes being possible by CMake (it can't write anything if no data was
  received, so why doesn't it create the file once it has a write
  buffer?)
 
 
  Recording the MD5 somewhere is the only way to have a reasonable
  re-assurance that what you've asked for is what you're getting from a
  network operation. It seems to me that it could be made maintainable
  if you centralize the knowledge of the checksums in a file that is
  changed whenever any of the downloadable files is changed.
 
  I guess we figure it's no use downloading bits over the network if you
  can't even open a (presumably local) output file for writing... so we
  try to open the output file for writing first, and if it succeeds,
  then we start grabbing bits from the network and writing them into the
  file as we receive them.
 
  There is room for improvement in the file(DOWNLOAD implementation, but
  it is the way it is right now (and will be for 2.8.10 as well...)
 
  Start proposing improvements for it now, and submitting patches to
  make stuff better for 2.8.11 and/or beyond. :-)
 
 
  HTH,
  David



 You can rely on the STATUS to see if there were any errors during the
 download. If the error code is 0, then you got whatever was on the server.
 You can rely on that.

 So, if you don't want to use a hash, you can rely on STATUS. I do not know
 of any case that reports a 0 status code, but gives an incorrect file
 result.


 What you *can't* rely on is that the correct thing was on the server. And to
 validate that, you should use checksums of some sort. (If you can't or don't
 want to, that's fine. To each his own.) Starting with CMake 2.8.10, there
 will be EXPECTED_HASH and you can use the hashing algorithm of your choice
 rather than just the MD5 that we had in 2.8.9 and earlier...

 Also new in 2.8.10, the Kitware provided pre-built binaries will link to
 OpenSSL such that we can handle downloading files from https://; URLs.

 In my tests, I've found that redirects can affect the return code of
 STATUS. For example, if I try to initiate a download of a file that
 doesn't really exist, the HTTP server may return a dummy file, in
 that case it would be downloaded just fine no matter what the URL or
 filename is, and status wouldn't know the difference.

 However for FTP URLs, it is generally more 

Re: [CMake] CMake/Ninja support in Qt Creator

[Marcus D. Hanwell]

On Thu, Sep 20, 2012 at 7:26 AM, Peter Kümmel syntheti...@gmx.net wrote:
 On 19.09.2012 08:08, Wouter van Kleunen wrote:

 Peter,

 i had 2.8.9-pre3 before, i upgraded to 2.8.9. But only after deleting
 the CMakeLists user file from qtcreator, deleting the build directory
 and restarting qtcreator I was able to get the option to build with Ninja.

 Anyway, it seems to work fine now, and the building is much faster.


 I've uploaded a new version:

 - Now out-of-source project files are supported (for cmake projects).
   There will be two new files in the build folder CMake.qtcreator and
 CMakeLists.txt.user
   CMake.qtcreator should be opened with creator.

 - out-of-source is default, could be changed by a check box in the wizard

 - shipped ninja.exe (1.0.0) is found automatically

 - generators are updated when cmake is selected in the wizard

 - a cmake warning about QT_QMAKE_EXECUTABLE could be suppressed when the
 project doesn't use Qt

I just saw this thread, on Linux if I already have CMake 2.8.9 and a
recent ninja build I take it I just need your patched Qt Creator? I
tried adding custom build steps and that kind of works but I lose the
warning/error parsing - would that work with this patched version?

Thanks for all your work, I am looking forward to Ninja generator
integration in Qt Creator!

Marcus
--

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake/Ninja support in Qt Creator

[Marcus D. Hanwell]

On Tue, Sep 25, 2012 at 2:56 PM, Peter Kümmel syntheti...@gmx.net wrote:
 On 25.09.2012 17:29, Marcus D. Hanwell wrote:

 On Thu, Sep 20, 2012 at 7:26 AM, Peter Kümmel syntheti...@gmx.net wrote:

 On 19.09.2012 08:08, Wouter van Kleunen wrote:


 Peter,

 i had 2.8.9-pre3 before, i upgraded to 2.8.9. But only after deleting
 the CMakeLists user file from qtcreator, deleting the build directory
 and restarting qtcreator I was able to get the option to build with
 Ninja.

 Anyway, it seems to work fine now, and the building is much faster.



 I've uploaded a new version:

 - Now out-of-source project files are supported (for cmake projects).
There will be two new files in the build folder CMake.qtcreator and
 CMakeLists.txt.user
CMake.qtcreator should be opened with creator.

 - out-of-source is default, could be changed by a check box in the wizard

 - shipped ninja.exe (1.0.0) is found automatically

 - generators are updated when cmake is selected in the wizard

 - a cmake warning about QT_QMAKE_EXECUTABLE could be suppressed when the
 project doesn't use Qt

 I just saw this thread, on Linux if I already have CMake 2.8.9 and a
 recent ninja build I take it I just need your patched Qt Creator? I
 tried adding custom build steps and that kind of works but I lose the
 warning/error parsing - would that work with this patched version?

 Yes, complete warning/error parsing. Use the 2.6-ninja branch.

Just got this compiled - it looks great.

 Thanks for all your work, I am looking forward to Ninja generator
 integration in Qt Creator!

 You are welcome! Please post any issue, I'll try to fix them.

Will do, so far it seems to be working great. It is nice to have an
option to store the CMakeLists.txt.user in the build directory too,
that always bugged me and I wondered why they had chosen to go that
way. Looks great, with all warnings etc showing up in the editor as I
would expect.

I have tested it with VTK, and will likely look at some of the other
projects I am working on soon. So far so good - thanks for pushing
this forward. How much of this will make it into Qt Creator 2.6?

Marcus
--

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] ExternalProject_Add examples

[Marcus D. Hanwell]

On Sat, Mar 17, 2012 at 5:03 PM, Bill Lorensen bill.loren...@gmail.com wrote:
 Folks,

 I've recently created a number of super builds using CMake's External
 Project mechanism. Each external project requires some sort of
 download, configuration, build and possibly install. The CMake defines
 needed to correctly access the results of the external project vary
 significantly. The trickiest part is find the proper download,
 configuration and CMake defines.

 For example, for the Point Cloud Library (http://pointclouds.org/) I
 created these external projects:
 VTK - git, cmake, make; VTK_DIR
 FLANN - zip, cmake, make install; FLANN_LIBRARY, FLANN_INCUDE_DIR
 Eigen - .tar.bz2,; EIGEN_INCLUDE_DIR
 Qhull - git, cmake, make;QHULL_LIBRARY,QHULL_INCLUDE_DIR
 Boost - .tar.gz, bootstrap.sh, b2; BOOST_ROOT
 GTest - .zip, cmake, make; GTEST_ROOT,GTEST_INCLUDE_DIR

 Slicer4 has many more.

 Should we start collecting sample ExternalProject_Add files for
 external projects?

We have talked about doing this too (I have Eigen, Boost, GTest and
others for example). The standard CMake based projects hardly seem
worth it, but it depends on what you want to do with them I suppose.
For the work we are doing in chemistry we have been working on an
experimental superbuild that uses a common prefix in the build tree to
install to, and then all we need pass in is CMAKE_PREFIX_PATH - this
can make the logic significantly easier for dependent CMake projects
as it will always search within the prefix first.

The Qt external project was pretty tricky too, and we are using that
in several places along with smaller libraries like libxml2.

Marcus
--

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Ninja + CMake on a dashboard?

[Marcus D. Hanwell]

On Fri, Mar 9, 2012 at 12:34 PM, Bill Hoffman bill.hoff...@kitware.com wrote:
 On 3/9/2012 12:21 PM, Steven Wilson wrote:

 Where does the Ninja generator currently live?   Ie which branch in the
 sources, etc?   I am keen to see support for the Ninja generator on
 Mac/Linux/Windows and would not mind working on it.

 Thanks,

 Steve

 The ninja support is in the next branch right now.  Where is stands:

 - Linux seems to be all done
 - Windows is close, still a few failing tests, and needs to use a special
 ninja:
 http://sourceforge.net/projects/cmakescript/files/ninja.exe/download
 - The Mac needs the most work, as Framework and App bundle creation is not
 yet implemented.

 I am working on getting nightly dashboards for all three linux, windows and
 Mac going.  I am going to turn on the ninja build by default on linux, and
 have an advanced cache option that will default to off for windows and mac.
   When the next version comes out it will be enabled on all platforms that
 are passing all the tests (currently only linux).

 The topic where the work happens is on the stage, and is called
 stage/ninja-generator.

I just tried this out and it is looking good on Linux. I can probably
get a CMake and VTK nightly submission up and running. I will have to
change my default generator once I figure out how I can make this work
with Qt Creator.

Marcus
--

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://www.cmake.org/mailman/listinfo/cmake

Re: [cmake-developers] target_include_directories branch in stage

[Marcus D. Hanwell]

On Wed, Feb 22, 2012 at 8:36 PM, David Cole david.c...@kitware.com wrote:
 On Wed, Feb 22, 2012 at 3:04 PM, David Cole david.c...@kitware.com wrote:
 On Wed, Feb 22, 2012 at 8:05 AM, David Cole david.c...@kitware.com wrote:
 On Thu, Feb 16, 2012 at 4:11 PM, Stephen Kelly steve...@gmail.com wrote:
 David Cole wrote:

 Pushed down the queue again... I'll get to it soon. There are a handful of
 minor changes that I still need to make first.

 Ok.

 Let me know if it's anything I can do.

 Thanks,

 Steve.


 --

 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


 Finally pushed the most recent commits this morning... Please see the
 target-include-directories branch on the stage. (Not yet merged to
 'next' -- but soon will be.)


 Question (probably for Brad):

 What should --help-property emit now that there are both directory and
 target level properties for INCLUDE_DIRECTORIES?

 Here's what it does:

 $ bin/Debug/cmake --help-property INCLUDE_DIRECTORIES
 cmake version 2.8.7.20120222-g56a44
  INCLUDE_DIRECTORIES
       List of preprocessor include file search directories.

       This read-only property specifies the list of directories given so far
       to the include_directories command.  It is intended for debugging
       purposes.

 So the most recent commit in the topic branch, which adds
 documentation for the target level property, appears useless... Should
 we eliminate the directory level documentation as well? Or emit both?
 If so, how?

 After we settle this one remaining point, I'll patch up the topic
 branch and merge it to 'next'.

 Thanks to everybody for your help and patience in getting this feature
 into CMake.


 Cheers,
 David C.


 Finally ready...

 I just force-pushed the 'target-include-directories' branch to stage
 again. I think it's ready for merging to 'next' -- before I do that,
 could I get a sanity check that the documentation in the top commit
 (ff44b88) is acceptable?


 Thanks,
 David


 All set. One more force-push after cleaning up a commit on Brad's
 recommendation and  it is now finally merged to 'next'.

 Whew.

Thanks for pushing on this - glad to see it get merged in and looking
forward to being able to use this.

Marcus
--

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] Upcoming What's New in CMake 2.8.7 webinar

[Marcus D. Hanwell]

On Wed, Dec 21, 2011 at 3:50 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
 On Wednesday 21 December 2011, David Cole wrote:
 The CMake team is hard at work on the 2.8.7 release - we
 announcedhttp://www.kitware.com/blog/home/post/208 CMake
 2.8.7 rc1 on December 8th, and we expect to release the final version by
 the end of the year. Want to learn more? Then please join us on
 January 4th from
 12:00-12:20 p.m. EST, when I will be presenting a free webinar highlighting
 what’s new in the CMake 2.8.7 release and giving a preview of what’s in the
 pipeline. You'll also get a chance to ask the CMake team any questions you
 may have on this release in particular or CMake in general. You can
 register for this event through
 GoToWebinarhttps://www3.gotomeeting.com/register/152723134
 .
 https://www3.gotomeeting.com/register/152723134
 Please note that you'll need to attend this webinar from a Windows or Mac
 computer - GoToWebinar does not yet support Linux.

 Are there plans for GoToWebinar to support also Linux ?
 It's really a pity that also the other webinars by Kitware exclude Linux :-/

Agreed, I can't view them on my desktop. I have access to those other
platforms on secondary machines at least, but it would be great to
allow viewing of our webinars on the platforms we are targeting. Are
there any good alternatives you know of Alex?

Marcus
--

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://www.cmake.org/mailman/listinfo/cmake

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

[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:
     ^[^][:/*?]+\$

  To include a literal ] in the list, make it either the first item

 It must be the [: in this regex that TRE sees as special since it
 allows expressions like [:digit:] inside a bracket expression.

 Still, this is a case that my proposed policy would pick up.

 -Brad

 I am still very wary about this policy.  For 99% of folks the current regex
 is just fine.  Making them eventually change to get the new regex is
 making them do work that they don't need or want.  I would rather have two
 API's.   I just don't see the big upside of TRE, and I see this causing pain
 for lots and lots of folks if we push them to make the change.  CMake has
 most likely 100,000 or more users at this point.  A change like this could
 easily inflict a man years of effort onto the world, and should not be taken
 lightly.

Couldn't they defer by setting the policy to OLD? If they bump the
minimum version the user knows that backward incompatible changes may
be introduced. If there was a way to verify that the output of the
regex were the same with both implementations too, that should reduce
the possibility of subtle bugs.

Marcus
--

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] debug/optimized include directories

[Marcus D. Hanwell]

On Fri, Nov 4, 2011 at 11:16 AM, Robert Dailey rcdai...@gmail.com wrote:
 David,
 There is a directory-level property for preprocessor definitions too, right?
 So how do the target properties for preprocessor definitions handle those? I
 think they are additive aren't they?
 I would expect the include directories to be additive too.

 -
 Robert Dailey


 On Fri, Nov 4, 2011 at 9:04 AM, David Cole david.c...@kitware.com wrote:

 On Wed, Nov 2, 2011 at 8:30 PM, Stephen Kelly steve...@gmail.com wrote:
  David Cole wrote:
 
  On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey
  rcdai...@gmail.com wrote:
  On Tue, Nov 1, 2011 at 3:32 PM, David Cole
  david.c...@kitware.com wrote:
 
  Not yet
 
  Meaning there are plans in the works to add such functionality in the
  near future?
  For now I guess I could actually hard code VS environment variables in
  my
  include directory strings, such as $(Configuration).
 
  There is a feature planned to add per-target include directories (as a
  target property). As part of that work, we will probably naturally
  also add per-configuration values of that new target property. It is
  not yet added as a feature request in the bug tracker, but there are
  related ones that I may borrow for the purpose. Stay tuned for more
  info, but it is not coming in the next week or two. Hopefully, in time
  for 2.8.7, but it depends on timing at this point so no promises.
 
  Hi David,
 
  I'm interested in this feature. I'd like to get it into CMake 2.8.7.
 
  It came up in the recent thread about how Qt5Config.cmake should work:
 
  http://thread.gmane.org/gmane.comp.lib.qt.project.devel/79/focus=226
 
  You mentioned that there are some side-line relevant bugs in the CMake
  tracker for this. Could you point me to them? Could you also indicate
  the
  approximate location in the code to look to for starting to work on this
  (cmTarget.cxx?).
 

 See these bugs (and probably others, too, but these looked like the
 most relevant ones when I searched for include_directories...)

  http://public.kitware.com/Bug/view.php?id=1968
  http://public.kitware.com/Bug/view.php?id=6269
  http://public.kitware.com/Bug/view.php?id=6493
  http://public.kitware.com/Bug/view.php?id=8189

 I think the main thing we want is a new target property named
 INCLUDE_DIRECTORIES - There's already a directory property with that
 name; the include_directories command is implemented in terms of that
 directory property. Along with that, we will also want
 per-configuration variants of the property, similar to the many
 existing target properties that have per-config variants.

 If you look at the code, you'll see that use of the existing
 INCLUDE_DIRECTORIES property triggers a call to
 cmMakefile::SetIncludeDirectories, which just saves it in a data
 member for later use. You can grep the code for GetIncludeDirectories
 for callers, or for just IncludeDirectories to see the direct usage in
 cmMakefile.cxx itself.

 The interesting bits here are going to be in deciding how to make
 these per-target include_directories behave. Should they be additive?
 Or should they override the directory-level includes entirely?

 There is quite some discussion to be had here and some decisions to
 make. (Which is why I hesitate to promise that this will definitely be
 ready by 2.8.7...)

I would expect them to be additive.

Marcus
--

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.6 available for download

[Marcus D. Hanwell]

On Wed, Oct 5, 2011 at 6:53 AM, Peter Kuemmel syntheti...@gmx.net wrote:
 When I install the .sh version over an existing 2.8.4 release
 and use CodeBlocks - Unix Makefiles QtCreator only shows the
 CMakeLists.txt, nothing more.

 Seems the CodeBlocks - Unix Makefiles generator is broken in 2.8.6.

 The entry Option virtualFolders=..  looks quite different between
 the two generated .cbp files.

I just tried this with CMake compiled from master, on a fresh ParaView
build tree (hadn't made one in a while) using,

cmake -G CodeBlocks - Unix Makefiles ~/ssd/src/ParaView

I was able to open the resulting build directory in Qt Creator 2.3.1
and see all of the source files etc. I can dig a little deeper if you
let me know what version of Qt Creator you are using, a project you
see the issue with etc. I could also give the installer a try if the
problem persists (I normally just build from source and current CMake
master is 2.8.6).

Marcus
--
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://www.cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, next, updated. v2.8.5-1918-g33e1a63

[Marcus D . Hanwell]

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  33e1a63ca1084abf76939f8a4a6bf112d69abcde (commit)
   via  2d1acfe359852836f3096da0d3262d558ee383d3 (commit)
   via  d6795685ae25f1a9d0d7cda02d639ce8b402f9f9 (commit)
  from  beb2cd74fc7de307e76a69c3cc2adc20b7ef248f (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=33e1a63ca1084abf76939f8a4a6bf112d69abcde
commit 33e1a63ca1084abf76939f8a4a6bf112d69abcde
Merge: beb2cd7 2d1acfe
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Mon Sep 19 15:21:19 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Sep 19 15:21:19 2011 -0400

Merge topic 'generate-export-header' into next

2d1acfe Don't warn when nothing to do in visibility function.
d679568 Just code style changes.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2d1acfe359852836f3096da0d3262d558ee383d3
commit 2d1acfe359852836f3096da0d3262d558ee383d3
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Mon Sep 19 14:55:19 2011 -0400
Commit: Marcus D. Hanwell marcus.hanw...@kitware.com
CommitDate: Mon Sep 19 14:55:19 2011 -0400

Don't warn when nothing to do in visibility function.

diff --git a/Modules/GenerateExportHeader.cmake 
b/Modules/GenerateExportHeader.cmake
index e1ce16d..f2eaf8c 100644
--- a/Modules/GenerateExportHeader.cmake
+++ b/Modules/GenerateExportHeader.cmake
@@ -353,7 +353,7 @@ function(add_compiler_export_flags)
   _test_compiler_has_deprecated()
 
   if(NOT (USE_COMPILER_HIDDEN_VISIBILITY AND COMPILER_HAS_HIDDEN_VISIBILITY))
-message(WARNING Compiler doesn't have hidden visibility)
+# Just return if there are no flags to add.
 return()
   endif()
 

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d6795685ae25f1a9d0d7cda02d639ce8b402f9f9
commit d6795685ae25f1a9d0d7cda02d639ce8b402f9f9
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Mon Sep 19 14:04:42 2011 -0400
Commit: Marcus D. Hanwell marcus.hanw...@kitware.com
CommitDate: Mon Sep 19 14:04:42 2011 -0400

Just code style changes.

diff --git a/Modules/GenerateExportHeader.cmake 
b/Modules/GenerateExportHeader.cmake
index 4eb67b5..e1ce16d 100644
--- a/Modules/GenerateExportHeader.cmake
+++ b/Modules/GenerateExportHeader.cmake
@@ -25,7 +25,8 @@
 # adds -fvisibility=hidden to CMAKE_CXX_FLAGS if supported, and is a no-op on 
Windows
 # which does not need extra compiler flags for exporting support.
 #
-# This means that in the simplest case, users of these functions will be 
equivalent to:
+# This means that in the simplest case, users of these functions will be
+# equivalent to:
 #
 #   add_compiler_export_flags()
 #   add_library(somelib someclass.cpp)
@@ -43,8 +44,8 @@
 # ...
 #   };
 #
-# The CMake fragment will generate a file in the ${CMAKE_CURRENT_BUILD_DIR} 
called
-# somelib_export.h containing the macros SOMELIB_EXPORT, SOMELIB_NO_EXPORT,
+# The CMake fragment will generate a file in the ${CMAKE_CURRENT_BUILD_DIR}
+# called somelib_export.h containing the macros SOMELIB_EXPORT, 
SOMELIB_NO_EXPORT,
 # SOMELIB_DEPRECATED, SOMELIB_DEPRECATED_EXPORT and 
SOMELIB_DEPRECATED_NO_EXPORT.
 # The resulting file should be installed with other headers in the library.
 #
@@ -86,11 +87,14 @@
 #   add_library(shared_variant SHARED ${lib_SRCS})
 #   add_library(static_variant ${lib_SRCS})
 #   generate_export_header(shared_variant BASE_NAME libshared_and_static)
-#   set_target_properties(static_variant PROPERTIES COMPILE_FLAGS 
-DLIBSHARED_AND_STATIC_STATIC_DEFINE)
+#   set_target_properties(static_variant PROPERTIES
+# COMPILE_FLAGS -DLIBSHARED_AND_STATIC_STATIC_DEFINE)
 #
-# This will cause the export macros to expand to nothing when building the 
static library.
+# This will cause the export macros to expand to nothing when building the
+# static library.
 #
-# If DEFINE_NO_DEPRECATED is specified, then a macro 
${BASE_NAME}_NO_DEPRECATED will be defined
+# If DEFINE_NO_DEPRECATED is specified, then a macro ${BASE_NAME}_NO_DEPRECATED
+# will be defined
 # This macro can be used to remove deprecated code from preprocessor output.
 #
 #   option(EXCLUDE_DEPRECATED Exclude deprecated parts of the library FALSE)
@@ -122,7 +126,6 @@
 #
 # Generates the macros VTK_SOMELIB_EXPORT etc.
 
-
 #=
 # Copyright 2011 Stephen Kelly steve...@gmail.com
 #
@@ -139,10 +142,10 @@
 include(CMakeParseArguments)
 include(CheckCXXCompilerFlag)
 
-
 # TODO: Install this macro separately?
 macro(_check_cxx_compiler_attribute _ATTRIBUTE _RESULT

Re: [cmake-developers] Automoc in cmake

[Marcus D. Hanwell]

On Sun, Sep 18, 2011 at 6:39 AM, Alexander Neundorf neund...@kde.org wrote:
 On Saturday, September 17, 2011 07:16:28 PM Stephen Kelly wrote:
 Stephen Kelly steveire@... writes:
  Alexander Neundorf wrote:
 
 
  Would it be possible to make CMAKE_AUTOMOC imply
  CMAKE_INCLUDE_CURRENT_DIR?
 
  All the best,
 
  Steve.

 Is it still possible to consider this? It's not ideal that you have to do
 this:

 set(CMAKE_AUTOMOC ON)
 set(CMAKE_INCLUDE_CURRENT_DIR ON)

 instead of this:

 set(CMAKE_AUTOMOC ON)

 Don't know.
 I'm usually ok with having to set the include directories explicitely.
 What do others think ?

It seems to me that if you always need to do both for it to work, then
it should be a candidate for consolidation.

Marcus
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding argument OPTIONAL to find_package() and add_subdirectory

[Marcus D. Hanwell]

On Thu, Jun 9, 2011 at 9:19 AM, Brad King brad.k...@kitware.com wrote:
 On 6/9/2011 8:50 AM, Alexander Neundorf wrote:
 What if the FindFoo.cmake script calls find_package(Bar) and does
 not require it but the project also does find_package(Bar) and does? I'm
 sure there are more cases I haven't listed here.

 I think this can be handled.
 find_package() should error out in this case, because Bar was required but it
 was disabled.
 Maybe this option to disable a find_package() could even be provided for all
 find_package() calls, and for each REQUIRED one it will cause an error. This
 would create a bunch of unusable options, but would be very consistent ;-)

 Okay.  However, the option does not need to be provided as a
 gui-settable value for packagers to be able to disable things from build
 scripts.  The command could honor the value if it is present but not
 advertise it.

I think (as a former packager) that this would certainly go a long way
to addressing the issue for packages. If the packager passes in
--disable-find=Qt4 (or whatever command line syntax you use to expose)
then all calls to find_package(Qt4) fail, and you just made CMake
easier for packagers to use with little effort for developers in
changing their scripts.

Marcus
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [CMake] FindQt4.cmake to automatically include QT_USE_FILE?

[Marcus D. Hanwell]

On Tue, Jun 7, 2011 at 9:46 AM, Michael Wild them...@gmail.com wrote:
 On 06/07/2011 03:21 PM, John Drescher wrote:
 If you don't care for the macros and want to set up the
 include-directories and defines yourself, no. Also, it is common to
 find_package(Qt4) in the top-level CMakeLists.txt file, but then include
 QT_USE_FILE only in specific subdirectories, where Qt is actually used.


 I have started doing that in my projects. It cuts down on the
 unnecessary includes for subprojects that do not need Qt.

 John


 Ah, this reminds me of one of the things on my wish list for FindQt4:
 Modern Qt4 uses a Mac-framework compatible layout, such that in order to
 e.g. include QObject header, you would do

 #include QtCore/QObject

 If a project is using this include-practice, the module could cut down
 considerably on include-paths. Also, it makes the framework detection
 ugliness on Mac unnecessary.

 So, here my wish: similar to QT_USE_IMPORTED_TARGETS, introduce
 QT_USE_FRAMEWORK_INCLUDES (or similar) which only adds the directory
 containing all the QtCore, QtGui, QtXml, ... header directories to the
 include-path.

You can already do this, and the explicit individual libraries are all
found via the find_package call. I rarely include the use file in
small projects, and have module/class style includes and link to the
individual libraries. It does cut down significantly on the include
paths too.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] FindQt4.cmake to automatically include QT_USE_FILE?

[Marcus D. Hanwell]

2011/6/7 Michael Wild them...@gmail.com:
 On 06/07/2011 06:23 PM, Bjørn Forsman wrote:
 2011/6/7 Michael Wild them...@gmail.com:
 On 06/07/2011 03:38 PM, Bjørn Forsman wrote:
 Why not put find_package(Qt4) in the sub directories where it is actually 
 used?

 And if it is used in multiple subdirectories?

 What's bad about that? (Sorry, I really don't know).

 Then you would need to call find_package in all the subdirectories, with
 all the work that goes along with that.

Virtually everything is cached AFAIK, there is minimal cost in multiple calls.

 FindXXX.cmake modules should only do the minimum, i.e. finding the
 required libraries and include-directories, setting XXX_FOUND,
 XXX_INCLUDE_DIRS and XXX_LIBRARIES. Anything more complex, e.g. calling
 add_definitions(), include_directories(), function(), macro() etc.
 should go into a UseXXX.cmake module.

 Ok, I didn't know about that policy.

 If you find a FindXXX.cmake module that calls add_definitions(),
 include_directories(), link_libraries() or some such, it is broken and
 needs to be fixed.

 Broken because of the above defined policy? Or of technical reasons?
 Sorry, but I still don't see the reason why the current find_package +
 use_file is better than a find_package that includes the use_file
 itself.

 If the FindXXX.cmake file called add_definitions(),
 include_directories() et al., that could be potentially harmful. Some
 sources might required that some define is not set, or a wrong header
 file might be #include'ed (thing of all the different X.h that exist).
 FindXXX.cmake modules should just define a few variables, *not* change
 the build system. That's the caller's responsibility, either by calling
 the functions himself or by including the UseXXX.cmake (if provided).

It could perhaps go one step further and populate QT_LIBRARIES with
the requested components.

 What I see is that current usage goes something like this:

 1) find_package(Qt4 REQUIRED) at the top level
 2) subdirs that actually need Qt: set what modules to enable/disable
 and then include the use_file.

 How about doing it this way:
 1) subdirs that actually need Qt: call find_package(Qt4 COMPONENTS
 QtCore [...] REQUIRED) with the modules it needs.

 Is there a problem with this approach? Other than breaking the policy ;-)

 In principle not, except that all these redundant find_path() and
 find_library() calls will incur some slight overhead.

Aren't they very minimal as they see that the variable is set and return?

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] GenerateExportHeader macrr for CMake?

[Marcus D. Hanwell]

On Sat, Jun 4, 2011 at 3:17 PM, Stephen Kelly steve...@gmail.com wrote:
 Hi,

 I came up with an idea to simplify the creation of export headers for hidden
 visibility by using configure_file.

 After implementing it I saw that the idea has come up before :)

 http://www.mail-archive.com/cmake@cmake.org/msg27058.html

 Please see the attached proof of concept. Could we get something like
 GenerateExportHeader.cmake and exportheader.cmake.in into CMake 2.8?

 Alex tells me I'd have to maintain it, respond to bugs, and keep source
 compatibility, so I guess I can say I'll do that :).

I have been working on similar functionality in the Titan project, and
wrote some abstraction for VTK's handling of symbol import/export
logic. As we modularize VTK we will be doing what Titan has now been
doing for quite some time.

http://www.vtk.org/gitweb?p=VTK.git;a=blob;f=Common/vtkABI.h

From reading the documentation, even though GCC 4.0 didn't necessarily
do the right thing it does know about the visibility attribute.

 I know there are other special cases for other compilers, but I thought I'd
 put the implementation of the concrete idea here for discussion at this
 point.

I think this is a great idea, and something that would be good to
provide some utility functionality around.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] GenerateExportHeader macrr for CMake?

[Marcus D. Hanwell]

On Sun, Jun 5, 2011 at 3:47 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
 On Sunday, June 05, 2011 08:43:02 PM Hendrik Sattler wrote:
 Am Sonntag, 5. Juni 2011, 18:16:03 schrieb Michael Wild:
  On 06/05/2011 05:34 PM, Hendrik Sattler wrote:
   Am Sonntag, 5. Juni 2011, 11:45:20 schrieb Stephen Kelly:
   Hendrik Sattler wrote:
   Really why? There is no dynamic content in such a header file.
  
   I'm not sure what you mean? Could you be more specific?
  
   This header file only contains static content. You don't even one
   definition per library, it's the same for each anyway. I find it
   strange to create a file that will always contain the same content.
   The difference of MSVC vs. gcc4 can be fully handled in the export
   header file. So why do you need CMake for that?
  
   HS
 
  That's not quite true. Each library will have it's own (hopefully
  unique) XXX_EXPORTS define (the DEFINE_SYMBOL property), otherwise the
  whole thing won't work.

 You mean something like:
 #ifdef FOO_EXPORTS
 #include export.h
 #define FOO_DLLEXPORT DLLEXPORT
 #endif

 This still makes export.h very static content. As I said in the old thread,
 CMake is a build system, not a code-generator.

 Well, one could also say that cmake is a tool to make building software easy
 :-)
 In that sense it is useful to put stuff which you more or less always need
 when you build a library into cmake.

That was my line of thinking too. This seems like something I do for
virtually every project I work on that wants to generate libraries. It
would provide for a standard way of doing it, but certainly would not
preclude projects from doing their own thing if preferred.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Dynamic linking doesn't work after install

[Marcus D. Hanwell]

On Fri, Apr 22, 2011 at 9:48 AM, David Doria daviddo...@gmail.com wrote:
 I have created an executable like this:

  add_executable(ImageCompleter ${AppSources})
  target_link_libraries(ImageCompleter ${LibrariesAlwaysUsed})

  INSTALL( TARGETS ImageCompleter
    RUNTIME DESTINATION ${INSTALL_DIR} )

 When I run the one that is created with 'make', it works fine.
 However, when I run the one that is copied by 'make install' I get:

 error while loading shared libraries: I get
 libwx_gtk2u_core-2.9.so.1: cannot open shared object file: No such
 file or directory

 It looks like this problem:
 http://www.cmake.org/pipermail/cmake/2010-July/038213.html
 but that link doesn't offer a solution.

 When I install it says
 -- Installing: /home/doriad/bin/Research/ImageCompleter
 -- Removed runtime path from /home/doriad/bin/Research/ImageCompleter

 I'm assuming that removed runtime path is the problem? How do I stop
 that from happening?

I think the CMake page on RPATHs might be what you are looking for.

http://www.cmake.org/Wiki/CMake_RPATH_handling

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Dynamic linking doesn't work after install

[Marcus D. Hanwell]

On Fri, Apr 22, 2011 at 9:57 AM, David Doria daviddo...@gmail.com wrote:
 I think the CMake page on RPATHs might be what you are looking for.

 http://www.cmake.org/Wiki/CMake_RPATH_handling

 Yea I read that, but I didn't really follow/see how to fix this
 problem. Surely there is a just copy the executable option?

Did you try,

SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

which is in one of the sections of that wiki article detailing using
full RPATH for installed binaries.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] QtCreator project generator

[Marcus D. Hanwell]

On Tue, Mar 1, 2011 at 9:15 AM, John Drescher dresche...@gmail.com wrote:
 On Tue, Mar 1, 2011 at 6:45 AM, Campbell Barton ideasma...@gmail.com wrote:
 QT-Creator which currently supports CMake by reading code::blocks project 
 files.

 The problem with this is code::blocks project files don't write in
 #defines, so the IDE shows #ifdef's incorrecyly.

 For the short term I wrote a eclipse - qtcreator project converter in
 python, which has a few hard coded values but could easily be made
 generic.
 http://www.pasteall.org/19595/python

 So I was wondering if CMake developers would accept a patch to add
 native generation of qtcreator project files?

 An alternative solutions could be to write defines into code::blocks
 files, or for qtcreator to read in eclipse files instead but qtcreator
 project files are quite simple to write so if this feature is
 acceptable I was thinking to try and write a patch.

 Recent versions of QtCreator use CMakeLists.txt directly? Is there
 something missing in this functionality?

You can open a CMakeLists.txt as a project, this then uses the CMake
plugin to create a build directory, use the CodeBlocks - Unix
Makefiles generator and then add a CMakeLists.txt.user with some
project settings. As stated, it lacks the #defines, although this is
less pronounced in many of the projects I work on where configured
headers are used.

I am not a core CMake developer, but it seems to me that extending the
CodeBlocks generator would be the right thing to do here (if that is
feasible). I think Alexander Neundorf did a lot of this work,
hopefully he will comment.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [cmake-developers] Cannot push to stage?

[Marcus D. Hanwell]

On Sun, Jan 30, 2011 at 7:37 AM, Eric Noulard eric.noul...@gmail.com wrote:
 Hi there,

 I cannot push to stage? or print staged branch:

 $ ssh g...@cmake.org stage cmake print

 is lasting forever.

 any know trouble or is it on my side?

It is certainly a little slow to respond, but it gets there in the
end. Try with ssh -vvv to see where it is failing perhaps?

Marcus
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [CMake] ExternalProject_Add, race conditions, MSVC_IDE

[Marcus D. Hanwell]

On Mon, Jan 24, 2011 at 9:50 AM, David Cole david.c...@kitware.com wrote:
 On Sat, Jan 22, 2011 at 8:15 AM, Pau Garcia i Quiles pgqui...@elpauer.org
 wrote:

 Hello,

 I've been using ExternalProject_Add and I have to say IMHO it's one of
 the best features added to CMake in the last years. It works great for
 me on Linux (makefiles), MSVC2010 (NMake Makefiles) and Mac
 (makefiles).

 Together with a small .sh (Unix) and a .bat (Windows), you can make
 your project full bootstrappable and only depend on the user having a
 C++ compiler (not even CMake, which has been the biggest argument
 against CMake by autotools fans)

 Now to the bad news:

 - I have experienced lots of race conditions on Windows, both with
 Cygwin and NMake

 What sort of race conditions? And how do you know they are race conditions?

I would be interested too, the Titan project has quite a few external
projects and I have not seen pathological race conditions. There are
occasional issues, such as an 8192 character limit on command line
arguments, and a recent change in CMake master alleviates this by
optionally using a file to pass the majority of initial cache
arguments into the external projects - again Titan has examples of
this.

 - I've tried to use it with MSVC solutions but if fails miserable with
 errors about cmd.exe. Is this by design or is it a bug?

 We do not intend to fail miserably, so I'm going to say that it's not by
 design... but if you are specifying commands that will not succeed, then
 perhaps it's by design on your side... :-)

I have built Titan successfully using MSVC 2008 and 2008 Express IDE
and NMake based builds. Quite a few of the Titan developers routinely
use the MSVC IDE as far as I am aware. I think there are other
projects out there using MSVS and the IDE solutions too although I
think there are still (maybe) some issues with 2010.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Use Eigen2 in CMake based project

[Marcus D. Hanwell]

On Mon, Jan 24, 2011 at 6:15 PM, Stefan Dänzer stefan.daen...@gmail.com wrote:
 Hi all,
 I have searched for the correct way to include the Eigen2 linear algebra
 library in my CMake based project. But doing a search has not brought up a
 suitable result. Has anyone used Eigen2 in their project? A CMake sample
 script including Eigen2 would be most helpful.

We make extensive use of Eigen2 in Avogadro.

http://avogadro.openmolecules.net/

Helpful parts are our FindEigen CMake module,

https://github.com/cryos/avogadro/blob/master/cmake/modules/FindEigen2.cmake

As it is header only you just need to call,

include_directories(${EIGEN2_INCLUDE_DIR})

to add it to the compiler include path, and you should be able to use
it as expected.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [cmake-developers] On Mac OS X, the CMake .app filename should not contain the version number ( http://public.kitware.com/Bug/view.php?id=11693#c24958 )

[Marcus D. Hanwell]

On Thu, Jan 20, 2011 at 1:11 PM, Clinton Stimpson clin...@elemtech.com wrote:
 On Thursday, January 20, 2011 09:36:13 am Eric Noulard wrote:
 2011/1/20 David Cole david.c...@kitware.com:
  Moving to the CMake developer's list, as requested by this bug comment:
  http://public.kitware.com/Bug/view.php?id=11693#c24958
 
  Comments or thoughts on the topic are welcome...
 
  Please reply here with any further discussion before adding more info
  to the bug report. Once a consensus is reached here, we'll update the
  bug again.

 I'm not a Mac user and I'm a poor Windows user :-]

 Now on linux (or other unices) I was puzzled by the /usr/share/cmake-2.8
 thing in fact the vast majority unix software don't come with such version
 mangling. FHS doesn't seems to include recommandation in this area:
 http://www.pathname.com/fhs/.

 Sometimes the version mangling appears when a major update (python2 --
 python3) arrives and one needs to have both versions installed for
 compatibility reason. In this case, most of the time, the up-to-date
 version is unnumbered and the old compatibility one is renamed with
 version mangling.
 In fact before the big old-new update thing the new version may be
 mangled for a
 while waiting for wider acceptance (Python case).

 Some libs do always have name mangling because the version is really part
 of their name., e.g. glib-2.0.

 Then update-alternative (Debian, Fedora, ?others?) may be used
 to create appropriate links:
 http://www.debian-administration.org/articles/91

 So I vote for no version mangling.
 Or may be an option (default to OFF==no mangling) in order to ease the
 mangling of cmake-2.8
 when cmake 3.0 will be out :-]

 I also vote for no version number, but allow the user to change it if they
 want.
 It seems that would give the general user a more clear upgrade path.

I vote for no version number. It is pretty irritating having to
recreate my build trees when I upgrade CMake, and it does not seem to
fit into the normal pattern used on the Mac.

I also noticed the /usr/share/cmake-2.8, and without a
/usr/bin/cmake-2.8 I am not sure it makes sense on Linux distros - two
CMake's could not coexist in the same prefix as the main binary would
collide.

Marcus
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[Cmake-commits] CMake branch, next, updated. v2.8.3-1395-gbbd7597

[Marcus D . Hanwell]

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  bbd7597e74c7cfbfb11d3651d9b635941aa3af74 (commit)
   via  23635ff1a0465010e8854d6f436042f03be79cd3 (commit)
  from  3961ca376a888f8c37b512b87e154cbe63d1ce78 (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=bbd7597e74c7cfbfb11d3651d9b635941aa3af74
commit bbd7597e74c7cfbfb11d3651d9b635941aa3af74
Merge: 3961ca3 23635ff
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Mon Jan 17 15:32:19 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jan 17 15:32:19 2011 -0500

Merge topic 'python-modules-header' into next

23635ff Bug #11715 - generate header in the build tree.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23635ff1a0465010e8854d6f436042f03be79cd3
commit 23635ff1a0465010e8854d6f436042f03be79cd3
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Mon Jan 17 15:29:01 2011 -0500
Commit: Marcus D. Hanwell marcus.hanw...@kitware.com
CommitDate: Mon Jan 17 15:29:01 2011 -0500

Bug #11715 - generate header in the build tree.

The module header was being placed in the source tree before. Thanks to
Marcel Loose for the patch, this ensures the file is written to the
build tree.

diff --git a/Modules/FindPythonLibs.cmake b/Modules/FindPythonLibs.cmake
index 6e5f6ef..ad98598 100644
--- a/Modules/FindPythonLibs.cmake
+++ b/Modules/FindPythonLibs.cmake
@@ -151,6 +151,7 @@ FUNCTION(PYTHON_WRITE_MODULES_HEADER _filename)
   GET_FILENAME_COMPONENT(_name ${_filename} NAME)
   STRING(REPLACE . _ _name ${_name})
   STRING(TOUPPER ${_name} _nameUpper)
+  SET(_filename ${CMAKE_CURRENT_BINARY_DIR}/${_filename})
 
   SET(_filenameTmp ${_filename}.in)
   FILE(WRITE ${_filenameTmp} /*Created by cmake, do not edit, changes will be 
lost*/\n)

---

Summary of changes:
 Modules/FindPythonLibs.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

Re: [CMake] ctest and git submodules

[Marcus D. Hanwell]

On Wed, Jan 12, 2011 at 12:16 PM, Gerhard Gappmeier
gerhard.gappme...@ascolab.com wrote:
 Hi,

 my project is stored in a git repo with submodules.

 I'm wondering if ctest is updating also the submodules when running

 ctest Nightly|Continuous etc.

 or just the main repo.

 I believe not, unless I have some other problems with my test script.

 I could do a manual git pull  git submodule init  git submodule update

 before running ctest, but then ctest -D Continuous will do nothing because
 it doesn't detect the change anymore.

 Has anybody working ctest with git submodules?

See this ParaView CTest script for an example of how we handle
submodules in ParaView right now. ctest_update will see changes in the
main repo, but not any of the submodules. The submodules are then
updated, and the build begins. Last time I looked there was no
automatic update of the submodules.

http://www.cdash.org/CDash/viewNotes.php?buildid=823021

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to have a target depend on an External Project

[Marcus D. Hanwell]

On Wed, Jan 12, 2011 at 12:53 PM, kent williams
nkwmailingli...@gmail.com wrote:
 For better or worse (mostly better) we are now heavy users of
 ExternalProject.  That module works really well to pull in external
 dependencies and get them built.

 ExternalProject_add has a DEPENDS keyword that lets you specify
 dependencies on other External Projects.  But an ExternalProject isn't
 an actual CMake target, so I can't figure out how to make a regular
 CMake target depend on an External Project.

 Suggestions?

Don't mix external projects and real targets. An external project
dependency is different to a target dependency. When expressing
external project dependencies you are stating that this external
project needs these others to be built before it is even configured.

With regular targets there is an assumption that the dependency is
part of the current build, and so CMake knows everything about it, or
it was already built. If you have Qt in an external project, and a Qt
based application depending on it, the find_package(Qt4) will fail
during initial configure, as there is no Qt built/installed.

Instead you would normally have your own project as an external
project that depends on the others it requires to build. That way,
when your external project is configured the others will have been
built and therefore could be found.

I hope that makes the mechanism a little clearer. You could take a
look at the Titan project as one example where we have many external
projects that we build, and the Libraries/Applications external
projects that depend upon them and use them.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, next, updated. v2.8.3-1277-gef64b45

[Marcus D . Hanwell]

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  ef64b450fa34b95d31bb0110901362af31c2c765 (commit)
   via  9c43e61a81331ef74887c36956de789f45c02063 (commit)
   via  2d3594b1bbd48d0dc7a071a6806c75c89341e1c5 (commit)
  from  5477047b201a92efa09c49b0afe9d65b754a0eb1 (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=ef64b450fa34b95d31bb0110901362af31c2c765
commit ef64b450fa34b95d31bb0110901362af31c2c765
Merge: 5477047 9c43e61
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Mon Jan 10 13:53:10 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jan 10 13:53:10 2011 -0500

Merge topic 'resolve/next/python-versions' into next

9c43e61 Merge remote branch 'origin/next' into python-versions
2d3594b Python additional version support, bug #10279.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9c43e61a81331ef74887c36956de789f45c02063
commit 9c43e61a81331ef74887c36956de789f45c02063
Merge: 2d3594b 5477047
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Mon Jan 10 13:52:21 2011 -0500
Commit: Marcus D. Hanwell marcus.hanw...@kitware.com
CommitDate: Mon Jan 10 13:52:21 2011 -0500

Merge remote branch 'origin/next' into python-versions

Conflicts:
Modules/FindPythonInterp.cmake

diff --cc Modules/FindPythonInterp.cmake
index f2c116f,6c97ba3..3592e4c
--- a/Modules/FindPythonInterp.cmake
+++ b/Modules/FindPythonInterp.cmake
@@@ -45,7 -36,8 +45,7 @@@ endif(
  
  # handle the QUIETLY and REQUIRED arguments and set PYTHONINTERP_FOUND to 
TRUE if
  # all listed variables are TRUE
- include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
 -INCLUDE(FindPackageHandleStandardArgs)
++include(FindPackageHandleStandardArgs)
  FIND_PACKAGE_HANDLE_STANDARD_ARGS(PythonInterp DEFAULT_MSG PYTHON_EXECUTABLE)
  
 -MARK_AS_ADVANCED(PYTHON_EXECUTABLE)
 -
 +mark_as_advanced(PYTHON_EXECUTABLE)

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2d3594b1bbd48d0dc7a071a6806c75c89341e1c5
commit 2d3594b1bbd48d0dc7a071a6806c75c89341e1c5
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Mon Jan 10 13:44:45 2011 -0500
Commit: Marcus D. Hanwell marcus.hanw...@kitware.com
CommitDate: Mon Jan 10 13:44:45 2011 -0500

Python additional version support, bug #10279.

Introduced an additional variable, Python_ADDITIONAL_VERSIONS, to both
FindPythonLibs and FindPythonInterp. Changed FindPythonInterp to loop
over versions rather than hardcoding all versions (more like libs).

diff --git a/Modules/FindPythonInterp.cmake b/Modules/FindPythonInterp.cmake
index 645ca79..f2c116f 100644
--- a/Modules/FindPythonInterp.cmake
+++ b/Modules/FindPythonInterp.cmake
@@ -2,8 +2,9 @@
 # This module finds if Python interpreter is installed and determines where the
 # executables are. This code sets the following variables:
 #
-#  PYTHONINTERP_FOUND - Was the Python executable found
-#  PYTHON_EXECUTABLE  - path to the Python interpreter
+#  PYTHONINTERP_FOUND - Was the Python executable found
+#  PYTHON_EXECUTABLE  - path to the Python interpreter
+#  Python_ADDITIONAL_VERSIONS - list of additional Python versions to search 
for
 #
 
 #=
@@ -19,25 +20,32 @@
 # (To distribute this file outside of CMake, substitute the full
 #  License text for the above reference.)
 
-FIND_PROGRAM(PYTHON_EXECUTABLE
-  NAMES python2.7 python2.6 python2.5 python2.4 python2.3 python2.2 python2.1 
python2.0 python1.6 python1.5 python
-  PATHS
-  [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.7\\InstallPath]
-  [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.6\\InstallPath]
-  [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.5\\InstallPath]
-  [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.4\\InstallPath]
-  [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.3\\InstallPath]
-  [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.2\\InstallPath]
-  [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.1\\InstallPath]
-  [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.0\\InstallPath]
-  [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\1.6\\InstallPath]
-  [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\1.5\\InstallPath]
-  )
+# Set up the versions we know about, in the order we will search. Always add
+# the user supplied additional versions to the front.
+set(_Python_VERSIONS
+  ${Python_ADDITIONAL_VERSIONS}
+  2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0 1.6 1.5)
+
+# Run first with the Python version in the executable

[Cmake-commits] CMake branch, next, updated. v2.8.3-829-g37929fe

[Marcus D . Hanwell]

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  37929fe34bdd226e05c78aa00a0f90a8d360fe4b (commit)
   via  3bc828df9a0869f292de09ddcec306c16fe6d743 (commit)
  from  1f70d7aa3829e8fab044a33f457449febab3180d (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=37929fe34bdd226e05c78aa00a0f90a8d360fe4b
commit 37929fe34bdd226e05c78aa00a0f90a8d360fe4b
Merge: 1f70d7a 3bc828d
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Mon Dec 13 12:52:44 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 13 12:52:44 2010 -0500

Merge topic 'external-project-args-file' into next

3bc828d Fixed bug where last entry would be lost.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3bc828df9a0869f292de09ddcec306c16fe6d743
commit 3bc828df9a0869f292de09ddcec306c16fe6d743
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Mon Dec 13 12:50:38 2010 -0500
Commit: Marcus D. Hanwell marcus.hanw...@kitware.com
CommitDate: Mon Dec 13 12:50:38 2010 -0500

Fixed bug where last entry would be lost.

The code to build up a list was missing the final entry in an initial
cache.

diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index 542dbc2..a3590cf 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -579,6 +579,11 @@ function(_ep_write_initial_cache script_filename args)
   set(accumulator ${accumulator};${line})
 endif()
   endforeach()
+  # Catch the final line of the args
+  if(setArg)
+set(setArg ${setArg}${accumulator}\ CACHE ${type} \Initial cache\ 
FORCE))
+set(script_initial_cache ${script_initial_cache}\n${setArg})
+  endif()
   # Write out the initial cache file to the location specified.
   if(NOT EXISTS ${script_filename}.in)
 file(WRITE ${script_filename}.in \...@script_initial_cache\@\n)

---

Summary of changes:
 Modules/ExternalProject.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, next, updated. v2.8.3-834-g1306474

[Marcus D . Hanwell]

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  1306474331ecf15bc048a4d0aff53f4f6ac4632d (commit)
   via  ce013215d27caebff882240968c9b0e9a6d230e2 (commit)
  from  a3f94a43b4b3db9a294801a3f810fcb6a4b59307 (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=1306474331ecf15bc048a4d0aff53f4f6ac4632d
commit 1306474331ecf15bc048a4d0aff53f4f6ac4632d
Merge: a3f94a4 ce01321
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Mon Dec 13 13:27:21 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 13 13:27:21 2010 -0500

Merge topic 'vim-help' into next

ce01321 Inline help in vim with vertical split.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ce013215d27caebff882240968c9b0e9a6d230e2
commit ce013215d27caebff882240968c9b0e9a6d230e2
Author: Matthias Kretz kr...@kde.org
AuthorDate: Mon Dec 13 13:15:43 2010 -0500
Commit: Marcus D. Hanwell marcus.hanw...@kitware.com
CommitDate: Mon Dec 13 13:25:27 2010 -0500

Inline help in vim with vertical split.

Added a small script to open a vertical split window with the output of
cmake --help-command for the word under the cursor.

diff --git a/Docs/cmake-help.vim b/Docs/cmake-help.vim
new file mode 100644
index 000..17cfa83
--- /dev/null
+++ b/Docs/cmake-help.vim
@@ -0,0 +1,21 @@
+nmap ,hc :call OpenCmakeHelp()CR
+
+function! OpenCmakeHelp()
+let s = getline( '.' )
+let i = col( '.' ) - 1
+while i  0  strpart( s, i, 1 ) =~ '[A-Za-z0-9_]'
+let i = i - 1
+endwhile
+while i  col('$')  strpart( s, i, 1 ) !~ '[A-Za-z0-9_]'
+let i = i + 1
+endwhile
+let start = match( s, '[A-Za-z0-9_]\+', i )
+let end = matchend( s, '[A-Za-z0-9_]\+', i )
+let ident = strpart( s, start, end - start )
+execute vertical new
+execute %!cmake --help-command .ident
+set nomodified
+set readonly
+endfunction
+
+autocmd BufRead,BufNewFile *.cmake,CMakeLists.txt,*.cmake.in nmap F1 :call 
OpenCmakeHelp()CR

---

Summary of changes:
 Docs/cmake-help.vim |   21 +
 1 files changed, 21 insertions(+), 0 deletions(-)
 create mode 100644 Docs/cmake-help.vim


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.3-806-gc9c1272

[Marcus D . Hanwell]

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  c9c1272a165b5e7f081746b975881b404d888586 (commit)
   via  b316087c095e23e131bf2ccf5eb7110b35df0e29 (commit)
   via  68cd3fe038471b5a60d396eac141a69414b3064d (commit)
  from  9323fedf89a7bac078c684220e47c237fba360cd (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=c9c1272a165b5e7f081746b975881b404d888586
commit c9c1272a165b5e7f081746b975881b404d888586
Merge: 9323fed b316087
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Sat Dec 11 12:13:18 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Dec 11 12:13:18 2010 -0500

Merge topic 'external-project-args-file' into next

b316087 Escape file write expansion, and build up lists.
68cd3fe Added CMAKE_CACHE_ARGS to ExternalProject.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b316087c095e23e131bf2ccf5eb7110b35df0e29
commit b316087c095e23e131bf2ccf5eb7110b35df0e29
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Fri Dec 10 20:03:58 2010 -0500
Commit: Marcus D. Hanwell marcus.hanw...@kitware.com
CommitDate: Sat Dec 11 12:11:27 2010 -0500

Escape file write expansion, and build up lists.

Escaped the @var@ in the file writes - this was being expanded at file
write and so not causing a reconfigure at the right time. I also took
care of build up lists of lists in the variables, especially important
for things like MPI_EXTRA_LIBRARY. Added some error checking, and use
the tmp_dir for initial cache file.

diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index c575a73..542dbc2 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -554,23 +554,36 @@ function(_ep_write_initial_cache script_filename args)
   # Write out values into an initial cache, that will be passed to CMake with 
-C
   set(script_initial_cache )
   set(regex ^([^:]+):([^=]+)=(.*)$)
+  set(setArg )
   foreach(line ${args})
-string(REGEX REPLACE ^-D  line ${line})
-if(${line} MATCHES ${regex})
-  string(REGEX MATCH ${regex} match ${line})
-  set(name ${CMAKE_MATCH_1})
-  set(type ${CMAKE_MATCH_2})
-  set(value ${CMAKE_MATCH_3})
-  set(setArg set(${name} \${value}\ CACHE ${type} \Initial cache\ 
FORCE))
-  set(script_initial_cache ${script_initial_cache}\n${setArg})
+if(${line} MATCHES ^-D)
+  if(setArg)
+# This is required to build up lists in variables, or complete an entry
+set(setArg ${setArg}${accumulator}\ CACHE ${type} \Initial cache\ 
FORCE))
+set(script_initial_cache ${script_initial_cache}\n${setArg})
+set(accumulator )
+set(setArg )
+  endif()
+  string(REGEX REPLACE ^-D  line ${line})
+  if(${line} MATCHES ${regex})
+string(REGEX MATCH ${regex} match ${line})
+set(name ${CMAKE_MATCH_1})
+set(type ${CMAKE_MATCH_2})
+set(value ${CMAKE_MATCH_3})
+set(setArg set(${name} \${value})
+  else()
+message(WARNING Line '${line}' does not match regex. Ignoring.)
+  endif()
+else()
+  # Assume this is a list to append to the last var
+  set(accumulator ${accumulator};${line})
 endif()
   endforeach()
   # Write out the initial cache file to the location specified.
   if(NOT EXISTS ${script_filename}.in)
-file(WRITE ${script_filename}.in @script_initial_ca...@\n)
+file(WRITE ${script_filename}.in \...@script_initial_cache\@\n)
   endif()
   configure_file(${script_filename}.in ${script_filename})
-
 endfunction(_ep_write_initial_cache)
 
 
@@ -1251,7 +1264,7 @@ function(_ep_add_configure_command name)
 # If there are any CMAKE_CACHE_ARGS, write an initial cache and use it
 get_property(cmake_cache_args TARGET ${name} PROPERTY _EP_CMAKE_CACHE_ARGS)
 if(cmake_cache_args)
-  set(_ep_cache_args_script 
${CMAKE_CURRENT_BINARY_DIR}/${name}-cache.cmake)
+  set(_ep_cache_args_script ${tmp_dir}/${name}-cache.cmake)
   _ep_write_initial_cache(${_ep_cache_args_script} ${cmake_cache_args})
   list(APPEND cmd -C${_ep_cache_args_script})
 endif()
@@ -1274,7 +1287,7 @@ function(_ep_add_configure_command name)
   # Fixes issue http://public.kitware.com/Bug/view.php?id=10258
   #
   if(NOT EXISTS ${tmp_dir}/${name}-cfgcmd.txt.in)
-file(WRITE ${tmp_dir}/${name}-cfgcmd.txt.in cmd='@cmd@'\n)
+file(WRITE ${tmp_dir}/${name}-cfgcmd.txt.in cmd='\...@cmd\@'\n)
   endif()
   configure_file(${tmp_dir}/${name}-cfgcmd.txt.in 
${tmp_dir}/${name}-cfgcmd.txt)
   list(APPEND file_deps ${tmp_dir}/${name

Re: [CMake] [Titan-developers] Forcing 'out-of-source' build

[Marcus D. Hanwell]

On Fri, Nov 26, 2010 at 3:24 PM, Wylie, Brian bnwy...@sandia.gov wrote:
 Hi All,

 I want to force an 'out-of-source' build for a small project that I converted 
 to use Cmake.

 I did a bit of searching and found variants of the following...

 # Make sure the build is out of source
 STRING(COMPARE EQUAL ${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} insource)
  IF(insource)
    MESSAGE(FATAL_ERROR Do not build in your source dir please :))
  ENDIF(insource)


 It works but it still generates a CMakeCache.txt file and a CMakeFiles 
 directory in the source directory (which I've also seen others discussing)... 
  is there a more official way to block 'in-source' builds that leaves the 
 source dir pristine?

This was discussed recently by the ITK community, the best they came
up with was making CMake give instructions on how to clean up your
source tree. Hopefully this link works, and you can see what I mean,

http://www.itk.org/gitweb?p=ITK.git;a=blob;f=CMake/PreventInSourceBuilds.cmake;h=78f6b4e63ab7b08ec87146f61adbb791a178;hb=HEAD

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, next, updated. v2.8.3-612-g2adf433

[Marcus D . Hanwell]

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  2adf43362641b98c82bdd7c1a057f03e84d5125f (commit)
   via  74e49aa441e4805b40b5e61348501f9143a5defe (commit)
  from  fc13fef3ab99fef90a16a3d7fdc8ced9c0ac61d2 (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=2adf43362641b98c82bdd7c1a057f03e84d5125f
commit 2adf43362641b98c82bdd7c1a057f03e84d5125f
Merge: fc13fef 74e49aa
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Sat Nov 13 09:04:36 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Nov 13 09:04:36 2010 -0500

Merge topic 'EP-extra-generator' into next

74e49aa BUG 11451 - pass CMAKE_EXTRA_GENERATOR down.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=74e49aa441e4805b40b5e61348501f9143a5defe
commit 74e49aa441e4805b40b5e61348501f9143a5defe
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Fri Nov 12 19:43:05 2010 -0500
Commit: Marcus D. Hanwell marcus.hanw...@kitware.com
CommitDate: Fri Nov 12 19:43:05 2010 -0500

BUG 11451 - pass CMAKE_EXTRA_GENERATOR down.

This patch fixes the behavior of external projects with respect to
generators using the CMAKE_EXTRA_GENERATOR variable.

diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index 997164a..1be6cfd 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -1228,7 +1228,12 @@ function(_ep_add_configure_command name)
 if(cmake_generator)
   list(APPEND cmd -G${cmake_generator} ${source_dir})
 else()
-  list(APPEND cmd -G${CMAKE_GENERATOR} ${source_dir})
+  if(CMAKE_EXTRA_GENERATOR)
+list(APPEND cmd -G${CMAKE_EXTRA_GENERATOR} - ${CMAKE_GENERATOR}
+  ${source_dir})
+  else()
+list(APPEND cmd -G${CMAKE_GENERATOR} ${source_dir})
+  endif()
 endif()
   endif()
 

---

Summary of changes:
 Modules/ExternalProject.cmake |7 ++-
 1 files changed, 6 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

Re: [CMake] CMake 2.8.3-rc4 ready for testing!

[Marcus D. Hanwell]

On Sun, Oct 31, 2010 at 7:30 PM, Campbell Barton ideasma...@gmail.com wrote:
 Hi I saw in the log you added a case for Python 2.7,
 Would you be able to add a check for Python 3.x ?

 For Blender 3D we use CMake and only support python 3.x series.

I added that (or part of it at least). I suspect it is too late, and
we really need to add a variable to request Python 3. That would be
too big of a change this late in the RC series. We could work on
something, with a view to getting it in CMake 2.8.4, that you could
add to Blender's CMake module path until the release.

I think for it to be general enough we would need something that
defaulted to Python 2.x, but could look for Python 3 if the project
requested it. I was not sure how best to handle this, and wanted to
make sure this release found Python 2.7. I know for most of the
project I develop we explicitly don't want Python 3 as our stuff is
not ready for it yet.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake for cygwin

[Marcus D. Hanwell]

On Thu, Oct 28, 2010 at 8:45 AM, Marco Atzeri marco_atz...@yahoo.it wrote:
 --- Mer 27/10/10, Marcus D. Hanwell  ha scritto:

 On Wed, Oct 27, 2010 at 2:38 PM, Alan
 W. Irwin

 wrote:
  On 2010-10-26 17:53-0400 Bill Hoffman wrote:
 
  The policy mechanism might not be ideal but in a
 year or so, all of this
  would go away, and the meantime the patches you
 have to maintain for cygwin
  ports would become trivial.  The patch would
 basically have a set cmake
  version at the top.   I thought the command line
 option was a nice
  compromise.
 
  Bill, as somebody associated with a software package
 (PLplot) which
  already works on Cygwin, I think the policy mechanism
 is the ideal way
  to handle this requested change.  I do believe the
 Cygwin packagers
  when they say the change will make a lot more projects
 build without
  issues on Cygwin, but it is also extremely likely
 their preferred
  solution (breaking backwards compatibility for cmake)
 would also break
  currently working builds (such as the PLplot one) on
 Cygwin.
 
  I sympathize with the frustrations of the Cygwin
 packagers at the
  slowness with which this issue has been dealt with,
 but OTOH, I am not
  sure they completely understand the neat resolution of
 the issue that
  you are now offering with a policy-based approach to
 the requested
  change. Thus, I suggest you just go ahead and
 implement that preferred
  solution without further frustrating delays. Then
 publish cookbook
  instructions about the one-line change that needs to
 be made in the
  top-level CMakeLists.txt file of each currently
 non-working Cygwin
  project (but not the working ones like PLplot) in
 order for the new
  policy to be recognized. Ideally, upstream projects
 that currently
  don't build on Cygwin will adopt this solution, but if
 they are slow
  in doing that, it should not be too difficult for the
 Cygwin packagers
  to implement a sed (or whatever) script to do the
 required one-line
  changes in the top-level CMakeLists.txt files for each
 package in an
  automatic fashion.

 As someone who packaged software for Gentoo Linux for many
 years I can
 sympathize with your frustration when something is not
 corrected in a
 timely fashion. I don't know much about the background of
 this
 particular case, but I would hope that you would choose to
 work with
 Bill rather than patch CMake and circumvent his efforts to
 fix this
 issue.

 If this results in a one line patch to Cygwin packages in
 the short
 term, which can be removed in the longer term, that would
 seem like a
 reasonable solution to the problem. Breaking backwards
 compatibility
 could potentially break all of the packages people got
 working on
 Cygwin with CMake, and that would be far worse.

 Disclaimer: I am also a Kitware employee, but before I came
 here I
 worked in open source for many years as part of larger
 projects such
 as Gentoo, KDE and Avogadro. I for one like the policy
 mechanism, as
 it allows CMake to move forward while not breaking existing
 builds. As
 a packager I would never intentionally change the default
 behavior of
 a project, effectively forking the project.

 If you chose to take such rash action I would also avoid
 cygwin in the future.

 Marcus

 Hi Marcus,
 I guess your comments were for me and not really for Irwin.

Yes, I failed at using the web interface to my email to reply to a
long thread...

 Unfortunately in this case the policy chosen for CYGWIN
 is a BAD one, causing most of package not originally designed
 with cygwin in mind (and I should say they are the vast majority)
 to be almost impossible to correctly port on Cygwin
 without a deep and invasive patch activity.
 My and Yaakov's experience is that inverting the policy
 the porting becomes very easy and almost all the package
 build from the source without patches or few very basic
 changes.

It seems that the policy based approach would have allowed you a one
line patch to most packages (changing the policy to NEW). I work with
people who have specifically worked on getting their project to build
in Cygwin, and it sounds like this change would require them to change
their project after CMake is updated. That sounds bad, and is the
whole reason that CMake policies were introduced - to allow CMake to
fix old behavior without breaking packages that rely upon said
behavior (until they are ready to port).

 I hope this also clarify you and the others why we are so
 obsessive about this change. I prefer this change in
 cmake than starting a don Quixote quest to change all the
 softwares that use cmake as build system.

I have patched many a build system in my time, and identify with you.

 Disclaimer: I am just a volunteer cygwin package maintainer,
 my job is totally unrelated to this activity.

All of my packaging experience was voluntary too, and it can be a
thankless task. I just always preferred to work with upstreams as much
as possible when packaging. My comments were more directed at you

Re: [CMake] cmake for cygwin

[Marcus D. Hanwell]

On Wed, Oct 27, 2010 at 2:38 PM, Alan W. Irwin
ir...@beluga.phys.uvic.ca wrote:
 On 2010-10-26 17:53-0400 Bill Hoffman wrote:

 The policy mechanism might not be ideal but in a year or so, all of this
 would go away, and the meantime the patches you have to maintain for cygwin
 ports would become trivial.  The patch would basically have a set cmake
 version at the top.   I thought the command line option was a nice
 compromise.

 Bill, as somebody associated with a software package (PLplot) which
 already works on Cygwin, I think the policy mechanism is the ideal way
 to handle this requested change.  I do believe the Cygwin packagers
 when they say the change will make a lot more projects build without
 issues on Cygwin, but it is also extremely likely their preferred
 solution (breaking backwards compatibility for cmake) would also break
 currently working builds (such as the PLplot one) on Cygwin.

 I sympathize with the frustrations of the Cygwin packagers at the
 slowness with which this issue has been dealt with, but OTOH, I am not
 sure they completely understand the neat resolution of the issue that
 you are now offering with a policy-based approach to the requested
 change. Thus, I suggest you just go ahead and implement that preferred
 solution without further frustrating delays. Then publish cookbook
 instructions about the one-line change that needs to be made in the
 top-level CMakeLists.txt file of each currently non-working Cygwin
 project (but not the working ones like PLplot) in order for the new
 policy to be recognized. Ideally, upstream projects that currently
 don't build on Cygwin will adopt this solution, but if they are slow
 in doing that, it should not be too difficult for the Cygwin packagers
 to implement a sed (or whatever) script to do the required one-line
 changes in the top-level CMakeLists.txt files for each package in an
 automatic fashion.

As someone who packaged software for Gentoo Linux for many years I can
sympathize with your frustration when something is not corrected in a
timely fashion. I don't know much about the background of this
particular case, but I would hope that you would choose to work with
Bill rather than patch CMake and circumvent his efforts to fix this
issue.

If this results in a one line patch to Cygwin packages in the short
term, which can be removed in the longer term, that would seem like a
reasonable solution to the problem. Breaking backwards compatibility
could potentially break all of the packages people got working on
Cygwin with CMake, and that would be far worse.

Disclaimer: I am also a Kitware employee, but before I came here I
worked in open source for many years as part of larger projects such
as Gentoo, KDE and Avogadro. I for one like the policy mechanism, as
it allows CMake to move forward while not breaking existing builds. As
a packager I would never intentionally change the default behavior of
a project, effectively forking the project.

If you chose to take such rash action I would also avoid cygwin in the future.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Status of clang support?

[Marcus D. Hanwell]

On Sun, Oct 24, 2010 at 2:58 PM, Michael Wild them...@gmail.com wrote:

 On 24. Oct, 2010, at 17:33 , Mateusz Loskot wrote:

 Hi,

 I'm trying to find out what's the status of clang support in CMake.
 What version of CMake is recommended to make proper use of clang 2.8+
 for building a C++ software, etc.

 Feeding the favourite search engine with this:

 clang site:http://www.cmake.org/pipermail/cmake/

 gives me literally 4 pages os results, but no announcement-like posts.


 Best regards,
 --
 Mateusz Loskot, http://mateusz.loskot.net
 Charter Member of OSGeo, http://osgeo.org
 Member of ACCU, http://accu.org

 Hi

 Clang's UI is a clone of gcc's, so there's very little extra work CMake has 
 to perform. For me it works flawlessly. I don't know about the earliest 
 version to support Clang, but AFAIK 2.8 works well.

I echo Michael's reports, setting it as the compiler just works for
many projects. The ones where it fails it is a compilation issue, and
I have used CMake 2.8.2 with several projects to test out the Clang
support.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, next, updated. v2.8.2-1094-g0d0b39d

[Marcus D . Hanwell]

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  0d0b39dec91fae1187047e672ed12ef0659925a7 (commit)
   via  beeca11c9bcfd0cc211c8c73f4b00709c914eac3 (commit)
  from  ee0ef5bdc84118423203bea83995a980305a17b4 (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=0d0b39dec91fae1187047e672ed12ef0659925a7
commit 0d0b39dec91fae1187047e672ed12ef0659925a7
Merge: ee0ef5b beeca11
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Fri Oct 22 11:19:26 2010 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Oct 22 11:19:26 2010 -0400

Merge topic 'external-project-extra-gen' into next

beeca11 Fixed parallel build for generators with EXTRA.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=beeca11c9bcfd0cc211c8c73f4b00709c914eac3
commit beeca11c9bcfd0cc211c8c73f4b00709c914eac3
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Fri Oct 22 11:16:21 2010 -0400
Commit: Marcus D. Hanwell marcus.hanw...@kitware.com
CommitDate: Fri Oct 22 11:16:21 2010 -0400

Fixed parallel build for generators with EXTRA.

Fixed parallel build for projects using generators that have the
CMAKE_EXTRA_GENERATOR as well as CMAKE_GENERATOR. Thanks to Bill Hoffman
for helping me to track this one down, I missed parallel builds.

diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index d76796f..dfd96cd 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -597,8 +597,7 @@ function(_ep_get_build_command name step cmd_var)
   # CMake project.  Select build command based on generator.
   get_target_property(cmake_generator ${name} _EP_CMAKE_GENERATOR)
   if(${CMAKE_GENERATOR} MATCHES Make AND
-  (${cmake_generator} STREQUAL ${CMAKE_GENERATOR} OR
-  NOT cmake_generator))
+ (${cmake_generator} MATCHES Make OR NOT cmake_generator))
 # The project uses the same Makefile generator.  Use recursive make.
 set(cmd $(MAKE))
 if(step STREQUAL INSTALL)

---

Summary of changes:
 Modules/ExternalProject.cmake |3 +--
 1 files changed, 1 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

Re: [cmake-developers] User vs CMake include mismatch handling

[Marcus D. Hanwell]

On Fri, Oct 15, 2010 at 1:59 PM, David Cole david.c...@kitware.com wrote:
 On Fri, Oct 15, 2010 at 1:36 PM, David Cole david.c...@kitware.com wrote:

 On Fri, Oct 15, 2010 at 8:23 AM, Bill Hoffman bill.hoff...@kitware.com
 wrote:

 On 10/14/2010 2:18 PM, David Cole wrote:

 On Thu, Oct 14, 2010 at 1:30 PM, Alexander Neundorf neund...@kde.org
 mailto:neund...@kde.org wrote:

    On Wednesday 13 October 2010, Alexander Neundorf wrote:
      On Wednesday 13 October 2010, Bill Hoffman wrote:
       So, I think we have to use the new name approach.  Do we want
    to call it
       2?  Or should we call it something else?
      
       Alex, do you have time to do this?
     
      I think it's not a good solution, and the one with
    CURRENT_LIST_DIR is
      definitely better and already implemented.
      And I am still convinced that I am right here, see my other mails.

    So I would suggest to merge the CURRENT_LIST_DIR branch for 2.8.3,
    and as soon
    as 2.8.3 is released, remove the full paths again and enable the new
    CMP0017
    instead (prefer CMAKE_ROOT when include()d from CMAKE_ROOT) and then
    see what
    happens during the whole 2.8.4 cycle.

    I think this (CMP0017) is necessary, because otherwise we can only
 hope
    nothing breaks with future releases (independent from FPHSA).

    Alex
    ___
    cmake-developers mailing list
    cmake-develop...@cmake.org mailto:cmake-developers@cmake.org
    http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers



 I'm ok with this since Alex feels so strongly about it, and the code
 change is restricted to using CMAKE_CURRENT_LIST_DIR only when including
 FPHSA.cmake... (i.e. -- it should not affect including *other* files
 from inside of modules that are presently overridden... which was my
 concern -- that we'd break some *other* scenario -- since that's not
 true, I retract my objection.)

 To review the change yourself:
   git fetch stage
   gitk remotes/stage/AddCMAKE_CURRENT_LIST_DIR

 Look at the top 3 commits. Looks pretty safe. I'd say we should merge it
 to 'next' and then after a night on the dashboards, merge it to 'master'
 and do an rc3 release based on that.


 OK, lets try this one.  Lets move it to next.

 -Bill
 ___
 cmake-developers mailing list
 cmake-developers@cmake.org
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


 I'm trying to merge this, and getting conflicts when merging to 'next'
 because of changes in cmMakefile.cxx like this:

   this-AddDefinition(CMAKE_CURRENT_LIST_FILE, filenametoread);

  HEAD

   this-MarkVariableAsUsed(CMAKE_CURRENT_LIST_FILE);

 ===

   this-AddDefinition(CMAKE_CURRENT_LIST_DIR,


 cmSystemTools::GetFilenamePath(filenametoread).c_str());

  AddCMAKE_CURRENT_LIST_DIR

 What's the best way to resolve this conflict? Should I delete the
 MarkVariableAsUsed lines because they're part of the dev/strict-mode branch
 which is *not* going into 2.8.3?

 If I leave the MarkVariableAsUsed call in there, does if affect how the
 commit will merge to 'master'...?

 Arg.

 Never mind.
 I think I resolved this correctly for next (including *both* features) and
 pushed it just now. The conflict should not occur when merging to master, so
 there should be nothing to resolve when I merge to master, and the
 additional lines I added as conflict resolution should not end up in master.
 (I'm going to verify that locally right now... :-)
 Thanks,
 David

Just to confirm that the current next fixes the issues I observed with
CMake failing to configure Avogadro. I think your merge should be fine
for master for the reason you state.

Marcus
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[Cmake-commits] CMake branch, next, updated. v2.8.2-1087-g4887a43

[Marcus D . Hanwell]

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  4887a4328cf7f965f10b1f9f0baecceffd0cad8c (commit)
   via  1f369a71c80d606c8610b7e79c8aeaecba81a87f (commit)
  from  cea559d2c4e2c691792da7b95533d717b79241a9 (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=4887a4328cf7f965f10b1f9f0baecceffd0cad8c
commit 4887a4328cf7f965f10b1f9f0baecceffd0cad8c
Merge: cea559d 1f369a7
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Tue Oct 19 14:55:02 2010 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Oct 19 14:55:02 2010 -0400

Merge topic 'PythonLibs-2.7' into next

1f369a7 ENH: Added case for Python 2.7.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1f369a71c80d606c8610b7e79c8aeaecba81a87f
commit 1f369a71c80d606c8610b7e79c8aeaecba81a87f
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Tue Oct 19 14:53:33 2010 -0400
Commit: Marcus D. Hanwell marcus.hanw...@kitware.com
CommitDate: Tue Oct 19 14:53:33 2010 -0400

ENH: Added case for Python 2.7.

diff --git a/Modules/FindPythonLibs.cmake b/Modules/FindPythonLibs.cmake
index 283c914..2b9341c 100644
--- a/Modules/FindPythonLibs.cmake
+++ b/Modules/FindPythonLibs.cmake
@@ -27,7 +27,7 @@ INCLUDE(CMakeFindFrameworks)
 # Search for the python framework on Apple.
 CMAKE_FIND_FRAMEWORKS(Python)
 
-FOREACH(_CURRENT_VERSION 2.6 2.5 2.4 2.3 2.2 2.1 2.0 1.6 1.5)
+FOREACH(_CURRENT_VERSION 2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0 1.6 1.5)
   STRING(REPLACE .  _CURRENT_VERSION_NO_DOTS ${_CURRENT_VERSION})
   IF(WIN32)
 FIND_LIBRARY(PYTHON_DEBUG_LIBRARY

---

Summary of changes:
 Modules/FindPythonLibs.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

Re: [cmake-developers] User vs CMake include mismatch handling

[Marcus D. Hanwell]

2010/10/12 Alexander Neundorf neund...@kde.org

 On Tuesday 12 October 2010, Marcus D. Hanwell wrote:
  2010/10/12 Alexander Neundorf neund...@kde.org
 
   On Tuesday 12 October 2010, Marcus D. Hanwell wrote:
On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf 
 neund...@kde.org
   wrote:
  
   ...
  
 Personally, I would try a rc3 with CMP0017 set to NEW and see how
 it
 goes. It works for kdelibs and for our project at work (which
 doesn't
 have a lot of
 fancy cmake stuff).
   
If it is just that one file why not go with the simple solution? I
would love to see a policy where includes in the same directory would
be considered first, and then the normal search behavior. I wasn't
 sure
how feasible this was in an rc3. Avogadro effectively copied what KDE
was doing, and so maybe the issue is not that widespread.
  
   I don't have the avogadro sources here.
   What does it do, i.e. what did it copy from KDE ?
   Does it a
   find_package(KDE4) ?
  
   Or does it include its own version of
 FindPackageHandleStandardArgs.cmake
   ?
  

  It has its own copy of FindPackageHandleStandardArgs.cmake, which is used
  in some of the Find modules. Avogadro is a dependency of Kalzium (KDE
 Edu),
  but is C++/Qt based itself. I was more thinking of all the other packages
  out there that may have done similar, and the fact that we should avoid
  breaking their builds with a new CMake release.

 Ok. So setting CMP0017 to NEW in FindKDE4.cmake would not help Avogadro,
 and
 KDE4 is not the only project which breaks together with current cmake
 2.8.3.

 This reduces the number of acceptable solutions I think.


Yes, that is correct. I think it is hard to assess which projects might be
broken after release that have not tried an rc. I would not be surprised if
quite a few out there might break.


 Remaining are as far as I see:

 -set new policy CMP0017 to NEW by default
 Projects with an exotic setup may break, but that's probably better than
 breaking all KDE 4.5.0/1 builds. One could also argue that these projects
 relied on internal implementation details of cmake. As a pro, I think this
 behaviour (include()s from CMAKE_ROOT first check in CMAKE_ROOT) makes
 sense,
 since we have that dependency but currently it's not enforced.


I would tend to agree with you there.


 -hardcode the path to FPHSA.cmake in the find-modules in cmake, probably
 also
 to CMakeParseArguments.cmake and FindPackageMessage.cmake
 IMO not a solution, just a quick fix for the moment, because we have to
 maintain this forever in the future and basically we need to check *all*
 other include()s in CMAKE_ROOT.


Agreed.


 -rename the enhanced FPHSA to FPHSA2
 Worse than above, since this doesn't give any guarantee that the same does
 not
 happen again in the next cmake release with the renamed function.

 I think this is the simplest, but I can see why you would rather avoid it.


 Did I miss anything ?

 I don't think so. I would go with option 1 or 3. Effectively the policy
would be the reverse of most though, and so very confusing - setting it to
OLD is more likely to cause breakage than setting it to NEW. This would mean
that the standard documentation would not really apply well to this one
policy, and it could cause a lot of confusion.

I wonder if Brad or Bill have any thoughts on this?

Marcus
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] User vs CMake include mismatch handling

[Marcus D. Hanwell]

On Tuesday 12 October 2010 17:27:31 David Cole wrote:
 On Tue, Oct 12, 2010 at 5:21 PM, Brad King brad.k...@kitware.com wrote:
  On 10/12/2010 03:32 PM, Alexander Neundorf wrote:
   On Tuesday 12 October 2010, Bill Hoffman wrote:
   Anyway, in the short term, we are going to go with FPHSA2, Alex do you
   have time to do that?
   
   FPHSA2 would have been my last choice.
  
   In staging there is already the branch AddCMAKE_CURRENT_LIST_DIR:
  http://cmake.org/gitweb?p=stage/cmake.git;a=log;h=refs/heads/AddCMAKE_CUR
  RENT_LIST_DIR
  
   where I implemented the option with the hardcoded paths:
  The original FPHSA floated around outside of CMake in many projects
  before it was distributed with CMake.  It is a long-established API
  that has been re-implemented (via copying) in many projects.  Therefore
  it is too late to change.  See James Bigler's comment earlier in this
  thread about ABI compatibility approaches.  No one proposes changing
  the ABI of malloc in C because many custom allocation libraries
  override it at link time.
  
  Currently projects have the option to override it with CMAKE_MODULE_PATH
  to providing a module with the same API but a tweaked implementation.
  With the CURRENT_LIST_DIR approach that option goes away, and any
  project that does it already will break.
  
   macro with a new name ... which we then have to maintain forever
  
  It's not too bad.  The new name has the new API.  The original FPHSA
  module can just include the new one and forward calls appropriately.
  Any call to the original FPHSA will either go through the CMake version
  of it and forward to FPHSA2 or go through a project-overridden one.
  Any call to the FPHSA2 will either go through the CMake version or
  through one overridden by a project aware of the new API.
  
  This isn't perfect but it is 100% compatible with current project
  releases and will get us through this CMake rc cycle safely.  Future
  enhancements to FPHSA2 may need yet another new module, but I think
  that is in the nature of this particular function.
  
 I really think a second function is the way to go here. It is the least
 risky and maintains full compatibility with existing module overrides. It
 does not have to be named FPHSA2 (I am not a big fan of 2 named
 functions...) but I do think it needs to be a newly-named function, and
 keep the old function as is.
 
 We can come up with better solutions moving forward, but for now, to keep
 *everything* working well without breaking anything *else*... I think a
 second function is our only realistic option.
 
I like the malloc analogy, and think it holds here. We do have a certain 
responsibility to maintain API compatibility, and having a new function seems 
like the best way to achieve that for the release. Going forward, versioned 
include files, or preference towards local files might be the way to go.

Marcus
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] User vs CMake include mismatch handling

[Marcus D. Hanwell]

On Sunday 10 October 2010 14:56:29 Alexander Neundorf wrote:
 On Friday 08 October 2010, David Cole wrote:
  On Fri, Oct 8, 2010 at 10:59 AM, Alexander Neundorf 
neund...@kde.orgwrote:
 ...
 
   Better idea:
   
   I'll add a policy which switches this behaviour (prefer CMAKE_ROOT over
   CMAKE_MODULE_PATH when used from within CMAKE_ROOT), and this policy
   will, as all other policies, default to the old behaviour, but warn.
 
 ...
 
  This latest idea does sound better, but I am still not a fan of
  invisible / magic behavior. I much prefer when things are explicitly
  spelled out.
 
 There is now a branch PreferCMakeModulesByCMakeModulesWithPolicy on
 staging. It includes this patch, a new policy CMP0017, and a basic test
 for it.
 
 I also verified that this fixes the KDE 4.5 problem.
 With KDE 4.5.0/4.5.1 there are now a lot of these new CMP0017 warnings, and
 in the end stuff has not been found which should have been found.
 
 Should I handle setting CMP0017 to NEW in kdelibs (- cmake 2.8.3 will not
 be able to build KDE 4.5.0/1, but complain loud) or in
 CMake/Modules/FindKDE4.cmake (then cmake 2.8.3 will be able to build KDE
 4.5.0/1) ?
 
So is there no chance of fixing this in a backward compatible way? One of the 
projects I work on has been bitten by this too, and so I guess the old, 
released versions are doomed to fail with CMake 2.8.3 with the current 
solution. This seems like quite a regression, and something the policies were 
supposed to avoid (old projects failing with new CMake versions).

I tested your topic branch with this project, and it still fails with the 
following error,

CMake Error at cmake/modules/FindPackageHandleStandardArgs.cmake:53 (MESSAGE):
  REQUIRED_VARS
Call Stack (most recent call first):
  /usr/local/share/cmake-2.8/Modules/FindZLIB.cmake:70 
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:234 (find_package)

Marcus
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] User vs CMake include mismatch handling

[Marcus D. Hanwell]

On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf neund...@kde.orgwrote:

 On Monday 11 October 2010, Marcus D. Hanwell wrote:
  On Sunday 10 October 2010 14:56:29 Alexander Neundorf wrote:
 ...
  So is there no chance of fixing this in a backward compatible way? One of

 Prefering module in CMAKE_ROOT when include() or find_package() is called
 from
 CMAKE_ROOT (which does have the potential to break existing builds, but
 those
 projects must have a weird setup I think).


Sounds reasonable to me, although I know other options were floated.


  the projects I work on has been bitten by this too, and so I guess the
 old,
  released versions are doomed to fail with CMake 2.8.3 with the current
  solution. This seems like quite a regression, and something the policies
  were supposed to avoid (old projects failing with new CMake versions).

 Hmm, this would mean that the module which uses FPHSA() would have to check
 how the new policy is set and depending on this call FPHSA() with the old
 or
 the new enhanced syntax. That's also ugly I think, and worse than using
 include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)

 This would fix the current problem, but IMO this is not a real solution,
 since
 it can break also for other modules, and then this hardcoded path must be
 used also in the future in all find-modules.
 I think prefering the modules from CMAKE_ROOT when included from CMAKE_ROOT
 is
 the right thing to do. This expresses the dependency we have (from cmake
 modules to the other current cmake modules in CMAKE_ROOT).


It seems like a reasonable approach to generally prefer the .cmake files in
the same directory, before all others. I am not a core CMake developer
though, and defer to them on issues like this. I think whatever is done
should ensure old projects continue to build, even if new warnings are
issues.


  I tested your topic branch with this project, and it still fails with the

 You should get the policy warning about CMP0017.
 Is that the case ?

 I saw lots of warnings about CMP0017.


  following error,
 
  CMake Error at cmake/modules/FindPackageHandleStandardArgs.cmake:53
  (MESSAGE): REQUIRED_VARS
  Call Stack (most recent call first):
/usr/local/share/cmake-2.8/Modules/FindZLIB.cmake:70
  (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:234 (find_package)

 I see the following options:
 * set policy 0017 to NEW behaviour by default (is that possible ?)


I guess this is aimed at someone else, it would be the first I think if it
is possible.



* set policy 0017 to NEW behaviour somewhere locally. What project is
 failing ?


Avogadro. We can obviously make a new release with this corrected in a
number of ways, but it would sidestep the issue that a new CMake release
would be incompatible with a source tree that configured/compiled fine with
CMake 2.8.2 and earlier. This seems like a major regression to me. Anything
done locally doesn't help out when someone downloads this project, and I
wonder how many other projects we don't know about might be affected by this
issue.


 * hardcode ${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake
 instead of just using include(FindPackageHandleStandardArgs), problems see
 above
 * revert the enhanced syntax :-( or put it into a file
 FindPackageHandleStandardArgs2.cmake (but the same can happen later on
 again) :-/

 Putting it in a FindPackageHandleStandardArgs2.cmake while not ideal seems
like one of the better solutions. I agree that it does not fix the problem
very elegantly.


 Personally, I would try a rc3 with CMP0017 set to NEW and see how it goes.
 It works for kdelibs and for our project at work (which doesn't have a lot
 of
 fancy cmake stuff).

 If it is just that one file why not go with the simple solution? I would
love to see a policy where includes in the same directory would be
considered first, and then the normal search behavior. I wasn't sure how
feasible this was in an rc3. Avogadro effectively copied what KDE was doing,
and so maybe the issue is not that widespread.

Until now setting a minimum CMake version has always been enough, I would
hate for that to change.

Marcus
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[Cmake-commits] CMake branch, next, updated. v2.8.2-957-g1b0e592

[Marcus D . Hanwell]

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  1b0e5925cbfe295bbf1e3f8226fdb708ea9efb87 (commit)
   via  1a92548ca29387d65472f63f8401532ae48f293a (commit)
   via  4ebc277a7a64ff9ea93a1b67959c39c6d7bc892f (commit)
   via  68fd37c39938635e992ec47bad2afa13150b9b3d (commit)
  from  97ec9c3b2fad7be5686b40c6484528441b4cd190 (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=1b0e5925cbfe295bbf1e3f8226fdb708ea9efb87
commit 1b0e5925cbfe295bbf1e3f8226fdb708ea9efb87
Merge: 97ec9c3 1a92548
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Tue Sep 28 18:52:41 2010 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Sep 28 18:52:41 2010 -0400

Merge topic 'xcode_source_group_fix_7932' into next

1a92548 Revert previous commit in topic.
4ebc277 Revert Fix shadow warning in groups code.
68fd37c Revert Fix compile problem from previous commit.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1a92548ca29387d65472f63f8401532ae48f293a
commit 1a92548ca29387d65472f63f8401532ae48f293a
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Tue Sep 28 18:39:38 2010 -0400
Commit: Marcus D. Hanwell marcus.hanw...@kitware.com
CommitDate: Tue Sep 28 18:47:21 2010 -0400

Revert previous commit in topic.

Revert XCode Source Grouping now allows for multiple levels of source 
groups (7932).

This reverts commit 1c2e17f2afe4dfcb2dac543af4a21121722b38f9.

diff --git a/Source/cmGlobalXCodeGenerator.cxx 
b/Source/cmGlobalXCodeGenerator.cxx
index 3603ddf..e238c2b 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -1073,7 +1073,7 @@ void 
cmGlobalXCodeGenerator::CreateCustomCommands(cmXCodeObject* buildPhases,
   std::vectorcmSourceFile*const classes = cmtarget.GetSourceFiles();
   // add all the sources
   std::vectorcmCustomCommand commands;
-  for(std::vectorcmSourceFile*::const_iterator i = classes.begin(); 
+  for(std::vectorcmSourceFile*::const_iterator i = classes.begin();
   i != classes.end(); ++i)
 {
 if((*i)-GetCustomCommand())
@@ -2443,14 +2443,10 @@ void 
cmGlobalXCodeGenerator::CreateGroups(cmLocalGenerator* root,
 std::string const source = sf-GetFullPath();
 cmSourceGroup sourceGroup =
   mf-FindSourceGroup(source.c_str(), sourceGroups);
-sourceGroup.AssignSource( sf );
-}
-
-  // Create all of the groups that should be created for this target.
-  // Loop through every source group.
-  for(unsigned int i = 0; i  sourceGroups.size(); ++i)
-{
-this-CreateSourceGroup( sourceGroups[i], cmtarget, false );
+cmXCodeObject* pbxgroup =
+  this-CreateOrGetPBXGroup(cmtarget, sourceGroup);
+cmStdString key = GetGroupMapKey(cmtarget, sf);
+this-GroupMap[key] = pbxgroup;
 }
   }
 }
@@ -2458,45 +2454,7 @@ void 
cmGlobalXCodeGenerator::CreateGroups(cmLocalGenerator* root,
 
 //
 cmXCodeObject* cmGlobalXCodeGenerator
-::CreateSourceGroup( cmSourceGroup sg, cmTarget cmtarget, bool child_group )
-{
-  // Only do something with the group if there are files or child groups
-  if( !sg.GetSourceFiles().empty() || !sg.GetGroupChildren().empty() )
-{
-cmXCodeObject* pbxgroup =
-  this-CreateOrGetPBXGroup(cmtarget, sg, !child_group);
-
-std::vectorconst cmSourceFile* sources = sg.GetSourceFiles();
-// Get all the source files and add them to the GroupMap
-for(std::vectorconst cmSourceFile*::const_iterator s = sources.begin();
-s != sources.end(); s++)
-  {
-  cmStdString key = GetGroupMapKey(cmtarget, (cmSourceFile*)*s);
-  this-GroupMap[key] = pbxgroup;
-  }
-
-// Do the child groups
-std::vectorcmSourceGroup children  = sg.GetGroupChildren();
-cmXCodeObject* groupChildren = pbxgroup-GetObject(children);
-
-for(unsigned int i=0;ichildren.size();++i)
-  {
-  cmXCodeObject* group =
-this-CreateSourceGroup( children[i], cmtarget, true );
-  if (group)
-{
-groupChildren-AddObject(group);
-}
-  }
-return pbxgroup;
-}
-  return NULL;
-}
-
-
-//
-cmXCodeObject* cmGlobalXCodeGenerator
-::CreateOrGetPBXGroup(cmTarget cmtarget, cmSourceGroup* sg, bool child_group)
+::CreateOrGetPBXGroup(cmTarget cmtarget, cmSourceGroup* sg)
 {
   cmStdString s = cmtarget.GetName();
   s += /;
@@ -2517,7 +2475,7 @@ cmXCodeObject

[Cmake-commits] CMake branch, next, updated. v2.8.2-921-gb319e46

[Marcus D . Hanwell]

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  b319e4621ecffc82e9784a8e6a2295403059ecef (commit)
   via  d36c16a7609d3329dc32ae800570a0a06dea628e (commit)
  from  e3279afebeb6ed4aa3b11b3506e9b3ad21250185 (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=b319e4621ecffc82e9784a8e6a2295403059ecef
commit b319e4621ecffc82e9784a8e6a2295403059ecef
Merge: e3279af d36c16a
Author: Marcus D. Hanwell marcus.hanw...@kitware.com
AuthorDate: Fri Sep 24 15:07:07 2010 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Sep 24 15:07:07 2010 -0400

Merge topic 'python_module_prefix_suffix' into next

d36c16a Set the module prefix, updated Windows suffix.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d36c16a7609d3329dc32ae800570a0a06dea628e
commit d36c16a7609d3329dc32ae800570a0a06dea628e
Author: David Gobbi david.go...@gmail.com
AuthorDate: Fri Sep 24 15:04:24 2010 -0400
Commit: Marcus D. Hanwell marcus.hanw...@kitware.com
CommitDate: Fri Sep 24 15:04:24 2010 -0400

Set the module prefix, updated Windows suffix.

Set the Python module prefix to PYTHON_MODULE_PREFIX, and changed the
suffix on Windows to .pyd as .dll is officially deprecated.

diff --git a/Modules/FindPythonLibs.cmake b/Modules/FindPythonLibs.cmake
index d12f14a..283c914 100644
--- a/Modules/FindPythonLibs.cmake
+++ b/Modules/FindPythonLibs.cmake
@@ -128,6 +128,13 @@ FUNCTION(PYTHON_ADD_MODULE _NAME )
 ADD_LIBRARY(${_NAME} ${PY_MODULE_TYPE} ${ARGN})
 #TARGET_LINK_LIBRARIES(${_NAME} ${PYTHON_LIBRARIES})
 
+IF(PYTHON_MODULE_${_NAME}_BUILD_SHARED)
+  SET_TARGET_PROPERTIES(${_NAME} PROPERTIES PREFIX 
${PYTHON_MODULE_PREFIX})
+  IF(WIN32 AND NOT CYGWIN)
+SET_TARGET_PROPERTIES(${_NAME} PROPERTIES SUFFIX .pyd)
+  ENDIF(WIN32 AND NOT CYGWIN)
+ENDIF(PYTHON_MODULE_${_NAME}_BUILD_SHARED)
+
   ENDIF(PYTHON_ENABLE_MODULE_${_NAME})
 ENDFUNCTION(PYTHON_ADD_MODULE)
 

---

Summary of changes:
 Modules/FindPythonLibs.cmake |7 +++
 1 files changed, 7 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

Re: [CMake] External projects and imported targets

[Marcus D. Hanwell]

On Sun, May 16, 2010 at 12:48 PM, Timothy M. Shead tsh...@k-3d.com wrote:

 I'd like to do the following:

  # Build external project A
  ExternalProject_Add(A ...)

  # Import target B, which is exported by A in AConfig.cmake
  ExternalProject_Get_Property(A, BINARY_DIR)
  set(A_DIR ${BINARY_DIR})
  find_package(A)

  # Link with B
  add_library(C ...)
  target_link_libraries(C B)

 Of course, this doesn't work because the external project hasn't been
 built yet at configure-time, so AConfig.cmake doesn't exist.  Which
 leads me to the following:

 Hi,

If I understand your question correctly, then adding DEPENDS A to your
ExternalProject_Add(B...) call will ensure that A has been built when B is
configured, thus satisfying your need to find A's exported targets. Using
the dependencies between external projects it is possible to control the
build order, so that A's config file will be present before B attempts a
configure step.

Hope that helps, I will take a look at this case in a moment and do some
test builds.

Thanks,

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] External projects and imported targets

[Marcus D. Hanwell]

On Sun, May 16, 2010 at 2:26 PM, Timothy M. Shead tsh...@k-3d.com wrote:

 On 05/16/2010 12:11 PM, Marcus D. Hanwell wrote:
  On Sun, May 16, 2010 at 12:48 PM, Timothy M. Shead tsh...@k-3d.com
  mailto:tsh...@k-3d.com wrote:
 
  I'd like to do the following:
 
   # Build external project A
   ExternalProject_Add(A ...)
 
   # Import target B, which is exported by A in AConfig.cmake
   ExternalProject_Get_Property(A, BINARY_DIR)
   set(A_DIR ${BINARY_DIR})
   find_package(A)
 
   # Link with B
   add_library(C ...)
   target_link_libraries(C B)
 
  Of course, this doesn't work because the external project hasn't been
  built yet at configure-time, so AConfig.cmake doesn't exist.  Which
  leads me to the following:
 
  Hi,
 
  If I understand your question correctly, then adding DEPENDS A to your
  ExternalProject_Add(B...) call will ensure that A has been built when B
  is configured, thus satisfying your need to find A's exported targets.
  Using the dependencies between external projects it is possible to
  control the build order, so that A's config file will be present before
  B attempts a configure step.

 That wasn't quite what I was describing - B isn't another external
 project, it's a library that's built by external project A.  Because A
 hasn't been built (isn't even downloaded yet) at configure time, I can't
 use find_package to benefit from A's internal understanding of where
 its' outputs are located.  Basically, I want the simplest possible
 add_library(... IMPORTED) call possible, one that doesn't end-up
 duplicating all of the platform-specific logic that CMake normally takes
 care of.  Since my last post, I've switched to the following, which
 works on Linux and seems like it could work on Windows:

  ADD_LIBRARY(B SHARED IMPORTED)
  SET_TARGET_PROPERTIES(B PROPERTIES
IMPORTED_LOCATION
 ${BINARY_DIR}/path/to/libB${CMAKE_SHARED_LIBRARY_SUFFIX}
   IMPORTED_IMPLIB ${BINARY_DIR}/path/to/libB.lib
  )


Ah, I understand now. This is one of the major reasons to avoid mixing
external projects and traditional targets in the same build. I would solve
that by adding another external project in the build, that would depend on
A, and so A would be there at configure time and no guessing would be
necessary.

Is there any particular reason why you cannot use that pattern in your case?
Otherwise you can quickly end up writing a lot of code to predict where
things will be, and that could be quite a fragile approach if the targets
changed in a new release.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] External projects and imported targets

[Marcus D. Hanwell]

On Sun, May 16, 2010 at 2:47 PM, Timothy M. Shead tsh...@k-3d.com wrote:

 On 05/16/2010 12:36 PM, Marcus D. Hanwell wrote:
  On Sun, May 16, 2010 at 2:26 PM, Timothy M. Shead tsh...@k-3d.com
  mailto:tsh...@k-3d.com wrote:
 
  On 05/16/2010 12:11 PM, Marcus D. Hanwell wrote:
   On Sun, May 16, 2010 at 12:48 PM, Timothy M. Shead
  tsh...@k-3d.com mailto:tsh...@k-3d.com
   mailto:tsh...@k-3d.com mailto:tsh...@k-3d.com wrote:
  
   I'd like to do the following:
  
# Build external project A
ExternalProject_Add(A ...)
  
# Import target B, which is exported by A in AConfig.cmake
ExternalProject_Get_Property(A, BINARY_DIR)
set(A_DIR ${BINARY_DIR})
find_package(A)
  
# Link with B
add_library(C ...)
target_link_libraries(C B)
  
   Of course, this doesn't work because the external project
  hasn't been
   built yet at configure-time, so AConfig.cmake doesn't exist.
   Which
   leads me to the following:
  
   Hi,
  
   If I understand your question correctly, then adding DEPENDS A to
 your
   ExternalProject_Add(B...) call will ensure that A has been built
  when B
   is configured, thus satisfying your need to find A's exported
 targets.
   Using the dependencies between external projects it is possible to
   control the build order, so that A's config file will be present
  before
   B attempts a configure step.
 
  That wasn't quite what I was describing - B isn't another external
  project, it's a library that's built by external project A.
  Because A
  hasn't been built (isn't even downloaded yet) at configure time, I
 can't
  use find_package to benefit from A's internal understanding of where
  its' outputs are located.  Basically, I want the simplest possible
  add_library(... IMPORTED) call possible, one that doesn't end-up
  duplicating all of the platform-specific logic that CMake normally
 takes
  care of.  Since my last post, I've switched to the following, which
  works on Linux and seems like it could work on Windows:
 
   ADD_LIBRARY(B SHARED IMPORTED)
   SET_TARGET_PROPERTIES(B PROPERTIES
 IMPORTED_LOCATION
  ${BINARY_DIR}/path/to/libB${CMAKE_SHARED_LIBRARY_SUFFIX}
IMPORTED_IMPLIB ${BINARY_DIR}/path/to/libB.lib
   )
 
 
  Ah, I understand now. This is one of the major reasons to avoid mixing
  external projects and traditional targets in the same build. I would
  solve that by adding another external project in the build, that would
  depend on A, and so A would be there at configure time and no guessing
  would be necessary.
 
  Is there any particular reason why you cannot use that pattern in your
  case? Otherwise you can quickly end up writing a lot of code to predict
  where things will be, and that could be quite a fragile approach if the
  targets changed in a new release.

 It's not impossible, but I had hoped to avoid the extra level of
 indirection.  I'm really just feeling-out the pros-and-cons of various
 approaches.

 OK, may be others on the list may have other experiences they will share.
After having spent quite a bit of time working on packaging for a Linux
distro, and using CMake's external projects I see many parallels.

The external project allows us to establish inter-package dependencies, and
from there build order. Traditional targets assume that project is building
everything, or that it was already built and found. So two levels are
necessary, and external projects allow us to do cross platform packaging for
our particular projects.

I would certainly be interested in what others who have been using external
project have found, but it seems to me that mixing external projects and
traditional targets is unlikely to work well, at least with what is
available to us right now.

Thanks,

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake interview for FLOSS Weekly in about 1 hour

[Marcus D. Hanwell]

On Wed, Mar 3, 2010 at 5:15 PM, Andrew Maclean andrew.amacl...@gmail.comwrote:

 Unfortunate acronym!
 I hope it wasn't like pulling teeth!

 On Thu, Mar 4, 2010 at 7:39 AM, Bill Hoffman bill.hoff...@kitware.com
 wrote:
  At 4:30, I am going to be interviewed for FLOSS Weekly.
 
  The video is here:
 
  http://live.twit.tv/
 
  Should be going on some time around 4:30 EST.
 

A few of us at Kitware HQ watched it on the big screen.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CTEST_COMMAND ignores -j in ctest command script

[Marcus D. Hanwell]

On Sat, Feb 27, 2010 at 2:11 PM, Derek Bruening i...@alum.mit.edu wrote:

 I have a ctest command script that runs a series of builds and tests via
 ctest_start(), ctest_test(), etc.  I want to run the tests in parallel by
 default (I'm using cmake 2.8.0).  If I pass -j to the ctest command that
 invokes the script, the tests are run in parallel:

  ctest -j5 -S /path/to/script.cmake

 However if I pass the -j via CTEST_COMMAND:

  set(CTEST_COMMAND ${CTEST_EXECUTABLE_NAME} -j5)

 and do not pass it in when invoking the script, the tests are not run in
 parallel.  Why is that?  Is there some way to accomplish this?


I think you want to add the PARALLEL_LEVEL argument to the ctest_test
command,

ctest_test(BUILD ${CTEST_BINARY_DIRECTORY} PARALLEL_LEVEL 8)

This command would run up to eight tests in parallel.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake finds the wrong Python interpreter on Windows

[Marcus D. Hanwell]

On Friday 26 February 2010 10:15:06 Bill Hoffman wrote:
 Mathieu Malaterre wrote:
 the windows one prefer python
 
  over any of the named version ones...
  
  Or find both independently and compare their versions. OTOH, the problem
  was the library/executable mismatch, so it doesn't matter which is
  found as long as the library matches the executable.
  
  +1
  There is an old bug report for cmake for this. PythonLibs should be
  derived from a python -c... (see bug #2257)
 
 We should create a new module that is FindPython that finds both of them
 and makes sure they are consistent.  We have to be careful with python
 -c because it won't work with a cross compiler.   I am thinking that we
 should put python in the front of the list of names.
 
I have been doing some work on FindPythonLibs, and after talking with Brad 
King we concluded that having a FindPython module where components could be 
requested (as in other modules such as Qt or Boost) would be a better 
solution. I have not had much time to work on this, but if the logic were all 
in one module it would certainly be easier to ensure the logic to find the 
libraries and interpreter were consistent.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [ANNOUNCE] CMake has moved to Git!

[Marcus D. Hanwell]

On Monday 22 February 2010 13:46:18 Brad King wrote:
 Hi Folks,
 
 Kitware has moved to distributed version control for CMake in order to
 better engage our growing community of developers and users.  It will
 enhance our process for accepting patches and help give credit to all
 contributors.
 
That is great news - very pleased to hear the switch has been made! How long 
is the rebase only, linear history policy likely to remain? I think that this 
is a great move, and I look forward to other projects we work on making the 
move too.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8 FindPythonLibs.cmake broken for default python2.5 install

[Marcus D. Hanwell]

On Monday 23 November 2009 10:38:27 Marcus D. Hanwell wrote:
 On Monday 23 November 2009 10:03:35 Mark Moll wrote:
  Between cmake 2.6.4 and cmake 2.8 the following lines were removed from
  the FIND_LIBRARY(PYTHON_LIBRARY ...) command in FindPythonLibs.cmake:
 
  -PATH_SUFFIXES
  -  python${_CURRENT_VERSION}/config
 
  I don’t understand why this was done, because this is where python
   libraries are found with the default settings. How do I make cmake find
   the python library now?
 
 What Linux distribution is this on? I tested these changes on quite a few
 different distributions and the shared object in
 python${_CURRENT_VERSION}/config was a symlink to
  python${_CURRENT_VERSION}.so in the /usr/lib directory. Does your
  installation not have
 /usr/lib[64]/libpython2.5.so?
 
 Quite a few Linux distributions do not have the symlink in
 python${_CURRENT_VERSION}/config, whereas all the ones I came across had it
  in /usr/lib. So this would lead to link errors as only the static lib
  would be found, and that cannot be used on x86_64 for example.
 
 If you could provide more details then I will look into this further (I
 committed the change in response to a bug report, and numerous reports I
  had from users who had trouble linking to Python on 64 bit platforms).
 
For the benefit of the list, as it seems the CC was lost  in Mark's reply, we 
discussed the issue and the problem was in linking to the static Python 
library. I emailed Mark a patched version of the FindPythonLibs.cmake module 
that solved his issue.

I will check in my changes this week once I have done a few more tests, they 
will make it in for CMake 2.8.1. Anyone suffering from this issue can override 
the module locally too.

Marcus
-- 
Marcus D. Hanwell, Ph.D.
RD Engineer, Kitware Inc.
(518) 881-4937
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8 FindPythonLibs.cmake broken for default python2.5 install

[Marcus D. Hanwell]

On Monday 23 November 2009 10:03:35 Mark Moll wrote:
 Between cmake 2.6.4 and cmake 2.8 the following lines were removed from the
  FIND_LIBRARY(PYTHON_LIBRARY ...) command in FindPythonLibs.cmake:
 
 -PATH_SUFFIXES
 -  python${_CURRENT_VERSION}/config
 
 I don’t understand why this was done, because this is where python
  libraries are found with the default settings. How do I make cmake find
  the python library now?
 
What Linux distribution is this on? I tested these changes on quite a few 
different distributions and the shared object in 
python${_CURRENT_VERSION}/config was a symlink to python${_CURRENT_VERSION}.so 
in the /usr/lib directory. Does your installation not have 
/usr/lib[64]/libpython2.5.so?

Quite a few Linux distributions do not have the symlink in 
python${_CURRENT_VERSION}/config, whereas all the ones I came across had it in 
/usr/lib. So this would lead to link errors as only the static lib would be 
found, and that cannot be used on x86_64 for example.

If you could provide more details then I will look into this further (I 
committed the change in response to a bug report, and numerous reports I had 
from users who had trouble linking to Python on 64 bit platforms).

Marcus
-- 
Marcus D. Hanwell, Ph.D.
RD Engineer, Kitware Inc.
(518) 881-4937
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++

[Marcus D. Hanwell]

James Bigler wrote:
 I've just been bitten hard by this issue (many hours of frustration
 while attempting to run a demo application that should have Just
 Worked (TM) ).

 According to this page:

 http://support.microsoft.com/kb/326922


 You should install these versions of the CRT on target computers by
 running the Vcredist_x86.exe application that is included with Visual
 Studio.  This is for the VS 2005 and 2008 versions of the C run-time
 libraries except for Windows 2000 in which case you need to install
 them in the system32 directory.

I hit this with Avogadro development, and at the time from my searching
it appeared that this is due to the version numbers being incorrect in
the manifest that MS distributes with the DLLs in question. By editing
the manifest for the DLLs they would load as expected on XP and Vista
hosts. This seems to work, and so I edited the manifest in the
redistributable folder and we have been using that ever since.


 I was dropping Msvcr80.dll and friends as per
 InstallRequiredSystemLibraries next to the binaries with ineffectual
 results.  It was really strange, because programs like Dependency
 Walker seemed to find them just fine.  It was only after running
 vcredist_x86.exe that I was able to run my programs properly.

I am sure there are people on this list who know better than I, but I
think this is because the version number in the manifest MS supplies
with the redistributable DLLs is incorrect. Changing this version fixed
it for me, but did feel a little hackish. I would be interested in what
the best practice is. Currently we can run our application from a flash
drive without installing on a clean system, which is a feature I would
also like to retain.


 I though I should tell everyone that this method of distributing
 Msvcr80.dll and Msvcr90.dll next to your binaries is not supposed to
 work.  You must install them into the Windows Side by Side location
 (WinSxS) using the CRT.msm merge module or the vcredist_x86.exe that
 comes with Visual Studio.

 Now to try and get CPack to tell NSIS run the vcredist_x86.exe program
 during installation.

 Note, that many people might get lucky and have already installed a
 product that installed the right vcredist_x86.exe before installing
 your software.

I would be interested in how others have solved this issue. I like our
current solution and I think several Kitware projects use a similar
mechanism.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++

[Marcus D. Hanwell]

James Bigler wrote:
 On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman
 bill.hoff...@kitware.com mailto:bill.hoff...@kitware.com wrote:

 James Bigler wrote:


 Well, I was using VS 2005 64 bit with SP 1.  I wonder if there
 is a similar bug or if there is something else going wrong
 such as what Marcus Hanwall described.


 I am not sure what your issue is, but I know I have done this many
 times...

 -Bill


 I checked the version numbers of the DLLs, and even checked the md5sum
 and everything was the same between the dlls in the WinSxS folder and
 the ones I'm distributing.  It failed on two clean systems without the
 vcredist install.  I guess I'll run vcredist as Microsoft suggests and
 see if I can trouble shoot later.

 It is a rather perplexing problem.

The link Bill supplied has all of the relevant information. In the
Community Discussion section the second comment provides three
possible workarounds. We are using the third of those when distributing
Avogadro packages for Windows. The version mismatch in the manifests of
the compiled executables and the manifest with the redistributable DLLs
is what causes the issue.

It seems that MS has no intention of fixing this issue. We have a clean
VM where we test new installers, as occasionally this change was lost
and the DLLs failed to load.

Marcus
___
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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Win32: Find location of VS redistributable runtime files ?

[Marcus D. Hanwell]

James Bigler wrote:
 On Thu, Apr 2, 2009 at 7:49 AM, Stephen Collyer
 scoll...@netspinner.co.uk mailto:scoll...@netspinner.co.uk wrote:


 2009/4/2 Philip Lowman phi...@yhbt.com mailto:phi...@yhbt.com

 On Thu, Apr 2, 2009 at 7:00 AM, Stephen Collyer
 scoll...@netspinner.co.uk mailto:scoll...@netspinner.co.uk
 wrote:

 In the course of installation, I want to copy the
 redistributable C++ runtime libs
 directory from VS into my deliverable package. However,
 this should work with
 both VS8 and VS9. Could someone tell me how I can detect
 the build environment
 and locate the appropriate directory to do this ? For
 example, if building with
 VS9 I want to locate the directory:

 C:\Program Files\Microsoft Visual Studio
 9.0\VC\redist\x86\Microsoft.VC90.CRT

 I'm guessing that there's a CMAKE_* variable that allow me
 to do this,
 but I'm not sure which.


 You can include InstallRequiredSystemFiles for this. See:
 
 http://www.cmake.org/cmake/help/cmake2.6docs.html#module:InstallRequiredSystemLibraries

 VS9 support was added to this script and I believe it was
 first added in CMake 2.6.0

 -- 
 Philip Lowman



 Thanks for that - I'd completely forgotten about the existence of
 that module.

 I've tried it and I have one question though - it seems to dump
 the manifest and
 DLLs into the bin directory - it was my understanding that these
 had to go into
 a subdirectory of bin called Microsoft.VC80.CRT. Am I misinformed ?


  
 I just recently shipped something with the redistributables, and it
 worked just fine putting them next to the dll (i.e. bin directory).

I worked on the packaging for Avogadro on Windows using VS. It works
very well with the files in the bin directory and as I understand
Windows, it looks in the same directory as the binary and then the path
is searched.

One issue we had was with plugins that were not in the binary directory.
I solved that by disabling the generation of manifests for modules in
our build scripts. I still need to clean up our Windows build as the way
we copy external libraries such as Qt is pretty hackish right now, but
that works too using a similar approach.
___
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://www.cmake.org/mailman/listinfo/cmake