[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-87-g1f9b35d

_VERSION_MINOR 6) -set(CMake_VERSION_PATCH 20160609) +set(CMake_VERSION_PATCH 20160610) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [CMake] MSVC /M[TD] as a compatible interface property?

Yeah, that issue with /MD and /MT is the reason every project I've seen that deals with this problem uses something like this: # https://cmake.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F foreach(flag_var CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG

Re: [CMake] MSVC /M[TD] as a compatible interface property?

A while ago I did an experiment along the same lines, using something like this in CMake/MTflags.cmake. (What we really needed was forcing /MT /D_HAS_ITERATOR_DEBUGGING=0 even on debug builds, because we were using an external library only available in /MT format. So I might have accidentally

Re: [cmake-developers] FindFreetype patch for Windows debug lib naming

On 6/9/2016 9:33 AM, Rolf Eike Beer wrote: Am 2016-06-09 15:00, schrieb Brad King: On 06/08/2016 12:33 AM, Stuart Mentzer wrote: Here is a little patch that lets FindFreetype find the debug library on Windows, where it is named with a d suffix. Thanks. I split the patch into two and

Re: [cmake-developers] Review request: extract-cmMessenger branch

On Thu, Jun 9, 2016 at 2:17 PM, Brad King wrote: > On 06/09/2016 05:06 AM, Tobias Hunger wrote: >> CMake Error at src/1/app/CMakeLists.txt:70 (add_custom_target): >> Cannot find source file: >> >> unknownFile.qml >> >> Tried extensions .c .C .c++ .cc .cpp .cxx .m .M

[CMake] execute_process, cmd /c and vcvarsall

Hello all, I am trying to develop a execute_process command that will first load the env variables set by the appropriate vcvarsall, and then run a compile command. See here for my progress so far: set(cuda_generation_command cmd /c "\"call

[CMake] MSVC /M[TD] as a compatible interface property?

Setting /MT or /MD is pretty important, and is a transitive requirement. See: https://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx The standard mechanism of using target_compile_options isn't quite appropriate because it will simply append the flags used by each library and use the last

Re: [cmake-developers] CMake daemon-mode

On 06/09/2016 04:24 PM, Tobias Hunger wrote: >> Please rebase on that (at least once it is in master). > > How long does it usually take to get something into master? Typically a (business) day or two, but sometimes longer depending on trouble with testing in 'next' on our dashboards. -Brad --

Re: [cmake-developers] daemon-mode: Project structure

On Thursday 09 June 2016 12:59:40 Tobias Hunger wrote: > Hi Milian, ... > > > "targets": > > > [ > > > { > > > "fullName":"test", > > > "name":"test", > > > "type":"GLOBAL_TARGET" > > > }, > > > > > > A

Re: [cmake-developers] CMake daemon-mode

Hi Brad, Am 09.06.2016 19:57 schrieb "Brad King" : > > On 06/09/2016 09:27 AM, Brad King wrote: > >> https://github.com/hunger/CMake/commit/bc060a44b6b2c2281ffe99815163ba02ec835dd6 > > Good. I need to review that one more deeply but should be able to integrate it. > > I

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-184-gbb18617

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via bb186170a4954d219bc2e799df8d7caa77a88ac0 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-188-gbcd2094

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via bcd209460fb45bc04ed0e99d23fac5c3c2e2c213 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-186-g29dd8a8

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via 29dd8a8ff8ca44b8bcc6af4ad0496106cd72c5c3 (commit) via

Re: [cmake-developers] daemon-mode: Project structure

Hello everybody, Ok, so far I changed this:  * sourceGroups got renamed to fileGroups  * System include paths get reported  * GLOBAL_TARGETs are no longer listed.   So this is what it looks right now:   [== CMake MetaMagic ==[ {   # Reply header:   "cookie":"",   "type":"reply",  

Re: [CMake] CMake v3.6.0 rc1

On 06/08/2016 06:02 PM, Gonzalo Garramuño wrote: > I tried v3.6.0 rc1 but it fails on linking with a message about unknown > symbols when doing cmake -E vs_link_dll on a windows library. It seems > not to recognize the symbols in, for example, tinyxml2. > > The same code works just fine under

Re: [cmake-developers] RFC: LLVM community CMake documentation

On Thu, Apr 28, 2016 at 14:16:40 -0700, Chris Bieneman wrote: > The only comment I think I didn’t directly update the document for was > Dan’s comment about GLOBAL properties. I kinda have mixed feelings > about GLOBAL properties. I know why we use them, but I’m not sure I > want to encourage

Re: [CMake] CMake v3.6.0 rc1

On 6/8/2016 6:02 PM, Gonzalo Garramuño wrote: I tried v3.6.0 rc1 but it fails on linking with a message about unknown symbols when doing cmake -E vs_link_dll on a windows library. It seems not to recognize the symbols in, for example, tinyxml2. The same code works just fine under cmake v3.5.2.

Re: [cmake-developers] cmLocalGenerator::GetTargetFlags

On 06/09/2016 11:28 AM, Ben Boeckel wrote: > On Wed, Jun 08, 2016 at 10:12:13 -0400, Brad King wrote: >> Side note: This is another thing that should be cleaned up in the Ninja >> generator. It should hold target-wide flags in the per-target rules.ninja >> entries instead of duplicating them for

Re: [cmake-developers] cmLocalGenerator::GetTargetFlags

On Wed, Jun 08, 2016 at 10:12:13 -0400, Brad King wrote: > Side note: This is another thing that should be cleaned up in the Ninja > generator. It should hold target-wide flags in the per-target rules.ninja > entries instead of duplicating them for every object file in build.ninja. > That would

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-182-g937e6f4

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via 937e6f484223ebe17fb729a01b5494c3ed1f6cd2 (commit) via

Re: [cmake-developers] daemon-mode: Project structure

On Do, 2016-06-09 at 16:07 +0200, Milian Wolff wrote: > On Donnerstag, 9. Juni 2016 13:27:26 CEST Tobias Hunger wrote: > > On Do, 2016-06-09 at 08:43 -0400, Brad King wrote: > > > >   "includePath": > > > >   [ > > > >

Re: [cmake-developers] daemon-mode: Project structure

On Do, 2016-06-09 at 09:47 -0400, Brad King wrote: > On 06/09/2016 09:27 AM, Tobias Hunger wrote: > > I am using the output of cmState::GetTargetTypeName. > > Okay.  We could consider excluding GLOBAL_TARGET targets from the > output.  They never have source files and are nebulously defined. OK,

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-175-ge7dbcb3

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via e7dbcb39f983dd6640bcc5336601a0d327c1209f (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-178-gcc1cbdb

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via cc1cbdb4f8647f55712abc2a1f74c43c9fe8f083 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-173-gc9281fd

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via c9281fd5147ba30d4da375ddbfa27bc1854b0220 (commit) via

Re: [CMake] CCMake is not getting updated

Perfect!! Now everything is working correctly!! Thank you so much!! Regards, Ana 2016-06-09 14:08 GMT+01:00 Domen Vrankar : > > And now? Do I have to uninstall cmake 3.5 and install it again? > > Rebuild (in such cases I usually remove previous build dir as in the >

Re: [cmake-developers] daemon-mode: Project structure

On 06/09/2016 09:27 AM, Tobias Hunger wrote: > I am using the output of cmState::GetTargetTypeName. Okay. We could consider excluding GLOBAL_TARGET targets from the output. They never have source files and are nebulously defined. > How can I get the directory a library/executable will be put

Re: [cmake-developers] FindFreetype patch for Windows debug lib naming

Am 2016-06-09 15:00, schrieb Brad King: On 06/08/2016 12:33 AM, Stuart Mentzer wrote: Here is a little patch that lets FindFreetype find the debug library on Windows, where it is named with a d suffix. Thanks. I split the patch into two and applied: FindFreetype: Factor out common find

Re: [cmake-developers] daemon-mode: Project structure

On Do, 2016-06-09 at 08:43 -0400, Brad King wrote: > On 06/09/2016 05:47 AM, Tobias Hunger wrote: > > I made some progress with extracting project structure from cmake via the > > daemon-mode. I am rather happy with the information and would love to get > > some > > feedback from other interested

Re: [cmake-developers] CMake daemon-mode

On 06/08/2016 10:11 AM, Brad King wrote: > I had to revert it from 'next' because it caused several LinkFlags > test failures. [snip] On 06/08/2016 12:02 PM, Tobias Hunger wrote: > https://github.com/hunger/CMake/commit/66acf05bc1737211f88b6ad13781c791f1a7bce4 > > has an update. None of the tests

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-171-g62fdf5d

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via 62fdf5d4646b6ca5a005cdea2804a47c7331e88a (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-84-gc21397b

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via c21397b2df9470bde02d19175e393110871cee91 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-76-g01632c2

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 01632c2552a5536415671f092a34ada76dccd002 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-86-g8f3bd1f

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 8f3bd1f454fe50a641fd9666ca5e5bc8064c09c7 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-82-g065bb0f

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 065bb0ffebb51c0a3b90e8be3958095afaf4231a (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc1-74-g5aa89a1

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 5aa89a1ae0554c8bf428d079a0a716e9254e516f (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-165-gc20fa7c

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via c20fa7c4fe805c2d9b38b7c35a4c7d4a3af77299 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-163-ge0e77e6

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via e0e77e695ed98884f93ed81679c9ade5802ac5a8 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-161-g85dca2c

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via 85dca2c756691ae8f954f6e4d4d002655ebdd206 (commit) via

Re: [CMake] CCMake is not getting updated

> And now? Do I have to uninstall cmake 3.5 and install it again? Rebuild (in such cases I usually remove previous build dir as in the past sometimes it did not detect if a new library was added to the environment) and install (install is a dumb command that only copies files so you don't need to

Re: [cmake-developers] FindFreetype patch for Windows debug lib naming

On 06/08/2016 12:33 AM, Stuart Mentzer wrote: > Here is a little patch that lets FindFreetype find the debug > library on Windows, where it is named with a d suffix. Thanks. I split the patch into two and applied: FindFreetype: Factor out common find command arguments

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-159-gad0f722

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via ad0f722461761a9bf2a63ae1a124ed7b7a572ffb (commit) via

Re: [cmake-developers] daemon-mode: Project structure

Hi Milian, great that you have found the time to look over this! It is greatly appreciated! On Do, 2016-06-09 at 12:32 +0200, Milian Wolff wrote: > > [== CMake MetaMagic ==[ > > { > >   # Reply header: > >   "cookie":"", > >   "type":"reply" > >   "inReplyTo":"project", > >    > >   # Data: > >  

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc1-156-gca701b2

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via ca701b2c12979cf70f7f824d93e735c8d78a564f (commit) via

Re: [CMake] CCMake is not getting updated

OK, thank you very much! And now? Do I have to uninstall cmake 3.5 and install it again? Regards 2016-06-09 13:31 GMT+01:00 Domen Vrankar : > > Now I have the right version of cmake (3.5.2), but the ccmake version is > > still 2.8.12... How can I update ccmake too? > >

Re: [CMake] CCMake is not getting updated

> Now I have the right version of cmake (3.5.2), but the ccmake version is > still 2.8.12... How can I update ccmake too? Not 100% certain but my guess would be that you are missing ncurses-devel package and therefore ccmake was not built. sudo yum install ncurses-devel Regards, Domen --

[CMake] CCMake is not getting updated

Hello! I had to update cmake version from 2.8.12 to 3.5.2. I followed the steps here: https://xinyustudio.wordpress.com/2014/06/18/how-to-install-cmake-3-0-on-centos-6-centos-7/ . Now I have the right version of cmake (3.5.2), but the ccmake version is still 2.8.12... How can I update ccmake

Re: [cmake-developers] Review request: extract-cmMessenger branch

On 06/09/2016 05:06 AM, Tobias Hunger wrote: > CMake Error at src/1/app/CMakeLists.txt:70 (add_custom_target): > Cannot find source file: > > unknownFile.qml > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp > > > CMake Error at src/1/CMakeLists.txt:8

Re: [cmake-developers] daemon-mode: Project structure

On Donnerstag, 9. Juni 2016 09:47:44 CEST Tobias Hunger wrote: > Hello everybody, Hey Tobias, > I made some progress with extracting project structure from cmake via the > daemon-mode. I am rather happy with the information and would love to get > some feedback from other interested parties.

[cmake-developers] daemon-mode: Project structure

Hello everybody, I made some progress with extracting project structure from cmake via the daemon-mode. I am rather happy with the information and would love to get some feedback from other interested parties. Here is the format that is currently reported (with comments;-): [== CMake MetaMagic

Re: [cmake-developers] Review request: extract-cmMessenger branch

On Do, 2016-06-09 at 10:18 +0200, Stephen Kelly wrote: > > What I would like to have, is separate subclasses for gcc-style and > > msvc-style messages. In gcc-style, messages look like this: > > > > :row:column: error: > > > > In msvc-style, messages look like this: > > > > (row,column):

Re: [CMake] Build-system dependency (as opposed to target)

> On 9 Jun 2016, at 09:51, Petr Kmoch wrote: > > I believe you're looking for the directory property CMAKE_CONFIGURE_DEPENDS ( > https://cmake.org/cmake/help/latest/prop_dir/CMAKE_CONFIGURE_DEPENDS.html ). > Adding a file path to that property causes any changes to that

Re: [CMake] Build-system dependency (as opposed to target)

Hi James, I believe you're looking for the directory property CMAKE_CONFIGURE_DEPENDS ( https://cmake.org/cmake/help/latest/prop_dir/CMAKE_CONFIGURE_DEPENDS.html ). Adding a file path to that property causes any changes to that file to trigger a regeneration: set_property(DIRECTORY APPEND

[CMake] Build-system dependency (as opposed to target)

Hi, Is there a way to make the entire build-system depend on a file? I have some data I’m reading into my CMakeList.txt via file(READ), and I want changes to that file to effectively act as if the CMakeList.txt itself was modified. The read values are used to populate some variables via string

Re: [CMake] CPack and executable permissions on linux

Thanks for all answers. I had to read the documentation before asking :-D I changed the line for the executable from > install(FILES ... into > install(PROGRAMS ... That worked and as far as i can see is sufficient for my requirements. 2016-06-08 20:09 GMT+02:00 Domen Vrankar

Re: [cmake-developers] Review request: extract-cmMessenger branch

On 06/09/2016 09:49 AM, Daniel Pfeifer wrote: > On Thu, Jan 28, 2016 at 10:42 PM, Stephen Kelly wrote: >> Hi, >> >> I have pushed a extract-cmMessenger branch to my clone: >> >> https://github.com/steveire/CMake/commits/extract-cmMessenger > I have rebased it to master and

Re: [cmake-developers] Review request: extract-cmMessenger branch

On Thu, Jan 28, 2016 at 10:42 PM, Stephen Kelly wrote: > > Hi, > > I have pushed a extract-cmMessenger branch to my clone: > > https://github.com/steveire/CMake/commits/extract-cmMessenger I have rebased it to master and cherry-picked some minor changes. Once those minor