Re: [cmake-developers] CMake daemon-mode

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

Re: [cmake-developers] CMake daemon-mode

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

Re: [cmake-developers] CMake daemon-mode

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

Re: [cmake-developers] CMake daemon-mode

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'

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

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

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

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

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

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

Re: [cmake-developers] CMake daemon-mode

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

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

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:

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

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

Re: [cmake-developers] CMake daemon-mode

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

Re: [cmake-developers] CMake daemon-mode

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

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

The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=16137 == Reported By:Andry81 Assigned To:

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

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

Re: [cmake-developers] CMake daemon-mode

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

Re: [cmake-developers] CMake daemon-mode

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

Re: [cmake-developers] CMake daemon-mode

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

Re: [cmake-developers] CMake daemon-mode

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

Re: [cmake-developers] CMake daemon-mode

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