[CMake] Intel compilers with Visual Studio Project on Windows

[Nicholas Kinar]

Hello,

I am wondering if there is a way to have Cmake use Intel compilers on 
Windows when generating a Visual Studio project file.  Searching around 
the Internet, I found that the following might be used to do this within 
the CMakeLists.txt file:


set_target_properties(inv_spline_interp PROPERTIES PLATFORM_TOOLSET 
"Intel C++ Compiler XE 12.1")


Is this the case for the current version of Cmake, or is a patch 
required?  How do I select the string "Intel C++ Compiler XE 12.1" for 
the most recent version of the Intel compilers?


Thank you,

Nicholas
--

Powered by www.kitware.com

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

Please keep messages on-topic and check 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] WiX Generator Start menu shortcut

[Fredrik Axelsson]

Hi!

The WiX generator supported by the nightly builds will currently not
generate Start Menu Shortcuts. I opened a new ticket in the bugtracker for
this feature.

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

and I attached a patch to enable this.

Best regards,

Fredrik Axelsson
--

Powered by www.kitware.com

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

Please keep messages on-topic and check 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] add_custom_command which generates new sources which I want to specify before

[Eric Noulard]

2013/3/1 Baradé :
> Hi,
> assuming I have the following statements:
>
> add_library(targetName src1 src2 ... generatedSrc)
> add_custom_command(TARGET targetName PRE_BUILD COMMAND bash -c "bla bla
> bla")
>
> and the custom command generates sources which are specified before in
> "add_library" CMake/build process will abort since they don't exist
> already when specified (not needed actually).

Yes they should be flagged as GENERATED, see

cmake --help-property GENERATED

> Unfortunately, since it is an automated process I cannot easily get the
> names of the generated sources, they're just included in the usual
> sources variable (I can't separate them from the others).

You mean you GLOB them or you list them ?
If you list them then

set_source_files_properties(${generatedSrc}
 PROPERTIES GENERATED TRUE)

should be enough.

> Is there any possibility to get this working without knowing the source
> file names?

No I don't think so.

I shall add that this doesn't seem wise not to know the files you'll
have to compile.

if this was possible how would you ensure "clean rebuild" if
you don't even know which would be the generated files?

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

[CMake] add_custom_command which generates new sources which I want to specify before

[Baradé]

Hi,
assuming I have the following statements:

add_library(targetName src1 src2 ... generatedSrc)
add_custom_command(TARGET targetName PRE_BUILD COMMAND bash -c "bla bla 
bla")

and the custom command generates sources which are specified before in 
"add_library" CMake/build process will abort since they don't exist 
already when specified (not needed actually).
Unfortunately, since it is an automated process I cannot easily get the 
names of the generated sources, they're just included in the usual 
sources variable (I can't separate them from the others).
Is there any possibility to get this working without knowing the source 
file names?

regards
--

Powered by www.kitware.com

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

Please keep messages on-topic and check 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] Per-target include dirs that work in both 2.8.7 and 2.8.10.2?

[Jean-Christophe Fillion-Robin]

Hi Magnus,

As already mentioned, the target property INCLUDE_DIRECTORIES has been
introduced in CMake 2.8.8. The following page is useful to find out such
things. See
http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix/Properties#Properties_on_Targets

To get around it, as mentioned by Bill, you could probably create on folder
per target and call include_directories() in each folder.

An other option could be to create a wrapper around the "add_target"
command that would create a directory, write a CMakeLists and then call
add_subdirectory(/path/to/project-build/target target).

Hth
Jc


On Thu, Feb 28, 2013 at 3:32 AM, Magnus Therning wrote:

> The other day I was putting together some cmake files and made them
> work on my system, where I have version 2.8.10.2 installed.  After
> giving my work to a colleague he reported that it didn't work.  It
> came down to him using version 2.8.7 (comes with his Linux distro) and
> my use of
>
> 
> set_property( TARGET app PROPERTY INCLUDE_DIRECTORIES
> 
> )
> 
>
> In the folder in question there is source for several different
> targets, so I'd really like to use per-target include dirs (i.e.
> include_directories would not be a good match).  Is there a mechanism
> for (easily) getting per-target include dirs that work in both these
> versions?
>
> /M
>
> --
> Magnus Therning  OpenPGP: 0xAB4DFBA4
> email: mag...@therning.org   jabber: mag...@therning.org
> twitter: magthe   http://therning.org/magnus
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>



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

Re: [CMake] Per-target include dirs that work in both 2.8.7 and 2.8.10.2?

[Bill Hoffman]

On 2/28/2013 12:29 PM, Alexander Neundorf wrote:

Sorry, no, this is a new feature since cmake 2.8.8.

Alex
Only way to do it before was to make sure each target is in its own 
directory and then manipulate the includes from there.


-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

Re: [CMake] ctest_update with git fetch --tags (was: ctest & git submodules)

[NoRulez]

Thank you very much.

The goal is to have a nightly/continuous build with the tagged version number.

Without the "--tags" option it is only working if we push the changes after 
tagging.

With the "--tags" option it is now also possible to move/overwrite tags which 
gets then updated.

In the projects CMakeLists.txt file we get the current tag/version with "git 
describe --tags"

Maybe there would be alternatives but currently this is working fine. But we 
are open for suggestions.

Best Regards

Am 28.02.2013 um 17:38 schrieb Brad King :

> On 02/28/2013 11:11 AM, NoRulez wrote:
>> I've attached the two log files, can you take a look on it?
> 
> After running "git fetch" CMake reads .git/FETCH_HEAD to determine
> what branch is intended for merge (just as pull does).  This is the
> same as "git pull --tags" failing.  You need to specify the remote
> and branch explicitly to use pull with --tags:
> 
> set(CTEST_GIT_UPDATE_OPTIONS "--tags origin master")
> 
> CMake cannot add this automatically because the entire point of
> reading FETCH_HEAD is that CMake does not try to parse the git
> config to learn this information.
> 
> What is your goal of using --tags?  The ctest_update command's job
> is to follow a tracking branch.  What do tags have to do with that?
> 
> -Brad
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Per-target include dirs that work in both 2.8.7 and 2.8.10.2?

[Alexander Neundorf]

On Thursday 28 February 2013, Magnus Therning wrote:
> The other day I was putting together some cmake files and made them
> work on my system, where I have version 2.8.10.2 installed.  After
> giving my work to a colleague he reported that it didn't work.  It
> came down to him using version 2.8.7 (comes with his Linux distro) and
> my use of
> 
> 
> set_property( TARGET app PROPERTY INCLUDE_DIRECTORIES
> 
> )
> 
> 
> In the folder in question there is source for several different
> targets, so I'd really like to use per-target include dirs (i.e.
> include_directories would not be a good match).  Is there a mechanism
> for (easily) getting per-target include dirs that work in both these
> versions?

Sorry, no, this is a new feature since cmake 2.8.8.

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

Re: [CMake] cmake and MinGW - resolution

[Bill Hoffman]

On 2/28/2013 11:56 AM, Donald Robinson wrote:

Thanks to Bill Hoffmann and Alan Irwin for helping work through this
MinGW problem. As it turns out, the problem in my CMakeLists.txt file
wasn’t the residual presence of a CMakeFiles directory or a
CMakeCache.txt file, or the command-line, which is correctly:

Cmake –G “MinGW Makefiles”

Mea culpa. The source of the problem was due to the fact that the my
parent CMakeLists.txt file dynamically creates and then processes a set
of child CMakeLists.txt files. After creating them, those files (each in
a subdirectory) are run using the following loop in the parent file:

foreach(toProcess ${dirsToProcess})

 execute_process(COMMAND cmake CMakeLists.txt WORKING_DIRECTORY
${toProcess})

endforeach(toProcess)

Although the parent was happily running with the MinGW flags, these
child processes were not. I should have noticed this immediately. The
solution is to embed the MinGW flag within that loop. Doing that, the
build proceeds normally.

foreach(toProcess ${dirsToProcess})

  execute_process(COMMAND cmake –G “MinGW Makefiles” CMakeLists.txt
WORKING_DIRECTORY ${toProcess})

endforeach(toProcess)

The general solution will be to build this out a bit more for different
platforms.




You want to use the CMAKE_GENERATOR variable:
http://www.cmake.org/cmake/help/v2.8.10/cmake.html#variable:CMAKE_GENERATOR

 cmake –G ${CMAKE_GENERATOR}

That should work cross platform.

You may also want to look into external project instead of what you are 
doing...


http://www.cmake.org/cmake/help/v2.8.10/cmake.html#module:ExternalProject
http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html

-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

[CMake] cmake and MinGW - resolution

[Donald Robinson]

Thanks to Bill Hoffmann and Alan Irwin for helping work through this MinGW
problem. As it turns out, the problem in my CMakeLists.txt file wasn't the
residual presence of a CMakeFiles directory or a CMakeCache.txt file, or the
command-line, which is correctly:

 

   Cmake -G "MinGW Makefiles"

 

Mea culpa. The source of the problem was due to the fact that the my parent
CMakeLists.txt file dynamically creates and then processes a set of child
CMakeLists.txt files. After creating them, those files (each in a
subdirectory) are run using the following loop in the parent file:

 

   foreach(toProcess ${dirsToProcess})

execute_process(COMMAND cmake CMakeLists.txt WORKING_DIRECTORY
${toProcess})

   endforeach(toProcess)

 

Although the parent was happily running with the MinGW flags, these child
processes were not. I should have noticed this immediately. The solution is
to embed the MinGW flag within that loop. Doing that, the build proceeds
normally.

 

   foreach(toProcess ${dirsToProcess})

 execute_process(COMMAND cmake -G "MinGW Makefiles" CMakeLists.txt
WORKING_DIRECTORY ${toProcess})

   endforeach(toProcess)

 

The general solution will be to build this out a bit more for different
platforms.

--

Powered by www.kitware.com

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

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

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

Re: [CMake] ctest_update with git fetch --tags (was: ctest & git submodules)

[Brad King]

On 02/28/2013 11:11 AM, NoRulez wrote:
> I've attached the two log files, can you take a look on it?

After running "git fetch" CMake reads .git/FETCH_HEAD to determine
what branch is intended for merge (just as pull does).  This is the
same as "git pull --tags" failing.  You need to specify the remote
and branch explicitly to use pull with --tags:

 set(CTEST_GIT_UPDATE_OPTIONS "--tags origin master")

CMake cannot add this automatically because the entire point of
reading FETCH_HEAD is that CMake does not try to parse the git
config to learn this information.

What is your goal of using --tags?  The ctest_update command's job
is to follow a tracking branch.  What do tags have to do with that?

-Brad
--

Powered by www.kitware.com

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

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

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

[CMake] ctest & git submodules

[NoRulez]

Hello Brad,I've attached the two log files, can you take a look on it?Thanks in advanceBest Regards

Am 28.02.2013 um 16:41 schrieb Brad King :

> On 02/28/2013 10:34 AM, NoRulez wrote:
>> Yes, it is the command which I want.
>> 
>> On the command line the same command works in the source tree.
>> 
>> The command only fails during the CTest run if I set the option.
> 
> Read
> 
> Testing/Temporary/LastUpdate*.log
> 
> in the test build tree for verbose details.
> 
> -Brad
--- Begin Cleanup ---
--- End Cleanup ---
"/usr/bin/git" "rev-list" "-n" "1" "HEAD"
rl-err> fatal: ambiguous argument 'HEAD': both revision and filename
rl-err> Use '--' to separate filenames from revisions
--- Begin Update ---
"/usr/bin/git" "fetch" "--tags"
"/usr/bin/git" "rev-parse" "--git-dir"
rev-parse-out> .git
FETCH_HEAD has no upstream branch candidate!
--- End Update ---
"/usr/bin/git" "rev-list" "-n" "1" "HEAD"
rl-err> fatal: ambiguous argument 'HEAD': both revision and filename
rl-err> Use '--' to separate filenames from revisions
--- Begin Revisions ---
"/usr/bin/git" "rev-list" "--reverse" ".." "--" | "/usr/bin/git" "diff-tree" 
"--stdin" "--always" "-z" "-r" "--pretty=raw" "--encoding=utf-8"
dt-out> 
"/usr/bin/git" "update-index" "--refresh"
"/usr/bin/git" "diff-index" "-z" "HEAD"
di-err> fatal: ambiguous argument 'HEAD': both revision and filename
di-err> Use '--' to separate filenames from revisions
--- End Revisions ---
--- Begin Cleanup ---
--- End Cleanup ---
"/usr/bin/git" "rev-list" "-n" "1" "HEAD"
rl-err> fatal: ambiguous argument 'HEAD': both revision and filename
rl-err> Use '--' to separate filenames from revisions
--- Begin Update ---
"/usr/bin/git" "fetch"
"/usr/bin/git" "rev-parse" "--git-dir"
rev-parse-out> .git
FETCH_HEAD> b2209bbe079ff44ba7df190b55e75efcdba9ed0bnot-for-merge   branch 
'1.0' of SERVER:PROJECT
FETCH_HEAD> f7b45494636cacace32d334d86307c161ed1aa69not-for-merge   branch 
'1.1' of SERVER:PROJECT
FETCH_HEAD> f9eb31076046ef23bee15f395dd6904d98800afdnot-for-merge   branch 
'1.1.1' of SERVER:PROJECT
FETCH_HEAD> 8faab638d94b3ad5d70269d07e0cea1f3ad225fbnot-for-merge   branch 
'1.2' of SERVER:PROJECT
FETCH_HEAD> 057f5e4f4a09728526d433e67d0f87c2e8df18fenot-for-merge   branch 
'1.3' of SERVER:PROJECT
FETCH_HEAD> d34837a189fb9412424eee7da3f49f41430a02d0not-for-merge   branch 
'1.4' of SERVER:PROJECT
FETCH_HEAD> 0f16cb2c6725babbef4da42aebf74cab3fecaad2branch 'master' 
of SERVER:PROJECT
"/usr/bin/git" "reset" "--hard" "0f16cb2c6725babbef4da42aebf74cab3fecaad2"
reset-out> HEAD is now at 0f16cb2 Implemented the unified tool bar on Mac OS X
"/usr/bin/git" "rev-parse" "--show-cdup"
rev-parse-out> 
"/usr/bin/git" "--version"
version-out> git version 1.7.5.4
"/usr/bin/git" "submodule" "update" "--recursive"
--- End Update ---
"/usr/bin/git" "rev-list" "-n" "1" "HEAD"
rl-err> fatal: ambiguous argument 'HEAD': both revision and filename
rl-err> Use '--' to separate filenames from revisions
--- Begin Revisions ---
"/usr/bin/git" "rev-list" "--reverse" ".." "--" | "/usr/bin/git" "diff-tree" 
"--stdin" "--always" "-z" "-r" "--pretty=raw" "--encoding=utf-8"
dt-out> 
"/usr/bin/git" "update-index" "--refresh"
"/usr/bin/git" "diff-index" "-z" "HEAD"
di-err> fatal: ambiguous argument 'HEAD': both revision and filename
di-err> Use '--' to separate filenames from revisions
--- End Revisions ---
--

Powered by www.kitware.com

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

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

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

Re: [CMake] ctest & git submodules

[Brad King]

On 02/28/2013 10:34 AM, NoRulez wrote:
> Yes, it is the command which I want.
> 
> On the command line the same command works in the source tree.
> 
> The command only fails during the CTest run if I set the option.

Read

 Testing/Temporary/LastUpdate*.log

in the test build tree for verbose details.

-Brad
--

Powered by www.kitware.com

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

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

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

Re: [CMake] ctest & git submodules

[NoRulez]

Yes, it is the command which I want.

On the command line the same command works in the source tree.

The command only fails during the CTest run if I set the option.


Am 28.02.2013 um 13:07 schrieb Brad King :

> On 02/28/2013 02:38 AM, NoRulez wrote:
>> But if I set the option:
>> set(CTEST_GIT_UPDATE_OPTIONS "--tags")
>> 
>> Then I get the following error message:
>> Update command failed: "C:/Program Files/Git/cmd/git.cmd" "fetch" "--tags"
> 
> Isn't that the command you want?  Perhaps it really fails.
> Try running it by hand from a command line.
> 
> -Brad
--

Powered by www.kitware.com

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

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

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

Re: [CMake] CHECK_INCLUDE_FILES

[Nico Schlömer]

Never mind: The above code does exactly what it's advertised to do.
The mistake I'm making lies elsewhere...

Sorry for the noise!

--Nico

On Thu, Feb 28, 2013 at 2:24 PM, Nico Schlömer  wrote:
> Hi,
>
> I'd like to find out whether the file /usr/include/vtk-5.8/vtkMPI.h is
> present on the system. I found CHECK_INCLUDE_FILES, and tried to use
> it like
>
>  *snip* 
> cmake_minimum_required(VERSION 2.8)
> INCLUDE(CheckIncludeFiles)
>
> SET(CMAKE_REQUIRED_INCLUDES /usr/include/vtk-5.8)
> CHECK_INCLUDE_FILES(vtkMPI.h TEST)
>
> MESSAGE("<<${TEST}>>")
>  *snap* 
>
> However, this doesn't seem to work return TRUE even if the file is present.
> Any idea what I'm doing wrong?
>
> --Nico
--

Powered by www.kitware.com

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

Please keep messages on-topic and check 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] CHECK_INCLUDE_FILES

[Nico Schlömer]

Hi,

I'd like to find out whether the file /usr/include/vtk-5.8/vtkMPI.h is
present on the system. I found CHECK_INCLUDE_FILES, and tried to use
it like

 *snip* 
cmake_minimum_required(VERSION 2.8)
INCLUDE(CheckIncludeFiles)

SET(CMAKE_REQUIRED_INCLUDES /usr/include/vtk-5.8)
CHECK_INCLUDE_FILES(vtkMPI.h TEST)

MESSAGE("<<${TEST}>>")
 *snap* 

However, this doesn't seem to work return TRUE even if the file is present.
Any idea what I'm doing wrong?

--Nico
--

Powered by www.kitware.com

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

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

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

Re: [CMake] ctest & git submodules

[Kornel Benko]

Am Donnerstag, 28. Februar 2013 um 07:07:52, schrieb Brad King 

> On 02/28/2013 02:38 AM, NoRulez wrote:
> > But if I set the option:
> > set(CTEST_GIT_UPDATE_OPTIONS "--tags")
> > 
> > Then I get the following error message:
> > Update command failed: "C:/Program Files/Git/cmd/git.cmd" "fetch" "--tags"

Maybe, you should set also the working directory for this command (source 
tree!).

> Isn't that the command you want?  Perhaps it really fails.
> Try running it by hand from a command line.
> 
> -Brad

Kornel


signature.asc
Description: This is a digitally signed message part.
--

Powered by www.kitware.com

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

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

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

Re: [CMake] ctest & git submodules

[Brad King]

On 02/28/2013 02:38 AM, NoRulez wrote:
> But if I set the option:
> set(CTEST_GIT_UPDATE_OPTIONS "--tags")
> 
> Then I get the following error message:
> Update command failed: "C:/Program Files/Git/cmd/git.cmd" "fetch" "--tags"

Isn't that the command you want?  Perhaps it really fails.
Try running it by hand from a command line.

-Brad
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Cmake and Visual Studio platforms

[John Drescher]

On Thu, Feb 28, 2013 at 6:31 AM, John Drescher  wrote:
>> There are multiple posts in multiple forums asking this question, so
>> naturally there is public need for this feature. How come CMake never aimed
>> at creating a solution for this? I suspect there is some great design issue
>> that prevents implementing it in CMake. There are several platform and
>> generator specific options already inside CMake, why can't this be another
>> one?
>>
> I believe the current method of forcing the developer to use different
> build trees for 64bit and 32bit works very well. I have used this for
> almost 5 years now of development under Visual Studio 2005 to 2012.

Also there are reasons why this will not work in the current design.
Outside of the few CMAKE variables that are set for the compiler that
would be wrong the biggest problem I believe would be libraries. You
can not link a x64 library with a 32 bit program so CMake would have
to track what libraries were x64 versus 32bit which may seem like just
adding additional configurations over Release,Debug ... would solve
but that will not work with the way finders work. Also I do not
believe CMake supports this configuration on any other platform.

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 and Visual Studio platforms

[John Drescher]

> There are multiple posts in multiple forums asking this question, so
> naturally there is public need for this feature. How come CMake never aimed
> at creating a solution for this? I suspect there is some great design issue
> that prevents implementing it in CMake. There are several platform and
> generator specific options already inside CMake, why can't this be another
> one?
>
I believe the current method of forcing the developer to use different
build trees for 64bit and 32bit works very well. I have used this for
almost 5 years now of development under Visual Studio 2005 to 2012.

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

[CMake] Cmake and Visual Studio platforms

[Meteorhead]

Hi!

I've been learning CMake for the past 2-3 weeks now, expanding my project
feature by feature through making a tutorial for fellow scientists, and
there is one big question that people (such as myself and others) ask coming
from the Windows side of development: Why can't CMake create platforms
inside a generated project?

The question is not whether CMake can do it or not. I have found enough
topics stating that it cannot. I understand that MSVC is the only compiler
that has seperate executables for the 32-bit and the 64-bit compiler, which
all other civilized compilers handle via a command line architecture flag.
Clearly it is inside VS that handles whether it calls the 32-bit cl.exe, or
the 64-bit one. And the interesting part comes here:

There are multiple posts in multiple forums asking this question, so
naturally there is public need for this feature. How come CMake never aimed
at creating a solution for this? I suspect there is some great design issue
that prevents implementing it in CMake. There are several platform and
generator specific options already inside CMake, why can't this be another
one?



--
View this message in context: 
http://cmake.3232098.n2.nabble.com/Cmake-and-Visual-Studio-platforms-tp7583415.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

[CMake] Per-target include dirs that work in both 2.8.7 and 2.8.10.2?

[Magnus Therning]

The other day I was putting together some cmake files and made them
work on my system, where I have version 2.8.10.2 installed.  After
giving my work to a colleague he reported that it didn't work.  It
came down to him using version 2.8.7 (comes with his Linux distro) and
my use of


set_property( TARGET app PROPERTY INCLUDE_DIRECTORIES

)


In the folder in question there is source for several different
targets, so I'd really like to use per-target include dirs (i.e.
include_directories would not be a good match).  Is there a mechanism
for (easily) getting per-target include dirs that work in both these
versions?

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus
--

Powered by www.kitware.com

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

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

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