Re: [cmake-developers] Undocumented change in behavior in cmake 3.9.X (SWIG)

On 17/08/17 22:18, Ben Boeckel wrote: > On Thu, Aug 17, 2017 at 17:41:35 +0930, Simon Lees wrote: >> We at openSUSE have noticed a change in behavior presumably in >> swig_link_libraries in one package cproton_perl.so is now being >> generated rather then libcproton_perl.so I presume the lines

Re: [cmake-developers] [CMake] cmake-gui on windows and qt5 dlls

On Fri, Aug 18, 2017 at 6:23 AM, Craig Scott wrote: > > > On Fri, Aug 18, 2017 at 5:05 AM, Konstantin Podsvirov < > konstan...@podsvirov.pro> wrote: > >> Hello Clément Gregoire! >> >> 17.08.2017, 21:55, "Clément Gregoire" : >> > So the following worked

Re: [cmake-developers] [CMake] cmake-gui on windows and qt5 dlls

On Fri, Aug 18, 2017 at 5:05 AM, Konstantin Podsvirov < konstan...@podsvirov.pro> wrote: > Hello Clément Gregoire! > > 17.08.2017, 21:55, "Clément Gregoire" : > > So the following worked for me: > > > > move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder > >

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

On 8/17/2017 12:11 PM, Eric Wing wrote: Oddly, I don't have any direct experience with FLTK even though I've known about it for years. The projects I get involved with usually need a lot more native UI integration, so FLTK is never on the list. And I personally prefer native UI experience. But

Re: [cmake-developers] [CMake] cmake-gui on windows and qt5 dlls

Hello Clément Gregoire! 17.08.2017, 21:55, "Clément Gregoire" : > So the following worked for me: > > move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder > > create a batch file named > > cmake-gui.bat > > with the following content > > @echo off > start ""

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

On 2017-08-17 08:55-0700 Eric Wing wrote: On 8/17/17, Alan W. Irwin wrote: On 2017-08-17 04:15-0700 Eric Wing wrote: I hope I'm doing this right...but the resulting program I think looks correct testing on my Mac. Attached are two pictures. The first is a simple

Re: [cmake-developers] List of commands

On Thu, Aug 17, 2017 at 14:34:27 -0300, Ivam Pretti wrote: > Hi there I am new at coding with cmake and I would like to know if there is > a list of commands avaiable. Thanks anyway. The cmake-commands(7) manpage has a listing of the builtin commands. They're also available in the HTML

[cmake-developers] List of commands

Hi there I am new at coding with cmake and I would like to know if there is a list of commands avaiable. Thanks anyway. -- 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

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

> If small and self-reliant are the criteria, how does FLTK > (http://www.fltk.org/index.php) stack up? For something like > cmake-gui it would probably work just fine, and AFAIK it doesn't > require GTK... it uses LGPLv2 with a static linking exception, so > it's probably as good/better than

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

I think asio being on track to be included in the standard library is a strong point in its favor, but in my opinion there are two strong reasons to prefer libuv: - libuv is entirely a C library. I don't think this is a hard requirement but most of kwsys is C and I suspect there is a reason for

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

On 2017-08-17 04:15-0700 Eric Wing wrote: I hope I'm doing this right...but the resulting program I think looks correct testing on my Mac. Attached are two pictures. The first is a simple label in a window. The second is from your MessageBox line. Yes, I confirm those two PNG images have

Re: [cmake-developers] Undocumented change in behavior in cmake 3.9.X (SWIG)

On Thu, Aug 17, 2017 at 17:41:35 +0930, Simon Lees wrote: > We at openSUSE have noticed a change in behavior presumably in > swig_link_libraries in one package cproton_perl.so is now being > generated rather then libcproton_perl.so I presume the lines generating > the library are below (I am not

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

On Wed, Aug 16, 2017 at 23:02:52 +0200, Jean-Michaël Celerier wrote: > @Ben Boeckel : > > The idea for process creation is to migrate to libuv once all of the > dependencies are supported. > Quick question : why not asio instead ? it's bound to end up in the > standard library at some point (e.g.

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

On Thu, Aug 17, 2017 at 2:27 AM, Eric Wing wrote: >> 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

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

I hope I'm doing this right...but the resulting program I think looks correct testing on my Mac. Attached are two pictures. The first is a simple label in a window. The second is from your MessageBox line. Thanks, Eric -- Powered by www.kitware.com Please keep messages on-topic and check the

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

On 17/08/17 19:53, Alan W. Irwin wrote: > On 2017-08-17 19:29+0930 Simon Lees wrote: > >> >> >> On 17/08/17 19:01, Jean-Michaël Celerier wrote: And Mac doesn't have configure/autotools by defaul. >>> >>> but... "configure" has nothing to do with autotools. >>> It's just a shell script

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

On 2017-08-17 19:29+0930 Simon Lees wrote: On 17/08/17 19:01, Jean-Michaël Celerier wrote: And Mac doesn't have configure/autotools by defaul. but... "configure" has nothing to do with autotools. It's just a shell script (which is sometimes generated *from* autotools; this is not the case

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

On 17/08/17 19:01, Jean-Michaël Celerier wrote: >> And Mac doesn't have configure/autotools by defaul. > > but... "configure" has nothing to do with autotools. > It's just a shell script (which is sometimes generated *from* autotools; > this is not the case with Qt AFAIK). > Yes Qt's

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

> For example, I've seen way too many projects screw up with Brew because they fail to ship a binary that can work on a clean user system who is not going to install Brew. I must be lucky then, because just using macdeployqt copies all the dependencies for me and updates all the install paths

[cmake-developers] Undocumented change in behavior in cmake 3.9.X (SWIG)

Hi, We at openSUSE have noticed a change in behavior presumably in swig_link_libraries in one package cproton_perl.so is now being generated rather then libcproton_perl.so I presume the lines generating the library are below (I am not familiar with the package) swig_add_module(cproton_perl perl

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

On 2017-08-16 23:27-0700 Eric Wing wrote: Thanks to your post the possibility now exists that I or one of my PLplot colleagues will develop an IUP-based device driver in the intermediate future. So if that occurs I would plan to download and build IUP for myself on Linux. And that would put

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

> 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