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

[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 setup (especially on Mac
and Windows...and building Qt on Raspberry Pi is a nightmare). And the
binary sizes are large. (I do ship CMake to my users and its size with
the GUI is non-trivial.)

CMake's actual GUI isn't that complex. Have you considered something
lighter-weight?

As one alternative, there is IUP:
http://webserver2.tecgraf.puc-rio.br/iup/
(it's from the same university that created Lua...in fact I think one
of the original authors of the white paper/project went on to become
one of the Lua authors.)

IUP differs from Qt in that is is focused on wrapping native GUI
widgets (in constrast to Qt which creates its own non-native widgets).
Hence, the library is really small since it only depends on each
platform's native libraries. The core library is about 1MB. I just
ported (rewrote) a simple Qt based app to IUP. The Qt version was
almost 40MB. The IUP RAM usage is also many times smaller.

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 is a lot implemented and I'm actually shipping
a simple app with it this week. Since CMake's GUI usage is also pretty
simple, I *think* there might already be enough implemented to do the
CMake-GUI...or it's close enough that I probably could finish those
needed features.

Also, I implemented a CMake build system for IUP.

IUP is MIT licensed.

Now IUP only does GUI (which is another reason it stays small), so you
will need to fill in the JSON and Process requirements. But there are
tons of JSON libraries. Off the top of my head, cJSON is a really
fast, tiny, and simple to use JSON library. It's a single C file and
header, so you can drop it right in the project. (Also MIT). It also
has a CMake build system if you really want it.

And a cross-platform create process...those I've seen everywhere and
I've actually written my own too. I think Apache Runtime is only
measured in hundreds of kilobytes even with all the stuff you don't
need.
A quick Google search turned up this one C++ (MIT)
https://github.com/eidheim/tiny-process-library

So IUP + some JSON + some Process should be around 1MB-2MB. This is in
contrast to the Qt frameworks I have right now in my CMake bundle for
Mac.


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.

However, it is a very strong point that a light-weight API is much
nicer to use than a heavy-weight API.  So your post and that
open-source license got me quite interested in IUP (which I had frankly
never heard of before).

One of my fundamental criteria for a graphics library is it must have
complete internationalization support, i.e., the library must support
both unicode (preferably in the utf-8 encoding of unicode) and Complex
Text Layout (CTL).  Just for fun, I tested this cmake-gui capability
using a utf-8 encoded Arabic word "ﺳﻼم" (for "Peace" since that is
about the only Arabic word I know) to temporarily document one of the
PLplot cache variables and got good results (e.g., when I hovered over
the "TEST_PEACE" option the "ﺳﻼم" documentation of that option was laid out in 
the
correct right-to-left order by the current Qt-based cmake-gui because
Qt (as well as at least GTK+, wxWidgets, and GDI/GDI+/Uniscribe,
Direct2D/DirectWrite on Windows and preumably Mac OS X graphics as
well) support both unicode and CTL.  I also tried naming the
option itself "ﺳﻼم" rather than TEST_PEACE, and that rendered correctly
as well.

Note the above Arabic word for "Peace" may not be rendered correctly
(or at all) by your mailer, but if you dump this e-mail to a file
and look at it with less, or some unicode-aware editor like
emacs or vi (but not jed (!) I just discovered), it will be rendered
correctly just as in the PLplot Peace flag example,
.

Also, if you use the cmake application instead of cmake-gui, the
resulting cache file CMakeCache.txt has the correct rendering
of "ﺳﻼم" if viewed with the correct unicode-aware application.

So both the cmake and cmake-gui applications currently support unicode
and CTL, but the question on my mind is if cmake-gui is changed to use
IUP rather than Qt will that nice result continue for that application?

So to help answer that question I did a google search for the terms

unicode site:http://webserver2.tecgraf.puc-rio.br/iup/

and it appears from those 10 hits that IUP completely 

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

[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.
Usually GTK3 or GTK2. As far as I know, the GTK ABI itself is stable
(everything is C which also helps), so on something like Linux, the
only issue is the usual how do you deal glibc and your own
dependencies. My typical approach is build on old distro like Ubuntu
12.04LTS, though I've been moving to Steam-Runtime since they actually
care about ABI stability.


> There's already a JSON library in CMake: jsoncpp.

Even better.

> The idea for process creation is to migrate to libuv once all of the
> dependencies are supported. Looking at the implementation here it
> is…naïve at best. It uses `sh -c` instead of `exec` to do its work which
> means that CMake would need to do manual pipe management anyways.

As I've said, there are tons of different ones. And I've even written
my own. Wrapping Unix fork/exec and Windows CreateProcess is a known
quantity so I'm just suggesting it doesn't need a massive library
dependency to accomplish.

-Eric
-- 

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] Future of ccmake and cmake-gui

[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 get an environment setup (especially on Mac
> and Windows...and building Qt on Raspberry Pi is a nightmare).
>
> Really ? On mac it's just brew install qt. On windows choco install qt-sdk
> (and it even comes with mingw so that you don't necessarily have to install
> visual studio).
> On Raspberry sudo apt-get install qtbase5-dev.
>

So 3rd party package systems are banned for me. They cause too many
dependency problems themselves. 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.
Also, it causes needless redundancy and changes the toolset if I
recall. It pulls a new version of gcc instead of using Xcode/clang on
your system and builds an entire dependency chain based on GNU tools.
Similar problem for Windows...Visual Studio is the requirement.

As for Pi, I think the problem I had was the Qt available in the repo
at the time was too old for me. (Typical Debian long release cycle
problem.)

But I still consider it a problem if these things are too hard to
build because (especially for me) there is always a new platform that
needs to be ported to.


> Building qt itself is a matter of doing (cue errors from typing in a mail
> without checking)
>
> git clone https://github.com/qt/qt5
> cd qt5 ; git submodule update --init qtbase ... # whatever submodules you
> need
> ./configure -open-source -confirm-license -nomake tests -nomake examples
> -prefix /opt/my-qt
> make -j8 && make install
>

My last experience was that there were critical bugs in the Qt Mac
release at the time (and this was the official binary release). And
Mac doesn't have configure/autotools by defaul. Again...no brew for
various reasons like above.

>
> Maybe consider a LTCG build (-ltcg) if this really matters ? This way I can
> get a moderately complex GUI app that uses gui, widgets, network, qml,
> etc...
> under ten megabytes, so something like cmake-gui should be way smaller...
> (this also removes any problem related to DLLs).

I wouldn't be able to say. And I never figured why Qt's RAM
consumption footprint is so high...based on all the DLL binary code it
has to load, or something more intrinsic to its implementation.


-Eric
-- 

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] Future of ccmake and cmake-gui

[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 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 result is 100% compatible with `ccmake`. The same would
>> > be
>> > possible with cmake-gui.
>> >
>> > Shall we proceed in this direction?
>> >
>> > To make the server available everywhere, we should backport the code
>> > from
>> > C++14 to C++11. I think this is limited to replacing `std::make_shared`.
>> >
>> > For cmake-gui, the proxies could use Qt functionality (QProcess,
>> > QJsonDocument, etc.). As a result, cmake-gui would not have any build
>> > dependencies apart from Qt.
>> >
>> > It might be worth considering to move ccmake and cmake-gui to their own
>> > repositories.
>> >
>> > Cheers, Daniel
>> >
>>
>> If this is a new rewrite...
>
>
> It is not. Both ccmake and cmake-gui use the use the `cmake` class as a
> facade to the cmakelib.
> In my prototype I re-implemented the `cmake` class as a client to the
> cmake-server using json-cpp and libuv.
> This allows separating ccmake and cmake-gui from the cmakelib without
> further changes to the rest of the code.
>
> The same client implementation might be used for ccmake and cmake-gui, but
> cmake-gui might as well use Qt facilities instead.
>
>> 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 Windows...and building Qt on Raspberry Pi is a nightmare). And the
>> binary sizes are large. (I do ship CMake to my users and its size with
>> the GUI is non-trivial.)
>>
>> CMake's actual GUI isn't that complex. Have you considered something
>> lighter-weight?
>>
>> As one alternative, there is IUP:
>> http://webserver2.tecgraf.puc-rio.br/iup/
>> (it's from the same university that created Lua...in fact I think one
>> of the original authors of the white paper/project went on to become
>> one of the Lua authors.)
>>
>> IUP differs from Qt in that is is focused on wrapping native GUI
>> widgets (in constrast to Qt which creates its own non-native widgets).
>> Hence, the library is really small since it only depends on each
>> platform's native libraries. The core library is about 1MB. I just
>> ported (rewrote) a simple Qt based app to IUP. The Qt version was
>> almost 40MB. The IUP RAM usage is also many times smaller.
>>
>> 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 is a lot implemented and I'm actually shipping
>> a simple app with it this week. Since CMake's GUI usage is also pretty
>> simple, I *think* there might already be enough implemented to do the
>> CMake-GUI...or it's close enough that I probably could finish those
>> needed features.
>>
>> Also, I implemented a CMake build system for IUP.
>>
>> IUP is MIT licensed.
>
>
> Sounds interesting.
>
>> Now IUP only does GUI (which is another reason it stays small), so you
>> will need to fill in the JSON and Process requirements. But there are
>> tons of JSON libraries. Off the top of my head, cJSON is a really
>> fast, tiny, and simple to use JSON library. It's a single C file and
>> header, so you can drop it right in the project. (Also MIT). It also
>> has a CMake build system if you really want it.
>>
>>
>>
>> And a cross-platform create process...those I've seen everywhere and
>> I've actually written my own too. I think Apache Runtime is only
>> measured in hundreds of kilobytes even with all the stuff you don't
>> need.
>> A quick Google search turned up this one C++ (MIT)
>> https://github.com/eidheim/tiny-process-library
>
>
> That would not be necessary. A cache editor build on IUP could use the same
> cmake client implementation as ccmake.
>
>> So IUP + some JSON + some Process should be around 1MB-2MB. This is in
>> contrast to the Qt frameworks I have right now in my CMake bundle for
>> Mac.
>>
>>
>> Anyway, I know this is going to be outside peoples' comfort-zone which
>> is why I'm not going to push hard on it. But in general, I would like
>> something smaller, easier to build, and lighter on system resources
>> (and real native GUIs generally provide a better user experience). So
>> I'm hoping 

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

[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 is a lot implemented and I'm actually shipping
> a simple app with it this week. Since CMake's GUI usage is also pretty
> simple, I *think* there might already be enough implemented to do the
> CMake-GUI...or it's close enough that I probably could finish those
> needed features.

How easy is it to ship binaries which work on any platform without also
shipping all of the necessary platform backends as well?

> Now IUP only does GUI (which is another reason it stays small), so you
> will need to fill in the JSON and Process requirements. But there are
> tons of JSON libraries. Off the top of my head, cJSON is a really
> fast, tiny, and simple to use JSON library. It's a single C file and
> header, so you can drop it right in the project. (Also MIT). It also
> has a CMake build system if you really want it.

There's already a JSON library in CMake: jsoncpp.

> And a cross-platform create process...those I've seen everywhere and
> I've actually written my own too. I think Apache Runtime is only
> measured in hundreds of kilobytes even with all the stuff you don't
> need.
> A quick Google search turned up this one C++ (MIT)
> https://github.com/eidheim/tiny-process-library

The idea for process creation is to migrate to libuv once all of the
dependencies are supported. Looking at the implementation here it
is…naïve at best. It uses `sh -c` instead of `exec` to do its work which
means that CMake would need to do manual pipe management anyways.

--Ben
-- 

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] Future of ccmake and cmake-gui

[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 result is 100% compatible with `ccmake`. The same would be
> possible with cmake-gui.
>
> Shall we proceed in this direction?
>
> To make the server available everywhere, we should backport the code from
> C++14 to C++11. I think this is limited to replacing `std::make_shared`.
>
> For cmake-gui, the proxies could use Qt functionality (QProcess,
> QJsonDocument, etc.). As a result, cmake-gui would not have any build
> dependencies apart from Qt.
>
> It might be worth considering to move ccmake and cmake-gui to their own
> repositories.
>
> Cheers, Daniel
>

If this is a new rewrite...
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 Windows...and building Qt on Raspberry Pi is a nightmare). And the
binary sizes are large. (I do ship CMake to my users and its size with
the GUI is non-trivial.)

CMake's actual GUI isn't that complex. Have you considered something
lighter-weight?

As one alternative, there is IUP:
http://webserver2.tecgraf.puc-rio.br/iup/
(it's from the same university that created Lua...in fact I think one
of the original authors of the white paper/project went on to become
one of the Lua authors.)

IUP differs from Qt in that is is focused on wrapping native GUI
widgets (in constrast to Qt which creates its own non-native widgets).
Hence, the library is really small since it only depends on each
platform's native libraries. The core library is about 1MB. I just
ported (rewrote) a simple Qt based app to IUP. The Qt version was
almost 40MB. The IUP RAM usage is also many times smaller.

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 is a lot implemented and I'm actually shipping
a simple app with it this week. Since CMake's GUI usage is also pretty
simple, I *think* there might already be enough implemented to do the
CMake-GUI...or it's close enough that I probably could finish those
needed features.

Also, I implemented a CMake build system for IUP.

IUP is MIT licensed.

Now IUP only does GUI (which is another reason it stays small), so you
will need to fill in the JSON and Process requirements. But there are
tons of JSON libraries. Off the top of my head, cJSON is a really
fast, tiny, and simple to use JSON library. It's a single C file and
header, so you can drop it right in the project. (Also MIT). It also
has a CMake build system if you really want it.

And a cross-platform create process...those I've seen everywhere and
I've actually written my own too. I think Apache Runtime is only
measured in hundreds of kilobytes even with all the stuff you don't
need.
A quick Google search turned up this one C++ (MIT)
https://github.com/eidheim/tiny-process-library

So IUP + some JSON + some Process should be around 1MB-2MB. This is in
contrast to the Qt frameworks I have right now in my CMake bundle for
Mac.


Anyway, I know this is going to be outside peoples' comfort-zone which
is why I'm not going to push hard on it. But in general, I would like
something smaller, easier to build, and lighter on system resources
(and real native GUIs generally provide a better user experience). So
I'm hoping to at least get you thinking about that irrespective of any
particular framework. And if there is interest in IUP, I'm happy to
discuss more or help.

Thanks,
Eric
-- 

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] Future of ccmake and cmake-gui

[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` instances in the code.

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] Future of ccmake and cmake-gui

[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
> `cmState`. The result is 100% compatible with `ccmake`. The same would be
> possible with cmake-gui.

Well, not sure that I want *100%* compatible with ccmake if we're
rewriting bits of it; there are lots of improvements that could be made
;) .

> To make the server available everywhere, we should backport the code from
> C++14 to C++11. I think this is limited to replacing `std::make_shared`.

The make_shared function is there, but make_unique is missing in C++11.

--Ben
-- 

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] iOS: direction to official support and questions

[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 Enficiaud  wrote:
> Le 10.08.17 à 17:04, Brad King a écrit :
>> On 08/08/2017 08:08 AM, Raffi Enficiaud wrote:
>>> I have looked a bit to the Android toolchains, and I have to say I found
>>> those quite complicated as a first reading :)
>>

I personally think the Android toolchain is way more complicated than
the iOS toolchain. Among the reasons are that every NDK release broke
something different as they kept changing the compiler and conventions
(the gcc to clang move was the most recent biggie, but old-timers
might remember the standalone toolchain difficulties.). Then you have
to pick different API levels because the each NDK release ships a
separate API subtarget for all prior versions of Android. Then add all
the multiple architectures (mips, arm, x86, 64-bit) and the
subvariants (armv5, armv7, armv7+NEON, etc), 4 different C++ standard
libraries you have to choose from, and other nuisances like Android on
Windows...makes the whole thing a mess.


>> Ideally CMake would gain iOS platform modules such that one could
>> set CMAKE_SYSTEM_NAME to `iOS`.


>>> where this path is hard coded, and points to the fat static libraries
>>> prefix path of boost. If I remove this path, FindBoost does not find the
>>> boost libraries anymore (of course I am passing BOOST_ROOT). In
>>> addition, I have this:
>>>
>>> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY)
>>> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>>> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>>
>> These last three lines tell the find commands to only look at
>> paths re-rooted under CMAKE_FIND_ROOT_PATH and CMAKE_SYSROOT.
>> If boost is not under one of those then it won't be found.
>>

That sounds right. The general problem is you don't want to
accidentally pick up OSX stuff on your system.

I've generally used a combination of two things. I modified my
toolchain to have special new root paths which I can define and I put
all my iOS stuff there, and/or I use the -C initial cache feature of
CMake to prespecify the locations. (And sometimes my initial caches
use my new root path variables so the initial cache is flexible and
not hard coded.)

>>> set(CMAKE_MACOSX_BUNDLE YES)
>>
>> Is it possible to build any binary of any form on iOS without this?
>
> You're right, I do not think this is possible.

As far as I know, it always must be a bundle.

> As I understand it, this is a problem of try_compile: as signing of 
> application is required for generating a binary for iOS, this one fails very 
> early when CMake discovers the capabilities of the compiler.

I have not encountered this. I don't think it is true, but I rarely
use try_compile.

Building iOS static libraries are not signed. And I don't think
simulator targets require signing either.

Signing is required for running on device.


That said, there are a ton of other problems related to signing which
are completely broken with CMake.

Right now, the biggest pain point for me is the new Automatic Code
signing. Prior to Xcode 8, you could set a CMake Xcode attribute to
explicitly set the key to use. But this now conflicts with the new
Automatic Code signing, and this his cannot be controlled by a CMake
attribute and it breaks everything. And even if that were fixed, Xcode
needs a second property, the Team. While this can be set by an
attribute, the problem is just about every user has a different team
and it is not easy to know. Xcode has a way of finding out what teams
are available so you can pick it in a drop-down list (same with the
keys). But for a CMake user, this is nearly impossible to know
apriori. I think the only way to fix this is to modify CMake to 1) try
to defer to Xcode's built-in behavior & 2) if the user sets this, some
how don't let CMake overwrite/clobber just that setting when the
project regenerates on an update.

Semi-related is the Mac OS X entitlements system which is connected to
code signing and shipping on the Mac App Store. It has a lot of these
same problems and I think it needs to be fixed in the same fashion.
The entitlements are supposed to show up in a dedicated tab in the
project settings, but CMake projects tend to be blank in this area.

And related to that is the iOS device orientation and launch screen
setting which is the same story.

>
> Currently the main issue I am seeing is the multiarch/multisysroot
> target of XCode that is kind of lost when using CMake. By
> multiarch/multisysroot, I mean that Xcode is able to switch from
> iPhoneSimulatorXY to iPhoneXY without changing the project, and within
> the same view.

Yes, that is a huge problem. I've found this to be very fragile.
However for the moment, it kind of works.

Re: [cmake-developers] Windows symbolic links handling

[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 happened?
>
>
I happened in release 3.1.0, back 2014. The commit which changed behaviour
was this:

https://github.com/Kitware/CMake/commit/9571214e55cb8b86dadb26b6b1d696ef488bdd4b

In source file Source/cmTimestamp.cxx, stat call was replaced by kwsys
ModifiedTime
call. kwsys relies in system function GetFileAttributesExW which do not
resolve symlinks, however stat does (in spite of not being documentented in
MSDN).

Removing the #ifdef WIN32 clause in ModifiedTime and using stat call
resolves the problem, nevertheless, this change does not resolves
get_filename_compoment symlinks issue in Windows. The problem here is again
in kwsys, which uses system call GetFullPathNameW (which do not resolves
symlinks) instead of GetFinalPathNameByHandleW (which does).

Despite of being two different commands, I think they are very related in
this issue and the change should be make together.


> > patch to fix both get_filename_compoment and FILE(TIMESTAMP ...)
> >
> > What troubles me is that symlink under Windows is a feature introduced in
> > Windows Vista and the change for handling them will break Windows XP
> > compatibility. Is this acceptable?
>
> We still support running on XP.  If any newer Windows APIs are needed they
> need to be looked up dynamically.  Also, behavior changes for existing
> commands
> may need a policy.
>
>
I did not dig into cmake policies development but I am willing to submit a
patch which includes a new policy as soon I can piece it up all together.


> See also https://gitlab.kitware.com/cmake/cmake/issues/16926 for
> discussion
> of symbolic link APIs.
>
> -Brad
>

Manuel.
-- 

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