Re: [CMake] Command line cmake not picking up variable that gets picked up in the GUI

[Yuri Timenkov]

You should put this variable into cache one way or another. (e.g.
explicitly set with CACHE option or use in some find_* command).

The most straight-forward approach is to add to your
CMakeLists.txtsomething like:
set(CODE_BUILD_DIR "${CODE_BUILD_DIR}" CACHE PATH "Path to CODE package")

But beware that behavior depends on whether you specify this flag in
successive CMake invocations.

If you build nested project by yourself I suggest using find_package in
config mode. Once config file found, CMake puts appropriate directory into
cache and on successive runs reads package config file immediately. If that
project is also build with CMake I suggest looking at exporting targets and
registering exports locally.

On Fri, Nov 30, 2012 at 12:44 AM, katie outram wrote:

> I am trying to automate my build process and before going down this path,
> I set up findMYCODE script that requires a variable CODE_BUILD_DIR that the
> user defines.This variable is the build directory for another code base
> that my current code base is dependent on.   When I run CMAKE  in the gui,
> and define the variable, the find script locates the necessary path/items
> and this value is populated in the CMakeCache file.In the CMakeCache
> file my variable is listed as
>
> CODE_BUILD_DIR:PATH=C:/builddir/Win64/VC10/bin/Release
>
> However ,when I go to the command line and try to pass the needed
> build parameter via the command line, my value is not getting picked up and
> so my solution does not get generated.   In order to get my solution I must
> have this variable defined.
>
> From the build directory where I am trying to complete the build I execute
> the following command:
>
> cmake -G "Visual Studio 10 Win64"
> -DCODE_BUILD_DIR:PATH=C:/builddir/Win64/VC10/bin/Release c:\mysource
>
> The variable CODE_BUILD_DIR int he above line is the first build directory
> for another code base that my current code is dependent on.
>
> I have tried several variations of this command line option and passing
> the -D variable, with and without escaping my path, however I am not having
> any success.   Without this parameter defined,* *I am unable to locate
> the necessary libraries that I must use to link into my current code.
>
> I am thinking that I am possibly missing something in my find script, or
> maybe I'm not escaping the characters in my path correctly.
>
> Does anyone have any suggestions?
>
> Thanks
>
>
>
> --
>
> 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] cmake on Windows x64

[Yuri Timenkov]

The 32 vs 64 bit switch based on pointer size is not sufficient. To be 100%
correct you shall be able to differentiate between x86_64 and IA-64
(However I think it's quite rare case). And to me personally condition with
target architecture looks better than CMAKE_CL_64 or checking the size of
pointer.

I think the "... Win64" generator is a bit confusing because what it
actually does - is cross-compilation however cross-compilation requires
more variables to be set properly.

I also need an advice on how to deal with package configs. They've proven
to be very convenient but how to differentiate when you have single header
location and 32- and 64-bit libraries?


On Mon, Oct 15, 2012 at 9:37 PM, John Drescher  wrote:

> > Having CMAKE_SYSTEM_PROCESSOR be "x86" for a 64-bit build is very
> inconvenient when detecting machine-dependent compiler flags, constructing
> directory names for outputs based on configuration, configuring third party
> search directories, etc.  It's always possible to work around (among other
> things, one can consult the generator string for Visual Studio builds,
> though not for MinGW builds) but that doesn't mean it shouldn't be better
> behaved - it's entirely reasonable to assume that CMAKE_SYSTEM_PROCESSOR
> should be the target processor for the build, especially so that you can
> have similar behavior on Windows, Linux, and Mac.  Though as previously
> discussed I also have the opposite problem on Linux when compiling for
> 32-bit CPU on 64-bit OS.
>
>
> I see. I have always compared the size of the pointer for this..
>
> 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] cmake on Windows x64

[Yuri Timenkov]

Except that you have CMAKE_SYSTEM_PROCESSOR == "x86" (event for "Win64"
generators) in your CMake files along with all search paths which sometimes
very inconvenient.

On Fri, Oct 12, 2012 at 5:31 PM, John Drescher  wrote:

> > I noticed that there is cmake binary package for Windows x64. Should a
> > 32-bit cmake (under syswow6432) be adequate for all cmake tasks? If
> > not, what is the right way to build cmake for 64-bit. I tried building
> > it on a 32-bit build server using the 64 bit generator (this build
> > server routinely does 64-bit cross compiles). However, apparently some
> > of the products of the 64-bit build are run to generate sources that
> > are built by other parts of the build. This being a 32-bit box does
> > not allow that and hence the cross-compile to 64-bit failed.
> >
>
> 32 bit cmake works fine for 64 bit builds on x64. I use this almost
> every day for the last 3+ years..
>
> 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] Scanning dependencies of target slowness weirdness.

[Yuri Timenkov]

Or it's implementation on Linux... I doubt anybody had any problems with
NTFS on Windows :)

You may also be using it via FUSE... not fastest approach.

If you need to keep your sources on NTFS you may create temporary location
on native FS and rsync before building (or DVCS). We used it instead of
NFS/SAMBA for quick cross-platform builds. Much faster.

On Mon, Sep 10, 2012 at 7:10 PM, Carlo Wood  wrote:

> Bah, this whole mailinglist disappeared to some file that I wasn't
> aware of :p  But I found it back now...
>
> I moved the sources to a slow (7200 rpm) HDD using ext4, and it
> became 5 times faster.
>
> Conclusion: NTFS sucks totally.
>
> On Thu, Sep 06, 2012 at 11:47:36AM -0400, Bill Hoffman wrote:
> > On 9/6/2012 5:56 AM, Amine Chadly wrote:
> > >Hi,
> > >I am no CMake expert, but I would test on an identical file system
> types...
> > >I am pretty sure that ntfs and ext3fs don't have the same read-write
> > >access latency and this might explain your time difference.
> > >You could additionally launch a strace on the two settings and see if
> > >there are major differences that could explain the performance hit...
> > >Good luck.
> > >
> > and has a NTFS.
> >
> > It is almost certainly the NTFS.  What if you move the source to the SSD?
> >
> > -Bill
>
> --
> Carlo Wood 
> --
>
> 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] configuring cmake using program options?

[Yuri Timenkov]

I think on contrary, the value passed from command line wasn't saved into
cache. You should do it manually in your CMakeLists.txt, like
set(Mylib_DIR "${Mylib_DIR}" CACHE PATH "Path to something")

But variables with _DIR suffix are usually set by find_package command, I'm
not sure about expected behavior in this case.

On Mon, Sep 10, 2012 at 2:40 PM, J Decker  wrote:

> blow away cmakecache.txt and try again.
> That is probably cached if it's an option you can set in ccmake or
> cmake-gui
>
> On Mon, Sep 10, 2012 at 3:08 AM, Witold E Wolski 
> wrote:
> > Hi,
> >
> > When calling ccmake I can configure a variable Mylib_DIR (library
> location)/
> >
> > However, I would like to run the configuration and build process in bash
> > script (its an out of source build). Therefore I am trying to configure
> > everything on the command line using the -D switch:
> >
> > cmake -G "Eclipse CDT4 - Unix Makefiles"
> > -DMylib_DIR=/home/witold/prog/OpenMS/gitsvn ../mapdiv
> >
> > However, when starting ccmake the Mylib_DIR is still set to some default
> > other default variable.
> >
> > cheers
> > Wolski
> >
> >
> > --
> >
> > 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
>
--

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 an entire static library

[Yuri Timenkov]

As an option you may create .def file which lists functions from static
library as exported. This will force linker to treat them as undefined and
link with all dependencies. However this requires some actions and works
only for quite stable libs.
We employed this approach when we had no control over static library.

Regards,
Yuri

On Mon, Sep 10, 2012 at 11:54 AM, Petr Kmoch  wrote:

> Hi Eric.
>
> Many thanks for your reply.
>
> On Mon, Sep 10, 2012 at 9:49 AM, Eric Noulard 
> wrote:
> > 2012/9/10 Petr Kmoch :
> >> Hi all.
> >>
> >> I'm on Windows, and I need a DLL composed of multiple static
> >> libraries, any of which can define dllexport functions not otherwise
> >> referenced in the DLL. The problem is that the Visual Studio linker
> >> does not provide flags to link an entire static library (i.e. there is
> >> no equivalent to ld's --whole-archive). I tried /OPT:NOREF, it didn't
> >> help.
> >>
> >> The only solution I can think of is to link all of the static
> >> library's object files instead of the library itself (I verified
> >> manually that this works). I cannot put source files into the DLL
> >> directly, because the DLL is C and the static lib(s) are Fortran.
> >
> > Why can't you do that?
> > I do not use fortran since a long time ago but I do not see why you
> can't do
> >
> > add_library(mymixedllib foo.c blah.f90)
>
> Because I need the Fortran VS project to be a .vfproj, and that only
> works for pure-Fortran targets.
>
> >
> >
> >> My question is thus: is there a way to retrieve the list of a target's
> >> object files from cmake?
> >
> > Since CMake 2.8.9 you can build "OBJECT" library,
> > see:
> > cmake --help-command add_library
> >
> > [...]
> >  add_library( OBJECT ...)
> >
> >creates a special "object library" target.  An object library
> compiles
> >source files but does not archive or link their object files into
> a
> >library.  Instead other targets created by add_library or
> >add_executable may reference the objects using an expression of
> the
> >form $ as a source, where "objlib" is the
> >object library name.  For example:
> >
> >  add_library(... $ ...)
> >  add_executable(... $ ...)
> >
> >will include objlib's object files in a library and an executable
> >along with those compiled from their own sources.
> > [...]
>
> A hundred thanks! That's precisely what I need. On to ask for an
> upgrade our company-wide cmake installation, then.
>
> Petr
> --
>
> 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] Different compiler in sub directory

[Yuri Timenkov]

It's better to use ExternalProject.cmake to configure part of your solution
with different compiler.

On Wed, Sep 5, 2012 at 12:09 PM, Nicholas Yue wrote:

> Hi,
>
> I have a need to build different parts of a project using different
> version of g++
>
> If I set the top level CMakeLists.txt compiler
>
> via -DCMAKE_CXX_COMPILER=/usr/**local/bin/g++
>
> and subsequently use another compiler
>
> SET ( CMAKE_CXX_COMPILER "/usr/bin/g++" )
>
> will the compiler being set only scoped within that directory (when I
> use ADD_SUBDIRECTORY) or would that become global for other projects
> later...
>
> Regards
>
> --
> Nicholas Yue
> Graphics - RenderMan, Visualization, OpenGL, HDF5
> Custom Dev - C++ porting, OSX, Linux, Windows
> Management - Recruitment, career management
> http://www.proceduralinsight.**com/ 
> http://au.linkedin.com/in/**nicholasyue
>
> --
>
> 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] C# and cmake ?

[Yuri Timenkov]

Generator expressions are special placeholders $<> used in custom commands
and targets. If external project weren't of "utility" type in CMake (e.g.
executable) it would be possible to associate imported location with it and
use in other custom commands and targets as any other target. This allows
CMake to automatically substitute configuration and handle dependencies
where necessary.

For example if you have code generator or test runner written in C#. Now
it's still possible but you have to use CMAKE_CFG_INTDIR.

On Wed, Aug 22, 2012 at 4:08 PM, Gerhard den Hollander <
gdenhollan...@fugro-jason.com> wrote:

> * Yuri Timenkov  (Wed, Aug 22, 2012 at 01:20:37PM +0200)
> > It's better to use include_external_msproject with C# projects. After
> fixing bug http://public.kitware.com/Bug/view.php?id=13120 it's possible
> to use:
> >
> > include_external_msproject(Configurator
> ${CMAKE_SOURCE_DIR}/MyCSProject.csproj
> > TYPE FAE04EC0-301F-11D3-BF4B-00C04F79EFBC
> > PLATFORM "Any CPU"
> > )
>
>
> According to the 2.8.9 changelog, this bugfix is part of 2.8.9.
>
>
> >
> > Additionally you can use configure_file to create file in $(SolutionDir)
> to pass information (like paths, configuration options, etc.) to msbuild
> and VS IDE.
>
> > The only drawback is that CMake sees these project as utility projects,
> so you can't use them in generator expressions. However you can link to
> them by adding dependencies.
>
> Im not sure what you mean with the above. What are generator
> expressions ?
>
>
>
>
--

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] C# and cmake ?

[Yuri Timenkov]

It's better to use include_external_msproject with C# projects. After
fixing bug http://public.kitware.com/Bug/view.php?id=13120 it's possible to
use:

include_external_msproject(Configurator
${CMAKE_SOURCE_DIR}/MyCSProject.csproj
TYPE FAE04EC0-301F-11D3-BF4B-00C04F79EFBC
PLATFORM "Any CPU"
)

Additionally you can use configure_file to create file in $(SolutionDir) to
pass information (like paths, configuration options, etc.) to msbuild and
VS IDE.

The only drawback is that CMake sees these project as utility projects, so
you can't use them in generator expressions. However you can link to them
by adding dependencies.

On Wed, Aug 22, 2012 at 3:03 PM, Gerhard den Hollander <
gdenhollan...@fugro-jason.com> wrote:

> We have a large code base, that consists of a large number of C++ file
> and a smaller number of C# files.
>
> Most fo the C++ code is being build using CMake,
> the C# code is build using the msbuild tools.
>
> I know that currently there is no C# support planned in CMake,
> but reading through the google results, it sounds like people have had
> various degrees of success using custom_command(..) or other CMake
> tricks to kick of C# builds using msbuild/devenv.
>
> For those who have succesfully build mixed code projects (so C# and
> C/C++ ), would you mind explainign how this is done ?
>
> Preferably with some example CMake files ?
>
> Thanks
>
> --
>
> 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] "UTILITY" library?

[Yuri Timenkov]

But it would be great if one can override msproject target type. It
could be used properly in generator commands and test afterwards
without any problems with configurations. (E.g. if you have test
runner or kind of code generator written in C# or VB).

On Wed, Aug 8, 2012 at 4:49 PM, Klaim - Joël Lamotte  wrote:
> I apparently fixed the problem by using add_dependencies() instead of
> target_link_libraries() ...
>
> Klaim / Joel Lamotte
>
> --
>
> 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] Automatic rebuild of external projects

[Yuri Timenkov]

Hi,

It's possible with some modifications to ExternalProject.cmake:
http://public.kitware.com/Bug/view.php?id=12322

However it is not encouraged by CMake developers.

On Mon, Jul 2, 2012 at 2:25 PM, Evgeny Startsev
 wrote:
> I am using external project module for cmake. Is there any way to rebuild
> local external project (from local directory), then its sources was changed?
> I have tried special DOWNLOAD_COMMAND or UPDATE_COMMAND, but this commands
> called only first time.
>
> --
>
> 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] /STACK:10000000 being added to linker in Visual Studio?

[Yuri Timenkov]

As an option you can set up all these flags manually. In my current
project we don't have many compilers to support but we need
fine-grained control over compiler options (due to legacy and
compatibility reasons). CMake allows to set precisely required
options:

# Override default Compiler flags
set(CMAKE_USER_MAKE_RULES_OVERRIDE MyCompilerFlags)

project(MyProject)

Where MyCompilerFlags contains something like this:
if(MSVC)
   # Set default linker options.
   set(CMAKE_SHARED_LINKER_FLAGS_INIT "/MACHINE:X86 /DEBUG")
   set(CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT "/INCREMENTAL:NO")
   set(CMAKE_SHARED_LINKER_FLAGS_RELEASE_INIT "/INCREMENTAL:NO")

   # Now use same options for all dynamic modules.
   set(CMAKE_EXE_LINKER_FLAGS_INIT "${CMAKE_SHARED_LINKER_FLAGS_INIT}")
   set(CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT
"${CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT}")
   set(CMAKE_EXE_LINKER_FLAGS_RELEASE_INIT
"${CMAKE_SHARED_LINKER_FLAGS_RELEASE_INIT}")

   set(CMAKE_MODULE_LINKER_FLAGS_INIT "${CMAKE_SHARED_LINKER_FLAGS_INIT}")
   set(CMAKE_MODULE_LINKER_FLAGS_DEBUG_INIT
"${CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT}")
   set(CMAKE_MODULE_LINKER_FLAGS_RELEASE_INIT
"${CMAKE_SHARED_LINKER_FLAGS_RELEASE_INIT}")

   set(CMAKE_CXX_FLAGS_INIT "${CMAKE_CXX_FLAGS_INIT} /Zi
/D_WIN32_WINNT=0x0501")

   if(MSVC_VERSION GREATER 1200)
   set(CMAKE_CXX_FLAGS_INIT "${CMAKE_CXX_FLAGS_INIT} /WX
/D_SCL_SECURE_NO_DEPRECATE /wd4251 /wd4275 /wd4503")
   endif()
endif(MSVC)

#
# Tune compiler and linker flags.
#
if(CMAKE_COMPILER_IS_GNUCXX)
   # Our default policy: Treat all warnings as errors.
   # Build multi-threaded libraries and applications.
   set(CMAKE_C_FLAGS_INIT "-fmessage-length=0 -pthread -D_REENTRANT -ggdb")

   # Enable C++ 0x support.
   set(CMAKE_CXX_FLAGS_INIT "${CMAKE_C_FLAGS_INIT} -std=c++0x")
endif(CMAKE_COMPILER_IS_GNUCXX)

On Wed, Jun 27, 2012 at 11:38 PM, Robert Dailey
 wrote:
> Yeah certainly, especially since multicore is pretty much everywhere now and
> most applications are designed with parallelization in mind.
>
> Like every other compiler and linker flag out there, have the user manually
> set that up if they want it. CMake doesn't automatically add any other
> compiler flags for me, so /STACK shouldn't be any different IMHO.
>
> Thanks for your help, I will try using those new global variables.
>
>
> On Wed, Jun 27, 2012 at 2:35 PM, David Cole  wrote:
>>
>> Ah. I just read through Windows-cl.cmake again to refresh my memory
>>
>> Also do the same thing with these two variables:
>> CMAKE_SHARED_LINKER_FLAGS for SHARED dll targets, and
>> CMAKE_MODULE_LINKER_FLAGS for MODULE dll targets. That should take
>> care of it.
>>
>> Whew. Maybe we should just remove it from CMake one of these days.
>> Seems like a bit of an excessive stack size to have by default,
>> doesn't it? :-)
>>
>>
>> David
>>
>>
>> On Wed, Jun 27, 2012 at 3:27 PM, Robert Dailey 
>> wrote:
>> > I just tried your code and unfortunately /STACK still shows up for DLL
>> > targets, although for EXE targets it seems to be gone.
>> >
>> >
>> > On Wed, Jun 27, 2012 at 2:24 PM, David Cole 
>> > wrote:
>> >>
>> >> Try my code, and tell us if it removes the generated /STACK from all
>> >> your linker calls or not...
>> >>
>> >> Thx,
>> >> David
>> >>
>> >> On Wed, Jun 27, 2012 at 3:22 PM, Robert Dailey
>> >> 
>> >> wrote:
>> >> > Apparently this won't work... /STACK doesn't show up in any of the
>> >> > compile
>> >> > flags retrieved this way. However, CMAKE_EXE_COMPILER_FLAGS doesn't
>> >> > apply to
>> >> > library targets, right?
>> >> >
>> >> >
>> >> > On Wed, Jun 27, 2012 at 2:19 PM, Robert Dailey
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> This flag is appended to DLL targets too, so I created this (i
>> >> >> haven't
>> >> >> tested it yet though):
>> >> >>
>> >> >> function( _remove_stack_flag target_name )
>> >> >> get_property( flags TARGET ${target_name} PROPERTY COMPILE_FLAGS )
>> >> >> string( REGEX REPLACE "/STACK:[0-9]+" "" flags ${flags} )
>> >> >> set_property( TARGET ${target_name} PROPERTY COMPILE_FLAGS ${flags}
>> >> >> )
>> >> >> endfunction()
>> >> >>
>> >> >> I call this once for each target I define.
>> >> >>
>> >> >>
>> >> >> On Wed, Jun 27, 2012 at 2:17 PM, David Cole 
>> >> >> wrote:
>> >> >>>
>> >> >>> You could do:
>> >> >>>
>> >> >>>  string(REPLACE "/STACK:1000 " "" CMAKE_EXE_LINKER_FLAGS
>> >> >>> "${CMAKE_EXE_LINKER_FLAGS}")
>> >> >>>
>> >> >>> after the first project command in the top level CMakeLists file.
>> >> >>> (Or
>> >> >>> "/STACK:some other number" to change it, instead of the empty
>> >> >>> string
>> >> >>> to just remove it...)
>> >> >>>
>> >> >>> The /STACK string only appears in the two files:
>> >> >>>
>> >> >>>  Modules/Platform/Windows-Intel.cmake
>> >> >>>  Modules/Platform/Windows-cl.cmake
>> >> >>>
>> >> >>>
>> >> >>> HTH,
>> >> >>> David
>> >> >>>
>> >> >>>
>> >> >>> On Wed, Jun 27, 2012 at 3:11 PM, Robert Dailey
>> >> >>> 
>> >> >>> wrot

Re: [CMake] local and system installs that include python and shell scripts

[Yuri Timenkov]

I think it should be quite common case in KDE community, since GUI
usually have resources, but I don't know if apps can run from build
dir.

We use custom commands for these purposes, something like this:
 get_filename_component(destPath "${destName}" PATH)
 add_custom_command(OUTPUT ${destName}
 MAIN_DEPENDENCY ${source}
 COMMAND ${CMAKE_COMMAND} -E copy ${source} "${destPath}"
 COMMENT "Copying file ${source}"
 VERBATIM
 )
(I don't remember if cmake can copy file with renaming or it's our legacy code)

If your scripts aren't attached to any target, you may create "custom"
one for them.

On build server you don't usually need this (because it uses install),
then you can control the behavior via special switches to allow
running locally from build directory.

I also suggest wrapping all such stuff into macros.
CMakeParseArguments helps significantly in writing macros with
informative and self-descriptive calls.

On Sat, Jun 23, 2012 at 1:29 AM, Ateljevich, Eli  wrote:
> Hi again,
>
> My project is set up so that the compiled targets naturally get output to a
> structure that looks like a "development mode" installation:
>
> /myproj
>
>    /build
>
>   /bin
>
>   /lib
>
>   /include
>
>
>
> This is convenient for some users ... it is the sort of code people tinker
> with, and I think a lot of my users will actually want to keep it local. I
> will offer a more typical install as well.
>
>
>
> In addition, I have some python and shell scripts mixed in with my source
> code in subdirectories. These don’t naturally get moved anywhere during the
> build and I would like to do so to complete the "development installation"
> idea:
>
> /myproj
>
>    /build
>
>   /bin
>
>   /lib
>
>   /include
>
>   /scripts
>
>  something.sh
>
>  /pylib
>
>  scripts and python shared libraries
>
>
>
>
>
> How is this best done? Should I treat this as a case of “install”? In that
> case when development mode is on I would install to the local directory.
> Strangely, for 90% of the project the source and destination will be the
> same – which is what makes it seem weird. Or should I just use "command"
> with cmake -E style copying locally and only use install for the system
> install?
>
>
>
> It may be that either will work, but it seems from my last post or two that
> I don't always see the usual idioms and it could be neither of my guesses is
> a good one.
>
>
>
> Thanks,
>
> Eli
>
>
> --
>
> 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] Separate compiler and linker pdb

[Yuri Timenkov]

I had problems overwriting pdbs when tried to make single pch for
several similar projects (targets).

I think it could be possible to work-around this issue while
preserving current behavior (using policies or extra flags).

On Fri, Jun 22, 2012 at 2:03 PM, Michele Santullo
 wrote:
> Hello, thanks for your reply. I saw that page already, and I understand
> cmake needs to work around other people's mistakes, so the fix is not an
> easy one.
> My doubt is not about setting a specific path, but about the pdbs ending up
> in the same spot. Is there any known problem with the pdbs overwriting each
> other? Or is that safe? Couldn't you just call them *.compiler.pdb and
> *.linker.pdb as a temporary fix, and leave to the user the burden of picking
> up the relevant ones?
>
> Michele
>
>
> On 21/06/2012 19:10, Yuri Timenkov wrote:
>>
>> This is a limitation of CMake. There is a discussion at
>> http://public.kitware.com/Bug/view.php?id=11899
>>
>> On Tue, Jun 19, 2012 at 7:57 PM, Michele Santullo
>>   wrote:
>>>
>>> Hello, we recently converted our project to cmake but for some reason, as
>>> we
>>> generate for VS 2008 on Windows, we get the same path for both the
>>> compiler
>>> and the linker generated pdb files.
>>>
>>> The path is something like /bin/Debug/Project.pdb for both, so they
>>> overwrite each other causing various errors. If I pass the /Fd switch to
>>> the
>>> compiler, cmake just keeps the old path and appends the new one to the
>>> command line parameters, confusing the VS IDE and causing a full rebuild
>>> every time we build.
>>>
>>> Is there a solution to produce two different files?
>>> Could it be caused by some error in my cmake files? The only settings
>>> about
>>> paths I can think of are:
>>>
>>> set( CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/../bin )
>>> set( CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/../lib )
>>>
>>> if(MSVC)
>>>        set(PDB_SEARCH_PATHS "/PDBPATH")
>>>        SET(LNK_FLAGS_DEBUG "${LNK_FLAGS_DEBUG} ${PDB_SEARCH_PATHS}")
>>>        SET(LNK_FLAGS_RELEASE "${LNK_FLAGS_RELEASE} ${PDB_SEARCH_PATHS}")
>>>        SET(LNK_FLAGS_SHIPPING "${LNK_FLAGS_SHIPPING}
>>> ${PDB_SEARCH_PATHS}")
>>> endif(MSVC)
>>>
>>> Thanks,
>>> Michele
>>> --
>>>
>>> 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
--

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] Current binary directory confusion

[Yuri Timenkov]

Is it strict requirement? Can't you just add your .rc files as source
file to your target or just add target name as part of file name? This
way they can be put everywhere, including current binary dir. I use
this for adding version information to binaries.

Otherwise you may try to use post-build steps
(http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:add_custom_command)
to put your file in right place (e.g. create in current binary dir and
then use ${CMAKE_COMMAND} -E copy_if_different).

On Thu, Jun 21, 2012 at 10:06 PM, Robert Dailey
 wrote:
> This is becoming a challenge :-)
>
> I'm generating .RC files using configure_file() in my CMake script. Since I
> can have multiple targets defined in the same directory, and the resource
> file generated for each target has the same name, I need them to be placed
> in the .dir directory inside of CMAKE_CURRENT_BINARY_DIR. Right
> now I hard-code the path:
>
> set( output_dir "${CMAKE_CURRENT_BINARY_DIR}/${target_name}.dir" )
>
>
> On Thu, Jun 21, 2012 at 11:46 AM, J Decker  wrote:
>>
>> On Thu, Jun 21, 2012 at 9:26 AM, Robert Dailey 
>> wrote:
>> > You're totally confused. I'm not looking to work around a problem, I
>> > just
>> > want information from CMake that I know it has. Somewhere it knows
>> > exactly
>> > where binaries will be placed (those binaries that get compiled) because
>> > it
>> > has to generate the scripts and visual studio projects with those paths
>> > inside.
>> >
>> > CMake is generating resource files that must be placed in these
>> > directories
>> > and are later included in the targets to be compiled, so I need to know
>> > this
>> > directory so that no matter what generator I'm using, the resource file
>> > will
>> > always be copied to the proper location.
>> >
>>
>> that's didn't help a lot :)   what sort of resource files do you mean?
>>  Watcom .rc handling isn't great for instance, and I have custom rules
>> to generate the .res output, but then I just specify that output.
>>
>> >
>> > On Thu, Jun 21, 2012 at 11:07 AM, J Decker  wrote:
>> >>
>> >> On Thu, Jun 21, 2012 at 8:58 AM, Robert Dailey
>> >> 
>> >> wrote:
>> >> > So how do I get the absolute path to this directory in a portable
>> >> > (between
>> >> > generators) way?
>> >> >
>> >> >
>> >>
>> >> Well, what is it you want from there?  I generate INSTALL commands to
>> >> put the outputs where I want them and let them worry about where the
>> >> files are?
>> >>
>> >> > On Thu, Jun 21, 2012 at 9:03 AM, J Decker  wrote:
>> >> >>
>> >> >> On Wed, Jun 20, 2012 at 12:08 PM, Robert Dailey
>> >> >>  wrote:
>> >> >> > ${CMAKE_CURRENT_BINARY_DIR} returns a directory that contains
>> >> >> > generated
>> >> >> > files, such as vcproj files when generating for visual studio.
>> >> >> > However,
>> >> >> > actual compiled binaries are placed:
>> >> >> >
>> >> >> > ${CMAKE_CURRENT_BINARY_DIR}/${target_name}.dir/Debug (for debug
>> >> >> > configuration)
>> >> >> >
>> >> >> > Is there a variable or target property that will give me the
>> >> >> > following
>> >> >> > path
>> >> >> > for any target:
>> >> >> >
>> >> >> > ${CMAKE_CURRENT_BINARY_DIR}/${target_name}.dir
>> >> >> >
>> >> >> > (I don't care about debug/release being part of the path, I just
>> >> >> > want
>> >> >> > the
>> >> >> > "target.dir" part to be included in the path. Right now I'm
>> >> >> > hard-coding
>> >> >> > the
>> >> >> > ".dir" directory and appending it to my path, but I don't know if
>> >> >> > this
>> >> >> > naming scheme is guaranteed by CMake or if it will change in the
>> >> >> > future.
>> >> >> >
>> >> >> it differs from generator to generator
>> >> >>
>> >> >> > --
>> >> >> >
>> >> >> > 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
--

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] automatable way to specify parallel --builds

[Yuri Timenkov]

I was thinking of same problem also and it would be good to have
common switch in CMake which translates into generator-specific
parameter (actually CMAKE_BUILD_TOOL's one, btw you can get it with
from CMakeCache.txt).
Our builds broke couple of times when CMake jumped between devenv and
msbuild for VS2010 (they use different command line options).

On Sat, May 5, 2012 at 3:45 PM, Dave Abrahams  wrote:
>
> on Sat May 05 2012, Michael Wild 
>  wrote:
>
>> On 05/05/2012 08:25 AM, Dave Abrahams wrote:
>>>
>>> I am driving invocations of cmake with another tool, and I would like to
>>> pass the equivalent of -jN for the "cmake --build" step, but I don't
>>> seem to be about to find out what generator will be used, which makes it
>>> hard to even write code to generate the right command line options.  Can
>>> anyone help?
>>>
>>> Thanks!
>>>
>>
>> When you run CMake to configure the project, you can select the
>> generator with -G. Does that help?
>
> Hmm, for some reason I didn't think of doing that, but I guess it might
> help, thanks!
>
> --
> Dave Abrahams
> BoostPro Computing
> http://www.boostpro.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
--

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] Problem with Visual Studio, custom commands, and dependencies. Bug?

[Yuri Timenkov]

I'm not sure but this may be "feature" of msbuild: it doesn't rescan
dependencies after run. This causes a lot of troubles with generated
code (for same reason auto-reloading macro doesn't work since VS2010).

You may try to work this around by splitting build into several stages
(i.e. adding custom targets containing only custom commands, probably
adding later target-level dependencies).

On Wed, May 9, 2012 at 11:04 PM, Jensen, Erik A  wrote:
> Part of my build involves generating an archive of several files. To do
> this, I have custom commands for copying each file into a directory (some
> from the source tree, some from the build tree), a custom command for
> generating the archive, and a custom target that depends on the latter
> custom command. Each copy command depends on its source file, and the
> archive command depends on all of the destination files.
>
>
>
> This works fine with NMake files, but I have noticed a problem with Visual
> Studio 2010 solution files: when I modify a source file and build, the
> command to copy the file into the directory is run, but the command to build
> the archive is not run unless I run build a second time. It seems that
> Visual Studio checks the dependencies for the archive command before running
> the copy commands, so it doesn’t pick up the changed files until a
> subsequent run.
>
>
>
> Is this a known limitation, or a bug in the generated files? It seems like
> it could be solved in this case by also including dependencies of
> dependencies in the generated project files, but I haven’t thought about it
> enough to know if that would cause other problems.
>
>
>
> Thanks.
>
> -- Erik
>
>
> --
>
> 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] Current binary directory confusion

[Yuri Timenkov]

Then you should use LOCATION target property
(http://www.cmake.org/cmake/help/v2.8.8/cmake.html#prop_tgt:LOCATION)
or use generator expressions, because exact place where resulting
binary located depends on many things (used generator, other
variables, like CMAKE_RUNTIME_OUTPUT_DIR, etc).

On Thu, Jun 21, 2012 at 8:26 PM, Robert Dailey  wrote:
> You're totally confused. I'm not looking to work around a problem, I just
> want information from CMake that I know it has. Somewhere it knows exactly
> where binaries will be placed (those binaries that get compiled) because it
> has to generate the scripts and visual studio projects with those paths
> inside.
>
> CMake is generating resource files that must be placed in these directories
> and are later included in the targets to be compiled, so I need to know this
> directory so that no matter what generator I'm using, the resource file will
> always be copied to the proper location.
>
>
> On Thu, Jun 21, 2012 at 11:07 AM, J Decker  wrote:
>>
>> On Thu, Jun 21, 2012 at 8:58 AM, Robert Dailey 
>> wrote:
>> > So how do I get the absolute path to this directory in a portable
>> > (between
>> > generators) way?
>> >
>> >
>>
>> Well, what is it you want from there?  I generate INSTALL commands to
>> put the outputs where I want them and let them worry about where the
>> files are?
>>
>> > On Thu, Jun 21, 2012 at 9:03 AM, J Decker  wrote:
>> >>
>> >> On Wed, Jun 20, 2012 at 12:08 PM, Robert Dailey
>> >>  wrote:
>> >> > ${CMAKE_CURRENT_BINARY_DIR} returns a directory that contains
>> >> > generated
>> >> > files, such as vcproj files when generating for visual studio.
>> >> > However,
>> >> > actual compiled binaries are placed:
>> >> >
>> >> > ${CMAKE_CURRENT_BINARY_DIR}/${target_name}.dir/Debug (for debug
>> >> > configuration)
>> >> >
>> >> > Is there a variable or target property that will give me the
>> >> > following
>> >> > path
>> >> > for any target:
>> >> >
>> >> > ${CMAKE_CURRENT_BINARY_DIR}/${target_name}.dir
>> >> >
>> >> > (I don't care about debug/release being part of the path, I just want
>> >> > the
>> >> > "target.dir" part to be included in the path. Right now I'm
>> >> > hard-coding
>> >> > the
>> >> > ".dir" directory and appending it to my path, but I don't know if
>> >> > this
>> >> > naming scheme is guaranteed by CMake or if it will change in the
>> >> > future.
>> >> >
>> >> it differs from generator to generator
>> >>
>> >> > --
>> >> >
>> >> > 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
--

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] Separate compiler and linker pdb

[Yuri Timenkov]

This is a limitation of CMake. There is a discussion at
http://public.kitware.com/Bug/view.php?id=11899

On Tue, Jun 19, 2012 at 7:57 PM, Michele Santullo
 wrote:
> Hello, we recently converted our project to cmake but for some reason, as we
> generate for VS 2008 on Windows, we get the same path for both the compiler
> and the linker generated pdb files.
>
> The path is something like /bin/Debug/Project.pdb for both, so they
> overwrite each other causing various errors. If I pass the /Fd switch to the
> compiler, cmake just keeps the old path and appends the new one to the
> command line parameters, confusing the VS IDE and causing a full rebuild
> every time we build.
>
> Is there a solution to produce two different files?
> Could it be caused by some error in my cmake files? The only settings about
> paths I can think of are:
>
> set( CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/../bin )
> set( CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/../lib )
>
> if(MSVC)
>        set(PDB_SEARCH_PATHS "/PDBPATH")
>        SET(LNK_FLAGS_DEBUG "${LNK_FLAGS_DEBUG} ${PDB_SEARCH_PATHS}")
>        SET(LNK_FLAGS_RELEASE "${LNK_FLAGS_RELEASE} ${PDB_SEARCH_PATHS}")
>        SET(LNK_FLAGS_SHIPPING "${LNK_FLAGS_SHIPPING} ${PDB_SEARCH_PATHS}")
> endif(MSVC)
>
> Thanks,
> Michele
> --
>
> 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] different assemblers in single build?

[Yuri Timenkov]

Hi,

You should have either 2 build trees or use custom commands.
If you have a lot of files you should go first way.
To ease development you may compile other tree using external project.
Unfortunately external project is not rebuilt if its sources changed. You
have to do it manually.

On Fri, May 11, 2012 at 8:12 PM, Alexey Istomin  wrote:

> Hi all,
>
> Is it possible to use different assemblers in single build with CMake?
>
> I try to use CMake for building embedded application - statically linked
> elf file.
> Main CPU has 2 cores: general-purpose MIPS based core and DSP. Project has
> simple structure: main dir contains asm and C sources for Mips core,
> dsp-lib subdir has only asm sources for DSP core:
>
> main/
>crt0-mips.s
>main.c
>...
>dsp-lib/
>fft.s
>
>
> GCC compiler and assembler are used for Mips sources, special assembler
> (dspasm) based on gnu should be used for DSP. Main should be linked with
> dsp lib into single elf file.
> I can successfully build main app without dsp-lib. But when I try to add
> dsp-lib subdir and set dspadm as assembler, CMake still uses mips-asm in
> the dsp-lib. Is it any solution?
>
> Thanks a lot
> Alex
> --
>
> 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] include_external_msproject for MS Visual Studio *.csproj

[Yuri Timenkov]

This is because CMake generates invalid GUIDs in solution (these GUIDs are
for C++ project).

There is a bug report with patch on CMake bug tracker:
http://www.cmake.org/Bug/view.php?id=9742 but it seems C# is not very
interesting for CMake developers (complete C# support requires much more
effort).

The only way to build C# projects at the moment is to use custom commands
or targets (may be via ExternalProject script).

On Sat, Mar 31, 2012 at 2:05 AM, Valentine S.  wrote:

> I have several C++ projects (library, tests, examples) for Linux and
> Windows. This projects are generated by CMake (Makefile for Linux, *.vcproj
> for Windows MS Visual Studio). And I have C++/CLI (C++ library wrapper) and
> C# projects (tests, examples). This projects are written in MS Visual
> Studio and used on Windows platform only. I can include external MS C++/CLI
> project (*.vcxproj) to generated solution file (*.sln) using command
> "include_external_msproject". But I cannot include MS C# project (*.csproj)
> to generated solution. How can I do that? When will you
> implement "include_external_msproject" for *.csproj 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
>
--

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 presentation/tutorial in Toulouse/France (8thFebruary)

[Yuri Timenkov]

I did the same. And besides being a good CMake tutorial this is also
awesome example how to make presentations with Latex :)
Thanks for sharing sources.

On Fri, Feb 10, 2012 at 4:03 AM,  wrote:

> I went through the slides; pretty good introduction-intermediate
> presentation.  I'm forwarding it to all the teams I work with here!
>
> Aaron Meadows
>
>
> -Original Message-
> From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
> Of Eric Noulard
> Sent: Thursday, February 09, 2012 3:26 PM
> To: CMake ML
> Subject: Re: [CMake] CMake presentation/tutorial in Toulouse/France
> (8thFebruary)
>
> 2012/1/29 Eric Noulard :
> > Hi All,
> >
> > Just a small advertisement.
> > I will be giving a CMake presentation & tutorial in Toulouse/France on
> > February 8th, 2012:
> >
> > http://www.toulibre.org/evenements_a_venir
> > "À 20h00 Éric Noulard présentera CMake, outil de compilation et de
> > test multi-plateforme. "
> > Presentation will be given in French.
>
> This is done and it was nice (at least from my side)
>
> The slides (in english) are here:
> http://noulard.name/CMake/CMake-tutorial-8feb2012.pdf
>
> The material I used for making the presentation is available here:
> http://noulard.name/CMake/CMake-tutorial-8feb2012.tar.bz2
>
> and may be cloned/forked from github as well:
> https://github.com/TheErk/CMake-tutorial
>
> feel free to re-use/improve it.
>
> --
> 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
>
> This email was sent to you by Thomson Reuters, the global news and
> information company. Any views expressed in this message are those of the
> individual sender, except where the sender specifically states them to be
> the views of Thomson Reuters.
> --
>
> 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] Under Visual Studio , allow developers to hit "F7" to run the INSTALL target

[Yuri Timenkov]

I use a special macro for such purposes, something like this:
Sub Install()
Dim prj As Project
Dim sb As SolutionBuild = DTE.Solution.SolutionBuild
Dim prjs As Projects = DTE.Solution.Projects

For Each prj In prjs
If prj.Name = "INSTALL" Then
sb.BuildProject(sb.ActiveConfiguration.Name, prj.UniqueName)
Exit For
End If
Next
End Sub

Good thing is that you can put it on toolbar or bind to hot key and run it
separately (while keeping active project you're debugging).

On Tue, Feb 7, 2012 at 11:47 PM,  wrote:

> Developers on our team have found issues with the difference between
> “INSTALL” and the default build or “F7” build all under Visual Studio.  My
> question is, there’s a reasonable way to configure cmake or Visual Studio
> to run the INSTALL target when you hit “F7” or use the default “Build
> Solution” functionality to run INSTALL.
>
> ** **
>
> We’re working a fairly large project and the default setting of having
> INSTALL dependent on ALL or separating out the two targets makes sense when
> you’re building the entire project.
>
> ** **
>
> However, we allow developers to build sub projects and it makes sense if
> these sub project just install quickly into a larger pre-built installation
> directory.  The confusion currently is, they run ALL_BUILD or “F7” and the
> build finishes and they forget to run “INSTALL”.Particularly we, had
> developers that worked formally on smaller non-Cmake Visual Studio projects
> and not Linux so, they’re not used to the make all and then make install
> defacto standard.
> This request is similar as the following on “Selecting INSTALL target in
> Visual Studio Configuration by default”  but, I wanted to see if anyone had
> any other suggestions on this topic.
>
> http://www.cmake.org/pipermail/cmake/2011-April/044025.html
>
> ** **
>
> ++David->Bjornbak;
>
> ** **
>
> --
>
> 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] How to use CMake with icc via configuration options when needing interprocedural optimization?

[Yuri Timenkov]

I think this could work, but if compiler is altered before project() call
(but I didn't check this and suggest set variable only if it's not already
set). Specifying only one variable  in command line looks more
user-friendly and robust than several ones.
Anther option is using initial cache.

Regards,
Yuri

On Wed, Feb 8, 2012 at 12:59 AM, Alexander Neundorf  wrote:

> Hi Janitor,
>
> On Tuesday 07 February 2012, janitor 048 wrote:
> > Hello,
> >
> > this is a question I recently asked on stackoverflow (
> >
> http://stackoverflow.com/questions/9129233/recommended-ways-to-use-cmake-wi
> > th-icc-via-configuration-options) but that has not received any response
> > since then. Maybe this mailing list is a better place to ask... Here goes
> >
> > I would like to use the Intel compiler icc (or icpc) with a CMake-based
> > project (on Linux for what it's worth). I can of course export the CXX
> > variable when calling cmake, e.g. like
> >
> > CXX=icpc cmake ../
> >
> > and this works fine. I would however like to make this choice available
> via
> > a custom option. For this I parse custom option, e.g.
> >
> > cmake -DMY_COMPILER_OPTION=Intel ..
> >
> > as
> >
> > IF (MY_COMPILER_OPTION STREQUAL "Intel")
> >   MESSAGE(STATUS "** Compiling with Intel settings **")
> >   SET(CMAKE_CXX_COMPILER "icpc")
> >   SET(CMAKE_CXX_FLAGS_RELEASE "-O3 -w")
> >   SET(CMAKE_CXX_FLAGS_DEBUG "-g")
> > ENDIF ()
>
> Don't do that, this is too late in the initialization process.
> The recommended way is to set the CXX environment variable. This is only
> necessary during the initial cmake run, afterwards this is stored in the
> cmake
> cmake cache.
> It should also work to preset the compiler variables:
> cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc 
>
> (I didn't check, but it should work).
>
> Alex
> --
>
> 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] Compile flag issues and VS Express

[Yuri Timenkov]

I can assume that 10M stack is reasonable for C code, where it's usual to
allocate temporary buffers on stack (in C++ it's easier to use heap, e.g.
using std::vector).

Bad thing is - impact of this flag is detected only at run time. If with
/Zm your code just won't compile, with /STACK everything compiles and links
perfectly, works fine in simple cases, but you'll receive OOM under load
(in C, when stack will be over).
That's why I didn't insist on changing behavior when found this bug 3 years
ago.

On Tue, Jan 31, 2012 at 8:02 PM, Glenn Coombs wrote:

> On a related note:
>
> http://www.gccxml.org/Bug/view.php?id=12437
>
> can you check if ITK and VTK build fine without the large stack size
> argument (/STACK:1000) as well ?
>
> --
> Glenn
>
>
> On 30 January 2012 15:58, Bill Lorensen  wrote:
>
>> ITK and VTK both build fine if I remove the /Zm1000 flag.
>>
>> On Mon, Jan 30, 2012 at 10:44 AM, Bill Hoffman 
>> wrote:
>> > On 1/28/2012 10:51 AM, David Cole wrote:
>> >>
>> >> Seems reasonable. Is anybody worried that changing the default values
>> >> of these flags would have a negative impact on any projects out there?
>> >> (i.e. is it likely that anybody relies on these flags being present
>> >> and that would somehow break their build without them...? I don't
>> >> think it's likely, but I'm willing to discuss before making a change
>> >> in CMake)
>> >
>> >
>> > They were originally put in for VTK/ITK.  They would be the projects to
>> try.
>> >
>> > -Bill
>> >
>> >
>> > --
>> >
>> > 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
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot 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
>>
>
>
> --
>
> 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] Compile flag issues and VS Express

[Yuri Timenkov]

Don't know about 2010 Express, but IIRC there were problems (at least in
previous VS versions) with compiling code with a lot of templates (like
spirit, xpressive or MPL from boost). So compiler asks to increase heap
size.

Anyways, in our projects I always reset CMake's default compile flags: this
is essential during migration from plain projects but proves useful anyways.

On Sat, Jan 28, 2012 at 7:51 PM, David Cole  wrote:

> On Sat, Jan 28, 2012 at 9:02 AM, Bill Lorensen 
> wrote:
> > Folks,
> >
> > I'm using VS 2010 Express.
> >
> > When ever I build a VTK or ITK related app I get errors regarding
> > virtual memory and warnings about deprecated compiler flags:
> > use 'EHsc' instead of 'GX'
> >
> > I always have to remove the /Zm1000 flag and add the /EHsc flag.
> >
> > I assumed this was do to something screwed up in my installation.
> >
> > Doing a web search for this issue, I found several other people having
> > similar issues. Try this search:
> > visual studio express 2010 /zm1000
> >
> > At Second Life,
> > http://wiki.secondlife.com/wiki/Microsoft_Windows_Builds they advise
> > editing the Windows-cl.cmake file to solve the problem.
> >
> > Is there a reason this cannot be fixed in cmake?
> >
> > Bill
> >
> >
> >
> > --
> > Unpaid intern in BillsBasement at noware dot 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
>
>
> Seems reasonable. Is anybody worried that changing the default values
> of these flags would have a negative impact on any projects out there?
> (i.e. is it likely that anybody relies on these flags being present
> and that would somehow break their build without them...? I don't
> think it's likely, but I'm willing to discuss before making a change
> in CMake)
>
>
> Thx,
> 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
>
--

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] Creating the resource-only dll with NMake

[Yuri Timenkov]

Unfortunately, as I can understand from sources this can't be done in
current CMake version. Only preprocessor definitions are supported.

On Tue, Jan 17, 2012 at 10:20 AM, Kozlovskiy, Alexey
 wrote:
> Thanks for support!
> I specified the SET_TARGET_PROPERTIES (${PROJECT_NAME} PROPERTIES 
> LINKER_LANGUAGE "CXX" ) and error was disappear.
>
> Another question is: How to specify the "Culture" properties? In the VS it 
> could be find in the Property Pages -> Resources -> General -> Culture
> Thanks again!
>
> Regards,
> Alexey
>
> -Original Message-
> From: Yuri Timenkov [mailto:y...@timenkov.ru]
> Sent: Tuesday, January 17, 2012 7:28 AM
> To: Kozlovskiy, Alexey
> Cc: cmake@cmake.org
> Subject: Re: [CMake] Creating the resource-only dll with NMake
>
> Won't it work if you set target's linker language to C or C++? I suppose it's 
> a LINKER_LANGUAGE property.
>
> On Mon, Jan 16, 2012 at 6:17 PM, Kozlovskiy, Alexey 
>  wrote:
>>
>> Hi,
>>
>>
>>
>> I tried to create a simple CMake project to assemble a resource only dll. My 
>> CMakeList.txt file:
>>
>> cmake_minimum_required(VERSION 2.8)
>>
>> set (PROJECT_NAME viewerResDLL)
>>
>> project ( ${PROJECT_NAME} )
>>
>> set ( SRCS_MAIN
>>
>>    viewerres_en.rc
>>
>>    )
>>
>> set ( HDRS_MAIN
>>
>>    resource.h
>>
>>    )
>>
>> add_library ( ${PROJECT_NAME} SHARED ${SRCS_MAIN} ${HDRS_MAIN} )
>>
>> SET_TARGET_PROPERTIES (${PROJECT_NAME} PROPERTIES LINK_FLAGS
>> "/MANIFEST:NO /NODEFAULTLIB /NOENTRY" )
>>
>>
>>
>> I execute CMake with the following flags:
>>
>> cmake -DCMAKE_BUILD_TYPE=Release -G"NMake Makefiles"
>>
>>
>>
>> and receive the following error:
>>
>> -- Configuring done
>>
>> CMake Error: Error required internal CMake variable not set, cmake may be 
>> not be built correctly.
>>
>> Missing variable is:
>>
>> CMAKE_RC_CREATE_SHARED_LIBRARY
>>
>> -- Generating done
>>
>>
>>
>> “Nmake all” command finished without any errors, but in the same time 
>> without any results - viewerResDLL.dll not created.
>>
>> If I use the “Visual Studio 9 2008 Win64” generator all looks working
>> correct and I’m able to build viewerResDLL.dll
>>
>>
>>
>> Any help will be very appreciated…
>>
>> Thanks!
>>
>>
>>
>> Regards,
>>
>> Alexey
>>
>>
>>
>>
>> --
>>
>> 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] Creating the resource-only dll with NMake

[Yuri Timenkov]

Won't it work if you set target's linker language to C or C++? I
suppose it's a LINKER_LANGUAGE property.

On Mon, Jan 16, 2012 at 6:17 PM, Kozlovskiy, Alexey
 wrote:
>
> Hi,
>
>
>
> I tried to create a simple CMake project to assemble a resource only dll. My 
> CMakeList.txt file:
>
> cmake_minimum_required(VERSION 2.8)
>
> set (PROJECT_NAME viewerResDLL)
>
> project ( ${PROJECT_NAME} )
>
> set ( SRCS_MAIN
>
>    viewerres_en.rc
>
>    )
>
> set ( HDRS_MAIN
>
>    resource.h
>
>    )
>
> add_library ( ${PROJECT_NAME} SHARED ${SRCS_MAIN} ${HDRS_MAIN} )
>
> SET_TARGET_PROPERTIES (${PROJECT_NAME} PROPERTIES LINK_FLAGS "/MANIFEST:NO 
> /NODEFAULTLIB /NOENTRY" )
>
>
>
> I execute CMake with the following flags:
>
> cmake -DCMAKE_BUILD_TYPE=Release -G"NMake Makefiles"
>
>
>
> and receive the following error:
>
> -- Configuring done
>
> CMake Error: Error required internal CMake variable not set, cmake may be not 
> be built correctly.
>
> Missing variable is:
>
> CMAKE_RC_CREATE_SHARED_LIBRARY
>
> -- Generating done
>
>
>
> “Nmake all” command finished without any errors, but in the same time without 
> any results - viewerResDLL.dll not created.
>
> If I use the “Visual Studio 9 2008 Win64” generator all looks working correct 
> and I’m able to build viewerResDLL.dll
>
>
>
> Any help will be very appreciated…
>
> Thanks!
>
>
>
> Regards,
>
> Alexey
>
>
>
>
> --
>
> 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] does CMake have "usage targets" like Premake?

[Yuri Timenkov]

if i understand correctly it's CMake's find_package analog.

On Jan 16, 2012 10:41 AM, "Lance Luvaul"  wrote:

> See http://sourceforge.net/**tracker/index.php?func=detail&**
> aid=2794681&group_id=71616&**atid=531880for
>  more detail on what constitutes a usage-target.   How can I achieve the
> same result in CMake?  Thanks.
> --
>
> 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] ExternalProject and clean targets

[Yuri Timenkov]

IIRC for Visual Studio I had opposite problem: clean on external project
didn't triggered rebuild.

On Sat, Oct 15, 2011 at 2:34 PM, David Cole  wrote:

> On Sat, Oct 15, 2011 at 3:48 AM, Michael Hertling 
> wrote:
> > On 10/12/2011 10:22 PM, Lori Pritchett-Sheats wrote:
> >>
> >> I'm building external packages in my CMake system using the
> >> ExternalPackages_Add function. When a package is built this way and I
> >> execute a 'make clean' at the top of my build tree,  all targets are
> >> cleaned including the external packages. Is there a way to remove the
> >> external package targets from the the default clean target?
> >
> > The following exemplary project does not exhibit this behavior:
> >
> > # CMakeLists.txt:
> > CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> > PROJECT(CLEAN C)
> > SET(CMAKE_VERBOSE_MAKEFILE ON)
> > INCLUDE(ExternalProject)
> > ExternalProject_Add(external
> >SOURCE_DIR ${CMAKE_SOURCE_DIR}/external
> >CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=)
> > FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
> > ADD_EXECUTABLE(main main.c)
> > ADD_DEPENDENCIES(main external)
> > INSTALL(TARGETS main DESTINATION bin)
> >
> > # external/CMakeLists.txt:
> > CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> > PROJECT(EXTERNAL C)
> > SET(CMAKE_VERBOSE_MAKEFILE ON)
> > FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")
> > ADD_LIBRARY(f SHARED f.c)
> > INSTALL(TARGETS f DESTINATION lib)
> >
> > After configuring and building:
> >
> > % ls main external-prefix/src/external-build/libf.so
> > external-prefix/src/external-build/libf.so  main
> >
> > After "make clean" in CMAKE_BINARY_DIR:
> >
> > % ls main external-prefix/src/external-build/libf.so
> > ls: cannot access main: No such file or directory
> > external-prefix/src/external-build/libf.so
> >
> > The top-level project's target is gone whereas the external project's
> > one is intact, and [1] reports the same, i.e. the opposite of your
> > concern. Thus, could you boil down your issue to a minimal but
> > self-contained example for further investigation?
> >
> > Regards,
> >
> > Michael
> >
> > [1] http://www.mail-archive.com/cmake@cmake.org/msg35411.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
> >
>
> When Lori said "all targets are cleaned including the external
> packages" I think she meant that she would like the ExternalProject
> stamp files to remain intact across a "clean" such that the
> ExternalProject steps do not re-execute on the next make. Is that
> indeed what you meant, Lori?
>
> If so, I do not know of an easy way to achieve that goal.
>
> One thing that comes to mind is separating out the parts that you
> don't want to re-build after a clean into a separate project, and
> build/[install] that into a place where you can reference the
> built/installed products from a second project in which you frequently
> 'clean'...
>
> Another alternative would be to avoid the top-level clean altogether,
> and simply go down into an individual external project's build tree
> and do the make clean in there so as to only clean the individual
> project you're immediately working with.
>
> I've frequently thought we should cache/share ExternalProject builds
> across other multiple builds that could reference them but I
> hesitate to put legs on that idea because of possibly introducing easy
> ways to create giant tangled messes of projects with incompatible
> compiler/linker flags. It's worth keeping on the idea pile, though,
> and a motivated individual could certainly already achieve this by
> placing the build/install products of ExternalProject_Add calls in
> shared locations (i.e., in the HOME directory instead of as
> sub-directories of the present build tree).
>
>
> 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
>
--

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] Bug fix requests for the *next* release of CMake...

[Yuri Timenkov]

Hi David,

Please add http://public.kitware.com/Bug/view.php?id=9742 to road map.
At least part which generates proper GUIDS for different projects (I'm
especially interested into including C# projects).

Thanks,
Yuri

On Fri, Oct 21, 2011 at 10:20 PM, David Cole  wrote:

> As an esteemed colleague has pointed out, those with "reporter" level
> account in Mantis may not edit bugs other than their own directly.
> So. if you are in that boat, but would like to vote for a bug fix
> to be considered for 2.8.7, please reply to this thread, and just list
> the bug number, or a URL linking to its bug tracker page.
>
> I will follow the replies to this thread and add those bugs to the
> roadmap as they roll in.
>
>
> Thanks,
> David C.
>
>
> On Fri, Oct 21, 2011 at 12:19 PM, David Cole 
> wrote:
> > Hi all,
> >
> > *NO* replies requested. Different technique this time. Please edit the
> > bug tracker directly. (Unless you have problems with the bug tracker:
> > if so, please feel free to reply here with your suggestions.)
> >
> > We are planning for CMake 2.8.7, aiming for a December release. We're
> > targeting Dec. 28, 2011 for releasing it, and in order to make that
> > happen we'll have to do an "rc1" by Dec. 7th or so... about 7 weeks
> > from now.
> >
> > If you have a particular issue that you think should be fixed for
> > inclusion in 2.8.7, please put it on the roadmap yourself by the end
> > of next week, Fri. Oct. 28th. To do so, edit the bug at
> > http://public.kitware.com/Bug and set the "Target Version" field to
> > "CMake 2.8.7" - that will make it appear on the roadmap page (
> > http://www.cmake.org/Bug/roadmap_page.php?version_id=89 ). Also: add a
> > note saying why it's important to you, or even add a patch that fixes
> > and documents and tests it if you're able to.
> >
> > Ideally, each issue will be discussed as needed on the mailing list to
> > come to any consensus about what should be done to fix it, and then
> > the entry in the bug tracker may be used to keep it on the radar
> > screen, and to track activity related to it.
> >
> > Patches are *always* welcome. Patches that include testing of any new
> > features, or tests that prove a bug is really fixed on the dashboards
> > are better: a patch with testing is strongly preferred over a patch
> > with no testing. Also, if you are *adding* code, then you also
> > probably need to add *tests* of that code, so that the coverage
> > percentage stays as is or rises.
> >
> > Please discuss issues here on the mailing list as needed, and add
> > notes to existing issues in the bug tracker that you are interested in
> > seeing fixed for 2.8.7 -- we will be looking at activity both on the
> > mailing list and in the bug tracker to help prioritize the bug fixes
> > for the next couple months.
> >
> >
> > Thanks,
> > David Cole
> > Kitware, Inc.
> >
> >
> > P.S. - as a nice summary of what we accomplished in the CMake 2.8.6
> > release, including contributions from 27 individuals around the world,
> > see here: http://public.kitware.com/Bug/changelog_page.php?version_id=87
> > -- it currently lists 43 issues that we resolved: nice job, everybody!
> >
> > (Many of those were specifically addressed because somebody brought it
> > up in response to my similar email from just after 2.8.5... Don't be
> > shy!)
> >
> --
>
> 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] Curious build output

[Yuri Timenkov]

It's because VS2010 uses msbuild to build C++ projects. You can modify
verbosity level in settings menu: Tools > Options > Projects and Solutions >
Build and Run > MSBuild project build output verbosity

On Wed, Oct 5, 2011 at 10:49 PM, James Bigler  wrote:

> What is this extra chatty output from?  I never remember seeing it in VS
> 2008, but I see it in VS 2010.
>
> >-- Build started: Project: copy_scripts, Configuration: Release x64
> --
> 1>Build started 10/5/2011 12:38:07 PM.
> 1>InitializeBuildStatus:
> 1>  Creating "x64\Release\copy_scripts\copy_scripts.unsuccessfulbuild"
> because "AlwaysCreate" was specified.
> 1>FinalizeBuildStatus:
> 1>  Deleting file
> "x64\Release\copy_scripts\copy_scripts.unsuccessfulbuild".
> 1>  Touching "x64\Release\copy_scripts\copy_scripts.lastbuildstate".
> 1>
> 1>Build succeeded.
>
> 3>-- Build started: Project: ALL_BUILD, Configuration: Release x64
> --
> 3>Build started 10/5/2011 12:38:08 PM.
> 3>InitializeBuildStatus:
> 3>  Creating "x64\Release\ALL_BUILD\ALL_BUILD.unsuccessfulbuild" because
> "AlwaysCreate" was specified.
> 3>CustomBuild:
> 3>  Build all projects
> 3>FinalizeBuildStatus:
> 3>  Deleting file "x64\Release\ALL_BUILD\ALL_BUILD.unsuccessfulbuild".
> 3>  Touching "x64\Release\ALL_BUILD\ALL_BUILD.lastbuildstate".
> 3>
> 3>Build succeeded.
>
> I'm using VS 2010 and CMake 2.8.6 (2.8.5 also did this).
>
> When I click "build solution" it always seems to run this, as if VS thinks
> that the dependencies aren't met and decides to build it.
>
> Hmm... I wonder if this is related to the bug where we removed the
> %(Outputs) from the Outputs field.
>
>
> C:/code/rtsdk/rtmain/build-64-vs10-c40/tests/Regression/scripts/CMakeFiles/copy_scripts.rule;C:\code\rtsdk\rtmain\build-64-vs10-c40\bin\correctness.rb;C:\code\rtsdk\rtmain\build-64-vs10-c40\bin\performance.rb;C:\code\rtsdk\rtmain\build-64-vs10-c40\bin\run_tests.rb;C:\code\rtsdk\rtmain\build-64-vs10-c40\bin\test_cases.rb;%(AdditionalInputs)
>
> I removed the $(AdditionalInputs), and that didn't seem to make a
> difference.
>
> One thing that is curious is that I have this for the Outputs field, but
> that doesn't exist anywhere:
>
> C:\code\rtsdk\rtmain\build-64-vs10-c40\tests\Regression\scripts\CMakeFiles\copy_scripts
>
> How is it that we have a build rule that says it generates a particular
> output, but the output isn't generated by the rule.
>
> This is what I used to create this target:
>
> foreach( script ${scripts} )
>   set( src  "${CMAKE_CURRENT_SOURCE_DIR}/${script}" )
>   set( dest "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${script}" )
>   list( APPEND dest_files "${dest}" )
>   add_custom_command(
> OUTPUT "${dest}"
> COMMAND ${CMAKE_COMMAND} -E copy "${src}" "${dest}"
> MAIN_DEPENDENCY "${src}"
> COMMENT "Copying ${src} to ${dest}"
> VERBATIM
>   )
> endforeach()
>
> add_custom_target( copy_scripts
>   ALL
>   DEPENDS ${dest_files}
>   )
>
> Note that I have the same problem with the ALL_BUILD target.
>
> James
>
> --
> 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] Fwd: Save stripped debugging information

[Yuri Timenkov]

Hi Michael,

On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling wrote:

> On 10/01/2011 10:07 AM, Yuri Timenkov wrote:
> > that's the problem: you don't know neither file name nor it's location,
> > especially in multi-configuration generators.
>
> You *do* know a debug file's name and location, either because you must
> generate it explicitly (objcopy approach) or via the concerned target's
> $ generator expression in custom targets/commands
> (Visual approach). Otherwise, a debug file with unknown name and/or
> location would be rather useless.
>
I'm sorry that you misunderstood me, but I was concerned about install()
commands.

CMake already does a lot of things to make different platforms and
generators work in same way. As it was noted before, install already knows
about such subtleties between generators and platforms like export
libraries. So why not make it aware of separate debug information?

Adding objcopy/whatever to separate debug information to out-of-box CMake is
just one more step to unifying different platforms and generators.
Basically, in Makefile generator there are a lot of things that VS provides
from GUI (fast build, compile only file).

Of course it should be controlled through policy, property or variable to
keep backward compatibility.


> W.r.t. a debug file's installation, one must currently take generator-
> specific measures: Either generate the file at all (objcopy approach)
> or copy it to a configuration-independent location (Visual approach).
> This might be considered as annoying, but it can be easily achieved
> with CMake's present means, so I'm not fully aware of the actual
> problem we're discussing ATM.
>
> > It's also bad idea to mix build and install steps. [...]
>
> Absolutely.
>
> > [...] Install command doesn't
> > understand generators expressions.
>
> Regarding files that
>
> - should be installed,
> - are not target binaries,
> - are put in configuration-specific locations,
>
> it would be handy to have generator expressions available in
> the INSTALL() command; perhaps; that's worth a feature request.
>
> > If it were possible to emulate vs behavior for gcc things would be much
> > easier in some cases. [...]
>
> In which cases?
>
install debug into separate location for further usage, like generating
"runtime" and "devel" packages. The third one is "debug".


>
> > [...] However extracting debug info from binaries is
> > performed by packager (at least rpmbuild does this)
>
> Sometimes - or quite often, as the case may be - packages are installed
> without any packager's ado, and with a simple tar archive, e.g., you'll
> be out of luck, too, so one shouldn't rely on a packager's capabilities
> when it comes to the extraction of debug information or the like, IMO.
>
Yes, in proprietary software there are no packagers, so it is essential to
have an option to keep debug information after the build. I think that's
exactly why this question arose.

>
> Regards,
>
> Michael
>
> > On Oct 1, 2011 8:09 AM, "Michael Hertling"  wrote:
> >> On 09/30/2011 08:39 AM, Rolf Eike Beer wrote:
> >>>> On 09/29/2011 06:15 AM, Yuri Timenkov wrote:
> >>>>> When I was investigating similar problem, I found alternative
> approach
> >>>>> at
> >>>>>
> http://code.google.com/p/dynamorio/source/browse/trunk/CMakeLists.txt.
> >>>>>
> >>>>> The thing is to change linker rules, to something like this:
> >>>>> set(CMAKE_C_CREATE_SHARED_LIBRARY
> >>>>> # standard rule
> >>>>> " 
> >>>>>  
> >>>>> 
> >>>>>  -o 
> >>>>> 
> >>>>> "
> >>>>> # now create a .debug copy
> >>>>> "${CMAKE_OBJCOPY} --only-keep-debug  .debug"
> >>>>> # link original to point at .debug copy
> >>>>> # directory components are removed, so "../lib/" is fine
> >>>>> "${CMAKE_OBJCOPY} --add-gnu-debuglink=.debug "
> >>>>> # Strip all information from target binary.
> >>>>> "${CMAKE_STRIP} --strip-debug --discard-all --preserve-dates
> >>>>> "
> >>>>> )
> >>>>>
> >>>>> I don't exactly remember benefits from this approach but it kind of
> >>>>> works.
> >>>>
> >>>> The benefits are that one needs to define these rule variables once as
> >>>> 

Re: [CMake] Fwd: Save stripped debugging information

[Yuri Timenkov]

that's the problem: you don't know neither file name nor it's location,
especially in multi-configuration generators.
It's also bad idea to mix build and install steps. Install command doesn't
understand generators expressions.

If it were possible to emulate vs behavior for gcc things would be much
easier in some cases. However extracting debug info from binaries is
performed by packager (at least rpmbuild does this)

On Oct 1, 2011 8:09 AM, "Michael Hertling"  wrote:
> On 09/30/2011 08:39 AM, Rolf Eike Beer wrote:
>>> On 09/29/2011 06:15 AM, Yuri Timenkov wrote:
>>>> When I was investigating similar problem, I found alternative approach
>>>> at
>>>> http://code.google.com/p/dynamorio/source/browse/trunk/CMakeLists.txt.
>>>>
>>>> The thing is to change linker rules, to something like this:
>>>> set(CMAKE_C_CREATE_SHARED_LIBRARY
>>>> # standard rule
>>>> " 
>>>>  
>>>> 
>>>>  -o 
>>>> 
>>>> "
>>>> # now create a .debug copy
>>>> "${CMAKE_OBJCOPY} --only-keep-debug  .debug"
>>>> # link original to point at .debug copy
>>>> # directory components are removed, so "../lib/" is fine
>>>> "${CMAKE_OBJCOPY} --add-gnu-debuglink=.debug "
>>>> # Strip all information from target binary.
>>>> "${CMAKE_STRIP} --strip-debug --discard-all --preserve-dates
>>>> "
>>>> )
>>>>
>>>> I don't exactly remember benefits from this approach but it kind of
>>>> works.
>>>
>>> The benefits are that one needs to define these rule variables once as
>>> they're inherited by the subdirectories. The downside is that the rule
>>> variables are used by Makefile generators only, whereas the target-
>>> associated custom commands are a more generic approach.
>>>
>>>> And I agree that functionality like installing debug symbols in
>>>> install()
>>>> rules out of box would be quite handy.
>>>
>>> INSTALL() is essentially about copying files and directories, so it
>>> doesn't depend on the toolchain; in particular, you can use INSTALL()
>>> for projects which are configured with PROJECT(... NONE), i.e. without
>>> any toolchain. By contrast, extracting debug symbols does highly depend
>>> on the toolchain, e.g. the objcopy(1) utility isn't mentioned in POSIX,
>>> and even with the GNU tools, you have multiple possibilities to connect
>>> the stripped binary with the unstripped one, note --add-gnu-debuglink
>>> vs. build IDs. Windows and MacOSX will further enrich this entire zoo
>>> of utilities and command line switches, not to mention toolchains for
>>> specific platforms. So, opening and parameterizing INSTALL() - w.r.t.
>>> its interface and its implementation - in order to provide reasonable
>>> support for the extraction of debug symbols during installation is a
>>> major undertaking, IMO, besides the conceptional issue of toolchain-
>>> dependence.
>>
>> The idea was not to generate those during install, but to be able to let
>> them being installed. For e.g. MSVC you don't have anything to do, the
>> linker will already generate the PDB file already. So all you would have
>> to do would be to copy the generated debug file to the proper place. This
>> whish comes from the fact that for multi-configuration generators you
>> don't know which configuration is active so you don't know where to
search
>> the PDB file. And INSTALL() and ADD_CUSTOM_TARGET()/_COMMAND() don't
>> understand generator expressions.
>
> INSTALL() doesn't, but ADD_CUSTOM_TARGET/COMMAND() are right the two
> commands which *do* understand generator expressions. As long as you
> know the location of the debug files relative to the location of the
> concerned target's binary, the $ expressions
> should do the trick. So, the worst case you might suffer is that you
> must use a custom target/command to copy or move the debug files to
> a suitable location in order to apply INSTALL(FILES ...) on them in
> the end. IMO, that's bearable; does it not work for you? However,
> adding generator expressions to the INSTALL() command might be
> worth a thought.
>
>> So my idea would be to generate the debug file during or after the link
>> step and save the position to this file somewhere internally, so
>> INSTALL(... DEBUG_SYMBOLS) would know which to take. Or to do just
nothing
>> if we do not su

Re: [CMake] Fwd: Save stripped debugging information

[Yuri Timenkov]

When I was investigating similar problem, I found alternative approach at
http://code.google.com/p/dynamorio/source/browse/trunk/CMakeLists.txt.

The thing is to change linker rules, to something like this:
set(CMAKE_C_CREATE_SHARED_LIBRARY
# standard rule
" 
  
 -o  
"
# now create a .debug copy
"${CMAKE_OBJCOPY} --only-keep-debug  .debug"
# link original to point at .debug copy
# directory components are removed, so "../lib/" is fine
"${CMAKE_OBJCOPY} --add-gnu-debuglink=.debug "
# Strip all information from target binary.
"${CMAKE_STRIP} --strip-debug --discard-all --preserve-dates
"
)

I don't exactly remember benefits from this approach but it kind of works.

And I agree that functionality like installing debug symbols in install()
rules out of box would be quite handy.

Regards,
Yuri

On Sat, Sep 24, 2011 at 4:02 AM, Michael Hertling wrote:

> On 09/22/2011 01:24 PM, Rolf Eike Beer wrote:
> >> Il 22/09/2011 10.13, Rolf Eike Beer ha scritto:
>  Yeah, that's exactly what I had in mind. Any chance that we will see
>  this in a future release?
> >>> This is usually "find someone who does it and writes tests for it".
> >>> Which
> >>> then boils down to find someone who has enough knowledge and spare time
> >>> to
> >>> do or someone that needs it and is willing to pay Kitware for doing it.
> >
> >> Why don't you invoke ${CMAKE_OBJCOPY} as a post build command?
> >
> > That would be a way to _get_ these debug symbol files, but not a clean
> way
> > to _install_ them. And the other reason is that this variable doesn't
> show
> > up in any CMake documentation.
> >
> > Eike
>
> In order to take up Andrea's suggestion for Lukas' concern:
>
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> PROJECT(DEBUGINFO C)
> SET(CMAKE_VERBOSE_MAKEFILE ON)
> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
> ADD_EXECUTABLE(main main.c)
> FIND_PROGRAM(OBJCOPY objcopy)
> ADD_CUSTOM_COMMAND(TARGET main POST_BUILD
>COMMAND ${OBJCOPY} --only-keep-debug
>$ ${CMAKE_BINARY_DIR}/main.dbg
>COMMAND ${OBJCOPY} --strip-debug
>$
>COMMAND ${OBJCOPY} --add-gnu-debuglink=main.dbg
>$
> )
> INSTALL(TARGETS main RUNTIME DESTINATION bin)
> INSTALL(FILES ${CMAKE_BINARY_DIR}/main.dbg DESTINATION bin)
>
> This exemplary project simply follows objcopy's manpage
> w.r.t. the --only-keep-debug switch and works on *nix.
> Does it not work for you, or is it not clean enough?
>
> 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] Setting RuntimeLibrary tag on Visual Studio 10

[Yuri Timenkov]

These flags should work. If you specify them, CMake automatically translates
them into appropriate XML tags. At least 2.8.5 and 2.8.4 work well.

On Tue, Sep 20, 2011 at 1:16 PM, Perry Ismangil  wrote:

> Hi,
>
> I've read
>
>
> http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F
>
> which seems to do what I want to which is have 4 configurations one
> for each: MT, MTd, MD, MDd.
>
> However using flags doesn't seem to work as it is this tag that is
> important:
>
> MultiThreadedDebug
>
> Is there anyway to control what is put on the RuntimeLibrary for
> Visual Studio 10 generation?
>
> Thanks.
>
> --
> Perry Ismangil
> ___
> 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] [CMake 0012322]: Ability to add source files to target created with ExternalProject

[Yuri Timenkov]

It is, if you use it for 3rd-party libraries.

But some people (including me :)) may use it to build different parts of
single project with different compilers (I have one library which should be
built with VC6 and the rest of the project with VC2010, but I change code in
each place with same frequency).

In this case it is far from black box. But I completely agree, that this is
discussion about "typical usage". I just was very happy when I got chance to
significantly simplify and make even more user-friendly our build procedure
:).

On Fri, Aug 12, 2011 at 7:29 PM, David Cole  wrote:

> The typical ExternalProject is a bit of a black-box to the containing
> project, and a list of sources is something most users will not
> have... That's another reason why I am skeptical as to the usefulness
> of this feature to the general ExternalProject consumer.
>
>
> On Fri, Aug 12, 2011 at 11:24 AM, Yuri Timenkov  wrote:
> > Ok, I'll double-check this next monday. That's why I was confused.
> >
> > On the second thought if you have a list of sources you can add them as
> > dependencies in addition to build rule, then step will be re-run as
> > expected. May be it's my case.
> >
> > Anyways I need to do some more investigation.
> >
> > Best wishes,
> > Yuri
> >
> > On Aug 12, 2011 6:54 PM, "David Cole"  wrote:
> >> You can re-open the issue if you would like to have more discussion
> there.
> >>
> >> The build step does not always re-run. If you have an "update" step
> >> before the build step, then the update step always re-runs, and the
> >> build step after it, but many external projects do not have an update
> >> step, or anything else that "always" forces a build when there's a
> >> "Build Solution" executed on the containing project. (If it does, then
> >> that's a bug, because it's only supposed to re-execute steps that
> >> *need* to be re-executed.)
> >>
> >>
> >> Thanks,
> >> David
> >>
> >>
> >> On Fri, Aug 12, 2011 at 10:46 AM, Yuri Timenkov 
> wrote:
> >>> Hello David,
> >>> It seems that I can't add notes to closed bug, so I ask you directly.
> >>> I don't quite understand what kind of automatic dependencies you're
> >>> talking
> >>> about.
> >>> If I change file in this way and do "build solution" cmake will
> >>> automatically launch build for external project. IIRC it always
> executes
> >>> build when I build solution.
> >>> As I said, for my local purposes I can use modified
> ExternalProject.cmake
> >>> file, but I thought such feature might be useful for others.
> >>>
> >>> On Fri, Aug 12, 2011 at 5:24 PM, Mantis Bug Tracker
> >>>  wrote:
> >>>>
> >>>> A NOTE has been added to this issue.
> >>>> ==
> >>>> http://public.kitware.com/Bug/view.php?id=12322
> >>>> ==
> >>>> Reported By:Yuri
> >>>> Assigned To:David Cole
> >>>> ==
> >>>> Project:CMake
> >>>> Issue ID:   12322
> >>>> Category:   CMake
> >>>> Reproducibility:always
> >>>> Severity:   tweak
> >>>> Priority:   normal
> >>>> Status: resolved
> >>>> Resolution: won't fix
> >>>> Fixed in Version:   CMake 2.8.6
> >>>> ==
> >>>> Date Submitted: 2011-07-08 05:27 EDT
> >>>> Last Modified:  2011-08-12 09:24 EDT
> >>>> ==
> >>>> Summary:Ability to add source files to target
> >>>> created
> >>>> with
> >>>> ExternalProject
> >>>> Description:
> >>>> In my scenario I have part of project which should be built with
> >>>> different
> >>>> toolset (Main project is built with VC2010, and some legacy libraries
> >>>> with
> >>>> VC6
> 

Re: [CMake] [CMake 0012322]: Ability to add source files to target created with ExternalProject

[Yuri Timenkov]

Ok, I'll double-check this next monday. That's why I was confused.

On the second thought if you have a list of sources you can add them as
dependencies in addition to build rule, then step will be re-run as
expected. May be it's my case.

Anyways I need to do some more investigation.

Best wishes,
Yuri

On Aug 12, 2011 6:54 PM, "David Cole"  wrote:
> You can re-open the issue if you would like to have more discussion there.
>
> The build step does not always re-run. If you have an "update" step
> before the build step, then the update step always re-runs, and the
> build step after it, but many external projects do not have an update
> step, or anything else that "always" forces a build when there's a
> "Build Solution" executed on the containing project. (If it does, then
> that's a bug, because it's only supposed to re-execute steps that
> *need* to be re-executed.)
>
>
> Thanks,
> David
>
>
> On Fri, Aug 12, 2011 at 10:46 AM, Yuri Timenkov  wrote:
>> Hello David,
>> It seems that I can't add notes to closed bug, so I ask you directly.
>> I don't quite understand what kind of automatic dependencies you're
talking
>> about.
>> If I change file in this way and do "build solution" cmake will
>> automatically launch build for external project. IIRC it always executes
>> build when I build solution.
>> As I said, for my local purposes I can use modified ExternalProject.cmake
>> file, but I thought such feature might be useful for others.
>>
>> On Fri, Aug 12, 2011 at 5:24 PM, Mantis Bug Tracker
>>  wrote:
>>>
>>> A NOTE has been added to this issue.
>>> ==
>>> http://public.kitware.com/Bug/view.php?id=12322
>>> ==
>>> Reported By:Yuri
>>> Assigned To:David Cole
>>> ==
>>> Project:CMake
>>> Issue ID:   12322
>>> Category:   CMake
>>> Reproducibility:always
>>> Severity:   tweak
>>> Priority:   normal
>>> Status: resolved
>>> Resolution: won't fix
>>> Fixed in Version:   CMake 2.8.6
>>> ==
>>> Date Submitted: 2011-07-08 05:27 EDT
>>> Last Modified:  2011-08-12 09:24 EDT
>>> ==
>>> Summary:Ability to add source files to target
created
>>> with
>>> ExternalProject
>>> Description:
>>> In my scenario I have part of project which should be built with
different
>>> toolset (Main project is built with VC2010, and some legacy libraries
with
>>> VC6
>>> and VS2005).
>>> Basically nested project contains
>>> set(Proj_SRCS src1.cpp src2.cpp...)
>>> add_library(Proj MODULE ${Proj_SRCS})
>>>
>>> So set() command may be moved into separate file which in turn could be
>>> included
>>> into main project. So I want to see them there to edit in IDE, but not
>>> compile.
>>>
>>> The only possibility to add files to custom target - is specify SOURCES
in
>>> add_custom_target command (It's impossible to call cmTarget::AddSources
>>> from
>>> outside). However, ExternalProject_Add macro doesn't add any sources.
>>>
>>> Moreover, there is a kind of chicken-and-egg problem: all arguments are
>>> parsed
>>> and set as property on target. But you can't set property while there is
>>> no
>>> target.
>>>
>>> So as quick work-around I made private copy of ExternalProject.cmake and
>>> pass
>>> sources as directory property.
>>>
>>> So I'm asking for ideas how to properly implement this feature: modify
>>> somehow
>>> parameters parsing in ExternalProject, or may be introduce command which
>>> allows
>>> adding new sources to existing targets (I'm not sure if this will work,
>>> but for
>>> me it sounds like target_link_libraries command).
>>> ==
>>>
>>> --
&g

Re: [CMake] External_Project and WIndows

[Yuri Timenkov]

For non-CMake project (especially VS native ones) you could use
${CMAKE_CFG_INT_DIR} variable instead (
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_CFG_INTDIR
)

It will be evaluated into current solution's configuration. However please
note that in this case configurations in CMake should be the same as in
nested project.

And may be I misunderstood your question, but BUILD_COMMAND in external
project should work without extra quotes (that is msbuild '/p:Configuraion'
...). I suppose /p gets converted to \p because CMake interprets this whole
string as path to binary and converts path separator to native form (which
is back-slash on windows).

On Sun, Aug 7, 2011 at 1:15 AM, Bill Hoffman wrote:

> On 8/6/2011 11:53 AM, Richard Offer wrote:
>
>>
>> Hi,
>>
>> I'm trying to build Google protocol buffers as an external project on
>> Windows and am hitting an issue with over assuming something is a path.
>>
>>
>> I need to be able to call msbuild with options. (/p:Configuration=Debug),
>> but cmake converts this to \p:Configuration=Debug before passing the
>> string to msbuild.
>>
>>  This might work:
>
> cmake --build path/to/project --config Debug
>
>
> __**_
> 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] Intertwined projects.

[Yuri Timenkov]

So you are trying to install your project into public location on CI server?
If so, why?

Otherwise I don't see any reasons why install shouldn't work, if you're
installing these libraries into app1's specific temporary build location.

And do you really need libA and libB installed? May be you should just skip
install step?

On Thu, Aug 4, 2011 at 2:31 PM, Mathias Sulser  wrote:

> Hello.
>
> This is my first post on this ML - so hi to everyone.
> I have been playing around with CMake for a while now and would love
> to introduce it to our projects. However, I wasn't able to answer the
> question below myself. Help appreciated.
>
> Short version:
> How do you layout internal project dependencies in CMake from multiple
> repositories? Is ExternalProject, a super build or something else the
> way to go?
>
> Long version:
> I have the following project/repo layout:
>
> app1.git
>  /src
>  /include
>  /test
>  CMakeLists.txt
>
> app2.git
>  ..
>
> libA.git
>  ..
>
> libB.git
>  ..
>
>
> I was thinking of using ExternalProject_Add in app1's CMakeLIsts.txt
> to declare it's dependencies on libA and libB. This works fine, it
> even allows pointing to a local git repo and branch on the dev boxes.
>
> Now, if I bring a central CI server (i.e. jenkins) into play, the
> INSTALL command required for ExternalProject screws things up for me.
> I can't have app1 depending on v1 of libA and app2 on v2 of libA as
> both get installed in the same location.
>
> Any ideas how to solve this? Am I misusing ExternalProject's
> functionality for internal dependencies?
>
> Cheers,
> Mathias
> ___
> 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] separation between .hpp and .inl

[Yuri Timenkov]

See source_group command

On Aug 2, 2011 12:51 PM, "Julien Dardenne" 
wrote:
**
Hello,

I want to do the separation between .hpp and .inl in my Visual project.
Is there a command CMake to create sub folder in the project and organize my
files ?

Thanks



___
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] Problem making vc project

[Yuri Timenkov]

It's really hard to find problem without having whole picture.

I can only suggest printing debug information from your CMakeLists.txt with
message() command. There could be problems with CUDA_COMPILE, it may return
empty list for example, if cuda library isn't found for current
platform/compiler. So try printing values of all required variables
(_CUDA_GENERATED_FILES, _libGPIUTMD_cu_sources, etc) to localize problem.

On Thu, Jul 28, 2011 at 9:47 AM, Nima Nouri  wrote:

> Hi
> I cannot make a small stand alone example, it is a big project.
> however I have checked the cmakelists. I am sending you the part that is
> responsible for making the cuda file lists.
>
>
> On Thu, Jul 28, 2011 at 8:03 AM, Yuri Timenkov  wrote:
>
>> The original CMakeLists will be helpful to solve your problem. Could you
>> provide a small stand-alone example reproducing your problem?
>>
>> On Wed, Jul 27, 2011 at 8:02 PM, Nima Nouri wrote:
>>
>>> Hi everybody
>>>
>>> I am currently trying to compile my source code on VC9.
>>> Previously I was using VC8 and every thing was fine but now cmake does
>>> make everything like before but only a vcproject file.
>>> I have attached both files in a rar archive to this mail, the one made
>>> for VC8 is larger 250KB and the one made for VC9 is the smaller 70KB.
>>>
>>> if you comparison the files (of course with a comparison utility like the
>>> ones notepad++ have) you will find that all cuda source files are not added
>>> to the build list on the VC9 file.
>>> Does any one has any idea about whats causing this? and How i can fix it?
>>>
>>> I should add that the settings of the cmake files for both VC8 and VC9
>>> are set using the cmake internal parameters MSVC80 and MSVC90 and the
>>> configurations are the same. for example
>>>
>>> if (MSVC80)
>>> -The block of command
>>> endif (MSVC80)
>>>
>>> if (MSVC90)
>>> -The same block of command
>>> endif (MSVC90)
>>>
>>> --
>>>  Best Regards
>>> N.Nouri
>>>
>>> Ph.D Student
>>> Department of Mechanical Engineering
>>> Isfahan University of Technology
>>> Isfahan, Iran
>>>
>>> ___
>>> 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
>>>
>>
>>
>
>
> --
> Best Regards
> N.Nouri
>
> Ph.D Student
> Department of Mechanical Engineering
> Isfahan University of Technology
> Isfahan, Iran
>
> gpiutmd.iut.ac.ir
> gpiutmd.webs.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] VS2010 and superbuild - Fwd: [Ctk-developers] VS2010 support

[Yuri Timenkov]

I'm not sure I understood your question, but now I use ExternalProject (from
CMake 2.8.4) with Visual Studio 2010 which has 2 externals: one built with
custom command (the C# project) and the second one is CMake-based but with
VC6 generator. Everything compiles and works fine. But I don't have download
step - everything is in my source directory.

The only wish I have I filed to Mantis:
http://public.kitware.com/Bug/view.php?id=12322

Regards,
Yuri

On Thu, Jul 28, 2011 at 12:37 AM, Sascha Zelzer  wrote:

> **
> Hi,
>
> Is nobody on this list using CTK or Slicer with Visual Studio 2010 in
> superbuild mode? If you do, could you please post if you had success or not?
>
> Thanks,
> Sascha
>
>
> On 07/22/2011 06:20 PM, Jean-Christophe Fillion-Robin wrote:
>
> Hi Folks,
>
> Before digging further into the problem ... if some your experience issue
> with VS2010 and superbuild .. would be great if you could provide more
> details about your investigation.
>
> Thanks
> Jc
>
> -- Forwarded message --
> From: Sascha Zelzer 
> Date: Fri, Jul 22, 2011 at 12:07 PM
> Subject: Re: [Ctk-developers] VS2010 support
> To: ctk-develop...@commontk.org
>
>
> Hi,
>
> there is something very strange going on. The generated VS 2010 projects (I
> am using the Express editions, 32bit) for the external dependencies like
> DCMTK, Log4Qt, etc. only call the download step of the ExternalProject_add
> call in our superbuild scripts. The projects are not configured and build.
>
> Did anybody experience the same? I tried with and without the VS 2010 SP1
> and with CMake 2.8.4 and 2.8.5.
>
> Thanks,
>  Sascha
>
>
> On 07/22/2011 01:39 PM, Sascha Zelzer wrote:
>
>> Hi Folks,
>>
>> I would like to get Visual Studio 2010 compatibility for CTK.
>>
>> Currently, it looks like I will have to copy ExternalProject.cmake to
>> CTK for the CMAKE_CACHE_ARGS argument. Then a couple of small
>> modifications should do.
>>
>> Any other ideas or objections?
>>
>> Thanks,
>>
>> Sascha
>> ___
>> Ctk-developers mailing list
>> ctk-develop...@commontk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>
>
> ___
> Ctk-developers mailing list
> ctk-develop...@commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>
>
> --
> +1 919 869 8849
>
>
>
> ___
> 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] Problem making vc project

[Yuri Timenkov]

The original CMakeLists will be helpful to solve your problem. Could you
provide a small stand-alone example reproducing your problem?

On Wed, Jul 27, 2011 at 8:02 PM, Nima Nouri  wrote:

> Hi everybody
>
> I am currently trying to compile my source code on VC9.
> Previously I was using VC8 and every thing was fine but now cmake does make
> everything like before but only a vcproject file.
> I have attached both files in a rar archive to this mail, the one made for
> VC8 is larger 250KB and the one made for VC9 is the smaller 70KB.
>
> if you comparison the files (of course with a comparison utility like the
> ones notepad++ have) you will find that all cuda source files are not added
> to the build list on the VC9 file.
> Does any one has any idea about whats causing this? and How i can fix it?
>
> I should add that the settings of the cmake files for both VC8 and VC9 are
> set using the cmake internal parameters MSVC80 and MSVC90 and the
> configurations are the same. for example
>
> if (MSVC80)
> -The block of command
> endif (MSVC80)
>
> if (MSVC90)
> -The same block of command
> endif (MSVC90)
>
> --
>  Best Regards
> N.Nouri
>
> Ph.D Student
> Department of Mechanical Engineering
> Isfahan University of Technology
> Isfahan, Iran
>
> ___
> 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] Build the dependencies tree of an executable

[Yuri Timenkov]

Hi Marco,

I think target_link_libraries and add_dependencies are not applicable to
 imported targets. You should set IMPORTED_LINK_INTERFACE_LIBRARIES property
instead. I don't remember exactly, but I solved similar problem.

You can also try creating sample project with dependent static libraries
(you even don't need to compile it), and then export dependencies with
export(TARGETS) commands, and see what code CMake will generate.

Best wishes,
Yuri

On Mon, Jul 18, 2011 at 8:54 PM, Marco Corvo  wrote:

> Hi all,
>
> I'm facing the following problem trying to generate the dependencies tree
> of an executable. I have a working area
>
> /path/to/my/working/area/**MyPackage
>
> with, say, one executable I want to build. The relevant CMakeLists.txt line
> is something like:
>
> add_executable(App src/App.cc)
> target_link_libraries(App A B C D)
>
> now these libs (A B C D) are already installed somewhere and they depend on
> other libraries of my software release. Say they're under
>
> /path/to/sw/release/X.Y.Z/lib/**arch/libA.a
> /path/to/sw/release/X.Y.Z/lib/**arch/libB.a
> /path/to/sw/release/X.Y.Z/lib/**arch/libC.a
> /path/to/sw/release/X.Y.Z/lib/**arch/libD.a
> /path/to/sw/release/X.Y.Z/lib/**arch/libE.a
>
> ...
>
> and that A depends on D, E and F. When I run my build, cmake only finds
> that my App has A, B, C and D as dependencies, while actually these
> libraries have also their own dependencies.
>
> I tried to add a .cmake file to each package in the release area
>
> /path/to/sw/release/X.Y.Z/**packageA/Deps.cmake
> /path/to/sw/release/X.Y.Z/**packageB/Deps.cmake
> /path/to/sw/release/X.Y.Z/**packageD/Deps.cmake
>
> with
>
> add_library(A STATIC IMPORTED)
> add_dependencies(A D E F...)
>
> which is "include"ed with my CmakeLists.txt file in order to let cmake know
> that when I build App it depends on A, B, C D _and_ A itself depends in his
> turn on D, E and F. This should create a complete dependencies tree for my
> App.
>
> I know that add_dependencies gives "Adding dependency to non-existent
> target" with cmake version before 2.8.4 if the target is IMPORTED while with
> 2.8.4/5 on a Scientific Linux 5 I'm getting a seg fault with the add_dep
> directive.
>
> Is this nevertheless the way to solve this problem? Are there other ways to
> build the dependencies tree of an executable which depends directly on some
> libs and indirectly on some other ones? Consider that I build static
> libraries, so I need to have the full list of libraries when linking the
> executable.
>
> Thanks in advance for your help.
>
> Cheers
>
> Marco
>
> --
> Marco Corvo
> SuperB experiment
> CNRS - Orsay
> c/o INFN - Padova
> __**_
> 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] Adding a Visual Studio 10 specific flag

[Yuri Timenkov]

Hi Amir,

Although It's better to hear answer from CMake authors I could try to give
you some clues.

If your project is completely managed by CMake, it's better to employ target
property. So, you should add one to property definition map (in
cmTarget.cxx), say "MS_USE_LIBRARY_DEPENDENCY_INPUTS".

And then, use it to generate appropriate statements. It's reasonable to use
it only for VS2010, so you should look at
cmVisualStudio10TargetGenerator.cxx (at the end of WriteLinkOptions
function), where LinkLibraryDependencies is currently added. Just add
another if branch, checking if property is set and add there
 tag. Check for property may look like:

if ( this->Target->GetPropertyAsBool("MS_USE_LIBRARY_DEPENDENCY_INPUTS") )


Alternatively you can use different approach: set such property on static
libraries, and then (in the same place, in
cmVisualStudio10TargetGenerator.cxx ) check if target depends on static
library with this property set. See
cmGlobalVisualStudio8Generator::NeedLinkLibraryDependencies
(cmGlobalVisualStudio8Generator.cxx) for reference.

As you can see, it should be quite easy from technical point of view, but
you have to make hard architectural decision :). May be there is a way to
implement it without properties.

Regards,
Yuri

On Wed, Jul 13, 2011 at 10:21 PM, Amir Mohammadkhani-Aminabadi <
a...@mohammadkhani.eu> wrote:

> Hi Yuri,
>
> thanks for the feedback,
>
>
>  These flags used by CMake internally to properly handle dependencies (as I
>> can tell from source code). LinkLibraryDependencies is turned on when your
>> target depends on target added wihth include_external_msproject. As for
>> UseLibraryDependencyInputs - you can't set this flag with CMake.
>>
>
> Sadly I'm more interested in the UseLibraryDependencyInputs because this
> one makes or breaks the result when compiled as static lib.
> The other solution, besides refactoring the code, is to compile as DLL.
> This problem has only surfaced with MSVC10 and did not
> happen with previous versions. While I realize the problem should be dealt
> with in other ways eventually I'd like to try and fix the cmake
> build for MSVC10 without too many changes.
>
> Could you suggest a mechanism how this could be set? Has there been similar
> problems with other environments?
> I'd gladly implement the feature if you could point me into the right
> direction. From a quick study of the cmake
> code I got the impression that cmake does not deal with flags that have no
> command line equivalent.
>
>
> cheers
> amir
>
> __**_
> 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] Adding a Visual Studio 10 specific flag

[Yuri Timenkov]

These flags used by CMake internally to properly handle dependencies (as I
can tell from source code). LinkLibraryDependencies is turned on when your
target depends on target added wihth include_external_msproject. As for
UseLibraryDependencyInputs - you can't set this flag with CMake.

On Mon, Jul 11, 2011 at 10:19 AM, Amir Mohammadkhani-Aminabadi <
a...@mohammadkhani.eu> wrote:

> Hi,
>
> I'd like to add the ability to set a specific MSVC10 Linker flag to cmake
> and
> wonder how to go about it. The problem as I see it is that the flag does
> not contain any command line equivalent to use.
>
> Could someone point me to an similar flag that I can look at and implement
> my code in a similiar fashion.
>
> The linker flags (actually its two while I'm at it):
> LinkLibraryDependencies
> UseLibraryDependencyInputs
>
> And they end up modifying the .vcxproj file
> 
> true<**/LinkLibraryDependencies>
> **true
> 
>
> How would this be managed inside the CMakeLists.txt configuration file?
> What is the best way to manage such a highly tool-chain depended flag?
>
> Yes, I do want to set these flags and yes I know why and no I do not want
> to change
> the code to not have to use them. We've found solutions that do not require
> this flag but I really, really would like to make this solution work too.
>
> cheers
> amir
>
> __**_
> 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] How to remove "NOMINMAX" from Visual Studio projects in CMake

[Yuri Timenkov]

Look through your CMakeLists where it is defined. AFAIK CMake doesn't add it
if you don't ask. Then, there are options: if it is added via
add_definitions() then you can use remove_definitions to remove this macro
for single project. If it is passed via COMPILE_FLAGS - then you have to
adjust them for example, with string(replace).

2011/7/12 火灵 <348774...@qq.com>

> Hi everyone,
>
> I use CMake in Visual Studio 2008. When I generate MFC projects, in the
> "Preprocessor Definitions" there is an option "NOMINMAX". Anyone knows how
> to remove it use CMake? Thank you!
>
> Best Regards
> Shuiling
>
> ___
> 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] set(... CACHE ) broken for CMAKE_C_FLAGS_{DEBUG, RELEASE, ...} ?

[Yuri Timenkov]

May be you're looking for overriding default flags?
http://www.cmake.org/Wiki/CMake_FAQ#Make_Override_Files
Although it mentions VS static runtime, this approach is very useful to set
own initial flags in CMake.

On Wed, Jul 6, 2011 at 5:41 PM, Jerry Gagelman  wrote:

> I'm redistributing a library for which the original authors have hand coded
> their own Makefile, but I would like to streamline everything with CMake.
> Their Makefile provides for Debug and Release flavored configurations, each
> has its own set of CFLAGS, and for consistency I would like to incorporate
> the same set of flags.
>
> Using the following commands, the configuration can be selected in the
> cache:
>
> if( DEFINED CMAKE_BUILD_TYPE )
>
> set( CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING "Options are: Debug
> Release")
>
> else( DEFINED CMAKE_BUILD_TYPE )
>
> set(CMAKE_BUILD_TYPE Debug CACHE STRING "Options are: Debug Release")
>
> endif( DEFINED CMAKE_BUILD_TYPE )
>
>
> That works. Next, I tried to update the C_FLAGS :
>
>
> set( CMAKE_C_FLAGS_DEBUG "-Wall -Wno-format -g -DDEBUG" CACHE STRING
> "Recommended debug flags." )
>
> set( CMAKE_C_FLAGS_RELEASE "-Wall -Wno-unknown-pragmas -Wno-format -O3"
> CACHE STRING "Recommended release flags." )
>
> However running "make edit_cache" always reflects the default
> CMAKE_C_FLAGS_{type}, not the new ones that I supplied. I have tried several
> variations on this theme, but can't make it work. Before posting a bug
> report, I thought I'd post this here in case there is anything obvious that
> I'm missing.
>
> Incidentally, I'm running CMake version 2.8.4, built by MacPorts.
>
> Thanks,
> Jerry
>
> ___
> 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] Strange behaviour with -D option

[Yuri Timenkov]

Use something like
SET (GUI ${GUI} CACHE BOOL "description")
To put proper initial value from command line into cache. It won't be
overwritten on the second run.

On Jul 1, 2011 2:02 PM, "pellegrini"  wrote:
> Hello everybody,
>
> there is a behaviour I do not understand when using cmake with -D option.
>
> In my project I defined a few CACHE variables. One of them is GUI to
> specify whether or not my project should be
> built with graphical library support.
>
> So in my main CMakeLists.txt I wrote something like:
>
> SET(GUI FALSE CACHE BOOL "do the build in GUI mode")
> PROJECT(crysfml Fortran)
> ...
>
> When launching cmake with:
> cmake -G "NMake Makefiles" -D CMAKE_Fortran_COMPILER=ifort -D GUI=TRUE
> ..\..\.
>
> I always get the following message
>
> #
> GUI VALUE = TRUE
> -- Configuring done
> You have changed variables that require your cache to be deleted.
> Configure will be re-run and you may have to reset some variables.
> The following variables have changed:
> CMAKE_Fortran_COMPILER= ifort
>
> -- The Fortran compiler identification is Intel
> -- Check for working Fortran compiler:
> C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe
> -- Check for working Fortran compiler:
> C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe -- works
> -- Detecting Fortran compiler ABI info
> -- Detecting Fortran compiler ABI info - done
> -- Checking whether C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe
> supports Fortran 90
> -- Checking whether C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe
> supports Fortran 90 -- yes
> GUI VALUE = FALSE
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
> C:/Datas/Eclipse/workspace/crysfml/build/ifort_release_win
> #
>
> and the worse it that when deleting the cache and rebuilding it, the GUI
> variable is switched to FALSE as you can see in the two MESSAGE commands
> I put in my code (GUI VALUE =). Though, I would tend to think that the
> -D command should have the last word.
>
> There should be something I completely missed.
>
> thanks a lot
>
> see you
>
> Eric
>
>
> --
> Eric Pellegrini
> Calcul Scientifique
> Institut Laue-Langevin
> Grenoble, France
>
> ___
> 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] (no subject)

[Yuri Timenkov]

Unfortunately you can get only list of source files (using SOURCES target's
property). The location of object files depends on Generator (e.g. for
VisualStudio they will be put into configuration-specific location).

On Tue, Jun 7, 2011 at 12:32 AM,  wrote:

> Does CMake provide a way to get the list of objects going into a given
> target? I need such a list for a PRE_LINK custom command.
> ___
> 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] Invoking CMakle outside of the build/source dir.

[Yuri Timenkov]

I guess there are cases when you can't do this.
For example, on Windows you can't simply call "cd -" or you may have other
kind of script than sh one (for example ant).

Also both source dir and binary dir may be relative to current directory,
therefore you don't know neither absolute nor relative to bindir source
path. And determining it may be quite cumbersome (again, in ant this can be
done using property and property names are global and they're evaluated only
once per script, so you can't easily wrap cmake call into macro).

On Mon, Jun 6, 2011 at 6:41 PM, Kishore wrote:

> On Monday 06 Jun 2011 12:38:33 PM Campbell Barton wrote:
> > Hi, A handful of times I would have found it useful to run cmake
> > without having to be in the build dir, mostly there is some way to
> > change the CWD or write a shell wrapper, nevertheless it could still
> > be useful when launching builds from scripts or more limited
> > environments.
> >
> > Is there some way to do this?:
> > cmake /some/source/dir /some/build/dir
>
> ... I guess not. Instead just invoke it as
>
> "cd /some/build/dir && cmake /some/source/dir ; cd -"
>
> which should bring you back to the current dir.
>
> > ... rather than
> > cd /some/source/dir ; cmake /some/build/dir
>
> Reversed paths! :P
> --
> Cheers!
> Kishore
> ___
> 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] Incorrect extra MinGW link flags

[Yuri Timenkov]

Sorry, usually there are errors when trying to generate project under
cygwin, but cmake uses backslashes.

Then I suggest looking at xmlparse and CE_FEMxml dependencies. Because
they're static libraries, CMake adds all their dependencies into link
command.
You can also check CMake's advanced variables and files in CMakeFiles. There
information about system is kept (along with linker and compiler's command
line templates).

On Thu, May 19, 2011 at 6:55 PM, Stiaan Gerber  wrote:

>  On 19/05/11 14:41, Yuri Timenkov wrote:
>
> May be you should use Cygwin build of CMake?
>
> On Thu, May 19, 2011 at 12:46 PM, Stiaan Gerber  wrote:
>
>>  Dear list
>>
>> On Windows, MinGW (gcc 4.5.2), CMake 2.8.4.
>>
>> I have a project building two executables. The first one builds correctly.
>> On the second one it appears to me as though CMake adds flags to link to the
>> standard MinGW libraries (mingw32, moldname, mingwex, ...) with an incorrect
>> .lib suffix.  (See the output below) As far as I can tell this is totally
>> unnecessary since these flags are automatically added by the gfortran
>> compiler. So in the end I have -lmingw32.lib (presumably added by CMake,
>> which fails) and -lmingw32 (automatically added by gfortran, which correctly
>> links libmingw32.a)
>>
>> My CMakelists file for the target CE_SEMFEM is
>>
>> ---
>> cmake_minimum_required (VERSION 2.8.4)
>> project (CE_SEMFEM Fortran)
>>
>> set (CE_SRCS
>> src/CE_SEMFEM.f95
>> src/CE_config_module.f95
>> )
>>
>> add_executable (CE_SEMFEM ${CE_SRCS})
>> target_link_libraries (CE_SEMFEM SEMFEM CE_FEMxml xmlparse)
>>
>> ---
>>
>> The libraries SEMFEM, CE_FEMxml and xmlparse are built elsewhere in the
>> project.
>>
>> Ideas how I can fix this? Any help is much appreciated.
>>
>> Stiaan
>>
>>
>> ---
>> Linking Fortran executable CE_SEMFEM.exe
>> Driving: C:\MinGW\bin\gfortran.exe -v
>> CMakeFiles/CE_SEMFEM.dir/src/CE_SEMFEM.f95.obj
>> CMakeFiles/CE_SEMFEM.dir/src/CE_con
>> fig_module.f95.obj -o CE_SEMFEM.exe
>> -LC:\Loher_Berechner_repo\build\Utilities\xml_parser
>> -LC:\Loher_Berechner_repo\build
>> \SEMFEM\trunk\SEMFEM\core -Lc:\MinGW\lib\gcc\mingw32\4.5.2
>> -Lc:\MinGW\lib\gcc -Lc:\MinGW\mingw32\lib -Lc:\MinGW\lib -L\M
>> inGW\lib ..\..\core\SEMFEM.lib
>> ..\..\..\..\..\Utilities\xml_parser\libCE_FEMxml.a
>> ..\..\..\..\..\Utilities\xml_parser\li
>> bxmlparse.a C:\MPICH2\lib\fmpich2g.lib -lmingw32.lib -lmoldname.lib
>> -lmingwex.lib -lmsvcrt.lib -luser32.lib -lkernel32.l
>> ib -ladvapi32.lib -lshell32.lib -lmingw32.lib -lmoldname.lib -lmingwex.lib
>> -lmsvcrt.lib -lgfortran -shared-libgcc
>> Using built-in specs.
>> COLLECT_GCC=C:\MinGW\bin\gfortran.exe
>>
>> COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
>> Target: mingw32
>> Configured with: ../gcc-4.5.2/configure
>> --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions
>> --wi
>> th-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
>> --enable-libstdcxx-debug --enable-version-specific-r
>> untime-libs --disable-werror --build=mingw32 --prefix=/mingw
>> Thread model: win32
>> gcc version 4.5.2 (GCC)
>>
>> COMPILER_PATH=c:/mingw/bin/../libexec/gcc/mingw32/4.5.2/;c:/mingw/bin/../libexec/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.
>> 5.2/../../../../mingw32/bin/
>>
>> LIBRARY_PATH=c:/mingw/bin/../lib/gcc/mingw32/4.5.2/;c:/mingw/bin/../lib/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../..
>>
>> /../../mingw32/lib/;c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../;/mingw/lib/
>> COLLECT_GCC_OPTIONS='-v' '-o' 'CE_SEMFEM.exe'
>> '-LC:\Loher_Berechner_repo\build\Utilities\xml_parser' '-LC:\Loher_Berechn
>> er_repo\build\SEMFEM\trunk\SEMFEM\core' '-Lc:\MinGW\lib\gcc\mingw32\4.5.2'
>> '-Lc:\MinGW\lib\gcc' '-Lc:\MinGW\mingw32\lib'
>>  '-Lc:\MinGW\lib' '-L\MinGW\lib' '-shared-libgcc' '-mtune=i386'
>> '-march=i386'
>>  c:/mingw/bin/../libexec/gcc/mingw32/4.5.2/collect2.exe -Bdynamic -u
>> ___register_frame_info -u ___deregister_frame_info
>> -o CE_SEMFEM.exe c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../.

Re: [CMake] Incorrect extra MinGW link flags

[Yuri Timenkov]

May be you should use Cygwin build of CMake?

On Thu, May 19, 2011 at 12:46 PM, Stiaan Gerber  wrote:

>  Dear list
>
> On Windows, MinGW (gcc 4.5.2), CMake 2.8.4.
>
> I have a project building two executables. The first one builds correctly.
> On the second one it appears to me as though CMake adds flags to link to the
> standard MinGW libraries (mingw32, moldname, mingwex, ...) with an incorrect
> .lib suffix.  (See the output below) As far as I can tell this is totally
> unnecessary since these flags are automatically added by the gfortran
> compiler. So in the end I have -lmingw32.lib (presumably added by CMake,
> which fails) and -lmingw32 (automatically added by gfortran, which correctly
> links libmingw32.a)
>
> My CMakelists file for the target CE_SEMFEM is
>
> ---
> cmake_minimum_required (VERSION 2.8.4)
> project (CE_SEMFEM Fortran)
>
> set (CE_SRCS
> src/CE_SEMFEM.f95
> src/CE_config_module.f95
> )
>
> add_executable (CE_SEMFEM ${CE_SRCS})
> target_link_libraries (CE_SEMFEM SEMFEM CE_FEMxml xmlparse)
>
> ---
>
> The libraries SEMFEM, CE_FEMxml and xmlparse are built elsewhere in the
> project.
>
> Ideas how I can fix this? Any help is much appreciated.
>
> Stiaan
>
>
> ---
> Linking Fortran executable CE_SEMFEM.exe
> Driving: C:\MinGW\bin\gfortran.exe -v
> CMakeFiles/CE_SEMFEM.dir/src/CE_SEMFEM.f95.obj
> CMakeFiles/CE_SEMFEM.dir/src/CE_con
> fig_module.f95.obj -o CE_SEMFEM.exe
> -LC:\Loher_Berechner_repo\build\Utilities\xml_parser
> -LC:\Loher_Berechner_repo\build
> \SEMFEM\trunk\SEMFEM\core -Lc:\MinGW\lib\gcc\mingw32\4.5.2
> -Lc:\MinGW\lib\gcc -Lc:\MinGW\mingw32\lib -Lc:\MinGW\lib -L\M
> inGW\lib ..\..\core\SEMFEM.lib
> ..\..\..\..\..\Utilities\xml_parser\libCE_FEMxml.a
> ..\..\..\..\..\Utilities\xml_parser\li
> bxmlparse.a C:\MPICH2\lib\fmpich2g.lib -lmingw32.lib -lmoldname.lib
> -lmingwex.lib -lmsvcrt.lib -luser32.lib -lkernel32.l
> ib -ladvapi32.lib -lshell32.lib -lmingw32.lib -lmoldname.lib -lmingwex.lib
> -lmsvcrt.lib -lgfortran -shared-libgcc
> Using built-in specs.
> COLLECT_GCC=C:\MinGW\bin\gfortran.exe
>
> COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
> Target: mingw32
> Configured with: ../gcc-4.5.2/configure
> --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions
> --wi
> th-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
> --enable-libstdcxx-debug --enable-version-specific-r
> untime-libs --disable-werror --build=mingw32 --prefix=/mingw
> Thread model: win32
> gcc version 4.5.2 (GCC)
>
> COMPILER_PATH=c:/mingw/bin/../libexec/gcc/mingw32/4.5.2/;c:/mingw/bin/../libexec/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.
> 5.2/../../../../mingw32/bin/
>
> LIBRARY_PATH=c:/mingw/bin/../lib/gcc/mingw32/4.5.2/;c:/mingw/bin/../lib/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../..
>
> /../../mingw32/lib/;c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../;/mingw/lib/
> COLLECT_GCC_OPTIONS='-v' '-o' 'CE_SEMFEM.exe'
> '-LC:\Loher_Berechner_repo\build\Utilities\xml_parser' '-LC:\Loher_Berechn
> er_repo\build\SEMFEM\trunk\SEMFEM\core' '-Lc:\MinGW\lib\gcc\mingw32\4.5.2'
> '-Lc:\MinGW\lib\gcc' '-Lc:\MinGW\mingw32\lib'
>  '-Lc:\MinGW\lib' '-L\MinGW\lib' '-shared-libgcc' '-mtune=i386'
> '-march=i386'
>  c:/mingw/bin/../libexec/gcc/mingw32/4.5.2/collect2.exe -Bdynamic -u
> ___register_frame_info -u ___deregister_frame_info
> -o CE_SEMFEM.exe c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../crt2.o
> c:/mingw/bin/../lib/gcc/mingw32/4.5.2/crtbegin.o
> -LC:\Loher_Berechner_repo\build\Utilities\xml_parser
> -LC:\Loher_Berechner_repo\build\SEMFEM\trunk\SEMFEM\core -Lc:\MinGW
> \lib\gcc\mingw32\4.5.2 -Lc:\MinGW\lib\gcc -Lc:\MinGW\mingw32\lib
> -Lc:\MinGW\lib -L\MinGW\lib -Lc:/mingw/bin/../lib/gcc/m
> ingw32/4.5.2 -Lc:/mingw/bin/../lib/gcc
> -Lc:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/lib
> -Lc:/mingw/bin/..
> /lib/gcc/mingw32/4.5.2/../../.. -L/mingw/lib
> CMakeFiles/CE_SEMFEM.dir/src/CE_SEMFEM.f95.obj CMakeFiles/CE_SEMFEM.dir/src
> /CE_config_module.f95.obj ..\..\core\SEMFEM.lib
> ..\..\..\..\..\Utilities\xml_parser\libCE_FEMxml.a ..\..\..\..\..\Utilit
> ies\xml_parser\libxmlparse.a C:\MPICH2\lib\fmpich2g.lib -lmingw32.lib
> -lmoldname.lib -lmingwex.lib -lmsvcrt.lib -luser32
> .lib -lkernel32.lib -ladvapi32.lib -lshell32.lib -lmingw32.lib
> -lmoldname.lib -lmingwex.lib -lmsvcrt.lib -lgfortran -lmi
> ngw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32
> -ladvapi32 -lshell32 -lmingw32 -lgcc_s -lgcc -lmol
> dname -lmingwex -lmsvcrt c:/mingw/bin/../lib/gcc/mingw32/4.5.2/crtend.o
> c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/bin/ld.exe:
> cannot find -lmingw32.lib
> c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../..

Re: [CMake] Debug / release build types

[Yuri Timenkov]

The best way is to use imported targets, specifying different locations for
each configuration (
http://www.cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets).

Or simply use OPTIMIZED and DEBUG keywords in target_link_libraries (see
command help).

On Tue, May 17, 2011 at 1:42 PM, David Aldrich
wrote:

> Hi
>
>
>
> My understanding is that cmake will automatically set the compiler flags
> based on CMAKE_BUILD_TYPE.  I am wondering whether there is a clean way of
> specifying debug / release ‘extra’ libraries such that cmake will select the
> appropriate library at link time?
>
>
>
> Currently I use this code to link to the open source ‘SystemC’ library:
>
>
>
> if( USE_SYSTEMC )
>
> if( CMAKE_BUILD_TYPE STREQUAL "Release" )
>
> target_link_libraries( zodiac ${SYSTEMCLIB_R} )
>
> endif( CMAKE_BUILD_TYPE STREQUAL "Release" )
>
> if( CMAKE_BUILD_TYPE STREQUAL "Debug" )
>
> target_link_libraries( zodiac ${SYSTEMCLIB_D} )
>
> endif( CMAKE_BUILD_TYPE STREQUAL "Debug" )
>
> endif( USE_SYSTEMC )
>
>
>
> Is there a cleaner way of doing this?
>
>
>
> Best regards
>
>
>
> 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
>
___
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 deprecate INSTALL project creation

[Yuri Timenkov]

Hi Alexey,

just remove INSTALL() statements from your CMake files. Doesn't it help?

2011/5/16 Алексей Виноградов 

> Hi!
>
> I'm using CMake for quite a short time and I'd like to know,  how to
> deprecate creation of INSTALL project? (I've generated project only for MS
> Visual Studio 2009).
> I don't need this project for sure. Can anyone help me?)
>
> Sincerely yours, Alex.
>
> ___
> 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] Express Edition

[Yuri Timenkov]

Isn't CMAKE_USING_VC_FREE_TOOLS works? You can also look for files
containing builder configuration in BuildDir/CMakeFiles directory.

Anyways, you can write your own test to check for VC version.

On Sat, May 7, 2011 at 3:37 PM, QbProg  wrote:

> Hello there,
> is there a quick & clean way to detect if we are using a Visual C++
> express edition with the MSVC generator?
> A variable of something like that.
> I would like to exclude solution folders in that case.
>
> Thank you,
> Qb
> ___
> 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] Change variable default

[Yuri Timenkov]

I think you're looking exactly for this:
http://www.vtk.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F
It's very good use-case, but I wonder why it's called MSVC-specific.

On Thu, Apr 28, 2011 at 7:23 PM, Tim Gallagher wrote:

> We do this:
>
> if(NOT CMAKE_Fortran_FLAGS_RELEASE)
>   set(CMAKE_Fortran_FLAGS_RELEASE "-O2 -xhost" CACHE STRING "" FORCE)
> endif()
>
> In other words, if the flags haven't been set yet (initial start up), set
> them to what we want. If they have been set (either changed by the user, or
> specified on the cmake/ccmake line with -D), leave them alone.
>
> Tim
>
> - Original Message -
> From: "Ilja Golshtein" 
> To: cmake@cmake.org
> Sent: Thursday, April 28, 2011 9:03:43 AM
> Subject: [CMake] Change variable default
>
> Hello!
>
> There are some CMAKE variables with default values. For example
> CMAKE_CXX_FLAGS_DEBUG default value is '-g'.
> How is it possible to make it '-g -Wall'?
>
> What I don't want to have: User choice overwritten.
>
> What I want to have: Modified a variable cmake-time default. It must be
> possible to change the variable via cmake -D or ccmake GUI.
>
> Thanks.
>
> --
> Best regards,
> Ilja Golshtein.
> ___
> 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
>
___
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] Possiblity to speedup the build by compiling multiple files in one compiler invocation

[Yuri Timenkov]

However, it is well-known technique called Unity Build and has some side,
effects both useful (more room for optimizer) and not (always full rebuild).
You may google a bit more about it.

On Apr 27, 2011 12:01 AM, "Alexander Neundorf" 
wrote:
> On Tuesday 26 April 2011, Martin Nielsen wrote:
>> Hi,
>>
>> I have been asked to look into the possibilities of compiling multiple
>> files in one invocation of the compiler like:
>>
>> armcc.exe ... file1.c file2.c ... fileN.c -o mylib.lib
>>
>> The cross compiler we are using requires a license in order to compile
the
>> file. It is a network floating license mechanism and the majority of the
>> time it take to build the code is spent on acquiring the license.
Parallel
>> build is sadly not an option either since it just requests multiple
>> licenses and we quickly run out.
>>
>> I was wondering if CMake could be directed to somehow do this? or it
would
>> break some dependency between the source files and the generation of the
>> library.
>>
>> I suspect it isn't possible but would like to confirm this or explore
other
>> ideas on how to get around this problem.
>
> In KDE we have an option KDE4_ENABLE_FINAL.
> If this is set to TRUE, then for each binary a cpp-file is generated,
which
> has #include "file.cpp" statements for each of the original source files,
and
> then this one file, which then contains basically the whole source code,
is
> compiled at once.
>
> You can search for "enable_final" e.g. here:
>
http://websvn.kde.org/branches/KDE/4.5/kdelibs/cmake/modules/KDE4Macros.cmake?revision=1143427&view=markup
>
> This is transparent for the user.
> If he uses kde4_add_executable(foo a.cpp b.cpp main.cpp)
> and turns the option on, then the all-in-one file is created automatically
and
> built.
>
> Alex
> ___
> 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] Choosing MPI installation

[Yuri Timenkov]

Just remove these values from cache. If you always want to search in custom
location, look at find_package's options to avoid searching in default
locations

On Apr 11, 2011 6:03 PM, "Martin Vymazal"  wrote:
> Hello,
>
> I'm a beginner and I apologize in case I'm asking a question that
> has already been answered. I would like to find mpi in my
> CMakeLists.txt and enable the user to set the mpi inlude and lib
> directories by setting say variables MY_MPI_INCLUDE_DIR and
> MY_MPI_LIB_DIR in cmake gui.
> Using find_package(MPI) works just fine for me, but once the
> package is found (and the variables MPI_LIBRARY and MPI_INCLUDE_PATH
> are set and cached), I cannot force cmake to search again for MPI in a
> different directory).
> Could you please give me a hint how to do this? How should I handle
> a situation where a user has possibly multiple mpi installations?
>
> Thank you very much.
>
> Best regards,
>
> Martin Vymazal
>
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
>
> ___
> 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] rebuild

[Yuri Timenkov]

So what's your problem? :)
seriously, which command do you use? You may right-click on your project and
choose "rebuild only project".

On Apr 16, 2011 3:24 AM, "Jesse Werner"  wrote:
> I have a visual studio 2010 solution that I create with cmake. I have
about
> 10 projects in the solution. Nine of these are open source libraries im
> using. The 10th is obviously the project I am currently working on. When I
> do a rebuild, it takes several minutes because it recompiles all the 3rd
> party libs. I would like rebuild to only rebuild my project as the 3rd
party
> libs will not be changing.
___
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] Replacing compiler flags for certain project subdirectories

[Yuri Timenkov]

Actually there is a way. But you should be careful to track in what scope
particular flags are defined.

If you don't put a lot of stuff into directory scopes you can modify
CMAKE__FLAGS and etc before calling to add_library/add_executable
call. You can even completely replace them. As I understand calling set()
command takes preference over cached variable and its value is restored when
CMake leaves directory (if I'm right).

For example, we have a "treat warnings as errors" policy for 100+ projects,
so we have /WX option in CMAKE_CXX_FLAGS. But for some legacy projects which
we don't want to touch we use:
# Don't treat warnings as errors.
string(REPLACE "/WX" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})

As I said, you should be aware of the place where particular flag comes
from. If you use directory-scope or source-file scope (or whatever)
properties, you should modify them instead.

On Wed, Mar 30, 2011 at 10:00 PM, Whitcomb, Mr. Tim <
tim.whitc...@nrlmry.navy.mil> wrote:

> Shortening to reduce wall-of-text:
>
> I have a Fortran project with a top-level CMakeLists.txt file with 47
> add_subdirectory calls.  Three of the subdirectories require a different set
> of preprocessor definitions and compiler flags than the other 47.  I can add
> the preprocessor definitions, but am having trouble with the compiler flags.
>  I need to have a completely different set in those subdirectories, so
> COMPILE_FLAGS target property won't work as it augments what's already
> there.
>
> How can I replace (not extend) the compiler flags for these few
> subdirectories?
>
> Tim
>
> > -Original Message-
> > From: cmake-boun...@cmake.org
> > [mailto:cmake-boun...@cmake.org] On Behalf Of Whitcomb, Mr. Tim
> > Sent: Friday, March 25, 2011 3:18 PM
> > To: 'cmake@cmake.org'
> > Subject: [CMake] Replacing compiler flags for certain project
> > subdirectories
> >
> > I'm in the process of adding Cmake-build capability to a
> > Fortran project that currently follows a traditional
> > recursive-make build structure.  I've converted all the
> > makefiles to CMakeLists.txt files and can now produce all the
> > target libraries and executables with their dependencies
> > correctly recognized.  These dependencies have made a huge
> > difference in allowing us to perform parallel builds and have
> > the project ready to go *much* faster than before.  I have a
> > top-level CMakeLists.txt file that contains a few library
> > searches (e.g. LAPACK, BLAS) and then an add_subdirectory
> > call for each subdirectory in the project.  Each subdirectory
> > corresponds to a library and/or an executable.
> >
> > Now that the listing files contain all the sources files they
> > need, my current task is to go through and set the proper
> > compiler/preprocessor flags to match the original makefiles.
> > We have several directories in our source tree that are
> > auxiliary libraries that we store in our Subversion
> > repository and build as part of our regular build process.
> > The libraries that are built in these directories are
> > compiled with different compiler flags and different
> > preprocessor definitions than the rest of the project.  I've
> > been able to handle the preprocessor definitions by using
> > add_definitions in the CMakeLists.txt files in the
> > lower-level directories.  I see based on reading through some
> > past threads (including the recent "Different CMAKE_CXX_FLAGS
> > for different executables") on this list and on some
> > StackOverflow questions that the COMPILE_FLAGS target
> > property is very close to what I need (and actually *was*
> > what I needed in several cases) but only appends flags to
> > those currently  in use.  What I need is to be able to define
> > a new set of compile flags (i.e. "forget everything you were
> > using before and use THIS set in this directory").
> >
> > I've started going through the documentation for Building
> > External Projects[*] but the first line states that "[a]n
> > "external project" is one that you can get the source code
> > for, but does not readily build with a simple
> > ADD_SUBDIRECTORY call in your CMakeLists.txt file."  This
> > feels like it's designed to solve a slightly different
> > problem than what I'm trying to do - I have an
> > add_subdirectory call in my CMakeLists.txt file - is the
> > proper fix for this issue to make the pieces that require
> > different flags external projects?  Will making some of these
> > libraries external projects mess with the dependency calculation?
> >
> > I'm just getting started and trying to wrap my head around
> > the options available.  What is the standard way of dealing
> > with this issue?  Is there anything I'm missing?  Thank you
> > for your assistance!
> >
> > Tim
> > [w]
> >
> > [*]
> > http://www.kitware.com/products/html/BuildingExternalProjectsW
> > ithCMake2.8.html
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.ki

Re: [CMake] find library for static libraries

[Yuri Timenkov]

Hi David, Robert,

In my project I used the approach taken from FindBoost:

include(MacroPushRequiredVars)
macro_push_variables(CMAKE_FIND_LIBRARY_SUFFIXES)

if(UNIX AND WITH_MY_LIB_STATIC)
# Find only static libraries
set(CMAKE_FIND_LIBRARY_SUFFIXES ".a")
endif(UNIX AND WITH_MY_LIB_STATIC)

find_library(MY_LIB NAMES thelibrary ...)

macro_pop_variables(CMAKE_FIND_LIBRARY_SUFFIXES)

Actually this code was written for CMake 2.4 and now there may be more
convenient functions to push/pop vars. The MacroPushRequiredVars is written
by Alexander Neundorf, you can find it with your favorite search engine.

For windows things may be a bit trickier and heavily depend on particular
library architecture.

Regards,
Yuri

On Thu, Mar 31, 2011 at 7:51 PM, David Cole  wrote:

> Does:
>
>   find_library(
> MY_LIB
> libthelibrary.a
> PATHS
>   ...
>   )
>
> work?
>
>
> On Thu, Mar 31, 2011 at 11:38 AM, Robert Bielik 
> wrote:
>
>> I'm trying to use find_library to find static (.a) libraries on Mac OS X
>> (cmake 2.8.1). In a lib path I have f.i.:
>>
>> .../lib/libthelibrary.a
>> .../lib/libthelibrary.dylib
>>
>> and with:
>>
>> find_library(
>>   MY_LIB
>>   thelibrary
>>   PATHS
>> ...
>> )
>>
>> it consequently finds only the .dylib ones, whereas I'd like to get hold
>> of the .a ones...
>>
>> How to?
>>
>> TIA
>> /Rob
>>  ___
>> 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
>
___
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] set_target_properties not setting COMPILE_DEFINITIONS?

[Yuri Timenkov]

Then it can be a problem with mixing spaces and semicolons. Look at
command-line with make VERBOSE=1, this may give you some clues.

On Mar 28, 2011 10:31 PM, "David Doria"  wrote:
> On Mon, Mar 28, 2011 at 2:28 PM, Yuri Timenkov  wrote:
>> Try prefixing definitions with -D
>
> I changed to:
> SET(MAIN_BUILD_DEFINITIONS "${MAIN_BUILD_DEFINITIONS} -DUNIX;")
> SET(MAIN_BUILD_DEFINITIONS "${MAIN_BUILD_DEFINITIONS}
-DPIXEL_DIMENSION=3;")
>
> and I get:
>
> : error: macro names must be identifiers
>
> I think you don't have to add -D when you set COMPILE_DEFINITIONS, but
> you do if you set COMPILE_FLAGS.
>
> 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] set_target_properties not setting COMPILE_DEFINITIONS?

[Yuri Timenkov]

Try prefixing definitions with -D

On Mar 28, 2011 10:26 PM, "David Doria"  wrote:
> I have setup a list of definitions:
>
> SET(MAIN_BUILD_DEFINITIONS "${MAIN_BUILD_DEFINITIONS} UNIX;")
> SET(MAIN_BUILD_DEFINITIONS "${MAIN_BUILD_DEFINITIONS} PIXEL_DIMENSION=3;")
>
> I display them and apply them to my executable as follows:
>
> add_executable(ImageCompleter ${MainSources})
> message("Main build definitions: " ${MAIN_BUILD_DEFINITIONS})
> set_target_properties(ImageCompleter PROPERTIES COMPILE_DEFINITIONS
> "${MAIN_BUILD_DEFINITIONS}")
>
> The output is:
> Main build definitions: UNIX PIXEL_DIMENSION=3
>
> which looks correct (i.e. UNIX was defined)
>
> However, in my code there is:
>
> #if defined(UNIX)
> ... some code...
> #else
> #error "Not implemented for this platform!"
> #endif
>
> When I build, the error is produced, indicating that UNIX was not defined.
>
> I created a small standalone example and it worked as expected... any
> suggestions of what else to check?
>
> Thanks,
>
> 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
___
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] Build problem : beginner

[Yuri Timenkov]

It is pre-built library, that is you don't need to compile it. However it is
CMake-aware, therefore you can use it in your program putting
find_library(CMTK) into your CMakeLists.txt.

So to use this in your program you should start writing CMakeLists.txt file
(as described in tutorial). The .cmake files provided with this CMTK are
CMake modules which are used to determine library location, version and
other parameters. Also I suppose CMTK documentation has some clues on its
usage, please refer to it.

Regards,
Yuri

On Sun, Mar 27, 2011 at 3:29 AM, TomGratte  wrote:

> Hello,
>
> I'm a beginner with cmake, and I did not find answers whether in the cmake
> documentation or in the archive of the mailing list.
>
> I run a Ubuntu 64 bits and want to use a program.
>
> I've downloaded the .tar.gz file, then extracted it. The structure of the
> extracted files is :
>
> usr/local/ ->
>
> bin/, include/, lib64/, share/
>
> - In bin/, there are executable files.
> - In include/, there are .h files.
> - In lib64, I have :
> .:
> cmtk
>
> ./cmtk:
> cmtk
> lib
> libcmtkBase.a
> libcmtkGPU.a
> libcmtkIO.a
> libcmtkNumerics.a
> libcmtkPipeline.a
> libcmtkQt.a
> libcmtkRecon.a
> libcmtkRegistration.a
> libcmtkSegmentation.a
> libcmtksqlite3.a
> libcmtkSystem.a
> libD4CMTK.a
> libmxml.a
> libNrrdIO.a
>
> ./cmtk/cmtk:
> CMTKConfig.cmake
>
> ./cmtk/lib:
> CMTKLibraryDepends.cmake
> UseCMTK.cmake
>
> - And in share/, some documentation.
>
> I tried to use cmake on the .cmake files, but it does not work. What should
> I do to be able to use this software ? Is it already built ? Why is there
> not a CMakeLists.txt file in the file I've downloaded ? It must be stupid
> questions, that is why feel free to redirect me to a helpful tutorial if
> you
> think I need some.
>
> (the software I try to use  http://www.nitrc.org/projects/cmtk/ link )
>
> Thank you
>
> Best Regards,
>
> Tom
>
> --
> View this message in context:
> http://cmake.3232098.n2.nabble.com/Build-problem-beginner-tp6211511p6211511.html
> Sent from the CMake mailing list archive at Nabble.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
>
___
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] Different CMAKE_CXX_FLAGS for different executables

[Yuri Timenkov]

Use COMPILE_FLAGS target property. Like this:

set_target_properties(Exec2 PROPERTIES COMPILE_FLAGS "/flag1 /flag2")

You can see full list of properties in CMake documentation. Note that
compiler flags may be also set for particular source file with
set_source_files_properties command.

On Thu, Mar 24, 2011 at 5:44 PM, David Doria  wrote:

> Is there a way to explicitly set the CMAKE_CXX_FLAGS for a particular
> executable? That is, if I set CMAKE_CXX_FLAGS and then have a
> add_executable line, then change CMAKE_CXX_FLAGS and then have another
> add_executable, will the first set of CMAKE_CXX_FLAGS be applied to
> the first executable and the second set of CMAKE_CXX_FLAGS be applied
> to the second executable?
>
> I guess my confusion is that I don't understand how CMake variables are
> cached.
>
> Each time I modify the variable, should I do it using
>
> SET(CMAKE_CXX_FLAGS "some flags")
>
> or
>
> SET(CMAKE_CXX_FLAGS "some flags" CACHE STRING "compiler flags")
>
> ?
>
> In this example: http://codepad.org/PGJRBjss the messages are actually
> not displayed at all, which is only adding to my confusion :)
>
> Any comments on this?
>
> Thanks,
>
> 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
>
___
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] Find Library would not find the library

[Yuri Timenkov]

Hi Ankur,

May be you're just missing -devel or -dev pacakges on your system? They
usually provide a symlink from .so to .so.X.Y to allow ld or gcc find the
correct library.

Or do you really have multiple libraries versions installed simultaneously,
each with headers?

On Thu, Mar 10, 2011 at 2:25 AM, Andreas Pakulat  wrote:

> On 09.03.11 21:36:25, Ankur Handa wrote:
> > I'm using find_library to find a library in a given directory but it has
> > many different versions of this library listed as libcxcore.so,
> > libcxcore.so.2.1 and libcxcore.so.2.1.0  I wrote a very simple cmake file
> >
> > cmake_minimum_required(VERSION 2.8)
> >
> > find_library(OpenCV_LIBRARY_RELEASE NAMES "cxcore" PATHS
> > "/homes/ahanda/openCV2.1/OpenCV-2.1.0/opencvinstall/lib" NO_DEFAULT_PATH)
> >
> > if ( OpenCV_LIBRARY_RELEASE)
> > message("LIBRARY FOUND = " ${OpenCV_LIBRARY_RELEASE})
> > endif()
> >
> > if ( NOT OpenCV_LIBRARY_RELEASE)
> > message("LIBRARY NOT FOUND")
> > endif()
> >
> > It works fine if I search for "cxcore" for which it returns me
> libcxcore.so
> > and the OpenCV_LIBRARY_RELEASE
> > as /homes/ahanda/openCV2.1/OpenCV-2.1.0/opencvinstall/lib/libcxcore.so
> >
> > However if I try to search for cxcore21 or cxcore210 or even
> > libcxcore.so.2.1.0 it won't return me anything and I'd always see LIBRARY
> > NOT FOUND being printed.
> >
> > Could anyone please let me know how to really search for
> libcxcore.so.2.1.0
>
> You can't I think. Thats simply not how cmake or the linker work. The
> linker during the compilation phase will always link against
> lib.so. So you need to make sure that your lib.so is from
> cxcore 2.1.0 and search simply for cxcore.
>
> If you want to make sure that a user has at least cxcore 2.1.0 installed
> you'll need to use other means to find out the version number of the
> installed library. Usually such libs provide a header with version
> numbers which you can read. Or it may have a pkgconfig file for which
> cmake has extra macros to read them. In worst case you could try to grep
> for the version number in the output of strings running over the found
> library.
>
> Andreas
>
> ___
> 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] CMake command line arguments

[Yuri Timenkov]

Hi,

Try putting set(CMAKE_USER_MAKE_RULES_OVERRIDE MyCompilerFlags) before
project() command.
Then, override variable CMAKE_BUILD_TYPE_INIT (with plain unconditional set
command, without putting into cache) in MyCompilerFlags.cmake file (make
sure you put it into location CMake can reach).

Regards,
Yuri

2011/3/7 Gabriel Petrovay 

> This does not work because the "NMake Makefile" generator already sets
> the variable: CMAKE_BUILD_TYPE to "Debug"
>
> So your code will never be executed:
> if(NOT CMAKE_BUILD_TYPE)
>  # it will never get here
>  set(CMAKE_BUILD_TYPE RelWithDebInfo)
> endif(NOT CMAKE_BUILD_TYPE)
>
> And I want to have a default of "Release".
>
>
> Gabriel
>
> On Mon, Mar 7, 2011 at 3:14 AM, 徐亮  wrote:
> > You can check if the variable has defined. You can see
> > "http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:if"; for
> > detail information.
> >
> > if(NOT CMAKE_BUILD_TYPE)
> >   set(CMAKE_BUILD_TYPE RelWithDebInfo)
> > endif()
> >
> > 2011/3/7 Gabriel Petrovay 
> >>
> >> Hi,
> >>
> >> I don't understand how to do that...
> >>
> >> The user who builds does not set any environment and does not provide
> >> any -D arguments. I want CMake to automatically configure variables
> >> like: CMAKE_BUILD_TYPE or CMAKE_INSTALL_PREFIX when the user does not
> >> provide them. So I want *my* default values. But I don't want to set
> >> them when the user provides the *generator* ("NMake Makefiles")
> >> default values.
> >>
> >> The only way I see it is for CMake to tell you what parameters were
> >> there in the command line. Does CMake support this?
> >>
> >> How do you do this with the PATH environment variable?
> >>
> >>
> >> Gabriel
> >>
> >> On Mon, Mar 7, 2011 at 2:41 AM, 徐亮  wrote:
> >> >> From: Gabriel Petrovay 
> >> >> Subject: [CMake] CMake command line arguments
> >> >>
> >> >> Hi,
> >> >>
> >> >> Is there a way to read the arguments that were passed to CMake from
> >> >> inside a CMakeLists.txt file?
> >> >>
> >> >> There is a problem that some generators (like "NMake Makefiles") set
> a
> >> >> default value for certain variables (like CMAKE_BUILD_TYPE=Debug,
> >> >> CMAKE_INSTALL_PREFIX=C:\Program Files\${CMAKE_PROJECT_NAME})
> >> >>
> >> >> >From inside CMake one can not set up a different default value if
> the
> >> >> user does not specify it with a -D option. This is because
> >> >> IF(CMAKE_BUILD_TYPE) will always be true because of the default set
> by
> >> >> the generator ("NMake Makefiles").
> >> >>
> >> >> There was this guy having the same problem:
> >> >> http://www.mail-archive.com/cmake@cmake.org/msg09640.html
> >> >>
> >> >> Any solution how one can solve this? Reading the arguments passed to
> >> >> CMake would be one, but I find no documentation/example/google_result
> >> >> for this.
> >> >>
> >> >>
> >> >> Thanks!
> >> >>
> >> >> --
> >> >> MSc Gabriel Petrovay
> >> >> Mobile: +41(0)787978034
> >> >> www.28msec.com
> >> >>
> >> >
> >> > I use "environment variables" to handle this problem. Such as
> "$ENV{PATH}".
> >> > Liang Xu
> >> >
> >> > ___
> >> > 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
> >> >
> >>
> >>
> >>
> >> --
> >> MSc Gabriel Petrovay
> >> Mobile: +41(0)787978034
> >> www.28msec.com
> >
> >
> >
> > --
> > Liang Xu
> >
>
>
>
> --
> MSc Gabriel Petrovay
> Mobile: +41(0)787978034
> www.28msec.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
>
___
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] Multiple library configurations with the same output name

[Yuri Timenkov]

Hi Alexey,

Usually there are 2 ways: 1) put them into separate directories (like Debug
and Release), probably specifying different output directories  or 2) use
different file names, say adding suffixes like D, or d8.

BTW, what's the point to have different configurations in the same workspace
(do you really still use VC6?) in different projects? Usually for Visual
Studio configuration is coded into output directory path using macros like
$(Configuration), so resulting binaries are put into different dirs. And you
have to build twise to get all configurations.

Why do they required to have the same name? May be you're trying to solve
wrong problem?

Regards,
Yuri

On Thu, Mar 3, 2011 at 2:50 PM, Alexey Livshits  wrote:

> Hello CMakers,
> suppose I've got a library foo with tow configurations: foo_1 and
> foo_2. Both versions should have the same output name: foo. The
> problem is, the output directory for both ist the same, so the second
> will overwrite the first.
> What's the best way to organize it?
>
> --
> BG,
> Alexey
> ___
> 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] Parsing library list with keywords 'debug', 'optimized' and 'general' present

[Yuri Timenkov]

Hi Lori,

If you have options it's better to use imported libraries. They are far more
flexible and allow specifying more than just debug and optimized
configurations.

If you stuck with these keywords, you can look at QT4_EXTRACT_OPTIONS macro
in Qt4Macros.cmake (in CMake distribution). It contains only one option, but
you can use similar approach to extend for any number of named parameters.

On Thu, Mar 3, 2011 at 1:38 AM, Lori Pritchett-Sheats wrote:

> After reading the documentation, target_link_libraries allows a user to
> pass a list with keywords debug, optimized and general to indicate which set
> of libraries to use when CMAKE_BUILD_TYPE is set. Is there a command,
> function or macro that parses lists that have these keywords and returns the
> appropriate set of libraries. Something like
> set(lib_list "debug;a;b;c;optimized;e;f;general;g;h")
> parse_library_list( lib_list DEBUG debug_libs OPT opt_libs GENERAL
> gen_libs)
> and it would return
> debug_libs=a;b;c
> opt_libs=e;f
> gen_libs=g;h
>
> I've tried using CMakeParseArguments to parse lib_list but haven't had any
> success. Though I would ask before attempting to write my own parser.
>
> --
> Lori A. Pritchett-Sheats, PhD.
> CCS-2, Computational Physics and Methods
> Office: 505-665-6675
> Fax: 505-665-4972
>
> Los Alamos National Laboratory
> P.O. Box 1663
> MS D413
> Los Alamos, NM 87544
>
> ___
> 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] Splitting directory and file.

[Yuri Timenkov]

Does get_filename_component help?

On Wed, Mar 2, 2011 at 6:17 AM, Pablo Zurita  wrote:

> Hello everybody,
>
> I'm just getting started and I need some help dealing with strings in
> CMake. Basically what I have a bunch of strings such as the ones
> below:
>
> "Main.cpp"
> "Window/Example/Example.cpp"
> "Window/Window.cpp"
>
> What I need to do is create two strings for each, one is going to be
> the directory, so the output in order for the list above is:
>
> ""
> "Window/Example"
> "Window"
>
> And the other string I need is the file itself. So the output for that
> would be
>
> "Main.cpp"
> "Example.cpp"
> "Window.cpp"
>
> Since I'm processing each one by one it doesn't matter if there are
> collisions.
>
> As you can see all I need to is find the first forward slash on the
> string reading from right to left, and then put what's on the left of
> that string on one variable, and what is to the right in another.
>
> Does anybody know how I can do that?
>
> Thanks,
> Pablo Zurita.
> ___
> 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] Remove /D "MBCS" from VS projects

[Yuri Timenkov]

I think you can just add _UNICODE (or remove) to definitions, CMake will
automatically determine necessary vcproj options then.

On Tue, Mar 1, 2011 at 6:20 PM, gekso  wrote:

> Hello! How can I remove multi-byte character set (/D "MBCS") setting
> from visual studio projects? I need to create two configurations, one
> with UNICODE and one without anything
> ___
> 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] Preferred way to use 3rd-party dependencies

[Yuri Timenkov]

Ok, let me share chosen approach then.

I decided to use package config and it seems to rock :). That is with only
couple of lines I can easily describe what to link with. The main challenge
is that we work with C++ libraries, and they are configuration- and
compiler-dependent. Look at the boost nightmare for example. And since I
know in advance location and names of all libraries (in my corporate
environment) it is just a matter of few calls to set_target_properties
depending on compiler version, rather than writing monstrous find modules
which usually have a lot of copypasted stuff.

Also it seems that these configs should be very useful when dealing with
intra-company dependencies. Say if we share a library with other department
now we usually put it into both source trees using svn:externals (otherwise
it will be difficult to set up source tree dependencies). But svn:externals
have many pitfalls with branching or synchronizing changes when someone is
in release phase. I know that this may be externals misuse, but when
"convenient" crosses "right" the former usually wins. But with
export(PACKAGE) dealing with such dependencies may be much easier.

So thanks again for great software.

On Fri, Feb 18, 2011 at 2:17 PM, Yuri Timenkov  wrote:

> Dear all,
>
> I haven't been using CMake (and hence following) for almost 3 years and I
> suppose it has a big progress since 2.4.
>
> Now I'm looking for most kosher way to specify external dependencies for a
> particular project. The most straightforward way of specifying include dirs
> and libraries when porting from Visual Studio - is using include_directories
> & link_directories commands. However, I heard that link_directories is not
> very good idea and the preferred way is using imported targets.
>
> Some libraries are internal but built by separate teams for different
> compilers version. Also we don't need to find library & include dir's
> location, we know them in advance (and it is rather fixed).
>
> So may be there are some guides, and discussions or examples about recent
> Find* modules behavior?
>
> Thanks in advance,
> Yuri
>
___
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] Default visual studio filters

[Yuri Timenkov]

Also you could employ SOURCES property of target to get list of files to
eliminate the need of passing them to macro explicitly.

On Fri, Feb 25, 2011 at 8:58 PM, Michael Jackson <
mike.jack...@bluequartz.net> wrote:

> I have the following macro that I use:
>
>
> MACRO (cmp_IDE_SOURCE_PROPERTIES SOURCE_PATH HEADERS SOURCES)
>STRING(REPLACE "/" "" source_group_path ${SOURCE_PATH}  )
>source_group(${source_group_path} FILES ${HEADERS} ${SOURCES})
> ENDMACRO (cmp_IDE_SOURCE_PROPERTIES NAME HEADERS SOURCES INSTALL_FILES)
>
> #Example Usage
> set(SRCS Foo.cpp bar.cpp)
> set(HDRS Foo.h   bar.h)
> cmp_IDE_SOURCE_PROPERTIES( "Source/Lib" "${HDRS}" "${SRCS}")
> add_library( foolib  ${SRCS} ${HDRS})
>
> and in Visual Studio I get Foo.cpp bar.cpp foo.h bar.h all in the same
> "filter"/Folder thingie. Is that what you are looking for?
>
> ___
> Mike Jackson  www.bluequartz.net
> Principal Software Engineer   mike.jack...@bluequartz.net
> BlueQuartz Software   Dayton, Ohio
>
> On Feb 25, 2011, at 12:42 PM, aaron_wri...@selinc.com wrote:
>
> > I was curious about an answer to this question. I don't think source and
> > header files should be separated either. It's just a nag, but if there
> was
> > an easy fix, I'd jump on it.
> >
> > ---
> > Aaron Wright
> >
> >
> >
> >
> > From:   Orcun Gokbulut 
> > To: cmake@cmake.org
> > Date:   02/23/2011 07:48 AM
> > Subject:[CMake] Default visual studio filters
> > Sent by:cmake-boun...@cmake.org
> >
> >
> >
> > Hello cmake users,
> >
> > We are porting our visual studio based build system to cmake and its
> > allmost done with some minor problems.
> >
> > One of the minor problem is default visual c++ filters (source groups)
> > I don't like (actually hate) visual c++'s default *.cpp *.h filters. (Not
> > the filter feature but the default filters) They make navigation hard at
> > solution explorer and I want source and header file to be listed next to
> > each other.
> > Therefore I want all of my source files to be not included in a filter
> and
> > remove "Source Files" and "Header Files" filters.  I have read the
> > documentation and exprimented with SOURCE_GROUP command but I can not
> > figure out how to remove default *.cpp and *.h source groups.
> >
> > Also I'm going to add a special regex filter that combines auto generated
> > source codes in to a filter. Something like
> > source_group (ZPP REGULAR_EXPRESSION ".*\\.zpp")
> >
> >
> > How can I do that ?
> >
> > Thanks every one,
> > Orçun___
> > 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
>
> ___
> 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] How too set properties on all executables

[Yuri Timenkov]

Is changing global compiler/linker flags for all executables an option?

When you enable "show advanced options" in CMake, you should see them as
CMAKE_EXE_LINKER_FLAGS_.

Also, if you want to set them initially by your build system, use

set(CMAKE_USER_MAKE_RULES_OVERRIDE MyInitialFlags)

This "MyInitialFlags.cmake" is processed after compiler is determined and
you can modify flags. But note, that they have "_INIT" suffix. For example,

if(WIN32)
set(CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT
"${CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT} /SUBSYSTEM:WINDOWS")
endif()

Later the cache will be populated from these _INIT variables (when you call
project() or enable_language() command).

On Thu, Feb 24, 2011 at 11:34 PM, Hanna Symanska wrote:

> Hey,
> I have a fairly large project with multiple executables, about 90 to
> be exact and I would like to set the subsystem based on the
> LINK_FLAGS_* property.
> Is there a way for me to globally set this up in a top level
> CMakeLists.txt file so that i do not have to place the below code in
> every single project.
> add_executable(project_n )
> IF (WIN32)
>   SET_TARGET_PROPERTIES(project_n PROPERTIES LINK_FLAGS_RELEASE
> "/INCREMENTAL:NO /NODEFAULTLIB:LIBCMT.lib /SUBSYSTEM:WINDOWS" )
>   SET_TARGET_PROPERTIES(project_n PROPERTIES LINK_FLAGS_RELWITHDEBINFO
> "/NODEFAULTLIB:LIBCMT.lib /SUBSYSTEM:WINDOWS" )
>   SET_TARGET_PROPERTIES(project_n PROPERTIES LINK_FLAGS_DEBUG
> "/NODEFAULTLIB:LIBCMTD.lib /SUBSYSTEM:CONSOLE" )
> ENDIF (WIN32)
>
> As it stands right now I have a top level CMakeLists.txt file with
> several other CMakeLists.txt files in subsequent directories.
> I have 1 CMakeLists.txt per project executable. I am trying to avoid
> putting the above code in EVERY CMakeLists.txt file, when the only
> thing I am changing is the target to reflect the the project that I am
> setting the properties on.
> I am using CMake 2.8.4 to generate visual studio 2008 project files to
> be compiled 64-bit.
> I do not want to use set_executable(project_n WIN32...) because I want
> the subsystem to be console for projects that are being compiled as
> debug.
> - Hanna
> ___
> 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

[CMake] Preferred way to use 3rd-party dependencies

[Yuri Timenkov]

Dear all,

I haven't been using CMake (and hence following) for almost 3 years and I
suppose it has a big progress since 2.4.

Now I'm looking for most kosher way to specify external dependencies for a
particular project. The most straightforward way of specifying include dirs
and libraries when porting from Visual Studio - is using include_directories
& link_directories commands. However, I heard that link_directories is not
very good idea and the preferred way is using imported targets.

Some libraries are internal but built by separate teams for different
compilers version. Also we don't need to find library & include dir's
location, we know them in advance (and it is rather fixed).

So may be there are some guides, and discussions or examples about recent
Find* modules behavior?

Thanks in advance,
Yuri
___
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] shared libraries on windows

[Yuri Timenkov]

On Tuesday 29 July 2008 14:27:44 christian wrote:
> Hello:
>
> I am starting with cmake in order to have my project running on both
> linux and windows.
>
> In my project I create a library and several console tools linked with
> this library.
>
> I would like to use shared libraries (.so in linux and .dll in windows)
>
> In my CMakeLists.txt I have for the library target domething like:
>
> ADD_LIBRARY(MYLIB SHARED ${MYLIB_SRC})
>
> The tools are linked like:
>
> TARGET_LINK_LIBRARIES(Tool1 MYLIB)
>
> In Linux and Cygwin this works fine. However in Windows cmake creates
> the dll file but tries to link with the .lib file, which does not exist.
>
> Can anybody help me?
You didn't export symbols from your library.
Write header like this:

#ifdef _WIN32
#   ifdef MYLIB_EXPORTS
#   define MYLIB_API __declspec(dllexport)
#   else
#   define MYLIB_API __declspec(dllimport)
#   endif
#else
#   define MYLIB_API
#endif // WIN32
(Or look into classes which Visual Studio generates for you).

And prefix all your classes and functions:
class MYLIB_API MyClass
{};
int MYLIB_API myFunction();

CMake will automatically define symbol MYLIB_EXPORTS when compiling your 
library.

Alternatively you can use .def files for linker.

>
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] What's the point for making component-specific directory for CPack?

[Yuri Timenkov]

On Monday 28 July 2008 22:04:57 Doug Gregor wrote:
> On Mon, Jul 28, 2008 at 1:48 PM, Yuri Timenkov <[EMAIL PROTECTED]> 
wrote:
> > On Monday 28 July 2008 21:16:25 Doug Gregor wrote:
> >> On Mon, Jul 28, 2008 at 12:45 PM, Yuri Timenkov
> >> <[EMAIL PROTECTED]>
> >>
> >> > I suppose for RPM there could be each top-level
> >> > group - is a RPM archive which includes all components and subgroups.
> >>
> >> I'd suggest each top-level group and component, since components don't
> >> have to be in groups.
> >
> > I meant in this context "groupless" components are top-level groups.
>
> Okay.
>
> >> > I want to make generating of rpm single-pass, that is one spec
> >> > contains multiple %files sections. But rpm needs all files to be
> >> > installed into single build directory. Moreover, one file can be in
> >> > different packages and when several packages are generated from single
> >> > spec, it's OK for rpm, but I'm not sure about different specs.
> >>
> >> Interesting. Are there other advantages to building multiple RPMs in a
> >> single pass?
> >
> > packaging time, dependency tracking (if one file is in different rpms
> > generated from one spec, they can be installed at the same time without
> > conflict), timestamps, single debug package for multiple binary packages.
>
> Okay, I'm convinced :)
>
> >> It probably has to be a virtual function that decides whether
> >> components need to be installed into separate directories or into a
> >> single directory. When installing all of the components into a single
> >> directory, you'll need a way to determine which files came from which
> >> components. You could do that either by incrementally installing
> >> components and walking the installed directory tree each time to see
> >> what changed, or by finding and reading the manifests that CMake
> >> writes when it installs a component.
> >
> > Yes, I was looking again to manifests... Why does CPack uses globs to
> > determine file list?
>
> I don't know :)
>
> With INSTALL(DIRECTORY), we don't know what files will be installed
> until after we've told CMake to do the installation, so we can either
> look at what was installed or read the manifest. I wasn't around when
> this decision was made for CPack.
>
> > I supposed it is good form to add custom actions to
> > CMAKE_INSTALL_MANIFEST_FILES list.
>
> Probably, but that doesn't mean that people actually do this properly.
> If we're going to start relying on manifests, we should probably also
> add some code to produce a warning or error when a file not mentioned
> in a manifest is installed; otherwise, we'll get a bunch of bug
> reports along the lines of "my CPack installation used to work, but
> now it's missing files!"
>
> So, I guess a virtual function bool
> componentInstallsInSeparateDirectories(), for which the PackageMaker
> and NSIS generators return "true" but the RPM generator returns false,
> is what we'll need.
This is really not needed, because tempInstallDirectory used only if 
SET_DESTDIR is OFF :) Otherwise, everything is installed into 
baseTempInstallDirectory. Also I noticed, that realInstallDirectory variable 
is not longer used, so you can have a troubles in projects which set forth 
parameter in CPACK_INSTALL_CMAKE_PROJECTS to something other than "/".

So things with DESTDIR get really bad and too generator-dependent. What will 
happen if someone try to create RPM package without DESTDIR but with default 
/usr prefix? Will rpmbuild pack everything in my system (I didn't try :) ).

>
>   - Doug

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Debug libraries

[Yuri Timenkov]

On Monday 28 July 2008 22:14:51 Leopold Palomo-Avellaneda wrote:
> Hi,
>
> I'm not a windows user and now, sadly, I have to develop an application
> with Visual Studio 2005. I'm porting an application that use OpenGL,
> Coin3d, SoQt and Qt4.4.
>
> I have created the respective FindSoQt and FindCoin that reports me the
> libraries with the two versions (debug and release).
>
> One thing that i have not be able to solve is that when I create the MS
> Visual Studio Project, in the Debug option, the Qt libraries are the debug
> ones (with d) and in the release are the "normal" (without d). However, I
> couldn't do the same with the others and I don't know how I can tell
> MSStudio that when compile in Debug chose the debug ones.
>
> I have created my Find... with _LIBRARY and _LIBRARY_DEBUG.
It's better to have 3 variables:
XXX_LIBRARY_RELEASE, XXX_LIBRARY_DEBUG and XXX_LIBRARY.
First ones are determined with find_library, the latter one:
if(XXX_LIBRARY_RELEASE AND XXX_LIBRARY_DEBUG)
set(XXX_LIBRARY optimized ${XXX_LIBRARY_RELEASE} debug 
${XXX_LIBRARY_DEBUG})
endif(XXX_LIBRARY_RELEASE AND XXX_LIBRARY_DEBUG)

and link your applications to XXX_LIBRARY. Mike's script does same thing but a 
bit more generalized. Also, you can look to FindBoost.cmake. But the key point 
is to use "debug" and "optimized" keywords.

>
> Any idea?
>
> Regards,
>
> Leo
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Feature wish - constrained string values f or configuration options

[Yuri Timenkov]

On Friday 25 July 2008 12:58:42 Robert Haines wrote:
> On 24 Jul 2008, at 23:17, Alexander Neundorf wrote:
> > On Thursday 24 July 2008, Robert Haines wrote:
> >> On 18 Jul 2008, at 18:40, Bill Hoffman wrote:
> >
> > ...
> >
> >>> However, it is not that easy to implement, since the basic type in
> >>> CMake is a string.  There is no way to constrain the value of a
> >>> variable, or even store more information about a variable.
> >>
> >> I decided to knock something up using macros that does what I need.
> >> It
> >> obviously doesn't constrain choices in a UI or provide a drop down
> >> menu but it does raise an error if the user tries to configure a
> >> project with a value set outside of a list of allowed values. It does
> >> enough for me for now and hopefully someone else will find it useful.
> >>
> >> There are two versions. My first attempt needs you to define your
> >> variable first:
> >> set(TEST_OPT "None" CACHE STRING "Some Documentation")
> >> then call the assert_option macro like this:
> >> assert_option(${TEST_OPT} "TEST_OPT" "None, One, Two, Three")
> >>
> >> But I felt that was a little ungainly so my second attempt is called
> >> like this (without a prior "set"):
> >> select_option(VARIABLE INITIAL-VALUE ALLOWED-VALUE-LIST
> >> DOCUMENTATION)
> >> example:
> >> select_option(TEST_OPT "None" "None, One, Two, Three" "Some
> >> Documentation")
> >>
> >> You can grab it straight from my git repository here:
> >> http://git.kato.mvc.mcc.ac.uk/zzcgurh/option-macros.git/
> >>
> >> If you just want a tarball use the "snapshot" link on that page - you
> >> want the line with the yellow "v-1.0" tag on it.
> >>
> >> Once you've got it (and un-tarred it) you can just point ccmake at
> >> the
> >> directory as it has a full top-level CMakeLists.txt which uses both
> >> forms of the macro.
> >
> > The problem with that is that you can still set the variable to
> > different
> > values afterwards, and I guess this is what Bill means with "there
> > is no way
> > to constrain the value".
>
> What to you mean by "afterwards"? In the CMakeCache.txt? In the
> Makefiles? There comes a point where CMake has to say "you do that and
> you're on your own". I can only test on Makefile type builds so I
> don't know to what extent this sort of thing can be messed about with
> in an IDE such as VS or Xcode. Actually, I'd be surprised if most
> IDE's don't have an enum type that this sort of thing could be passed
> through as.
In sub-makefiles you can override variables. But check them only once. 
Moreover, user can push/pop such variables or some of them can be properties.

As for GUI hints, it is better to write descriptive help comments. Or make 
format of strings predefined (but I don't think its a good idea).

>
> > So I guess it's not good enough as a generic solution for cmake :-/
>
> Of course not, the real solution (if there is one) needs to go into
> the CMake core code rather than as a macro.
>
> How does the CMAKE_BUILD_TYPE set of options handle this type of
> thing? It looks like it just ignores it if it's set to something that
> it doesn't recognise but I find it hard to believe that that is a
> better solution than at least some minimal checking. At the moment you
> could set CMAKE_BUILD_TYPE to Relese by mistake and never be told that
> it's a nonsense value!
It's a point. Also, some people prefer to check that source dir != binary dir.

>
> Cheers,
> Rob
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPACK installation path configuration

[Yuri Timenkov]

On Wednesday 23 July 2008 15:38:52 Johnson, Hans wrote:
> Yuri,
>
> Thanks for your help.  The problem was that I needed to set both
> CPACK_PACKAGING_INSTALL_PREFIX  and CPACK_PACKAGE_DEFAULT_LOCATION  to get
> the desired behavior.  I'm still not sure how these two options interact to
> produce the correct result.
>
> SET(CPACK_PACKAGING_INSTALL_PREFIX "/")
> SET( CPACK_PACKAGE_DEFAULT_LOCATION "/opt/${CPACK_PACKAGE_NAME}")
>
> >From my testing my guess is that the install path is constructed as:
>
> ${CPACK_PACKAGE_DEFAULT_LOCATION}/${CPACK_PACKAGING_INSTALL_PREFIX}/...
As I understand CPACK_PACKAGE_DEFAULT_LOCATION is Mac-specific option which is 
used by PackageMaker when installing pkg.
I suppose you need to fix CMAKE_INSTALL_PREFIX in top-level CMakeLists.txt. I 
use following technique:
# Replace CMAKE_INSTALL_PREFIX to Currently used one,
# If it wasn't overridden from command line / cache.
if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
set(CMAKE_INSTALL_PREFIX "/opt/MyProduct" CACHE PATH "Install path 
prefix, 
prepended onto install directories." FORCE)
endif(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)

And to avoid putting stuff in /usr, you should set 
CPACK_PACKAGING_INSTALL_PREFIX to "/" (or CPACK_SET_DESTDIR to true).

>
>
> Again,
> Thanks,
> Hans
>
> On 7/23/08 2:29 AM, "Yuri Timenkov" <[EMAIL PROTECTED]> wrote:
> > What is your CMAKE_INSTALL_PREFIX? And where your product installs with
> > make install command?
> > Did you use CPACK_SET_DESTDIR?
> >
> > On Wednesday 23 July 2008 00:51:46 Hans Johnson wrote:
> >> Hello,
> >>
> >> I¹ve been trying to figure out how to use CPACK to distribute my package
> >> as a dmg, rpm, and tar.gz files.  I¹ve been able to successfully create
> >> the files, but the locations where the resulting files are being put are
> >> not as desired.
> >>
> >> I¹d like the resulting binary to be installed in
> >> /opt/BRAINSFit/bin/BRAINSFit
> >> Currently PackageMaker installs in /opt/BRAINSFit/usr/bin/BRAINSFit and
> >> RPM installs in /usr/bin/BRAINSFit.
> >>
> >> The  CMakeList.txt files are included in my previous message.
> >>
> >> Any help or suggestions on what to try would be enormously appreciated.
> >>
> >> Thanks,
> >> Hans
> >>
> >>
> >>
> >> From: Johnson Hans <[EMAIL PROTECTED]>
> >> Date: Sat, 19 Jul 2008 12:29:48 -0500
> >> To: 
> >> Subject: CPACK installation path configuration
> >>
> >> Hello,
> >>
> >> I am trying to use cpack to create distributions of a project available
> >> on NITRC:
> >> svn checkout https://www.nitrc.org/svn/multimodereg BRAINSFit
> >>
> >> I¹d like the resulting binary to be installed in
> >> /opt/BRAINSFit/bin/BRAINSFit
> >>
> >> Currently PackageMaker installs in /opt/BRAINSFit/usr/bin/BRAINSFit and
> >> RPM installs in /usr/bin/BRAINSFit.
> >>
> >> Can someone please help me fix my CPACK variables so that the desired
> >> install locations are respected?
> >>
> >> ==
> >> I¹m using CMake 2.6.0
> >>
> >> Any other advise about CPACK style issues would also be appreciated
> >> because I¹ll be repeating this process for several other packages next
> >> week.
> >>
> >> Thanks,
> >> Hans
> >>
> >> CMakeLists.txt
> >> PROJECT(BRAINSFit)
> >> cmake_minimum_required(VERSION 2.6)
> >> cmake_policy(VERSION 2.6)
> >>
> >> INCLUDE(${BRAINSFit_SOURCE_DIR}/IJMacros.txt)
> >>
> >> #the following are required to uses Dart
> >> ENABLE_TESTING()
> >> INCLUDE(Dart)
> >>
> >> #---
> >>--- - --
> >> # Output directories.
> >>  IF(NOT LIBRARY_OUTPUT_PATH)
> >>SET (LIBRARY_OUTPUT_PATH ${BRAINSFit_BINARY_DIR}/bin CACHE INTERNAL
> >> "Single output directory for building all librari
> >> es.")
> >>  ENDIF(NOT LIBRARY_OUTPUT_PATH)
> >>  IF(NOT EXECUTABLE_OUTPUT_PATH)
> >>SET (EXECUTABLE_OUTPUT_PATH ${BRAINSFit_BINARY_DIR}/bin CACHE
> >> INTERNAL "Single output directory for building all exec
> >> utables.")
> >>  ENDIF(NOT EXECUTABLE_OUTPUT_PATH)
> >>  MARK_AS_ADVANCED(LIBRARY_OUTPUT_PATH EXECUTABLE_OUTPUT_PATH)
> >>
> >>
> >> OPTION(BUILD_AGAINST_SLICER3 &

Re: [CMake] can a dependency be added to a specific test (CXX Test)?

[Yuri Timenkov]

On Wednesday 23 July 2008 07:50:18 Edward Flanigan wrote:
> I am trying to create a test.
>
> The traditional way uses the command :   add_test (simpleTest executable)
> I want to know if there is any way to add a dependency to a specific test?
> CMake does not recognize simpleTest as a target.
>
> For my application I am trying to use cxx test.
> A script (executable) is ran which produces a *.cpp file.
> That file is then compiled to an executable test (simpleTest).
>
> The target for the test (creating the *.cpp and test executable) should
> only build with command 'make test' A simple 'make' should not build the
> target of the test (create *.cpp and test executable)
>
>
> The way I have gotten this to work in the past is to have a new "Simple"
> project for the simple test, and use add_custom_command within the Simple
> project to generate the *.cpp file.
>
> add_test (simpleTest ${CMAKE_CTEST_COMMAND}
> --build-and-test "a directory/test"
>
>  "a directory/test"
>
> --build-generator ${CMAKE_GENERATOR}
> --build-makeprogram ${CMAKE_MAKE_PROGRAM}
> --build-project Simple
> --test-command simple)
>
> The add_test command calls the "Simple" project, builds the executable
> (simple) and then runs the test (simpleTest).
>
> If possible I want to avoid having to create a new project because my
> application requires that a lot of shell variables be set as well as a lot
> of libs to be linked in.
Macros can help you. Also, you can store essential part of your environment at 
CMake time and pass to test build with --build-options defines to make latter 
"environment-independent". Or you can dump it into some file on your build 
directory and load it later when building test. Also, you can use cmake in 
script-mode to load environment and build your complex target:
Instead of:
  CMakeLists.txt:
add_custom_command(myscript.sh)

Use:
  GenerateTest.cmake:
set(ENV{MyVal} foo)
execute_process(myscript.sh)
  CMakeLists.txt:
add_custom_command(cmake -P GenerateTest.cmake -DParam1=val1)

>
> When I call  'make test'
> I want the following:
> 1.) have the script execute to create a *.cpp file,
> 2.) build the test executable from the *.cpp file
> 3.) run the test.
> 4.) This all must be done without calling new projects
>
> My thoughts are the following:
> If I could add a dependency to a specific test,
> I could use target property "EXCLUDE_FROM_ALL" to make sure the test *.cpp
> and executable are only created during 'make test' and not during 'make'.
Also, you can look at KDE's add_test wrappers, they have some ideas about how 
to exclude tests from regular build, but they rely on BUILD_TESTS define too.

>
>
> Thanks in advance for any help.
>
>
>
>
>
> _
> Time for vacation? WIN what you need- enter now!
> http://www.gowindowslive.com/summergiveaway/?ocid=tag_jlyhm
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] find_package New features request

[Yuri Timenkov]

On Monday 21 July 2008 16:21:43 Alin M Elena wrote:
> Hi,
>
> I try to rewrite a module BLAS.
>
> After an analysis I realised that find_package as it stands now may not be
> enough for the functionality that I need.
>
> for BLAS it happens to be found in many forms supplied by different
> vendors. So I thought that an optional argument Vendor would be useful.
>
> Another issues is deciding what you want: static or dynamic linkage.
> This is an old discussion and some solution were suggested on the list.
>
> To make it portable again would be useful if inside the Findxxx.cmake you
> know what kind at linkage the user wants.
> Again some methods were presented on the list but they need running
> external tools. I would suggest an optional parameter STATIC for
> find_package.

This can be worked around in current implementation. Look into FindBoost.cmake 
in 2.6 version.

>
>
> Alin

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CTest + unit test frameworks integration

[Yuri Timenkov]

On Friday 18 July 2008 22:38:26 Alexander Neundorf wrote:
> On Friday 18 July 2008, Yuri Timenkov wrote:
> > Does anyone have an experience in integrating Unit test frameworks with
> > CTest? AFAIK many of such frameworks provide means to register tests and
> > test cases, and it would be nice to make ctest aware of such things,
> > because it's not good to make changes in multiple places when I add new
> > test.
> >
> > I know, KDE has some things, but their approach doesn't allow to run
> > single test.
>
> Do you mean with a "single" test a single test executable with all tests or
> a single test within a single test executable ?
> If there is something bad, of course we'll try to fix it.
I mean QTest allows to have multiple tests in single executable. So with CTest 
you have 2 options:
1) run all QTest tests as single CTest test (as it is works now).
2) Add custom CTest target which runs only selected tests.

This is just an idea how to have multiple tests in single executable and 
ability to invoke each of them from CTest.

>
> Alex
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CTest + unit test frameworks integration

[Yuri Timenkov]

Does anyone have an experience in integrating Unit test frameworks with CTest? 
AFAIK many of such frameworks provide means to register tests and test cases, 
and it would 
be nice to make ctest aware of such things, because it's not good to make 
changes in multiple places when I add new test.

I know, KDE has some things, but their approach doesn't allow to run single 
test. May be I'm wrong and it's complete ctest misusage...

I Just played with googletest (http://code.google.com/p/googletest) and came to 
such macro:

macro(ADD_UNIT_TESTS executable source)
file(READ "${source}" contents)
string(REGEX MATCHALL "TEST_?F?\\(([A-Za-z_ ,]+)\\)" found_tests 
${contents})
foreach(hit ${found_tests})
string(REGEX REPLACE ".*\\(([A-Za-z_]+)[, ]*([A-Za-z_]+)\\).*" 
"\\1.\\2" test_name ${hit})
add_test(${test_name} ${executable} --gtest_filter=${test_name})
endforeach(hit)
endmacro(ADD_UNIT_TESTS)

This way you automatically propagate all tests and test-cases from sources to 
CTest.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Staticly Link to VC++ Runtime

[Yuri Timenkov]

On Friday 18 July 2008 13:33:59 Mike Arthur wrote:
> I'm trying to distribute my application to Windows users and am getting
> some fairly horrendous grief with manifests.
>
> Can anyone advise how I'd get CMake to statictly link against the msvc*.dll
> files that my application needs when compiled with MSVC++?
According to MSDN you have 2 options:
1) add _STATIC_CPPLIB define.
2) Change compiler flags /MD -> /MT, /MDd -> /MTd (look into  
CMAKE_CXX_FLAGS_*)

>
> Thanks!

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] static libs and more

[Yuri Timenkov]

On Thursday 17 July 2008 23:00:15 Alin M Elena wrote:
> Hi,
>
> 1. Few days ago maybe weeks on the list I have seen a discussion about
> static/dynamic linking.
>
> One of the solution proposed there to achieve a static linking was
>
> if (UNIX)
>   set(CMAKE_FIND_LIBRARY_SUFFIXES ".a;.so")
> endif(UNIX)
> Something similar can be done for windows I suspect.
>
> Maybe you can add an extra argument to find_package(... USE_STATIC)
> and internally in FindXXX.cmake to use it to find the correct linkage. Just
> an idea.
The main problem AFAIK for VS is that static and dynamic libraries are 
indistinguishable by extension. They both have a .lib one. And you don't know 
in advance is some library is static one or just import library for some 
dynamic one.

For cygwin/mingw things may be more similar to Unix.

>
> 2. I read in one post that intel was interested in cmake, fortran and
> Visual Studio.
> Having the connections with them you could ask them if they may be
> interested in cmake and MKL. Just a thought as linking against mkl (pure
> layered versions) may be quite a pain for a new user.
>
> Alin

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Using try_compile before project() command

[Yuri Timenkov]

On Wednesday 16 July 2008 16:20:30 Bill Hoffman wrote:
> Carminati Federico wrote:
> > Hello,
> >my use case is similar. My package depends on another one that can be
> > installed with different compiler choices. So the first action I take is
> > always to check the compiler used to install the other package and then
> > to use the same. I could obviously do
> >
> > export CXX=`root-config --cxx` ; export CC=`root-config -cc` ;  cmake .
> >
> > but I would really prefer to do everything inside the CMakeLists.txt.
> > This is easy to do with the Fortran compiler, as I enable Fortran after
> > having chosen the compiler. For the moment i set also the c and cxx
> > compilers and it works, but this is explicitly "deprecated" by the CMake
> > doc. BEst,
>
> You might want to wrap cmake into a script of some sort for that machine.
Or you can compare ${CMAKE_C_COMPILER} with "root-config --cc" output after 
determined correct library paths to ensure right choice.

>
> -Bill

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Using try_compile before project() command

[Yuri Timenkov]

On Tuesday 15 July 2008 20:28:27 Yuri Timenkov wrote:
> On Tuesday 15 July 2008 20:01:52 Bill Hoffman wrote:
> > Carminati Federico wrote:
> > > Hello Yuri,
> > >   I posted a similar question some time ago. There seems to be no way
> > > to chose the compiler within the CMakeList.txt, because you can do very
> > > little before the Project command, and afterwards it is too late.
> > > Anybody can help here? best, regards,
> >
> > That is a very different question, and no, you can not change the
> > compiler from within a CMakeLists.txt file.  It must be picked with CC
> > or CXX environment variables before running CMake.
>
> Yes, I just want to tune build environment but allow user to change it
> later. KDE, for example, overrides ones later by specifying COMPILE_FLAGS
> variables in CMake scripts without CACHE option. But such usage seems a bit
> tricky for me, because user doesn't know which flags will be used for build
> (or it's hard to determine place where particular flag came from, when you
> build with VERBOSE=1).
>
> Overriding  CMake defaults seems most clear way, because user will see
> global settings in GUI and target-specific or source files-specific flags
> at the right place in CMakeLists.txt.
>
> > > On 15 Jul 2008, at 15:56, Yuri Timenkov wrote:
> > >> I want to tune initial compile and linker flags to put into cache.
> > >> in main CMakeLists.txt:
> > >>
> > >> # Override default Compiler flags
> > >> set(CMAKE_USER_MAKE_RULES_OVERRIDE MyCompilerFlags)
> > >> project(MyProject)
> > >>
> > >> in MyCompilerFlags.cmake:
> > >>
> > >> check_cxx_linker_flag("-Wl,--warn-unresolved-symbols"
> > >> HAVE_LD_WARN_UNRESOLVED_SYMBOLS)
> > >>
> > >> if(HAVE_LD_WARN_UNRESOLVED_SYMBOLS)
> > >> set(CMAKE_SHARED_LINKER_FLAGS_INIT
> > >> "${CMAKE_SHARED_LINKER_FLAGS_INIT} -Wl,--warn-unresolved-symbols")
> > >> endif(HAVE_LD_WARN_UNRESOLVED_SYMBOLS)
> > >>
> > >> This works fine for CMake 2.4:
> > >> -- Performing Test -Wl,--warn-unresolved-symbols
> > >> -- Performing Test -Wl,--warn-unresolved-symbols - Success
> > >> -- Performing Test -Wl,--no-undefined
> > >> -- Performing Test -Wl,--no-undefined - Success
> > >> -- Check for working C compiler: /usr/bin/gcc32
> > >> -- Check for working C compiler: /usr/bin/gcc32 -- works
> > >> ...
> > >>
> > >> But for CMake 2.6 this code fails with error:
> > >> -- The C compiler identification is GNU
> > >> -- The CXX compiler identification is GNU
> > >> -- Performing Test -Wl,--warn-unresolved-symbols
> > >> CMake Error: Unknown extension ".cxx" for file
> > >> "/vz/build/test/CMakeFiles/CMakeTmp/src.cxx".  TRY_COMPILE only works
> > >> for enabled languages.
> > >> Currently enabled languages are: C CXX
> > >> See PROJECT command for help enabling other languages.
> > >> -- Performing Test -Wl,--warn-unresolved-symbols - Failed
> > >> -- Performing Test -Wl,--no-undefined
> > >> CMake Error: Unknown extension ".cxx" for file
> > >> "/vz/build/test/CMakeFiles/CMakeTmp/src.cxx".  TRY_COMPILE only works
> > >> for enabled languages.
> > >> Currently enabled languages are: C CXX
> > >> See PROJECT command for help enabling other languages.
> > >> -- Performing Test -Wl,--no-undefined - Failed
> > >> -- Check for working C compiler: /usr/bin/gcc32
> > >> -- Check for working C compiler: /usr/bin/gcc32 -- works
> > >> -- Detecting C compiler ABI info
> > >> -- Detecting C compiler ABI info - done
> > >> ...
> > >>
> > >> where check_cxx_linker_flag macro looks line check_cxx_compiler_flag:
> > >>
> > >> file(WRITE
> > >> "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/src.cxx" "int
> > >> main() { return 0;}\n")
> > >> message(STATUS "Performing Test ${_FLAG}")
> > >> try_compile(${_RESULT}
> > >> ${CMAKE_BINARY_DIR}
> > >> "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/src.cxx"
> > >> CMAKE_FLAGS -DCMAKE_EXE_LINKER_FLAGS="${_FLAG}"
> > >> OUTPUT_VARIABLE OUTPUT
> > >> )
> > >>
> > >> Any suggestions?
> >
> > Looks like a bug.   Please file a bug report with a small example that
> > is easy to reproduce.
>
> I'll try to figure out the problem.
I filed an issue: http://public.kitware.com/Bug/view.php?id=7340

>
> > Thanks.
> >
> > -Bill
>
> P.S. Did you think about "Best practices" category on wiki? Many people ask
> similar questions on list, and some of them are kind of "is it moral in
> CMake?" Because there is a lot of such questions, FAQ will be too long.
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Using try_compile before project() command

[Yuri Timenkov]

On Tuesday 15 July 2008 20:01:52 Bill Hoffman wrote:
> Carminati Federico wrote:
> > Hello Yuri,
> >   I posted a similar question some time ago. There seems to be no way to
> > chose the compiler within the CMakeList.txt, because you can do very
> > little before the Project command, and afterwards it is too late.
> > Anybody can help here? best, regards,
>
> That is a very different question, and no, you can not change the
> compiler from within a CMakeLists.txt file.  It must be picked with CC
> or CXX environment variables before running CMake.
Yes, I just want to tune build environment but allow user to change it later. 
KDE, for example, overrides ones later by specifying COMPILE_FLAGS variables 
in CMake scripts without CACHE option. But such usage seems a bit tricky for 
me, because user doesn't know which flags will be used for build (or it's hard 
to determine place where particular flag came from, when you build with 
VERBOSE=1).

Overriding  CMake defaults seems most clear way, because user will see global 
settings in GUI and target-specific or source files-specific flags at the right 
place in CMakeLists.txt.

>
> > On 15 Jul 2008, at 15:56, Yuri Timenkov wrote:
> >> I want to tune initial compile and linker flags to put into cache.
> >> in main CMakeLists.txt:
> >>
> >> # Override default Compiler flags
> >> set(CMAKE_USER_MAKE_RULES_OVERRIDE MyCompilerFlags)
> >> project(MyProject)
> >>
> >> in MyCompilerFlags.cmake:
> >>
> >> check_cxx_linker_flag("-Wl,--warn-unresolved-symbols"
> >> HAVE_LD_WARN_UNRESOLVED_SYMBOLS)
> >>
> >> if(HAVE_LD_WARN_UNRESOLVED_SYMBOLS)
> >> set(CMAKE_SHARED_LINKER_FLAGS_INIT
> >> "${CMAKE_SHARED_LINKER_FLAGS_INIT} -Wl,--warn-unresolved-symbols")
> >> endif(HAVE_LD_WARN_UNRESOLVED_SYMBOLS)
> >>
> >> This works fine for CMake 2.4:
> >> -- Performing Test -Wl,--warn-unresolved-symbols
> >> -- Performing Test -Wl,--warn-unresolved-symbols - Success
> >> -- Performing Test -Wl,--no-undefined
> >> -- Performing Test -Wl,--no-undefined - Success
> >> -- Check for working C compiler: /usr/bin/gcc32
> >> -- Check for working C compiler: /usr/bin/gcc32 -- works
> >> ...
> >>
> >> But for CMake 2.6 this code fails with error:
> >> -- The C compiler identification is GNU
> >> -- The CXX compiler identification is GNU
> >> -- Performing Test -Wl,--warn-unresolved-symbols
> >> CMake Error: Unknown extension ".cxx" for file
> >> "/vz/build/test/CMakeFiles/CMakeTmp/src.cxx".  TRY_COMPILE only works
> >> for enabled languages.
> >> Currently enabled languages are: C CXX
> >> See PROJECT command for help enabling other languages.
> >> -- Performing Test -Wl,--warn-unresolved-symbols - Failed
> >> -- Performing Test -Wl,--no-undefined
> >> CMake Error: Unknown extension ".cxx" for file
> >> "/vz/build/test/CMakeFiles/CMakeTmp/src.cxx".  TRY_COMPILE only works
> >> for enabled languages.
> >> Currently enabled languages are: C CXX
> >> See PROJECT command for help enabling other languages.
> >> -- Performing Test -Wl,--no-undefined - Failed
> >> -- Check for working C compiler: /usr/bin/gcc32
> >> -- Check for working C compiler: /usr/bin/gcc32 -- works
> >> -- Detecting C compiler ABI info
> >> -- Detecting C compiler ABI info - done
> >> ...
> >>
> >> where check_cxx_linker_flag macro looks line check_cxx_compiler_flag:
> >>
> >> file(WRITE
> >> "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/src.cxx" "int
> >> main() { return 0;}\n")
> >> message(STATUS "Performing Test ${_FLAG}")
> >> try_compile(${_RESULT}
> >> ${CMAKE_BINARY_DIR}
> >> "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/src.cxx"
> >> CMAKE_FLAGS -DCMAKE_EXE_LINKER_FLAGS="${_FLAG}"
> >> OUTPUT_VARIABLE OUTPUT
> >> )
> >>
> >> Any suggestions?
>
> Looks like a bug.   Please file a bug report with a small example that
> is easy to reproduce.
I'll try to figure out the problem.

>
> Thanks.
>
> -Bill

P.S. Did you think about "Best practices" category on wiki? Many people ask 
similar questions on list, and some of them are kind of "is it moral in 
CMake?" Because there is a lot of such questions, FAQ will be too long.

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Using try_compile before project() command

[Yuri Timenkov]

I want to tune initial compile and linker flags to put into cache.
in main CMakeLists.txt:

# Override default Compiler flags
set(CMAKE_USER_MAKE_RULES_OVERRIDE MyCompilerFlags)
project(MyProject)

in MyCompilerFlags.cmake:

check_cxx_linker_flag("-Wl,--warn-unresolved-symbols" 
HAVE_LD_WARN_UNRESOLVED_SYMBOLS)

if(HAVE_LD_WARN_UNRESOLVED_SYMBOLS)
set(CMAKE_SHARED_LINKER_FLAGS_INIT "${CMAKE_SHARED_LINKER_FLAGS_INIT} 
-Wl,--warn-unresolved-symbols")
endif(HAVE_LD_WARN_UNRESOLVED_SYMBOLS)

This works fine for CMake 2.4:
-- Performing Test -Wl,--warn-unresolved-symbols
-- Performing Test -Wl,--warn-unresolved-symbols - Success
-- Performing Test -Wl,--no-undefined
-- Performing Test -Wl,--no-undefined - Success
-- Check for working C compiler: /usr/bin/gcc32
-- Check for working C compiler: /usr/bin/gcc32 -- works
...

But for CMake 2.6 this code fails with error:
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Performing Test -Wl,--warn-unresolved-symbols
CMake Error: Unknown extension ".cxx" for file 
"/vz/build/test/CMakeFiles/CMakeTmp/src.cxx".  TRY_COMPILE only works for 
enabled languages.
Currently enabled languages are: C CXX
See PROJECT command for help enabling other languages.
-- Performing Test -Wl,--warn-unresolved-symbols - Failed
-- Performing Test -Wl,--no-undefined
CMake Error: Unknown extension ".cxx" for file 
"/vz/build/test/CMakeFiles/CMakeTmp/src.cxx".  TRY_COMPILE only works for 
enabled languages.
Currently enabled languages are: C CXX
See PROJECT command for help enabling other languages.
-- Performing Test -Wl,--no-undefined - Failed
-- Check for working C compiler: /usr/bin/gcc32
-- Check for working C compiler: /usr/bin/gcc32 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
...

where check_cxx_linker_flag macro looks line check_cxx_compiler_flag:

file(WRITE "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/src.cxx"
"int main() { return 0;}\n")
message(STATUS "Performing Test ${_FLAG}")
try_compile(${_RESULT}
${CMAKE_BINARY_DIR}
"${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/src.cxx"
CMAKE_FLAGS -DCMAKE_EXE_LINKER_FLAGS="${_FLAG}"
OUTPUT_VARIABLE OUTPUT
)

Any suggestions?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] The reason of /STACK:10000000 linker flag on Visual Studio

[Yuri Timenkov]

Hi,
We encountered a problem with this option: Such big stack sizes negatively 
affect threads count.

Numbers: with 10Mb stacks it is possible to create ~195 threads on 32-bit 
system, with default 1Mb stacks it is possible to create ~2000 threads on the 
same system.

So why does CMake need such huge stacks? And are such stacks necessary for 
every program (even C++)?

Thanks.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] An example of DEFINE_SYMBOL please

[Yuri Timenkov]

On Monday 07 July 2008 19:59:24 Mehdi Rabah wrote:
> Hi,
>
> I need to set multiple symbols in one of my target of my project. I can't
> use add_definitions because I don't want to define those variable for all
> my targets, so I tried custom properties.
>
> set_target_properties( target PROPERTIES DEFINE_SYMBOL  VALUE1 VALUE2 )
> doesn't work : the function doesn't expect this number of variables.
>
> if I try :
>
> set( var "VALUE1 VALUE2" ).
> set_target_properties( target PROPERTIES DEFINE_SYMBOL  ${var} )
>
> I get
>
> c1xx : fatal error C1083: 'VALUE2': No such file or directory
>
> I'm working with the microsoft compiler, and cmake 2.6.
I just discovered nice feature: COMPILE_DEFINITIONS property.
That is you can add custom defines to source files, targets or directories 
(with 
commands set_source_files_properties, set_target_properties and 
set_directory_properties commands accordingly).

Moreover, COMPILE_DEFINITIONS can be configuration-specific, like 
COMPILE_DEFINITIONS_DEBUG.

>
> Any thoughts ?
>
> Regards,
> --
> Mehdi

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] DLL runtime error R6034

[Yuri Timenkov]

On Tuesday 08 July 2008 13:38:25 Mehdi Rabah wrote:
> Hi,
>
> Does anyone had this error
> http://msdn.microsoft.com/en-us/library/ms235560(VS.80).aspx while using a
> DLL built this cmake?
>
> My application (also built with cmake) works fine on Release mode, I get
> this error only in Debug configuration. In the old project (visual studio
> files only) the application seems to work in debug and release without
> problems. I've looked into the compiler options but I didn't find what
> could be the key difference.
>
> Since I switched from linux to windows recently, I'm really confused. Any
> ideas on how to find where the problem is coming from?
I suppose you use VS 2005?

You should put manifest file with your DLL. For example, I have to put 
"Microsoft.VC80.CRT.manifest" with "msvcr80.dll" to run on systems without MS 
VS 2005 redistributable runtime installed.

>
> Thanks in advance,
> --
> Mehdi

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Patch: Add NO_CACHE option to find_xxx commands

[Yuri Timenkov]

On Monday 07 July 2008 22:04:53 Enrico Scholz wrote:
> "Miguel A. Figueroa-Villanueva" <[EMAIL PROTECTED]>
>
> writes:
> >>> I would like to propose the addition of a NO_CACHE keyword to the
> >>> find_xxx commands that would treat  as a non-cached variable.
> >>
> >> Better wolution would be the equivalent of autoconf's './config.status
> >> --recheck', e.g. reinvoking cmake with empty cache but with original
> >> configuration options.
> >
> > This is not what we want. We want to keep the cache variables since
> > the user might have changed it in the gui.
>
> No; it is exactly what you want.  Just store the original configuration
> (e.g. 'cmake' commandline or items entered into the GUI by user) somewhere
> and rerun 'cmake' on it with an empty cache.
This is possible by using "initial configuration". For example, maintainer can 
prepare text file with options and paths, which should be known before  
configure steps. User after checkout (copies and) modifies it and passes to 
CMake via "-C" parameter.

>
>
> Enrico
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] An example of DEFINE_SYMBOL please

[Yuri Timenkov]

On Monday 07 July 2008 19:59:24 Mehdi Rabah wrote:
> Hi,
>
> I need to set multiple symbols in one of my target of my project. I can't
> use add_definitions because I don't want to define those variable for all
> my targets, so I tried custom properties.
>
> set_target_properties( target PROPERTIES DEFINE_SYMBOL  VALUE1 VALUE2 )
> doesn't work : the function doesn't expect this number of variables.
>
> if I try :
>
> set( var "VALUE1 VALUE2" ).
> set_target_properties( target PROPERTIES DEFINE_SYMBOL  ${var} )
>
> I get
>
> c1xx : fatal error C1083: 'VALUE2': No such file or directory
>
> I'm working with the microsoft compiler, and cmake 2.6.
>
> Any thoughts ?
1) Write with single define symbol. For example, put into some header something 
like this:
#ifdef MYTARGET_EXPORTS
#define VALUE1
#define VALUE2
#endif

2) use set_target_properties( target PROPERTIES COMPILE_FLAGS /DVALUE1 
/DVALUE2 ).
(According to documentation CMake 2.6 supports this, otherwise set 
COMPILE_FLAGS for particular source files).

The latter is not portable, so you have to choose proper flags for every 
compiler.

>
> Regards,
> --
> Mehdi

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake