Re: [cmake-developers] Future of ccmake and cmake-gui and internationalization

2017-08-16 Thread Eric Wing
> Hi Eric: > > My opinion is your point about size is weak because IUP normally depends on > a big suite of graphical libraries in the GTK+ case or a big set of > system libraries such as GDI/GDI+/Uniscribe or Direct2D/DirectWrite in > the Windows case. > On systems the provide first class native

Re: [cmake-developers] Future of ccmake and cmake-gui and internationalization

2017-08-16 Thread Alan W. Irwin
On 2017-08-16 09:16-0700 Eric Wing wrote: I am not making a strong push for this, but I want to bring it up to at least get people thinking about this... I am disturbed by the size and complexity of Qt. My past experiences have not been good and I find it a massive chore to get an environment se

Re: [cmake-developers] Future of ccmake and cmake-gui

2017-08-16 Thread Eric Wing
> How easy is it to ship binaries which work on any platform without also > shipping all of the necessary platform backends as well? So on Windows and Mac, there is only one backend, the native one. And so there is nothing to manage. On the remaining Unix's with IUP you pick one when you build it

Re: [cmake-developers] Future of ccmake and cmake-gui

2017-08-16 Thread Eric Wing
On 8/16/17, Jean-Michaël Celerier wrote: > @Eric Wing >> I am not making a strong push for this, but I want to bring it up to > at least get people thinking about this... I am disturbed by the size > and complexity of Qt. My past experiences have not been good and I > find it a massive chore to ge

Re: [cmake-developers] Future of ccmake and cmake-gui

2017-08-16 Thread David Cole via cmake-developers
This is great to see CMake continuing to evolve like this! What's next, a web page CMake UI connected to cmake server instances on multiple platforms? ;-) On Wed, Aug 16, 2017 at 6:05 PM, Daniel Pfeifer wrote: > On Wed, Aug 16, 2017 at 6:16 PM, Eric Wing wrote: >> >> On 8/15/17, Daniel Pfeife

Re: [cmake-developers] Future of ccmake and cmake-gui

2017-08-16 Thread Daniel Pfeifer
On Wed, Aug 16, 2017 at 6:16 PM, Eric Wing wrote: > On 8/15/17, Daniel Pfeifer wrote: > > Hi, > > > > With !977 merged, it is possible to base ccmake and cmake-gui on top of > the > > cmake server. > > For demonstration, I copied the contents of the Source/CursesDialog > > directory and added a

Re: [cmake-developers] Future of ccmake and cmake-gui

2017-08-16 Thread Jean-Michaël Celerier
@Eric Wing > I am not making a strong push for this, but I want to bring it up to at least get people thinking about this... I am disturbed by the size and complexity of Qt. My past experiences have not been good and I find it a massive chore to get an environment setup (especially on Mac and Windo

Re: [cmake-developers] Future of ccmake and cmake-gui

2017-08-16 Thread Ben Boeckel
On Wed, Aug 16, 2017 at 09:16:24 -0700, Eric Wing wrote: > It has native backends for Windows, GTK2, GTK3, Motif, Haiku. Because > it historically didn't have a Mac OS X backend, most people overlooked > it. However...I've been implementing a native Mac OS X backend. It's > not finished, but there

Re: [cmake-developers] Future of ccmake and cmake-gui

2017-08-16 Thread Eric Wing
On 8/15/17, Daniel Pfeifer wrote: > Hi, > > With !977 merged, it is possible to base ccmake and cmake-gui on top of the > cmake server. > For demonstration, I copied the contents of the Source/CursesDialog > directory and added a proxy implementation of the classes `cmake` and > `cmState`. The res

Re: [cmake-developers] Future of ccmake and cmake-gui

2017-08-16 Thread Brad King
On 08/15/2017 04:33 PM, Daniel Pfeifer wrote: > With !977 merged, it is possible to base ccmake and cmake-gui on top > of the cmake serverShall we proceed in this direction? Yes! That will be a nice separation. It will also reduce the number of places we have to set up `class cmake` instance

Re: [cmake-developers] Future of ccmake and cmake-gui

2017-08-16 Thread Daniel Pfeifer
On Wed, Aug 16, 2017 at 4:29 PM, Ben Boeckel wrote: > On Tue, Aug 15, 2017 at 22:33:04 +0200, Daniel Pfeifer wrote: > > With !977 merged, it is possible to base ccmake and cmake-gui on top of > the > > cmake server. > > For demonstration, I copied the contents of the Source/CursesDialog > > direc

Re: [cmake-developers] Future of ccmake and cmake-gui

2017-08-16 Thread Ben Boeckel
On Tue, Aug 15, 2017 at 22:33:04 +0200, Daniel Pfeifer wrote: > With !977 merged, it is possible to base ccmake and cmake-gui on top of the > cmake server. > For demonstration, I copied the contents of the Source/CursesDialog > directory and added a proxy implementation of the classes `cmake` and >

Re: [cmake-developers] iOS: direction to official support and questions

2017-08-16 Thread Eric Wing
I've been using a derivative of the iOS toolchain for many years that you probably can find easily with a Google search. It has a lot of shortcomings, but it generally works. And most of the shortcomings I think are only solvable by properly fixing/modifying the CMake core. On 8/15/17, Raffi Enfi

Re: [cmake-developers] Windows symbolic links handling

2017-08-16 Thread Manu
2017-08-15 16:43 GMT+02:00 Brad King : > On 08/14/2017 06:35 AM, Manu wrote: > > Recently I migrated from cmake 2.8.12 to cmake 3.8 and FILE(TIMESTAMP > ...) > > behaviour changed. Now it reports symbolic link timestamp instead of > pointed > > file timestamp. > > Can you track down when that happ