Re: [CMake] CMake + Ninja

[Stephen Kelly]

Hi,

I didn't time it, but I was able to use ninja with kdelibs and grantlee (my 
smaller Qt project).

Clifford Yapp wrote:
> In case anybody else wants to give ninja a spin, here's what I did to
> test it (using bash as a shell):
> 
> git clone git://github.com/martine/ninja.git

> git clone -b ninja-generator-pr git://github.com/pcc/CMake.git

If you already have a CMake clone, then instead of the above do this:

git remote add ninja git://github.com/pcc/CMake.git
git checkout ninja-generator-pr

I'm trying to decide whether I like the less wordy output compared to make, 
and I think I prefer ninjas output.

Thanks,

Steve.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake + Ninja

[Peter Collingbourne]

On Fri, Jan 06, 2012 at 02:08:24PM -0500, Clifford Yapp wrote:
> Peter,
> 
> FYI, I'm seeing a problem with the BRL-CAD build on the Mac with CMake
> + ninja using the latest git versions - when I try to run tclsh, I get
> a problem with it trying to link
> TARGET_INSTALLNAME_DIRlibtcl.8.5.dylib instead of the local
> libtcl.8.5.dylib in the build directory.  This doesn't seem to happen
> on Linux.

Hi Clifford,

The attached patch should add support for TARGET_INSTALLNAME_DIR.
Please let me know if it works -- it's untested, as I don't have easy
access to a Mac.

> Also, a question - is it in the plans longer term to add build.ninja
> files in subdirectories, so I can cd into a subdirectory and build
> just what's required for that directory (i.e. like make)?  Or is ninja
> a "toplevel-only" setup?

Ninja doesn't work that way.  You can of course list specific targets
to build on the command line.

That said, a way of saying "build every target in this subdirectory"
(for example, by specifying that subdirectory as a target on the
command line) would be a nice feature to have.

Thanks,
-- 
Peter
>From 185519576e8d59318e856a757695920372fea0a0 Mon Sep 17 00:00:00 2001
From: Peter Collingbourne 
Date: Mon, 9 Jan 2012 22:32:18 +
Subject: [PATCH] Add support for TARGET_INSTALLNAME_DIR (untested)

---
 Source/cmNinjaNormalTargetGenerator.cxx |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/Source/cmNinjaNormalTargetGenerator.cxx b/Source/cmNinjaNormalTargetGenerator.cxx
index 8a223b4..98cbe04 100644
--- a/Source/cmNinjaNormalTargetGenerator.cxx
+++ b/Source/cmNinjaNormalTargetGenerator.cxx
@@ -134,6 +134,7 @@ cmNinjaNormalTargetGenerator
 vars.ObjectDir = objdir.c_str();
 vars.Target = "$out";
 vars.TargetSOName = "$SONAME";
+vars.TargetInstallNameDir = "$INSTALLNAME_DIR";
 
 // Setup the target version.
 std::string targetVersionMajor;
@@ -322,6 +323,18 @@ void cmNinjaNormalTargetGenerator::WriteLinkStatement()
   this->GetConfigName());
   vars["SONAME"] = this->TargetNameSO;
 
+  if (this->GetTarget()->GetType() == cmTarget::SHARED_LIBRARY) {
+std::string install_name_dir =
+  this->GetTarget()->GetInstallNameDirForBuildTree(this->GetConfigName());
+
+if (!install_name_dir.empty()) {
+  vars["INSTALLNAME_DIR"] =
+this->GetLocalGenerator()->Convert(install_name_dir.c_str(),
+cmLocalGenerator::NONE,
+cmLocalGenerator::SHELL, false);
+}
+  }
+
   std::vector *cmdLists[3] = {
 &this->GetTarget()->GetPreBuildCommands(),
 &this->GetTarget()->GetPreLinkCommands(),
-- 
1.7.5.3

--

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] MSBuild and automatic project file regenation

[Michael Hertling]

On 01/09/2012 07:56 PM, Óscar Fuentes wrote:
> Michael Hertling 
> writes:
> 
>> On 01/09/2012 02:34 PM, David Cole wrote:
>>> No trick, but to avoid this, perhaps we should change the "--build"
>>> handler to run the cmake configure & generate step before calling out
>>> to MSBuild. You can easily do this yourself from the command line by
>>> adopting the pattern:
>>>
>>>   cmake . && cmake --build . --config Release
> 
> Fortunately my cmake scripts are simple enough so the extra invocation
> does not add much to the build.
> 
> Thanks David.
> 
>>> This is a good idea for a feature request. Not sure if we should just
>>> always do that by default and provide a way to turn off with a
>>> "--no-regenerate", or vice-versa with a "--please-generate-first" ...
>>> :-)
> 
> The effect of --no-regenerate would be the same as the current buggy
> behavior (MSBuild.exe uses outdated project files). IMHO the
> --please-generate-first is the right thing.
> 
>> Just out of curiosity: In [1], item (1), I reported on the fact that
>> one can modify a project's CMakeLists.txt, and "cmake --build" will
>> reconfigure/regenerate, but not rebuild. Is this the same issue the
>> OP asks about?
> 
> No.

But aren't the issues related at least? If I understand
correctly, "cmake --build" invokes MSBuild which

- loads the solution file and the project files,
- reinvokes CMake via the ZERO_CHECK project/target
  to regenerate them if CMakeLists.txt has been modified,
- does *not* use the regenerated ones for building, so the
  affected projects/targets are left inherently out-of-date.

Moreover, even an additional subsequent "cmake --build" command doesn't
rebuild; in fact, it does nothing, as though there is no dependency of
a project/target on its own project file. AFAICS for now, it's solely
David's hint, i.e. "cmake . && cmake --build .", that results in the
project being actually rebuilt after CMakeLists.txt has changed,
unless one uses the "--clean-first" option.

>> If so, I would strongly support a feature request in
>> this respect since, IMO, it's actually quite confusing that CMake's
>> "--build" command does anything but rebuilding.
> 
> I agree.

Do you file a feature request / bug report? Personally, I'd like to be
sure that after a "cmake --build" command, everything is up-to-date as
it is with Makefiles, provided it can be realized with MSBuild at all.

>> [1] http://www.mail-archive.com/cmake@cmake.org/msg39596.html
> 
> This returns 404.

Try .

Regards,

Michael
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] User configuration files for Visual Studio

[Robert Dailey]

there are .user files generated by newer versions of Visual Studio (since
2005 I believe) that contain per-machine or per-workspace information. For
all intents and purposes these are temporary files that are not checked
into version control.

The normal file naming convention for these are:

project.vcproj.DOMAIN.USER.user

Where DOMAIN is the machine/domain name, and USER is the local account name.

I found out a couple of years ago that if you rename it to this:

project.vcproj.user

Visual Studio will treat this as "defaults" for the machine-specific
version created using the naming convention I first outlined.

The user files are useful for setting debug working directory and command
arguments. There are some other things you can set but I have never found a
use for them. Since I like to set these two parameters, what I've done is
keep my template user file in version control, and use CMake's
configure_file() to fill in the command arguments and working directory
fields for me. This approach is a good workaround but I'd really like to
see CMake generate these for me. Right now I have to keep 1 user file for
each version of visual studio that can be used, and configure them
differently based on VS IDE selection.

Would it be suitable for CMake to incorporate this functionality? If CMake
provided built-in support for this, we could create target properties that
would set these fields on the target (it would set them on the generated
user file instead of the vcproj file like normal target properties would
do):

set_target_properties( project PROPERTIES
   DEBUG_COMMAND_ARGUMENTS "-debug -reg"
   DEBUG_WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
)

I'd be happy to help implement this should David, Bill, and others find it
to be a good idea.

PS: I think I can do it without boost this time ;)

-
Robert Dailey
--

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] Are u using mingw32 gcc / with Cmake?

[Alan W. Irwin]

On 2012-01-07 18:16+0100 Bram Kouwenberg wrote:


I'm looking for someone with a mingw32 install next to Cmake. I have a problem 
compiling probably because of mingw32 --look below if
you want.

shout out if you have mingw32


Hi Bram:


From time to time on a MinGW/MSYS/Wine platform, I have sucessfully

built CMake and other software projects.  The CMake build was
configured using the binary version of CMake for Windows that you can
download from cmake.org, and the rest of the builds were configured
with the Windows version of CMake that I built on my Wine platform.

For a while CMake was not compatible with the latest version of MinGW
(on my Wine platform and somebody else later reported the same problem
on a Microsoft version of the Windows platform).  The result was
uniformly broken builds for MinGW/CMake.  That CMake issue was
corrected fairly recently. Therefore, I suggest you try that latest
version of CMake (2.8.7) before you try anything else with MinGW.  I
also suggest you use the latest version of MinGW that can be installed
with the latest version of the MinGW/MSYS automatic installer.

To test whether your MinGW/CMake installation is working properly, I
suggest you first try to build CMake itself.  Once that works with
MinGW or MinGW/MSYS (whichever you prefer), then I would move on to
attempt other builds.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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] Re: linking mixed language executable; cmake choosing wrong compiler

[Mitchell, John A]

Thanks Brad.  Much appreciated.  

I can see that cmake has some relevant properties but I wasn't quite sure how 
to set them.  

I'll give this a shot.


From: Brad King [brad.k...@kitware.com]
Sent: Monday, January 09, 2012 2:28 PM
To: Mitchell, John A
Cc: cmake@cmake.org
Subject: [EXTERNAL] Re: [CMake] linking mixed language executable; cmake 
choosing wrong compiler

On 1/9/2012 3:44 PM, Mitchell, John A wrote:
> add_executable(demo_cf_pointer demo_cf_pointer.F90)
> target_link_libraries(demo_cf_pointer I_Fortran -lstdc++)

CMake prefers to use the C++ compiler to link when any C++ is involved.
Some toolchains use a "prelinker" step that actually runs the C++ compiler
to handle template instantiations.  IIRC some vendors document that the
C++ compiler should be used if there is any C++ in the link.  This may
or may not still be true on modern tools, but that is the historical
reason for this behavior.

You can tell CMake explicitly to use the Fortran compiler to link:

   set_property(TARGET demo_cf_pointer PROPERTY LINKER_LANGUAGE Fortran)

CMake should still take care of the implicit libraries so you do not need
the explicit "-lstdc++" (though I have not tested this with MPI compiler
wrappers myself).

-Brad


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] linking mixed language executable; cmake choosing wrong compiler

[Brad King]

On 1/9/2012 3:44 PM, Mitchell, John A wrote:

add_executable(demo_cf_pointer demo_cf_pointer.F90)
target_link_libraries(demo_cf_pointer I_Fortran -lstdc++)


CMake prefers to use the C++ compiler to link when any C++ is involved.
Some toolchains use a "prelinker" step that actually runs the C++ compiler
to handle template instantiations.  IIRC some vendors document that the
C++ compiler should be used if there is any C++ in the link.  This may
or may not still be true on modern tools, but that is the historical
reason for this behavior.

You can tell CMake explicitly to use the Fortran compiler to link:

  set_property(TARGET demo_cf_pointer PROPERTY LINKER_LANGUAGE Fortran)

CMake should still take care of the implicit libraries so you do not need
the explicit "-lstdc++" (though I have not tested this with MPI compiler
wrappers myself).

-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] linking mixed language executable; cmake choosing wrong compiler

[Mitchell, John A]

Hi,

I am trying to link a fortran/c++ executable.  main() is in the fortran file.  
cmake is choosing to "Link CXX executable" rather than fortran executable?

Based upon my current CMakeLists.txt file,  cmake is choosing the wrong linker.

I can in fact cut and paste the cmake link line and replace 'mpicxx' with the 
correct compiler/linker ('mpif77') and it works just fine.

Here is the relevant CMakeLists.txt piece; main is in the file 
demo_cf_pointer.F90; I_Fortran is a c++ library;  I am using the intel 
compilers.

# CMakeLists.txt file
add_executable(demo_cf_pointer demo_cf_pointer.F90)
target_link_libraries(demo_cf_pointer I_Fortran -lstdc++)



Here is the output from the linker;  It is using my mpicxx compiler; Also note 
that the link line contains demo_cf_pointer.F90.o which indicates to me that it 
successfully found the mpif77 compiler that I am using.  I know it is because I 
can re-use this entire command with mpicxx replace with mpif77 to produce a 
valid executable.


CMAKE OUTPUT
Linking CXX executable demo_cf_pointer
cd /ascldap/users/jamitch/pditi_projects/pditi.build/i_fortran/demo && 
/projects/sierra/linux/install/cmake/2.8.1/bin/cmake -E cmake_link_script 
CMakeFiles/demo_cf_pointer.dir/link.txt --verbose=1
/ascldap/users/jamitch/pditi_projects/TPL/mpich2-1.4.1p1_installed/bin/mpicxx   
-cxx=icpc -mkl -O0 -g -Wall   
CMakeFiles/demo_cf_pointer.dir/demo_cf_pointer.F90.o  -o demo_cf_pointer 
-rdynamic 
-L/ascldap/users/jamitch/pditi_projects/TPL/trilinos_dev.installed/lib 
-L/ascldap/users/jamitch/pditi_projects/TPL/vtk-5.8-installed/lib/vtk-5.8 
-L/ascldap/users/jamitch/pditi_projects/TPL/boost_1_48_0_installed/lib 
../libI_Fortran.a -lstdc++ -lifport -lifcore -lintlc 
-Wl,-rpath,/ascldap/users/jamitch/pditi_projects/TPL/trilinos_dev.installed/lib:/ascldap/users/jamitch/pditi_projects/TPL/vtk-5.8-installed/lib/vtk-5.8:/ascldap/users/jamitch/pditi_projects/TPL/boost_1_48_0_installed/lib
/usr/local/intel/parallel_studio_XE/composerxe-2011.4.191/compiler/lib/intel64/libimf.so:
 warning: warning: feupdateenv is not implemented and will always fail
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function 
`_start':
(.text+0x20): undefined reference to `main'
make[2]: *** [i_fortran/demo/demo_cf_pointer] Error 1


Thanks,
John


--

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 with Official Nokia install

[Michael Jackson]

Some more info. When running cmake I get the following output when looking for 
Qt4:
cmake 2.8.7
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - not found.
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found.
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found.
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found.
-- Found Qt4: /usr/bin/qmake (found version "4.7.4")

On my own machine (that works) I get this:
cmake 2.8.6
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - not found.
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found.
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found.
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - found
-- Looking for QT_MAC_USE_COCOA
-- Looking for QT_MAC_USE_COCOA - found
-- Found Qt4: /usr/bin/qmake (found version "4.7.4")

So something is funny enough with his machine that it can not find part of Qt? 
I guess I will have to debug down through the FindQt4.cmake module to back 
track what is going wrong.

___
Mike JacksonPrincipal Software Engineer
BlueQuartz SoftwareDayton, Ohio
mike.jack...@bluequartz.net  www.bluequartz.net

On Jan 9, 2012, at 2:10 PM, Clinton Stimpson wrote:

> On Monday, January 09, 2012 11:26:15 am Michael Jackson wrote:
>> I am having an issue with my project compiling against the Official Nokia
>> Qt4 downloaded from Nokia. The issue (I think) is that for some reason
>> when FindQt4 is running it determines that QT_USE_FRAMEWORKS is false and
>> so I don't get all of the proper include directories. Namely the
>> -F/Path/To/Frameworks on the compile line which makes code like
>> 
>> #include  fail.
>> 
>>  Is anyone else having issues compiling their projects against the
>> official Nokia Qt downloads? I usually build Qt myself but a colleague of
>> mine is using the prebuilt binaries and ran into this problem.
>> 
>> Thanks for any sanity check. Just trying to figure out where the possibly
>> bug lies. I am going to assume it is in my code somewhere since I don't
>> remember any one else complaining about the same thing.
>> 
> 
> It works for me.  But perhaps you're hitting a bug that was fixed in CMake 
> 2.8.6.
> 
> -- 
> Clinton Stimpson
> Elemental Technologies, Inc
> Computational Simulation Software, LLC
> www.csimsoft.com

--

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] MSBuild and automatic project file regenation

[John Drescher]

On Mon, Jan 9, 2012 at 1:56 PM, Óscar Fuentes  wrote:
> Michael Hertling 
> writes:
>
>> On 01/09/2012 02:34 PM, David Cole wrote:
>>> No trick, but to avoid this, perhaps we should change the "--build"
>>> handler to run the cmake configure & generate step before calling out
>>> to MSBuild. You can easily do this yourself from the command line by
>>> adopting the pattern:
>>>
>>>   cmake . && cmake --build . --config Release
>
> Fortunately my cmake scripts are simple enough so the extra invocation
> does not add much to the build.
>
> Thanks David.
>
>>> This is a good idea for a feature request. Not sure if we should just
>>> always do that by default and provide a way to turn off with a
>>> "--no-regenerate", or vice-versa with a "--please-generate-first" ...
>>> :-)
>
> The effect of --no-regenerate would be the same as the current buggy
> behavior (MSBuild.exe uses outdated project files). IMHO the
> --please-generate-first is the right thing.
>

One problem I have with doing this automatically in the --build
command is I run in parallel builds for each configuration (using a
program called RunJobs from codeproject.com):

cmake --build X:/64Bit/VC.100/Qt/StudyManager --config RelWithDebInfo
cmake --build X:/64Bit/VC.100/Qt/StudyManager --config Release
cmake --build X:/64Bit/VC.100/Qt/StudyManager --config Debug

for this I do the
cmake X:/64Bit/VC.100/Qt/StudyManager

step first then run the parallel jobs. I worry if --build forced a
configure that parallel building like this could break.

John
--

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 with Official Nokia install

[Michael Jackson]

We tried with CMake 2.8.7 and had the same results. I installed on my own 
machine and was able to compile successfully so it must be something add with 
their setup. I guess. Thanks for the sanity check.

--
Mike Jackson 

On Jan 9, 2012, at 2:10 PM, Clinton Stimpson wrote:

> On Monday, January 09, 2012 11:26:15 am Michael Jackson wrote:
>> I am having an issue with my project compiling against the Official Nokia
>> Qt4 downloaded from Nokia. The issue (I think) is that for some reason
>> when FindQt4 is running it determines that QT_USE_FRAMEWORKS is false and
>> so I don't get all of the proper include directories. Namely the
>> -F/Path/To/Frameworks on the compile line which makes code like
>> 
>> #include  fail.
>> 
>>  Is anyone else having issues compiling their projects against the
>> official Nokia Qt downloads? I usually build Qt myself but a colleague of
>> mine is using the prebuilt binaries and ran into this problem.
>> 
>> Thanks for any sanity check. Just trying to figure out where the possibly
>> bug lies. I am going to assume it is in my code somewhere since I don't
>> remember any one else complaining about the same thing.
>> 
> 
> It works for me.  But perhaps you're hitting a bug that was fixed in CMake 
> 2.8.6.
> 
> -- 
> Clinton Stimpson
> Elemental Technologies, Inc
> Computational Simulation Software, LLC
> www.csimsoft.com

--

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 with Official Nokia install

[Clinton Stimpson]

On Monday, January 09, 2012 11:26:15 am Michael Jackson wrote:
> I am having an issue with my project compiling against the Official Nokia
> Qt4 downloaded from Nokia. The issue (I think) is that for some reason
> when FindQt4 is running it determines that QT_USE_FRAMEWORKS is false and
> so I don't get all of the proper include directories. Namely the
> -F/Path/To/Frameworks on the compile line which makes code like
> 
> #include  fail.
> 
>   Is anyone else having issues compiling their projects against the
> official Nokia Qt downloads? I usually build Qt myself but a colleague of
> mine is using the prebuilt binaries and ran into this problem.
> 
> Thanks for any sanity check. Just trying to figure out where the possibly
> bug lies. I am going to assume it is in my code somewhere since I don't
> remember any one else complaining about the same thing.
> 

It works for me.  But perhaps you're hitting a bug that was fixed in CMake 
2.8.6.

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--

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] MSBuild and automatic project file regenation

[Óscar Fuentes]

Michael Hertling 
writes:

> On 01/09/2012 02:34 PM, David Cole wrote:
>> No trick, but to avoid this, perhaps we should change the "--build"
>> handler to run the cmake configure & generate step before calling out
>> to MSBuild. You can easily do this yourself from the command line by
>> adopting the pattern:
>> 
>>   cmake . && cmake --build . --config Release

Fortunately my cmake scripts are simple enough so the extra invocation
does not add much to the build.

Thanks David.

>> This is a good idea for a feature request. Not sure if we should just
>> always do that by default and provide a way to turn off with a
>> "--no-regenerate", or vice-versa with a "--please-generate-first" ...
>> :-)

The effect of --no-regenerate would be the same as the current buggy
behavior (MSBuild.exe uses outdated project files). IMHO the
--please-generate-first is the right thing.

> Just out of curiosity: In [1], item (1), I reported on the fact that
> one can modify a project's CMakeLists.txt, and "cmake --build" will
> reconfigure/regenerate, but not rebuild. Is this the same issue the
> OP asks about?

No.

> If so, I would strongly support a feature request in
> this respect since, IMO, it's actually quite confusing that CMake's
> "--build" command does anything but rebuilding.

I agree.

> [1] http://www.mail-archive.com/cmake@cmake.org/msg39596.html

This returns 404.

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] FindQt4 with Official Nokia install

[Michael Jackson]

I am having an issue with my project compiling against the Official Nokia Qt4 
downloaded from Nokia. The issue (I think) is that for some reason when FindQt4 
is running it determines that QT_USE_FRAMEWORKS is false and so I don't get all 
of the proper include directories. Namely the -F/Path/To/Frameworks on the 
compile line which makes code like 

#include  fail. 

  Is anyone else having issues compiling their projects against the official 
Nokia Qt downloads? I usually build Qt myself but a colleague of mine is using 
the prebuilt binaries and ran into this problem.

Thanks for any sanity check. Just trying to figure out where the possibly bug 
lies. I am going to assume it is in my code somewhere since I don't remember 
any one else complaining about the same thing. 

Thanks
___
Mike JacksonPrincipal Software Engineer
BlueQuartz SoftwareDayton, Ohio
mike.jack...@bluequartz.net  www.bluequartz.net

--

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] Copying of 3rd party DLLs in a POST-BUILD step

[David Cole]

2012/1/9 Hauke Heibel :
> 2012/1/9 Michael Stürmer :
>> Awesome! Sometimes you just need to know what's already available to solve 
>> your problems in a very elegant way. I'll have a look at these bundles and 
>> probably switch to them instead of maintaining my own stuff!
>
> When looking at the initial problem, I am pretty much convinced that
> you need a combination of your own script and GetPrerequisites since
> you want to copy to your run-time output directory - and there to
> specific sub-directories depending on the build type.
>
> It may well be that I have overseen some functionality in those new modules 
> ...
>
> - Hauke

BundleUtilities, on Windows, should copy dlls to be in the same
directory as the executable being analyzed... So, as long as the exe
is in the right directory when fixup_bundle is called on it, then the
dlls will get copied into that same directory.


Cheers,
David
--

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] Copying of 3rd party DLLs in a POST-BUILD step

[Hauke Heibel]

2012/1/9 Michael Stürmer :
> Awesome! Sometimes you just need to know what's already available to solve 
> your problems in a very elegant way. I'll have a look at these bundles and 
> probably switch to them instead of maintaining my own stuff!

When looking at the initial problem, I am pretty much convinced that
you need a combination of your own script and GetPrerequisites since
you want to copy to your run-time output directory - and there to
specific sub-directories depending on the build type.

It may well be that I have overseen some functionality in those new modules ...

- Hauke
--

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] Copying of 3rd party DLLs in a POST-BUILD step

[John Drescher]

> Awesome! Sometimes you just need to know what's already available to solve 
> your problems in a very elegant way. I'll have a look at these bundles and 
> probably switch to them instead of maintaining my own stuff!
>

Same here. I have spent a few hours writing scripts that keep a list
of necessary dlls. This approach is much cleaner.



John
--

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] Copying of 3rd party DLLs in a POST-BUILD step

[Michael Stürmer]

Awesome! Sometimes you just need to know what's already available to solve your 
problems in a very elegant way. I'll have a look at these bundles and probably 
switch to them instead of maintaining my own stuff!

-Ursprüngliche Nachricht-
Von: David Cole [mailto:david.c...@kitware.com] 
Gesendet: Montag, 9. Januar 2012 17:05
An: Michael Stürmer
Cc: cmake@cmake.org
Betreff: Re: [CMake] Copying of 3rd party DLLs in a POST-BUILD step

2012/1/9 Michael Stürmer :
> I have found some topics related to my issue on the web, but none so far
> helped me to fix it:
>
>
>
> I use Visual Studio 2010 on Windows 7 64Bit.
>
>
>
> During my build, all binaries are collected in one folder, which makes it
> easier for me to debug the project. But to be able to run the program
> actually, I have to copy several dlls (like Qt, openCV etc.) into the folder
> for the program to find them. Putting the libraries in the system path is
> not an option for me, as I switch between 32- and 64-bit on the same system.
>
>
>
> I managed to locate the folder where the dlls are (using some
> CMake-Variables) and using a custom command like
>
>
>
> ADD_CUSTOM_COMMAND( TARGET CopyDlls POST_BUILD
>
>     COMMAND copy "${DLL_3RD}/*.dll"
>  "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$"
>
>     COMMENT "copying dlls ."
>
>     )
>
>
>
> This copies ALL dlls from the ${DLL_3RD} folder to the binary folder, for Qt
> that would be the relase as well as the debug libraries.
>
>
>
> Now my question:
>
>
>
> I would like to only copy those dlls I need, i.e. I have to determine
> somehow if I'm in debug or release mode and select the appropriate libraries
> by adding "d" for debug versions. For openCV I need "opencv_core231.dll" in
> release and "opencv_core231d.dll" in debug mode. Does anyone have a
> solution/workaround/idea for this problem?
>
>
>
> Best regards,
>
> Michael
>
>
> --
>
> 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

Have a look at the CMake modules BundleUtilities and GetPrerequisites:

  http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:BundleUtilities
  http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:GetPrerequisites


HTH,
David

--

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] making the build fail

[David Cole]

Not directly... Not with existing ctest.

But after the ctest_coverage call, there should be a file in your
binary tree called something like "Testing/20120109-0100/Coverage.xml"
-- it is the xml file that will be submitted to CDash reporting what
files have what percent coverage. Near the bottom of that file, there
will be a line like

"74.83"

representing the total overall coverage value.

You could extract that number from there if you want to trigger some
action based on its value.

On the other hand, you can (as a project admin) define what percentage
coverage constitutes "failed coverage" for a project on the CDash
dashboard. Then, when the coverage is below that threshold, it will
show up as yellow to indicate "failed coverage result".


HTH,
David


On Mon, Jan 9, 2012 at 9:30 AM, Tom Deblauwe  wrote:
> Hello list,
>
> Is there a way when doing a coverage build and test run(with bullseye) to
> make the build fail when the total coverage percentage is below a certain
> treshold? for example getting the resulting percentage in your ctest script
> after the "ctest_coverage()" call.
>
> Best regards
> Tom,
> --
>
> 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
--

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] Copying of 3rd party DLLs in a POST-BUILD step

[David Cole]

2012/1/9 Michael Stürmer :
> I have found some topics related to my issue on the web, but none so far
> helped me to fix it:
>
>
>
> I use Visual Studio 2010 on Windows 7 64Bit.
>
>
>
> During my build, all binaries are collected in one folder, which makes it
> easier for me to debug the project. But to be able to run the program
> actually, I have to copy several dlls (like Qt, openCV etc.) into the folder
> for the program to find them. Putting the libraries in the system path is
> not an option for me, as I switch between 32- and 64-bit on the same system.
>
>
>
> I managed to locate the folder where the dlls are (using some
> CMake-Variables) and using a custom command like
>
>
>
> ADD_CUSTOM_COMMAND( TARGET CopyDlls POST_BUILD
>
>     COMMAND copy “${DLL_3RD}/*.dll”
>  “${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$”
>
>     COMMENT “copying dlls …”
>
>     )
>
>
>
> This copies ALL dlls from the ${DLL_3RD} folder to the binary folder, for Qt
> that would be the relase as well as the debug libraries.
>
>
>
> Now my question:
>
>
>
> I would like to only copy those dlls I need, i.e. I have to determine
> somehow if I’m in debug or release mode and select the appropriate libraries
> by adding “d” for debug versions. For openCV I need “opencv_core231.dll” in
> release and “opencv_core231d.dll” in debug mode. Does anyone have a
> solution/workaround/idea for this problem?
>
>
>
> Best regards,
>
> Michael
>
>
> --
>
> 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

Have a look at the CMake modules BundleUtilities and GetPrerequisites:

  http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:BundleUtilities
  http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:GetPrerequisites


HTH,
David
--

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] Copying of 3rd party DLLs in a POST-BUILD step

[Julien Malik]

Hi,

Did you try FixupBundle from the BundleUtilities module ?

I use it on windows, at install time, to copy all the dll required by an 
executable, just next to the executable.
Very usefull to generate a standalone installer. The good thing is that 
it introspects your executable (via the windows equivalent of ldd), and 
copy all that is needed, and only what is needed.
No need to maintain any list of DLL, they just need to be accessible in 
the PATH at the time FixupBundle is called.


I guess you can plug a call to it in a POST_BUILD step, and that it 
would automatically copy the right flavor (debug/release) of DLL.


Regards,
Julien


Le 09/01/2012 10:05, Michael Stürmer a écrit :


I have found some topics related to my issue on the web, but none so 
far helped me to fix it:


I use Visual Studio 2010 on Windows 7 64Bit.

During my build, all binaries are collected in one folder, which makes 
it easier for me to debug the project. But to be able to run the 
program actually, I have to copy several dlls (like Qt, openCV etc.) 
into the folder for the program to find them. Putting the libraries in 
the system path is not an option for me, as I switch between 32- and 
64-bit on the same system.


I managed to locate the folder where the dlls are (using some 
CMake-Variables) and using a custom command like


ADD_CUSTOM_COMMAND( TARGET CopyDlls POST_BUILD

COMMAND copy "${DLL_3RD}/*.dll" 
 "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$"


COMMENT "copying dlls ..."

)

This copies ALL dlls from the ${DLL_3RD} folder to the binary folder, 
for Qt that would be the relase as well as the debug libraries.


Now my question:

I would like to only copy those dlls I need, i.e. I have to determine 
somehow if I'm in debug or release mode and select the appropriate 
libraries by adding "d" for debug versions. For openCV I need 
"opencv_core231.dll" in release and "opencv_core231d.dll" in debug 
mode. Does anyone have a solution/workaround/idea for this problem?


Best regards,

Michael


--

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

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] Copying of 3rd party DLLs in a POST-BUILD step

[Michael Hertling]

On 01/09/2012 10:05 AM, Michael Stürmer wrote:
> I have found some topics related to my issue on the web, but none so far 
> helped me to fix it:
>  
> I use Visual Studio 2010 on Windows 7 64Bit.
>  
> During my build, all binaries are collected in one folder, which makes it 
> easier for me to debug the project. But to be able to run the program 
> actually, I have to copy several dlls (like Qt, openCV etc.) into the folder 
> for the program to find them. Putting the libraries in the system path is not 
> an option for me, as I switch between 32- and 64-bit on the same system.
>  
> I managed to locate the folder where the dlls are (using some 
> CMake-Variables) and using a custom command like
>  
> ADD_CUSTOM_COMMAND( TARGET CopyDlls POST_BUILD
> COMMAND copy "${DLL_3RD}/*.dll"  
> "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$"
> COMMENT "copying dlls ."
> )
>  
> This copies ALL dlls from the ${DLL_3RD} folder to the binary folder, for Qt 
> that would be the relase as well as the debug libraries.
>  
> Now my question:
>  
> I would like to only copy those dlls I need, i.e. I have to determine somehow 
> if I'm in debug or release mode and select the appropriate libraries by 
> adding "d" for debug versions. For openCV I need "opencv_core231.dll" in 
> release and "opencv_core231d.dll" in debug mode. Does anyone have a 
> solution/workaround/idea for this problem?
>  
> Best regards,
> Michael

Perhaps, you might perform a temporary installation for debugging
purposes and use the BundleUtilities for this installation only:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
ADD_EXECUTABLE(main main.c)
INSTALL(TARGETS main DESTINATION bin)
INSTALL(CODE "
IF(CMAKE_INSTALL_PREFIX STREQUAL \"${CMAKE_BINARY_DIR}/debuginstall\")
MESSAGE(\"Use BundleUtilities here\")
ENDIF()
")

If you specify ${CMAKE_BINARY_DIR}/debuginstall as CMAKE_INSTALL_PREFIX,
the BundleUtilities are included - if you replace the MESSAGE() command,
of course - and should do the job. Otherwise, i.e. with different CMAKE_
INSTALL_PREFIX, the installation runs as usual. In this way, you do not
need an installation component or the like to have CMake recognize your
special debugging installation. The downside is that you've to rebuild
the project with the final CMAKE_INSTALL_PREFIX when performing the
"real" installation, but usually, you do this anyway in order to
switch from the debug configuration to the release one.

Regards,

Michael
--

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] Copying of 3rd party DLLs in a POST-BUILD step

[Hauke Heibel]

On Mon, Jan 9, 2012 at 4:11 PM, Michael Jackson
 wrote:
> The only issue I really have with this is that this macro requires there to 
> be BOTH debug and Release libraries available and will copy BOTH no matter 
> which configuration is being built. I am thinking that the 
> "yourCopyDlls.cmake" could be auto generated based on what the programmer 
> says they need and then do the appropriate copy.

I experienced the exact same problem in the beginning - both libraries
had to be available. IIRC, passing ${CMAKE_CFG_INTDIR} to the script
allowed me to overcome this issue. The script does not even need to be
auto-generated. I am using one and the same script for all build
types.

- Hauke
--

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] Copying of 3rd party DLLs in a POST-BUILD step

[Michael Jackson]

I was going to chime in with my own macro:

# 
#-- Copy all the Qt4 dependent DLLs into the current build directory so that
#-- one can debug an application or library that depends on Qt4 libraries.
macro (CMP_COPY_QT4_RUNTIME_LIBRARIES QTLIBLIST)
#message(STATUS "CMP_COPY_QT4_RUNTIME_LIBRARIES")
if (MSVC)
if (DEFINED QT_QMAKE_EXECUTABLE)
set(TYPE "d")
FOREACH(qtlib ${QTLIBLIST})
GET_FILENAME_COMPONENT(QT_DLL_PATH_tmp ${QT_QMAKE_EXECUTABLE} 
PATH)
message(STATUS "Generating Copy Rule for Qt Debug DLL Library 
${QT_DLL_PATH_tmp}/${qtlib}d4.dll")  
add_custom_target(ZZ_${qtlib}-Debug-Copy ALL
COMMAND ${CMAKE_COMMAND} -E copy_if_different 
${QT_DLL_PATH_tmp}/${qtlib}${TYPE}4.dll
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/Debug/ 
COMMENT "Copying ${qtlib}${TYPE}4.dll to 
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/Debug/")
message(STATUS "Generating Copy Rule for Qt Release DLL Library 
${QT_DLL_PATH_tmp}/${qtlib}d4.dll")  
add_custom_target(ZZ_${qtlib}-Release-Copy ALL
COMMAND ${CMAKE_COMMAND} -E copy_if_different 
${QT_DLL_PATH_tmp}/${qtlib}4.dll
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/Release/ 
COMMENT "Copying ${qtlib}4.dll to 
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/Release/")
  
ENDFOREACH(qtlib)
endif(DEFINED QT_QMAKE_EXECUTABLE)
endif()
endmacro()

The only issue I really have with this is that this macro requires there to be 
BOTH debug and Release libraries available and will copy BOTH no matter which 
configuration is being built. I am thinking that the "yourCopyDlls.cmake" could 
be auto generated based on what the programmer says they need and then do the 
appropriate copy. I may look into this today. Thanks for sharing.
___
Mike JacksonPrincipal Software Engineer
BlueQuartz SoftwareDayton, Ohio
mike.jack...@bluequartz.net  www.bluequartz.net

On Jan 9, 2012, at 9:51 AM, John Drescher wrote:

> 2012/1/9 Hauke Heibel :
>> Hi Michael,
>> 
>> What I do is running a custom command which itself executes a CMake
>> script. Usually similar to
>> 
>> add_custom_command(TARGET CopyDlls
>>  COMMAND ${CMAKE_COMMAND}
>>-DMSVC_BUILD_CONFIG_DIR=${CMAKE_CFG_INTDIR}
>>-DCMAKE_RUNTIME_OUTPUT_DIRECTORY=${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
>>-P "/yourCopyDlls.cmake"
>>  VERBATIM
>> )
>> 
>> In the "yourCopyDlls.cmake", you can GLOB your DLLs with or without
>> the "d" postfix depending on MSVC_BUILD_CONFIG_DIR. You can now even
>> copy additional files such as e.g. PDB files.
>> 
> 
> Thanks for sharing this. I use cmake generate a batch file (using
> FILE(append ...) ) that calls cmake -E copy_if_different for each
> file. then add this as a custom target however your method looks much
> cleaner..
> 
> 
> John
> --
> 
> 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

--

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] Copying of 3rd party DLLs in a POST-BUILD step

[John Drescher]

2012/1/9 Hauke Heibel :
> Hi Michael,
>
> What I do is running a custom command which itself executes a CMake
> script. Usually similar to
>
> add_custom_command(TARGET CopyDlls
>  COMMAND ${CMAKE_COMMAND}
>        -DMSVC_BUILD_CONFIG_DIR=${CMAKE_CFG_INTDIR}
>        -DCMAKE_RUNTIME_OUTPUT_DIRECTORY=${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
>        -P "/yourCopyDlls.cmake"
>  VERBATIM
> )
>
> In the "yourCopyDlls.cmake", you can GLOB your DLLs with or without
> the "d" postfix depending on MSVC_BUILD_CONFIG_DIR. You can now even
> copy additional files such as e.g. PDB files.
>

Thanks for sharing this. I use cmake generate a batch file (using
FILE(append ...) ) that calls cmake -E copy_if_different for each
file. then add this as a custom target however your method looks much
cleaner..


John
--

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] Copying of 3rd party DLLs in a POST-BUILD step

[Michael Stürmer]

Hello Hauke,

thanks for the answer! I already got some workaround which is very similar to 
your suggestion: as I have this problem only in windows/msvc mode I use a 
batch-script now which takes the $ variable as an argument. 
Within the bat-script I check the content of %, i.e. 
"Release","Debug" etc. and set some batch-variables appropriately. I don't like 
it very much but it works.

-Ursprüngliche Nachricht-
Von: Hauke Heibel [mailto:hauke.hei...@googlemail.com] 
Gesendet: Montag, 9. Januar 2012 15:45
An: Michael Stürmer
Cc: cmake@cmake.org
Betreff: Re: [CMake] Copying of 3rd party DLLs in a POST-BUILD step

Hi Michael,

What I do is running a custom command which itself executes a CMake
script. Usually similar to

add_custom_command(TARGET CopyDlls
  COMMAND ${CMAKE_COMMAND}
-DMSVC_BUILD_CONFIG_DIR=${CMAKE_CFG_INTDIR}
-DCMAKE_RUNTIME_OUTPUT_DIRECTORY=${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
-P "/yourCopyDlls.cmake"
  VERBATIM
)

In the "yourCopyDlls.cmake", you can GLOB your DLLs with or without
the "d" postfix depending on MSVC_BUILD_CONFIG_DIR. You can now even
copy additional files such as e.g. PDB files.

HTH,
Hauke

2012/1/9 Michael Stürmer :
> I have found some topics related to my issue on the web, but none so far
> helped me to fix it:
>
>
>
> I use Visual Studio 2010 on Windows 7 64Bit.
>
>
>
> During my build, all binaries are collected in one folder, which makes it
> easier for me to debug the project. But to be able to run the program
> actually, I have to copy several dlls (like Qt, openCV etc.) into the folder
> for the program to find them. Putting the libraries in the system path is
> not an option for me, as I switch between 32- and 64-bit on the same system.
>
>
>
> I managed to locate the folder where the dlls are (using some
> CMake-Variables) and using a custom command like
>
>
>
> ADD_CUSTOM_COMMAND( TARGET CopyDlls POST_BUILD
>
>     COMMAND copy "${DLL_3RD}/*.dll"
>  "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$"
>
>     COMMENT "copying dlls ."
>
>     )
>
>
>
> This copies ALL dlls from the ${DLL_3RD} folder to the binary folder, for Qt
> that would be the relase as well as the debug libraries.
>
>
>
> Now my question:
>
>
>
> I would like to only copy those dlls I need, i.e. I have to determine
> somehow if I'm in debug or release mode and select the appropriate libraries
> by adding "d" for debug versions. For openCV I need "opencv_core231.dll" in
> release and "opencv_core231d.dll" in debug mode. Does anyone have a
> solution/workaround/idea for this problem?
>
>
>
> Best regards,
>
> Michael
>
>
> --
>
> 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

--

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] Copying of 3rd party DLLs in a POST-BUILD step

[Hauke Heibel]

Hi Michael,

What I do is running a custom command which itself executes a CMake
script. Usually similar to

add_custom_command(TARGET CopyDlls
  COMMAND ${CMAKE_COMMAND}
-DMSVC_BUILD_CONFIG_DIR=${CMAKE_CFG_INTDIR}
-DCMAKE_RUNTIME_OUTPUT_DIRECTORY=${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
-P "/yourCopyDlls.cmake"
  VERBATIM
)

In the "yourCopyDlls.cmake", you can GLOB your DLLs with or without
the "d" postfix depending on MSVC_BUILD_CONFIG_DIR. You can now even
copy additional files such as e.g. PDB files.

HTH,
Hauke

2012/1/9 Michael Stürmer :
> I have found some topics related to my issue on the web, but none so far
> helped me to fix it:
>
>
>
> I use Visual Studio 2010 on Windows 7 64Bit.
>
>
>
> During my build, all binaries are collected in one folder, which makes it
> easier for me to debug the project. But to be able to run the program
> actually, I have to copy several dlls (like Qt, openCV etc.) into the folder
> for the program to find them. Putting the libraries in the system path is
> not an option for me, as I switch between 32- and 64-bit on the same system.
>
>
>
> I managed to locate the folder where the dlls are (using some
> CMake-Variables) and using a custom command like
>
>
>
> ADD_CUSTOM_COMMAND( TARGET CopyDlls POST_BUILD
>
>     COMMAND copy “${DLL_3RD}/*.dll”
>  “${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$”
>
>     COMMENT “copying dlls …”
>
>     )
>
>
>
> This copies ALL dlls from the ${DLL_3RD} folder to the binary folder, for Qt
> that would be the relase as well as the debug libraries.
>
>
>
> Now my question:
>
>
>
> I would like to only copy those dlls I need, i.e. I have to determine
> somehow if I’m in debug or release mode and select the appropriate libraries
> by adding “d” for debug versions. For openCV I need “opencv_core231.dll” in
> release and “opencv_core231d.dll” in debug mode. Does anyone have a
> solution/workaround/idea for this problem?
>
>
>
> Best regards,
>
> Michael
>
>
> --
>
> 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
--

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] MSBuild and automatic project file regenation

[Michael Hertling]

On 01/09/2012 02:34 PM, David Cole wrote:
> On Sun, Jan 8, 2012 at 11:59 PM, Óscar Fuentes  wrote:
>> When MSBuild.exe is used (typically by "cmake --build") for building a
>> VS2010 project generated by cmake, it correctly invokes cmake for
>> regenerating the project files if changes to the CMakeLists.txt files
>> are detected. However, the build does not restart nor abort, so MSBuild
>> continues using the outdated project files that it previously read,
>> ending some time later with lots of error messages from the compiler or
>> linker, hence wasting time, causing confusion and making difficult to
>> notice that a regeneration had happened.
>>
>> Is there any trick for stopping MSBuild as soon as cmake ends
>> regenerating the project files?
>>
>> --
>>
>> 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
> 
> No trick, but to avoid this, perhaps we should change the "--build"
> handler to run the cmake configure & generate step before calling out
> to MSBuild. You can easily do this yourself from the command line by
> adopting the pattern:
> 
>   cmake . && cmake --build . --config Release
> 
> This is a good idea for a feature request. Not sure if we should just
> always do that by default and provide a way to turn off with a
> "--no-regenerate", or vice-versa with a "--please-generate-first" ...
> :-)
> 
> 
> HTH,
> David

Just out of curiosity: In [1], item (1), I reported on the fact that
one can modify a project's CMakeLists.txt, and "cmake --build" will
reconfigure/regenerate, but not rebuild. Is this the same issue the
OP asks about? If so, I would strongly support a feature request in
this respect since, IMO, it's actually quite confusing that CMake's
"--build" command does anything but rebuilding.

Regards,

Michael

[1] http://www.mail-archive.com/cmake@cmake.org/msg39596.html
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] making the build fail

[Tom Deblauwe]

Hello list,

Is there a way when doing a coverage build and test run(with bullseye) 
to make the build fail when the total coverage percentage is below a 
certain treshold? for example getting the resulting percentage in your 
ctest script after the "ctest_coverage()" call.


Best regards
Tom,
--

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] Changing "PROJECT" level build settings in Xcode

[David Cole]

On Mon, Jan 9, 2012 at 6:49 AM, Eric Noulard  wrote:
> 2012/1/9 Daniel Dekkers :
>> Hi,
>>
>> In Xcode, can I change build settings at "PROJECT" level via CMake?
>> SET_TARGET_PROPERTIES() always seems to work on "TARGETS" level.
>
> What kind of settings?
>
> Properties have a scope:
>    - global
>    - directories
>    - target
>    - tests
>    - source files
>
> see
> cmake --help-properties
>
> with the global ones you can use:
>
> set_property(GLOBAL ...)
>
> note that some properties are read-only, read the doc carefully.
>
>
> --
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel libre » -
> http://www.april.org
> --
>
> 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

And for other properties, they are typically initialized from a
corresponding CMake variable with a name of CMAKE_${PROPERTY_NAME}.
Often, you just have to set that variable if you want it to apply to
all targets. It's property-specific, though, so definitely look at the
documentation for the property you're interested in.


HTH,
David
--

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] MSBuild and automatic project file regenation

[David Cole]

On Sun, Jan 8, 2012 at 11:59 PM, Óscar Fuentes  wrote:
> When MSBuild.exe is used (typically by "cmake --build") for building a
> VS2010 project generated by cmake, it correctly invokes cmake for
> regenerating the project files if changes to the CMakeLists.txt files
> are detected. However, the build does not restart nor abort, so MSBuild
> continues using the outdated project files that it previously read,
> ending some time later with lots of error messages from the compiler or
> linker, hence wasting time, causing confusion and making difficult to
> notice that a regeneration had happened.
>
> Is there any trick for stopping MSBuild as soon as cmake ends
> regenerating the project files?
>
> --
>
> 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

No trick, but to avoid this, perhaps we should change the "--build"
handler to run the cmake configure & generate step before calling out
to MSBuild. You can easily do this yourself from the command line by
adopting the pattern:

  cmake . && cmake --build . --config Release

This is a good idea for a feature request. Not sure if we should just
always do that by default and provide a way to turn off with a
"--no-regenerate", or vice-versa with a "--please-generate-first" ...
:-)


HTH,
David
--

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] Changing "PROJECT" level build settings in Xcode

[Eric Noulard]

2012/1/9 Daniel Dekkers :
> Hi,
>
> In Xcode, can I change build settings at "PROJECT" level via CMake?
> SET_TARGET_PROPERTIES() always seems to work on "TARGETS" level.

What kind of settings?

Properties have a scope:
- global
- directories
- target
- tests
- source files

see
cmake --help-properties

with the global ones you can use:

set_property(GLOBAL ...)

note that some properties are read-only, read the doc carefully.


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Changing "PROJECT" level build settings in Xcode

[Daniel Dekkers]

Hi, 

In Xcode, can I change build settings at "PROJECT" level via CMake?
SET_TARGET_PROPERTIES() always seems to work on "TARGETS" level.

Thanks,
Daniel Dekkers

--

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] Some issues with visual studio

[Michael Stürmer]

--

Message: 2
Date: Sun, 8 Jan 2012 21:52:05 -0700
From: James Bigler 
Subject: Re: [CMake] Some issues with visual studio
To: Renato Utsch 
Cc: cmake@cmake.org
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

On Sun, Jan 8, 2012 at 7:29 AM, Renato Utsch  wrote:

> Hello, I have been experimenting some issue with visual studio and
> couldn't fix them, even when searching in google for help :O
>
> So, I have 2 main issues:
>
> 1. When CMake creates the visual studio solution, it configures to the
> "Debug win32" mode, but I wanted to be able to choose from "Release"
> to "Debug".
> Changing the CMAKE_BUILD_TYPE to "Release" didn't seem to help...
>
>
>
This can't be configured by CMake, because the current configuration is
stored in a binary format file along side the solution file.  This file
contains all sorts of things such as all the arguments for the Debugger
panel.  I don't remember what the name of the file is offhand, because I'm
not at my windows machine at the moment.  This file is created after you
first open the solution file.  What this means, though is there really
isn't a good way for CMake to change what the default build configuration
is.

As far as I can tell VS just picks the first configuration.  I don't know
if it's simply an alphabetical choice or the first configuration in the
projects.  Some simple experiments with hand modifying the project files
could yield the answer.  If it's based on the order in the project files,
CMake could be able to write the files differently, but if VS is being
clever and simply sorting them in ASCII order then it's game over.

James
-- next part --
An HTML attachment was scrubbed...
URL: 


--

I had quite a fight to convince Visual Studio to set the execution folders to 
the folders where I put the binaries. I found some configuration files and 
managed to change the defaults. Maybe your problem can be solved by editing the 
same or similar files. In the folder

C:\Users\\AppData\Local\Microsoft\MSBuild\v4.0

I found the files 

Microsoft.Cpp.Win32.user.props
Microsoft.Cpp.x64.user.props

Which contain all the default configurations for newly created projects. By 
creating some content like

  
$(OutDir)
  

I managed that the debugger working directory will always be the directory 
where the binary resides. Originally this would always be corresponding project 
dir, but if you collect all binaries in a common dir by using 
CMAKE_RUNTIME_OUTPUT_DIRECTORY you have to change the working dir.

I don't have the documentation for the props-files at hand right now, but it 
shouldn't be a problem for you to find it on the msdn pages.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Copying of 3rd party DLLs in a POST-BUILD step

[Michael Stürmer]

I have found some topics related to my issue on the web, but none so far helped 
me to fix it:
 
I use Visual Studio 2010 on Windows 7 64Bit.
 
During my build, all binaries are collected in one folder, which makes it 
easier for me to debug the project. But to be able to run the program actually, 
I have to copy several dlls (like Qt, openCV etc.) into the folder for the 
program to find them. Putting the libraries in the system path is not an option 
for me, as I switch between 32- and 64-bit on the same system.
 
I managed to locate the folder where the dlls are (using some CMake-Variables) 
and using a custom command like
 
ADD_CUSTOM_COMMAND( TARGET CopyDlls POST_BUILD
COMMAND copy "${DLL_3RD}/*.dll"  
"${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$"
COMMENT "copying dlls ."
)
 
This copies ALL dlls from the ${DLL_3RD} folder to the binary folder, for Qt 
that would be the relase as well as the debug libraries.
 
Now my question:
 
I would like to only copy those dlls I need, i.e. I have to determine somehow 
if I'm in debug or release mode and select the appropriate libraries by adding 
"d" for debug versions. For openCV I need "opencv_core231.dll" in release and 
"opencv_core231d.dll" in debug mode. Does anyone have a 
solution/workaround/idea for this problem?
 
Best regards,
Michael--

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