Re: [cmake-developers] CMake daemon-mode

[Tobias Hunger]

Hi Brad,

Am 07.06.2016 19:23 schrieb "Brad King" :
> If it doesn't conflict with 'master' too much I can take it directly.

It should not. I regularly rebase my branch on top of master.

> I've cherry-picked 124f8295bee0c228b79a5cf38f0b2581be308118 and merged
> to 'next' for testing:
>
>  cmLocalGenerator: Pass configuration to GetTargetFlags
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe0d2241

Great, thanks!

I would love to keep my patch set as small as possible:)

Best Regards,
Tobias
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Stuart Mentzer]

Hello,

Here is a little patch that lets FindFreetype find the debug library on 
Windows, where it is named with a d suffix.

Much thanks to Rolf Eike Beer for help on this.

Cheers,
Stuart
From 93576b26f52017eb9b60705c123be1956a512a77 Mon Sep 17 00:00:00 2001
From: Stuart Mentzer 
Date: Wed, 8 Jun 2016 00:26:31 -0400
Subject: [PATCH] FindFreetype updates for debug library name on Windows with d
 suffix

---
 Help/release/dev/FindFreetype-debug-libs.rst |  5 +++
 Modules/FindFreetype.cmake   | 47 ++--
 2 files changed, 29 insertions(+), 23 deletions(-)
 create mode 100644 Help/release/dev/FindFreetype-debug-libs.rst

diff --git a/Help/release/dev/FindFreetype-debug-libs.rst 
b/Help/release/dev/FindFreetype-debug-libs.rst
new file mode 100644
index 000..2637fb0
--- /dev/null
+++ b/Help/release/dev/FindFreetype-debug-libs.rst
@@ -0,0 +1,5 @@
+FindFreetype-debug-libs
+--
+
+* The :module:`FindFreetype` module now finds the debug library on
+Windows where it is named with a d suffix.
diff --git a/Modules/FindFreetype.cmake b/Modules/FindFreetype.cmake
index 7d46d15..9db34d5 100644
--- a/Modules/FindFreetype.cmake
+++ b/Modules/FindFreetype.cmake
@@ -51,9 +51,8 @@
 # wants explicit full paths and this trickery doesn't work too well.
 # I'm going to attempt to cut out the middleman and hope
 # everything still works.
-find_path(
-  FREETYPE_INCLUDE_DIR_ft2build
-  ft2build.h
+
+set(FREETYPE_FIND_ARGS
   HINTS
 ENV FREETYPE_DIR
   PATHS
@@ -64,6 +63,12 @@ find_path(
 ENV GTKMM_BASEPATH
 [HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path]
 [HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path]
+)
+
+find_path(
+  FREETYPE_INCLUDE_DIR_ft2build
+  ft2build.h
+  ${FREETYPE_FIND_ARGS}
   PATH_SUFFIXES
 include/freetype2
 include
@@ -75,16 +80,7 @@ find_path(
   NAMES
 freetype/config/ftheader.h
 config/ftheader.h
-  HINTS
-ENV FREETYPE_DIR
-  PATHS
-/usr/X11R6
-/usr/local/X11R6
-/usr/local/X11
-/usr/freeware
-ENV GTKMM_BASEPATH
-[HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path]
-[HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path]
+  ${FREETYPE_FIND_ARGS}
   PATH_SUFFIXES
 include/freetype2
 include
@@ -96,19 +92,23 @@ find_library(FREETYPE_LIBRARY
 freetype
 libfreetype
 freetype219
-  HINTS
-ENV FREETYPE_DIR
-  PATHS
-/usr/X11R6
-/usr/local/X11R6
-/usr/local/X11
-/usr/freeware
-ENV GTKMM_BASEPATH
-[HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path]
-[HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path]
+  ${FREETYPE_FIND_ARGS}
+  PATH_SUFFIXES
+lib
+)
+find_library(FREETYPE_LIBRARY_DEBUG
+  NAMES
+freetyped
+libfreetyped
+freetype219d
+  ${FREETYPE_FIND_ARGS}
   PATH_SUFFIXES
 lib
 )
+include(SelectLibraryConfigurations)
+select_library_configurations(FREETYPE)
+
+unset(FREETYPE_FIND_ARGS)
 
 # set the user variables
 if(FREETYPE_INCLUDE_DIR_ft2build AND FREETYPE_INCLUDE_DIR_freetype2)
@@ -159,6 +159,7 @@ find_package_handle_standard_args(
 
 mark_as_advanced(
   FREETYPE_LIBRARY
+  FREETYPE_LIBRARY_DEBUG
   FREETYPE_INCLUDE_DIR_freetype2
   FREETYPE_INCLUDE_DIR_ft2build
 )
-- 
2.8.3.windows.1

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [patch] FindBZip2: Add additional debug library name

[Roger Leigh]

I noticed that FindBZip2.cmake was searching for the bzip2d debug 
library but not bz2d (it uses bz2 and bzip2 for the release library 
names).  While bzip2[d] is the common form on Windows, which is what the 
upstream nmake build creates, there are at least two CMake builds for 
bzip2 which use the bz2 form to match the Unix naming:


https://gitlab.kitware.com/ben.boeckel/common-superbuild/blob/master/projects/patches/bzip2-add-cmake.patch
https://github.com/ome/ome-cmake-superbuild/blob/develop/packages/bzip2/patches/cmake.diff

I've merged this bzip2-debug-names branch into next for testing.


Regards,
Roger
--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake daemon-mode

[Brad King]

On 06/07/2016 12:18 PM, Tobias Hunger wrote:
>> When you have a few such independent refactoring changes done
>> we can look at integrating them immediately to avoid holding
>> them externally in your daemon topic for too long.
> 
> Can you take that patch from github or do you want them sent here?

If it doesn't conflict with 'master' too much I can take it directly.

I've cherry-picked 124f8295bee0c228b79a5cf38f0b2581be308118 and merged
to 'next' for testing:

 cmLocalGenerator: Pass configuration to GetTargetFlags
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe0d2241

Thanks,
-Brad
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake daemon-mode

[Tobias Hunger]

Hi Brad,

sorry for the empty mail, my phone acted up:-)

Am 07.06.2016 16:48 schrieb "Brad King" :
>
> On 06/07/2016 10:42 AM, Tobias Hunger wrote:
> > On Mo, 2016-06-06 at 13:24 -0400, Brad King wrote:
> >> We should be able to refactor things to share the flags computation.
> >> Methods like
> >>
> >>   cmLocalGenerator::GetTargetFlags
> >
> > Does this patch here make sense:
> >
> >
https://github.com/hunger/CMake/commit/124f8295bee0c228b79a5cf38f0b2581be308118
> >
> > It passes the configuration to GetTargetFlags instead of forcing it to
the build
> > type. Since I may end up with different configurations in the project
structure,
> > I think this is necessary.
>
> Yes.  Previously that method was only called in single-configuration
> generators so it could look up the CMAKE_BUILD_TYPE directly.  In
> multi-config generators that variable is meaningless and instead they
> iterate over CMAKE_CONFIGURATION_TYPES.
>
> When you have a few such independent refactoring changes done
> we can look at integrating them immediately to avoid holding
> them externally in your daemon topic for too long.

Can you take that patch from github or do you want them sent here?

Best Regards,
Tobias
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake daemon-mode

[Tobias Hunger]

Hi
Am 07.06.2016 16:48 schrieb "Brad King" :

> On 06/07/2016 10:42 AM, Tobias Hunger wrote:
> > On Mo, 2016-06-06 at 13:24 -0400, Brad King wrote:
> >> We should be able to refactor things to share the flags computation.
> >> Methods like
> >>
> >>   cmLocalGenerator::GetTargetFlags
> >
> > Does this patch here make sense:
> >
> >
> https://github.com/hunger/CMake/commit/124f8295bee0c228b79a5cf38f0b2581be308118
> >
> > It passes the configuration to GetTargetFlags instead of forcing it to
> the build
> > type. Since I may end up with different configurations in the project
> structure,
> > I think this is necessary.
>
> Yes.  Previously that method was only called in single-configuration
> generators so it could look up the CMAKE_BUILD_TYPE directly.  In
> multi-config generators that variable is meaningless and instead they
> iterate over CMAKE_CONFIGURATION_TYPES.
>
> When you have a few such independent refactoring changes done
> we can look at integrating them immediately to avoid holding
> them externally in your daemon topic for too long.
>
> Thanks,
> -Brad
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake daemon-mode

[Brad King]

On 06/07/2016 10:42 AM, Tobias Hunger wrote:
> On Mo, 2016-06-06 at 13:24 -0400, Brad King wrote:
>> We should be able to refactor things to share the flags computation.
>> Methods like
>>
>>   cmLocalGenerator::GetTargetFlags
> 
> Does this patch here make sense:
> 
> https://github.com/hunger/CMake/commit/124f8295bee0c228b79a5cf38f0b2581be308118
> 
> It passes the configuration to GetTargetFlags instead of forcing it to the 
> build
> type. Since I may end up with different configurations in the project 
> structure,
> I think this is necessary.

Yes.  Previously that method was only called in single-configuration
generators so it could look up the CMAKE_BUILD_TYPE directly.  In
multi-config generators that variable is meaningless and instead they
iterate over CMAKE_CONFIGURATION_TYPES.

When you have a few such independent refactoring changes done
we can look at integrating them immediately to avoid holding
them externally in your daemon topic for too long.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake daemon-mode

[Tobias Hunger]

On Mo, 2016-06-06 at 13:24 -0400, Brad King wrote:
> We should be able to refactor things to share the flags computation.
> Methods like
> 
>   cmLocalGenerator::GetTargetFlags

Does this patch here make sense:

https://github.com/hunger/CMake/commit/124f8295bee0c228b79a5cf38f0b2581be308118

It passes the configuration to GetTargetFlags instead of forcing it to the build
type. Since I may end up with different configurations in the project structure,
I think this is necessary.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Problem with find_path and Frameworks

[Harry Mallon]

Thanks Brad. I haven't run into a mac without 
/System/Library/Frameworks/Kernel.framework before but maybe it comes from 
XCode or something. Thanks for merging.

Harry.

Harry Mallon
CODEX | Software Engineer
60 Poland Street | London | England | W1F 7NT
E ha...@codexdigital.com | T +44 203 7000 989
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0016137]: ExternalProject_Add: Can't escape ; character in CMAKE_ARGS

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16137 
== 
Reported By:Andry81
Assigned To:
== 
Project:CMake
Issue ID:   16137
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-06-07 09:56 EDT
Last Modified:  2016-06-07 09:56 EDT
== 
Summary:ExternalProject_Add: Can't escape ; character in
CMAKE_ARGS
Description: 
Seems ExternalProject_Add became broken from some time ago. I could not figure
out when, but from version 3.5.2 (including 3.5.2-rc1) it does not work anymore.
All ";" characters does replace now by space whenever and not matter how you use
the expression.

Steps to Reproduce: 
ExternalProject_Add(MySubProject SOURCE_DIR ${SUBPROJECT_ROOT}
CMAKE_ARGS
-DMYPATH=c:/blabla1;c:/blabla1/blabla2;c:/blabla1/blabla3
INSTALL_COMMAND "" )

Additional Information: 
I Tried these to workaround it:
1. Quotes around the expression ("-DMYPATH=...")
2. Backlash escaping ("-DMYPATH=...\;...")
3. LIST APPEND instead SET
4. LIST_SEPARATOR in ExternalProject_Add
5. STRING REPLACE ^^ to ;

Nothing works.

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-06-07 09:56 Andry81New Issue
==

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows

[Brad King]

On 06/07/2016 02:07 AM, michael.jaent...@gmx.de wrote:
> problem is not the POST_BUILD which is set to "cd ." as you said but the
> CMAKE_CXX_ARCHIVE_FINISH which is before the POST_BUILD
[snip]
>   command = ... D:\gcc\win32\mips-sde-elf\bin\mips-sde-elf-ar.exe qc 
> $TARGET_FILE $LINK_FLAGS $in && : $TARGET_FILE && $POST_BUILD"

That is meant to be the "ranlib" call.  The only way I was able to get
a ":" there was by setting -DCMAKE_RANLIB=: on the command line.  What
is its value?  See CMakeFiles/${CMAKE_VERSION}/CMakeCCompiler.cmake
for a set(CMAKE_RANLIB) call.  Does the toolchain provide a "ranlib"
tool?

-Brad

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake daemon-mode

[Brad King]

On 06/07/2016 09:07 AM, Tobias Hunger wrote:
>> We should be able to refactor things to share the flags computation.
>> Methods like
>>
>>   cmLocalGenerator::GetTargetFlags
>>   cmLocalGenerator::GetIncludeDirectories
>>
>> are meant to be used across multiple generators.
> 
> So is that the complete picture?

No, just a starting point.

Note that we have no API to get all the flags for a source because
all the generators collect target-wide and per-source flags separately.
They are not combined until the native build tool constructs the final
command line.  The implementation of CMAKE_EXPORT_COMPILE_COMMANDS may
already have some code to combine flags within CMake directly though.

> You can override compile time flags on a per-file basis, based on the
> code I ran across in the ninja generator:-) Do I still need to add
> those per-source-file flags somehow?

Yes.  It looks like each generator currently does its own call to

  source->GetProperty("COMPILE_FLAGS")

to get the per-source flags.  The daemon would have to do something
similar, possibly by factoring the logic out of the generators into
a common helper.

-Brad

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Problem with find_path and Frameworks

[Brad King]

On 06/07/2016 07:29 AM, Harry Mallon wrote:
> I have updated my patch with new simplified logic and a test.

Thanks.  I revised the test to not depend on a specific framework
path to exist on the system (it didn't on mine).  Merged to 'next'
for testing:

 find_path: Fix location of  in a framework on OS X
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=188baef0

-Brad

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake daemon-mode

[Brad King]

On 06/07/2016 05:27 AM, Daniel Pfeifer wrote:
> If we have a daemon mode that provides this information (as your
> implementation already does), we could let ccmake and cmake-gui use
> the daemon instead of linking against CMakeLib.

That would be really nice.  A lot of the state space in CMake's
internal representation is muddled by historical evolution of
the different ways we have to invoke it (command line, ccmake,
cmake-gui, ctest internals, etc.).  Separating the interactive
modes would be a nice cleanup.

-Brad

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake daemon-mode

[Tobias Hunger]

Hi Brad!

On Mon, Jun 6, 2016 at 7:24 PM, Brad King  wrote:


>> A big chunk of Stephen's work has not even landed in my branch yet. Since 
>> cmake
>> reformated all the source in the meantime it is a bit tedious to apply 
>> patches
>> from his tree and I have simply not yet needed the changes as I did not 
>> venture
>> where he went yet.
>
> See commit v3.6.0-rc1~54^2~2 (82df6deaaf).  Its commit message explains
> how to rebase across the style transition.  If you rebase the original
> "cmake-daemon" branch on that then we can rewrite the style to make
> cherry-picking later easier.

Thanks, that might prove helpful.

So far i basically picked the same sha, that worked surprisingly well.

>> At this time I think I will need to duplicate a chunk of code from one of the
>> generators to find the flags. Is that really necessary? If so: Which 
>> generator
>> should I copy the code from?
>
> We should be able to refactor things to share the flags computation.
> Methods like
>
>   cmLocalGenerator::GetTargetFlags
>   cmLocalGenerator::GetIncludeDirectories
>
> are meant to be used across multiple generators.  Due to historical
> evolution in generator design not everything has been refactored to
> cleanly share such infrastructure across all generators.  Stephen made
> a lot of progress on that front, but there is still a way to go IIRC.

So is that the complete picture?

You can override compile time flags on a per-file basis, based on the
code I ran across in the ninja generator:-) Do I still need to add
those per-source-file flags somehow?

Best Regards,
Tobias
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Problem with find_path and Frameworks

[Harry Mallon]

I have updated my patch with new simplified logic and a test.


Harry Mallon
CODEX | Software Engineer
60 Poland Street | London | England | W1F 7NT
E ha...@codexdigital.com | T +44 203 7000 989


0001-Fix-a-problem-where-using-find_path-to-find-a-header.patch
Description: 0001-Fix-a-problem-where-using-find_path-to-find-a-header.patch


Yours,
Harry-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake daemon-mode

[Tobias Hunger]

Hi Daniel,

On Tue, Jun 7, 2016 at 11:27 AM, Daniel Pfeifer  wrote:
> On Mon, Jun 6, 2016 at 5:39 PM, Tobias Hunger  wrote:
>> Please help to support your use-cases.
>
> A while ago I wrote a graphical cache editor in GTK:
> https://github.com/purpleKarrot/cmake-gtk
> The tool reads the cache and provides a graphical view to modify it.
> It can then write the cache, run cmake, and read it back.
>
> I wanted to see how close we can get to ccmake or cmake-gui without
> linking against CMakeLib.
>
> Here is what I was *unable* to achieve:
> * Separating Configure from Generate (two buttons).
> * Progress bar.
>
> Quite a short list, right?
> If we have a daemon mode that provides this information (as your
> implementation already does), we could let ccmake and cmake-gui use
> the daemon instead of linking against CMakeLib.

If the daemon can expose the right information, then you could even be
able to write a generator in e.g. python;-)

Best Regards,
Tobias
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake daemon-mode

[Daniel Pfeifer]

On Mon, Jun 6, 2016 at 7:24 PM, Brad King  wrote:
> On 06/06/2016 11:39 AM, Tobias Hunger wrote:
>
>> A big chunk of Stephen's work has not even landed in my branch yet. Since 
>> cmake
>> reformated all the source in the meantime it is a bit tedious to apply 
>> patches
>> from his tree and I have simply not yet needed the changes as I did not 
>> venture
>> where he went yet.
>
> See commit v3.6.0-rc1~54^2~2 (82df6deaaf).  Its commit message explains
> how to rebase across the style transition.  If you rebase the original
> "cmake-daemon" branch on that then we can rewrite the style to make
> cherry-picking later easier.

When I rebased my own branches across the style transiton, I found the
process quite straight forward.
I can help with the style transition if someone rebases to 82df6deaaf.

When I tried to rebase steve's work, it was not the style transition
but changes like the following that I struggled with:
https://github.com/Kitware/CMake/commit/563bf9dd8a207e04697a92d8bcd239f52400b355

cheers, Daniel
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake daemon-mode

[Daniel Pfeifer]

On Mon, Jun 6, 2016 at 5:39 PM, Tobias Hunger  wrote:
> Please help to support your use-cases.

A while ago I wrote a graphical cache editor in GTK:
https://github.com/purpleKarrot/cmake-gtk
The tool reads the cache and provides a graphical view to modify it.
It can then write the cache, run cmake, and read it back.

I wanted to see how close we can get to ccmake or cmake-gui without
linking against CMakeLib.

Here is what I was *unable* to achieve:
* Separating Configure from Generate (two buttons).
* Progress bar.

Quite a short list, right?
If we have a daemon mode that provides this information (as your
implementation already does), we could let ccmake and cmake-gui use
the daemon instead of linking against CMakeLib.

cheers, Daniel

> Please report what information you would like to have available from your 
> cmake
> projects via daemon-mode.
>
> Patches are of course welcome at any time!
>
> Any help in getting any interesting information out of cmake is highly
> appreciated, too.
>
> At this time I think I will need to duplicate a chunk of code from one of the
> generators to find the flags. Is that really necessary? If so: Which generator
> should I copy the code from?
>
> Best Regards,
> Tobias
>
> --
> Tobias Hunger, Senior Software Engineer | The Qt Company
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 
> B
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers