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

[Marcus D. Hanwell]

On Wed, Aug 2, 2017 at 4:18 PM, J Decker  wrote:
>
> On Wed, Aug 2, 2017 at 8:55 AM, Marcus D. Hanwell 
>  wrote:
>>
>> 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/
>>
> 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

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

Re: [CMake] ctest & git submodules

[Marcus D. Hanwell]

On Tue, Feb 26, 2013 at 4:50 PM, Brad King  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

Re: [CMake] ctest & git submodules

[Marcus D. Hanwell]

On Tue, Feb 26, 2013 at 2:36 PM, Clinton Stimpson  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] How to specify LD_LIBRARY_PATH for a test?

[Marcus D. Hanwell]

On Tue, Feb 26, 2013 at 2:15 PM, Orion Poplawski  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] Passing CMAKE_TOOLCHAIN_FILE on command line causes CMake warning

[Marcus D. Hanwell]

On Wed, Feb 6, 2013 at 5:59 AM, Pat Marion  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

Re: [CMake] file( DOWNLOAD ) problem

[Marcus D. Hanwell]

On Fri, Sep 28, 2012 at 4:42 PM, Robert Dailey  wrote:
> On Fri, Sep 28, 2012 at 2:58 PM, David Cole  wrote:
>> On Fri, Sep 28, 2012 at 3:30 PM, Robert Dailey 
>> 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:
>>>
>>> ///include.7z
>>> ///.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 
>>> wrote:
>>> > On Wed, Sep 26, 2012 at 7:32 PM, Robert Dailey
>>> >  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 H

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

[Marcus D. Hanwell]

On Tue, Sep 25, 2012 at 2:56 PM, Peter Kümmel  wrote:
> On 25.09.2012 17:29, Marcus D. Hanwell wrote:
>>
>> On Thu, Sep 20, 2012 at 7:26 AM, Peter Kümmel  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] CMake/Ninja support in Qt Creator

[Marcus D. Hanwell]

On Thu, Sep 20, 2012 at 7:26 AM, Peter Kümmel  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] ExternalProject_Add examples

[Marcus D. Hanwell]

On Sat, Mar 17, 2012 at 5:03 PM, Bill Lorensen  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  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] Upcoming "What's New in CMake 2.8.7" webinar

[Marcus D. Hanwell]

On Wed, Dec 21, 2011 at 3:50 PM, Alexander Neundorf
 wrote:
> On Wednesday 21 December 2011, David Cole wrote:
>> The CMake team is hard at work on the 2.8.7 release - we
>> announced 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
>> GoToWebinar
>> .
>> 
>> 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] debug/optimized include directories

[Marcus D. Hanwell]

On Fri, Nov 4, 2011 at 11:16 AM, Robert Dailey  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  wrote:
>>
>> On Wed, Nov 2, 2011 at 8:30 PM, Stephen Kelly  wrote:
>> > David Cole wrote:
>> >
>> >> On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey
>> >>  wrote:
>> >>> On Tue, Nov 1, 2011 at 3:32 PM, David Cole
>> >>>  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  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  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

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

[Marcus D. Hanwell]

2011/6/7 Michael Wild :
> On 06/07/2011 06:23 PM, Bjørn Forsman wrote:
>> 2011/6/7 Michael Wild :
>>> 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] FindQt4.cmake to automatically include QT_USE_FILE?

[Marcus D. Hanwell]

On Tue, Jun 7, 2011 at 9:46 AM, Michael Wild  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 
>
> 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] GenerateExportHeader macrr for CMake?

[Marcus D. Hanwell]

On Sun, Jun 5, 2011 at 3:47 PM, Alexander Neundorf
 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] GenerateExportHeader macrr for CMake?

[Marcus D. Hanwell]

On Sat, Jun 4, 2011 at 3:17 PM, Stephen Kelly  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] Dynamic linking doesn't work after install

[Marcus D. Hanwell]

On Fri, Apr 22, 2011 at 9:57 AM, David Doria  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] Dynamic linking doesn't work after install

[Marcus D. Hanwell]

On Fri, Apr 22, 2011 at 9:48 AM, David Doria  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] SuperBuild whoes

[Marcus D. Hanwell]

On Thu, Apr 21, 2011 at 9:44 AM, Michael Wild  wrote:
> On 04/21/2011 02:45 PM, David Cole wrote:
>> On Thu, Apr 21, 2011 at 4:30 AM, Michael Wild > > wrote:
>>
>>     On 04/21/2011 06:48 AM, Michael Wild wrote:
>>     > Hi all
>>     >
>>     > I'm trying to set up a SuperBuild here. Everything works nicely the
>>     > first time round I build the project. The only real problem I have is
>>     > that if I change the sources of one of the sub-projects, the
>>     SuperBuild
>>     > still thinks everything is up to date. Of course, this is fully
>>     > explainable by the fact that the SuperBuild knows nothing about the
>>     > internal dependencies of the sub-project, and since the stamp
>>     files are
>>     > all there and unchanged, it thinks everything is fine. How do I get
>>     > around this? Anybody got an idea?
>>     >
>>     > Thanks
>>     >
>>     > Michael
>>
>>
>>     Found it myself. For completeness and documentation purposes: Add a
>>     custom target which removes the *-complete (see ExternalProject.cmake on
>>     where it is located, it is a bit tricky) and -*configure stamps. Of
>>     course, it should always run and depend on the external project target.
>>
>>     The thing I'm struggling with now is installing the various sub-projects
>>     into the system. Seems like it is impossible to install an imported
>>     target [1], but guessing and hard coding the paths is also not very
>>     attractive, but probably the only way to go at the moment. If anybody
>>     has a better idea, please speak up...
>>
>> If your intent is *always* to run the configure and later steps of an
>> ExternalProject build, you can consider adding an extra custom step that
>> configure depends on, which does nothing, but ALWAYS runs... No need to
>> do any fancy scrounging of stamp files for this to work.
>>
>>
>> Something like:
>>
>> ExternalProject_Add(Proj1
>>   ...
>> )
>>
>> ExternalProject_Add_Step(Proj1 forceconfigure
>>   COMMAND ${CMAKE_COMMAND} -E echo "This custom external project step
>> forces the configure and later steps to run whenever a top level build
>> is done..."
>>   DEPENDEES download
>>   DEPENDERS configure
>>   ALWAYS 1
>>   )
>
> Mhm, I thought I already tried this, but will check again. Thanks for
> the input.

We were messing with stamps in Titan too...just tried this approach
and it worked well. I will update Titan and some other projects, as
this is a much cleaner solution.
>
> I also solved my installation problem. By having all sub-projects
> install into a common prefix, and thanks to the wonders of RPATH and
> install_name which can handle relative paths and thanks to the fact that
> install(EXPORT) generated files are also relocatable, I can simply do a
> install(DIRECTORY) in the super project ;-) The only thing that required
> some thinking was writing a relocatable XXXConfig.cmake file. I think I
> will update my tutorial on the WIKI to use a un-configured, relocatable
> XXXConfig.cmake file.
>
I have been using a common prefix in a new superbuild project I have
been working on, and I think this is a very clean approach. Coupled
with the relocatable Config files it allows you to keep things very
simple.

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  wrote:
> On Tue, Mar 1, 2011 at 6:45 AM, Campbell Barton  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] Use Eigen2 in CMake based project

[Marcus D. Hanwell]

On Mon, Jan 24, 2011 at 6:15 PM, Stefan Dänzer  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] ExternalProject_Add, race conditions, MSVC_IDE

[Marcus D. Hanwell]

On Mon, Jan 24, 2011 at 9:50 AM, David Cole  wrote:
> On Sat, Jan 22, 2011 at 8:15 AM, Pau Garcia i Quiles 
> 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] How to have a target depend on an External Project

[Marcus D. Hanwell]

On Wed, Jan 12, 2011 at 12:53 PM, kent williams
 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

Re: [CMake] ctest and git submodules

[Marcus D. Hanwell]

On Wed, Jan 12, 2011 at 12:16 PM, Gerhard Gappmeier
 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] [Titan-developers] Forcing 'out-of-source' build

[Marcus D. Hanwell]

On Fri, Nov 26, 2010 at 3:24 PM, Wylie, Brian  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

Re: [CMake] How to install openbabel python bindings by using the new cmake installer (problem selecting a particular python version).

[Marcus D. Hanwell]

On Nov 13, 2010, at 8:57 AM, Michael Hertling wrote:

> On 11/12/2010 02:13 PM, Hector Martinez-Seara wrote:
>> Dear all,
>> I'm trying to install openbabel in linux which in its last version
>> (2.3.0) uses cmake installer. I haven't been able to compile it with
>> biddings with python 3.1 when using the -DPYTHON_BINDINGS=ON option. I
>> have python 2.7 and 3.1 installed in my system and the python command
>> points to python 3.1. Still cmake only select python 2.7 despite it is
>> not set as preferred in my system in any way. I have made a small
>> search and I have seen that there is a lot of troubles selecting
>> python 3 with cmake. Most of the information was very technical and
>> honestly I'm not sure if there was any solution at the end.
> 
> AFAIK, the FindPython{Interp,Libs}.cmake modules are currently not
> capable to find Python 3, so you should focus on a manual approach
> at the moment, see below. With the scheduling of issue 8396 for the
> 2.8.4 roadmap, there's a perpective for the availability of version-
> or pattern-aware find functions, so maybe, it is possible to improve
> the find modules w.r.t. version selection in the near or medium term.

This is certainly something I would like to address before the 2.8.4 release, 
but as you said there is no Python 3 awareness right now in the find modules. 
Do the Open Babel Python modules work in Python 3? I work on that project, and 
was not aware that Python 3 support was there, but do not work much on the 
bindings.
> 
>> My question is rather easy:
>> a) Is there any way to force a specific python version (3.1) from the
>> cmake command line?
> 
> You might try to set the PYTHON_EXECUTABLE, PYTHON_INCLUDE_DIR and
> PYTHON_LIBRARY variables to appropriate values for your Python 3.1
> installation on the command line, i.e. by use of the -D option or
> -C along with a prepared script. AFAICS, defining these variables
> makes the FindPython{Interp,Libs}.cmake modules not look for the
> interpreter, the include directory and the library by themselves,
> so you possibly get by without any further modifications, but I
> have not yet tested this with Open Babel.
> 
>> or b) Is there variable which I could export, e.g. CC=gcc4.5, to force
>> python to select the python version I want?
> 
> None I'm aware of, but - as stated above - there're some undertakings
> in the near future that might result in a comprehensive and flexible
> FindPython.cmake module which receives the requested version through
> FIND_PACKAGE()'s version parameter, including version 3.
> 
That would certainly be the ideal solution.

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.3-rc4 ready for testing!

[Marcus D. Hanwell]

On Sun, Oct 31, 2010 at 7:30 PM, Campbell Barton  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  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

Re: [CMake] cmake for cygwin

[Marcus D. Hanwell]

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
___
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  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

Re: [CMake] External projects and imported targets

[Marcus D. Hanwell]

On Sun, May 16, 2010 at 2:47 PM, Timothy M. Shead  wrote:

> On 05/16/2010 12:36 PM, Marcus D. Hanwell wrote:
> > On Sun, May 16, 2010 at 2:26 PM, Timothy M. Shead  > <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
> > 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] External projects and imported targets

[Marcus D. Hanwell]

On Sun, May 16, 2010 at 2:26 PM, Timothy M. Shead  wrote:

> On 05/16/2010 12:11 PM, Marcus D. Hanwell wrote:
> > On Sun, May 16, 2010 at 12:48 PM, Timothy M. Shead  > <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 12:48 PM, Timothy M. Shead  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] CMake interview for FLOSS Weekly in about 1 hour

[Marcus D. Hanwell]

On Wed, Mar 3, 2010 at 5:15 PM, Andrew Maclean wrote:

> Unfortunate acronym!
> I hope it wasn't like pulling teeth!
>
> On Thu, Mar 4, 2010 at 7:39 AM, Bill Hoffman 
> 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  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.
R&D 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.
R&D 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:
> On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman
> 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] 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] 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
> mailto:scoll...@netspinner.co.uk>> wrote:
>
>
> 2009/4/2 Philip Lowman mailto:phi...@yhbt.com>>
>
> On Thu, Apr 2, 2009 at 7:00 AM, Stephen Collyer
> 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