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

[Eric Wing]

> 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 the current Qt requirement in that
> department.

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 for something small
like the CMake GUI, it wouldn't bother me as much. That said, it
sounds like this is not a rewrite, so I guess the conversation is
moot.

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

[Eric Wing]

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

[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 GUIs, I would disagree with
this point because the system libraries are typically already loaded
by everything. Furthermore, even non-native frameworks like Qt need to
link into the native frameworks even though they may not be using much
from it. So you take a double hit because you get both the system
frameworks and the non-native implementation. This is very apparent on
Mac, where everything links to Foundation and AppKit as a baseline.

I do cede that GTK is not small. However, almost all the distros I see
today ship at least GTK2, with a lot of forks UI forks in protest of
GTK3 and Gnome, and intentionally kept GTK2 alive because it was much
smaller than GTK3. So there is probably something already on your
system using it. But if you really need something smaller, Motif is
always an option. (Also, somebody is experimenting with my Cocoa
backend and has a prototype working in GNUStep on Linux though I
wouldn't necessarily consider that small either and few systems
install it.)



> 
> 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 me in a position to
> do the above simple test myself. But that is in the speculative
> future and only for the GTK+ backend case.  So your test results now
> on this unicode and CTL question for as many of the IUP backends as
> possible would be much appreciated.
> 

I'll be honest, string encodings are not my strong suit. What I can
say is that IUP is developed in Brazil where they speak Portuguese. So
I know being able to at least support their language is important to
them, so I hope that means they got a lot of the string encoding stuff
right. For the Cocoa implementation, IUP has a mode called UTF8 mode
and I am basically enforcing that it is on for Mac. For every C string
I have to bridge, I hand it to the native Cocoa UTF8 APIs that convert
back and forth between C strings and NSStrings (native Cocoa string
type). I did have some fellow Cocoa devs review my code and run a few
tests, and they believed it was correct. Though it was not exhaustive.
If the implementation is wrong, I would like to correct it.

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

> 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 <jeanmichael.celer...@gmail.com> 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

[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] 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] Linking Apple frameworks

[Eric Wing]

On 8/8/17, Brad King <brad.k...@kitware.com> wrote:
> On 08/07/2017 05:27 PM, Eric Wing wrote:
>> I think that would be a mistake because it seems that the only purpose
>> of this change would be so you could bypass CMake and try to directly
>> invoke some kind of command line invocation on the dynamic library
>> inside the .framework bundle.
>
> The ld(1) man page on macOS says that "-framework foo" tells the
> linker to search for "foo.framework/foo".  For linking this is very
> similar to "-lfoo" searching for "libfoo.so" and "libfoo.a" in the
> linker search path.  We discourage the latter because it is hard to
> ensure that the proper library will be found.  I think framework
> libraries should be linked by absolute path too.
>
> For example, say one has these libraries in frameworks:
>
> /path/A/foo.framework/foo  # want this one
> /path/A/bar.framework/bar
> /path/B/foo.framework/foo
> /path/B/bar.framework/bar  # want this one
>
> How does one achieve this case with Xcode's abstractions or with
> the "-framework foo" flag?  CMake with imported targets already
> achieves this, and links via absolute path to each library file.
>
>> be treating the framework bundle as a whole because all parts of it
>> are designed to be useful.
>
> In cases where that is needed it is still possible to detect that
> a library file is part of a framework.
>
>> The bundle assets like any .nib files and
>> the Info.plist are sometimes critical components of the framework. So
>> things like copying the whole framework and embedding them in the app
>> bundle are important things to do.
> [snip]
>> But if you did decide to change this, I think it should only happen in
>> conjunction of solving the rest of the needed functionality for
>> dealing with frameworks, i.e. copying the entire framework bundle into
>> the app bundle, codesigning the framework in the app bundle,
>
> We already have ways of doing those things at installation and
> packaging time.  Linking the build-tree copy is too early.
>
> -Brad
>

So two more quick points.

1) The absolute path this is actually a problem, especially for iOS
because of the way the SDK stuff works. There are two subcases where
the CMake behavior breaks down:
a)  When the user needs to change the target SDK on the fly
a) When switching between simulator and device build, this
effectively changes the root of the SDK on the fly so different
binaries can be pulled in to link to. Unfortunately Apple doesn't use
their fat binary concept here, and actually causes problems for 3rd
party iOS frameworks because if you try to build a fat dynamic
library, the app store rejects it because you have simulator
architectures.

2) The packaging and installation conventions CMake imposes are just
plain wrong for Apple development. It needs to be an atomic piece as
part of the main build phase, not a two phase thing. Xcode knows it
must bundle all the resources, bundle the frameworks, manage the
sandboxing entitlements, and do all the codesigning in the correct
order and this is built into Xcode's build process. The CMake way
breaks this and basically gets in the way of developing any proper app
that would need to be shipped on the App store. It also breaks a lot
of the tooling around it since it assumes that once you hit the Run
button, Xcode puts everything together correctly. This can affect
everything from trying to test  InAppPurchase features to debugging
with Instruments. (And again, this is problematic for iOS which shares
the same expected atomic workflow.)

-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] Linking Apple frameworks

[Eric Wing]

On 8/7/17, Brad King  wrote:
> On 08/05/2017 07:58 PM, Craig Scott wrote:
>> target_link_libraries(foo PRIVATE "-framework AppKit")
>>
>> Strangely, with the library quoted as above, the embedded space
>> is not escaped, leading to the (desirable but surprising) result
>
> Link flags starting in `-` are treated as a raw part of the command
> line.  That's how it evolved historically.
>
>> As extra context, a correct final linker command line can also be achieved
>> like this:
>>
>> find_library(APPKIT_LIB AppKit)
>> target_link_libraries(foo PRIVATE ${APPKIT_LIB})
>>
>> In this case, while APPKIT_LIB contains a full absolute path to the
>> framework, CMake manages to recognise it as a framework and shortens
>> the linker flags to just -framework AppKit.
>
> There is special case logic for this, but IMO it was a mistake.
> Ideally when find_library finds a framework library it should
> return the absolute path to the library file within the framework,
> e.g. `/path/to/foo.framework/foo`.  Then no special logic would
> be needed to recognize it and the library file can be passed
> directly on link lines.  All the Modules/Find*.cmake modules
> that provide imported targets have special logic to transform
> the find_library result in this way.  Perhaps we should fix this
> with a policy.
>
> Also the points raised in Eric Wing's response are valid concerns.
>
> -Brad

I think that would be a mistake because it seems that the only purpose
of this change would be so you could bypass CMake and try to directly
invoke some kind of command line invocation on the dynamic library
inside the .framework bundle. This seems to encourage the wrong kind
of behavior and there is almost no real world use case in the native
Apple world where you should ever do that (I can contrive a couple in
my head for iOS but they are esoteric cases.). In general, you should
be treating the framework bundle as a whole because all parts of it
are designed to be useful. The bundle assets like any .nib files and
the Info.plist are sometimes critical components of the framework. So
things like copying the whole framework and embedding them in the app
bundle are important things to do. And I mentioned the current problem
of codesigning an app bundle. But right now, getting the path to the
entire framework is more useful so you can at least manually do these
things with CMake. Changing that would only complicate this process in
that now you have to play guessing games on what the framework’s
internal layout looks like. (Mac and iOS differ, and there are
esoteric corner cases if you have to deal with a framework that ships
multiple versions.) (And you can imagine this kind of change will
break a ton of my scripts that currently do all this missing steps.)


But if you did decide to change this, I think it should only happen in
conjunction of solving the rest of the needed functionality for
dealing with frameworks, i.e. copying the entire framework bundle into
the app bundle, codesigning the framework in the app bundle, and using
the built in Xcode functionality for this with the Xcode generator.
Also making this a little easier to automatically setup in CMake would
be welcome, and could include things like setting the @rpath on the
frameworks and install_name on the app as part of the process (since
these things always go together with bundling the framework). And
possibly some mechanism that can handle create fat binaries for
deploying an iOS framework but including stripping the simulator
architectures for a release app.


A slight tangent, but kind of related example of the problem is
Android’s new AAR library bundle format. AAR is still horribly broken
and incomplete when it comes to the NDK side (and by looking at the
current rate of progress may never get fixed), but does solve some
serious problems for Android libraries in general so I’m starting to
find they are unfortunately the best solution despite the PITA they
are. AARs share some concepts of the .framework in that they are
container packages that contain a lot of different important
components beyond just the dynamic library stub your native code needs
to link to. Two of the most important features is that it can merge
the R.java resource system and the AndroidManifest.xml that the
library declares it needs to use into your final app. (The way Android
works, all this stuff must be put directly into your app and libraries
don’t officially get their own notion of these things. This makes
integrating/using any library a PITA on Android, so AAR finally starts
automating this process.) But of course the consequence is that once
again, we have an alien library format that CMake doesn’t know how to
deal with yet. I think CMake can eventually be taught, but it requires
that users not be making too many direct assumptions about the build
and linking process, and especially direct invocations of flags.

(And another slight tangent…I’m still working on the 

Re: [cmake-developers] Linking Apple frameworks

[Eric Wing]

On 8/5/17, Craig Scott  wrote:
> I'm exploring the behaviour of target_link_libraries() where the library to
> be linked is an Apple framework. As part of this, I noticed that the
> following does not work:
>
> target_link_libraries(foo PRIVATE -framework AppKit)
>
>
> This fails because the link command ends up with -framework -lAppKit
> instead of -framework AppKit. Maybe that's expected, but then the following
> DOES work:
>
> target_link_libraries(foo PRIVATE "-framework AppKit")
>
>
> Strangely, with the library quoted as above, the embedded space is not
> escaped, leading to the (desirable but surprising) result -framework AppKit
> in
> the linker command line (i.e. the space isn't escaped and the two words are
> not quoted). *Which of these is the correct way (if either) and are both
> behaving as expected?*


I would argue both of the above are incorrect.

For some history, people passing explicit flags (e.g. -l and -L) was
the exact problem we fought in the first place many years ago. Most
people's scripts wouldn't work when porting to Mac because they
weren't using the CMake abstractions to inform CMake was going on, but
instead bypassing them by setting flags explicitly. So when brought to
Mac, things didn't necessarily work because there were a bunch of
explicit flags written in the scripts (including the Find*.cmake
scripts.) (There was actually a similar problem when porting to Visual
Studio too.)

Then when Apple brought (back) Universal binaries for Intel and then
64-bit, the flags needed to handle the build process got more
complicated. People passing their own flags at the wrong place could
cause problems. (A similar problem occurred as Apple pushed the SDK
model.)

Then (when not talking about system supplied frameworks), when iOS
came, they forbidded dynamic linking for the longest time, so
everything had to be as static libraries. So -framework flags would
not work. Obeying the normal CMake abstractions prevents problems here
too since it knows what to do for static libraries vs. frameworks.

And I would argue this is still wrong today because CMake will have a
harder time understanding there is a library involved here because you
didn't declare it with find_library. Particularly with the Xcode
generator, this information is very useful because the information
isn't always explicitly passed down to a command line invocation.
Sometimes it needs to be declarative so for the Xcode recognizes that
a framework is involved and allows Xcode to handle the correct
behavior.

Already there exists a problem in the Xcode generator that it doesn't
completely use all the framework and library built-in mechanisms, and
this is currently causing me problems for apps that need to be
codesigned. Xcode has a copy-frameworks-and-codessign phase which
CMake does not use. I hope this can be fixed, but I suspect it would
never work with the above two approaches you are asking about.

-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] [CMake] CMake integration in Gradle (Android Studio)

[Eric Wing]

So I have been using (a custom) CMake + Android Studio/Gradle for some
years now. I only recently saw that both official CMake is adding
Android support, and that the official Android tools are supporting
CMake. I’m actually still confused on the differences between the two
and what each offers in terms of features.

My custom/jury-rigged CMake is derived from the OpenCV Android
toolchain which has forked around for many years. Currently, I have a
combination of custom shell scripts + modified toolchain + modified
CMake to make things work.


My cross-platform requirements have been:

- Must generate be able to generate a new Android Studio/Gradle
project, like how Xcode, Visual Studio, etc. are generated.

- Must handle multiple Android architectures (armv5, armv7, x86, arm64, x86_64)

- Must be able to handle both the native code stuff, and the annoying
Android specific Java code in order to build a complete/working
Android application that can be installed/run through the normal
Android Studio/Gradle user interface.

- Should work on Mac, Linux, and Android



The way it currently works is:

- I have a front end scripts you must run which ultimately invoke
cmake -G “Unix Makefiles” for the Android NDK. These scripts feed my
android toolchain as well as provide the locations to the Android NDK
and SDK. Also, these scripts will generate Gradle and Android Studio
projects. (I basically brute force stripped down a real Gradle/Studio
project and figured out what values I need to inject into it to use as
a template. Many of the injected values are provided from CMake
variables I define in my project CMakeLists.txt)

- The Gradle/Studio project generated has a custom Groovy script phase
that when building, invokes an external shell script as part of the
build process. This external script ultimately calls CMake to build
the native components of the project.

- Because CMake doesn’t handle multiple architectures for Android, my
script actually generates multiple CMake projects, one for each
architecture, separated into directory structures that try to mimic
the official names of the different Android architectures. (This is
kind of brute force, and is not currently easy to opt-out of different
architectures.)

- At the end of the script phase, I use a CMake “install” to copy the
build products for each architecture to the correct location in the
Gradle/Studio Java layout, so the Java part of the build will continue
on doing the right thing.

- The rest of the Gradle/Studio build will continue on and build the
Android Java parts of the project. (I have a specific convention for
where the Android/Java files go in my project structure. Unlike the
annoying thing that Google forced us to do with ndk-build, the Java
stuff is no longer at the root of the source tree, but parked in a
special Android subdirectory. The former was a stupid/evil requirement
for every pre-existing cross-platform project out there, and an
arrogant presumption for new projects, so I did away with it.)



Here are a few videos that show the workflow (in my SDK called Blurrr)

"Workflow" in Swift: The Android Addendum (shows just the Android part)
https://www.youtube.com/watch?v=w6FY_qSi8yY


Workflow": Cross-platform Dev in Swift
(This shows the same project as above, but for the non-Android
platforms, showing it is indeed a single, unified CMake project that
can drive Linux, OS X, iOS, Windows, and Raspberry Pi (and Android).
https://www.youtube.com/watch?v=w8ftI9mpGdY


Blurrr Introduction Part 3 (Shows the different build platforms in a
little more detail. This video is the oldest, so things have improved
a bit.)
https://www.youtube.com/watch?v=exPtM-02YRY



So my wish list for the new CMake versions is that is handles all of
this. (Multi-arch and Gradle/Studio generation especially.)

I have not yet investigated how hard it will be to migrate to one of
the two other versions of CMake. Since Swift is one of my supported
languages, this currently requires me to use a forked CMake I’ve been
working on. However, I am happy to work with people who want to try to
integrate some of my features directly into CMake if they are still
missing (such as the Gradle/Studio generation).

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] Problem with find_path and Frameworks

[Eric Wing]

On 5/25/16, Harry Mallon  wrote:
> I have quite a specific problem with find_path where
> "find_path(IOKIT_INCLUDE_DIR "IOKit/pci/IOPCIDevice.h")" returns
> "/System/Library/Frameworks/Kernel.framework/Headers/IOKit/pci" rather than
> "/System/Library/Frameworks/Kernel.framework/Headers/".
>
> It is reproducible on OSX with the following CMakeLists.txt:
>
> cmake_minimum_required(VERSION 3.0)
> find_path(IOKIT_INCLUDE_DIR "IOKit/pci/IOPCIDevice.h")
> message("Path returned: ${IOKIT_INCLUDE_DIR}")
>
> Here is a patch which seems to fix it for me:
>

This is a pretty atypical situation. I’m actually not sure what the
behavior should be. But we need to be careful to not break the
existing cases. I’m a little worried that there may be things out
there relying on the existing behavior. I’m also not convinced this
actually needs a patch.


The framework header path system was hammered out over a long period
of time. There are two common use cases that it was designed to
handle:

case 1: #import 
find_path(COCOA_INCLUDE_DIR “Cocoa/Cocoa.h”)
# Returns something like /System/Library/Frameworks/Cocoa.framework


case 2: #include “al.h”
find_path(OPENAL_INCLUDE_DIR “al.h”)
# Returns something like /System/Library/Frameworks/OpenAL.framework/Headers


The reason for this behavior is that unlike other platforms,
frameworks are not a direct mapping to file system mapping. When
dealing with official Apple frameworks, you are expected to use case
1. But  the second form is an important concession for cross-platform
libraries. The problem is that many libraries, especially 3rd party
libraries, do not end up in subdirectories with the same names on all
platforms.

For OpenGL, most Unix’s do , but Apple does .
For OpenAL, it is crazier because it depends on which implementation
you use. Apple does , OpenAL Soft does , but
others have presumes no subdirectory at all.
And a lot of third party libraries don’t have any official
conventions, so distributions do everything differently. So for
cross-platform, you are encouraged to do “Foo.h” omitting a path and
letting the build system deal with it (since CMake can do a better job
here than a massive, hand-coded mess of #ifdefs in your files.


So your case seems very atypical because you are using something
inside Kernel.framework and the header you want is not in
IOKit.framework. If it was a more typical scenario like
IOKit.framework,

I would kind of expect you to find a file in IOKit at the top level
instead to represent all your IOKit dealings, e.g.

find_path(IOKIT_INCLUDE_DIR “IOKit/IOKitLib.h”)

Then in your code you would do:
#import , and what you get back from CMake
(/System/Library/Frameworks/IOKit.framework) would be correct.

But since pci doesn’t actually seem to be directly in IOKit, but
instead the Kernel.framework subdirectory mess, I’m not sure what the
appropriate thing is. The normal native Xcode header path search
mechanism doesn’t seem to support this case and I found an old mailing
list thread suggesting that this is Apple’s way of telling you to
keep-out.


I would actually be inclined to suggest a much more generic find for
Kernel.framework and build your paths manually from there.


So either something simple like:
find_path(KERNEL_INCLUDE_DIR IOKit)
# return /System/Library/Frameworks/Kernel.framework/Headers


Or something a little more defensive to avoid possible name
collisions, but requires manual construction:
find_path(KERNEL_INCLUDE_DIR Kernel/IOKit)
# return /System/Library/Frameworks/Kernel.framework
set(KERNEL_IOKIT_INCLUDE_DIR “${KERNEL_INCLUDE_DIR}/Headers”)


-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] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

I'm finding that I'm going to need to completely separate the C FLAGS
from the Swift FLAGS. I hit some complicated situations where the C
FLAGS (both compile and linker) are confusing the process and
shouldn't be passed to Swift.

I see in the CMakeSwiftInformation.cmake, there is a
. However, I do not see a ,
just .

Additionally, in regular CMake script, I was trying to set/use
${CMAKE_Swift_FLAGS} hoping it would just work, but it doesn't seem to
have any effect. Is this something I'm going to have to implement in
the C++ core?

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] Support of Scala language

[Eric Wing]

>>
>>If we're starting with support for a new language then we should
>>add it properly as a first-class language.  Eric and Michael (in Cc)
>>have been working on this for Swift and C# recently.  Likely there
>>is some overlap in design space.
>>

On 2/19/16, CHEVRIER, Marc  wrote:
> I agree. The right approach is to do an integration of Java in the same way
> as C or C++.
> But I don’t have currently enough CMake skills to do this work.
>
> Do you have some documentation explaining how language support is done in
> CMake ? And how specific behaviours of Java/Scala can be supported in
> CMake:
> * All sources composing a jar must be compiled all at once
> * A source file can produce an arbitrary number of binary files (.class)
> with various (and unpredictable) names.
>

Yes, for Swift, I think I'm going to need something similar to the all
sources at once thing. I'm avoiding this for the moment, but I'm told
the mechanism I'm relying on isn't guaranteed to work in the future.
-- 

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] Drop support for older Xcode versions?

[Eric Wing]

On 2/9/16, Davy Durham  wrote:
> I'll say that in my line of work, we still have to support OS X 10.6
> (just dropped 10.5 support) .. And we're doing this at Apple's own
> request/demand!  It's not fun.  I've had to hack tools around to get
> somewhat newer tool chains to continue to work, but it's been /great/
> that cmake hasn't been an obstacle in this endeavour.

Supporting 10.6...this is what I'm referring to. In Apple's world,
this means you are on 10.11 using Xcode 7.3 and setting the Deployment
target to 10.6.

I know for hard cases, it is never that simple, but do you really need
to be on 10.6 to develop for 10.6?

A corollary issue is that when you buy a new Mac, it usually can't
boot an operating system older than the one it shipped with. Backwards
compatibility is hard. This suggests two alternative paths:

- CMake archives older versions. You can always download the last
official supported version for CMake that runs on 10.6.

- We split the Xcode generators into per-version buckets. (Xcode 3, 4,
5, 6, 7). Work freezes on older generators after awhile, but hopefully
won't break. (Yeah, I know core CMake changes can get dicey, which is
why I didn't really want to suggest this.)

Anyway food for thought.
-- 

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] Drop support for older Xcode versions?

[Eric Wing]

On 2/6/16, Gregor Jasny via cmake-developers  wrote:
> Hello,
>
> I'd like to get your feedback on deprecating or dropping support for
> older Xcode versions. During changes on the Xcode generator it gets
> harder and harder to test against old and very old Xcode versions like 3
> and 4.
>
> Are there still users around for these versions of Xcode?
>
> PS: I'm talking here about the Xcode generator which creates Xcode
> projects, not the Makefile or Ninja generator.
>
> Thanks,
> Gregor
> --
>

I personally am not using them. My more serious problem is that the
Xcode projects being generated now are not keeping up with modern
Xcode and the features that need to be accessible/set. The reality of
Apple development is you must be on the latest stable Xcode if you
need to ship apps on the Mac or iOS Store, otherwise Apple can reject
your app. Their design philosophy, regardless if you agree with it or
not, is to build with the latest and build against backwards
compatibility deployment targets, not build with the oldest and pray
it will work with future changes that couldn't be predicted at the
time. Their platform, their rules.

So I'm all in favor of dropping legacy platforms if it means
ultimately helping make the Xcode generator work better for modern
Xcode. General rule of thumb for Apple development is support the
latest and -1 version. If you can do more, fine, but don't compromise
the recent stuff in order to achieve distant backwards compatibility.

-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] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

On 2/4/16, Brad King <brad.k...@kitware.com> wrote:
> On 01/29/2016 03:16 PM, Eric Wing wrote:
>> I need more guidance here. I'm not connecting the dots.
>> My problem seems to be that the execute_process() in
>> CMakeDetermineCompilerId.cmake is trying to invoke the command:
>> 'swift CompilerId/main.swift'
> [snip]
>> Looking at the execute_process() that gets invoked (final one in the
>> big if/elseif block of CMAKE_DETERMINE_COMPILER_ID_BUILD), the only
>> way to get the flags I need are via CMAKE_${lang}_COMPILER_ID_FLAGS.
>
> Some refactoring may be needed to allow language-specific behavior
> to add flags that must be there for the check.  Add an explicit
> internal variable or other code path to support it (that is just
> not set for other languages).  The semantics of selecting flags
> from the environment in CMAKE_${lang}_COMPILER_ID_FLAGS must not
> change.
>
> Thanks,
> -Brad
>
>

Okay, thanks, will do.

A quick update on my progress.

- I started looking at the DEFINE system for Swift. It has a very
simplified form of what we would do in C. You can doo -DFOO for
#if FOO
// do something
#endif

But it doesn't allow for anything more complicated like values. So
this is not supported: -DFOO=1

So currently there doesn't seem to be any compiler failure, it just
doesn't do anything useful.

Currently I'm using ADD_DEFINITIONS. And that works. However, since
this blends C/C++/Obj-C/Swift into the same pool, it doesn't feel
right. (I think Xcode has separate definitions for Swift.) Right now
if I'm clever and don't pick any definitions that conflict, I can use
the system. And the more complex ones are simply ignored by Swift. But
longer term, I'm thinking these may need to be split up.


- Second, I got word from a Swift engineer that the 'swift' frontend
compiler is not a supported tool and can break the interface. I should
be using swiftc. Furthermore, I was told that the file-by-file
compilation which 'swift' allows is not really supported and the
output I'm seeing from Xcode is more debug information than what's
really going on. They seemed adamant that the all files in one-shot
via swiftc was the correct path and what I was doing was unreliable
and also loses information for the debugger and libraries.

Anyway, I'm still reflecting on this about what to do next. The
reality is that what I have right now works (for me), and solves a
bunch of problems that their current tools do not solve (Xcode is more
proof of that). The current path has pretty minimal changes to CMake
as well. I'm still reflecting and will probably need to press them for
more specifics, but based on all the realities of the situation, I'm
thinking I should press on with this initial implementation to get
something useable if not perfect. But longer term, we probably need to
look at swiftc and one-shot.
-- 

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] [ANNOUNCE] cmake-unit - A new unit testing framework for CMake

[Eric Wing]

On 1/29/16, Brad King  wrote:
> On 01/25/2016 11:01 AM, Sam Spilsbury wrote:
>> Over the last two years I've been working on a new unit testing
>> framework for CMake. I started this project because I've been writing
>> some other fairly complex CMake modules and I kept making mistakes
>> which would take me hours to debug weeks down the line.
>>
>> The project is, rather unimaginatively, called cmake-unit. The key
>> difference between this and the RunCMake framework that's used by
>> CMake internally is that cmake-unit more closely resembles an xUnit
>> architecture. It has support for a generic assert_that function and
>> matchers, test-case autodiscovery, coverage report generation and
>> allows you to keep all your tests together in a single file. The only
>> downside so far is that it runs a fair bit slower than RunCMake does.
>
> Nice.  I think if something like this were to be provided by upstream
> CMake it would be better to implement it directly in C++, at least for
> the test execution and output matching parts.  That would be much faster
> than a pure CMake language implementation and also would not need hacks
> to execute CMake language functions.
>
> One of the weaknesses of RunCMake infrastructure is that the CMake regex
> engine is not meant for large expressions.  For example, the number of
> ()-groups is limited to 10 or so.  It is also not as expressive as
> modern regex implementations offer.  There has been discussion about
> replacing the regex engine previously:
>
>  https://cmake.org/pipermail/cmake-developers/2011-November/014249.html
>
> but there are major compatibility challenges:
>
>  https://cmake.org/pipermail/cmake-developers/2011-November/014376.html
>
> OTOH in a brand new interface we could use an alternate regex engine
> from the beginning.
>
> -Brad
>

Just a random thought on the regex issue since we were talking about
Lua in the other thread. Not saying this is the way to go, but
something worth knowing about.

Lua has a library called LPeg, which was created by the Lua authors
themselves. It is basically academically rigorous rethink of the regex
problem.

There is a good presentation of it here:
https://vimeo.com/1485123

But in a nutshell, "RegEx" (distinct for Computer Science notion of
regular expressions) are a hack because they leave the domain of CS
and what can be understood/proven about computability. This results in
implementation dependent, unpredictable performance costs for RegEx
with no mathematical grounding. And a lot of the features bolted on to
RegEx have odd behaviors and limitations that can be
surprising/frustrating. Lua thought about this problem not only
because the lack of elegance, but also because PCRE implementations
are huge...much larger than Lua itself.

So they turned to old research on something called PEGs (Parseable
Expression Grammars). They are akin to Context Free Grammars...drawing
the analogy that CFGs are one up the computability ladder from regular
expressions. This allows PEGs to capture more complicated/expressive
things that RegEx has been abused to try to handle. (Some examples are
in the video.)

I'm by no means an LPeg expert, but I had one project where I had to
do Android package name validation, which follows the rules of Java
language package names. LPeg comes with a convenience layer called
"re" (which might stand for regular expression...haven't thought if
they mean in the 'pure' sense), which allows you to write your
patterns in something that resembles BNF grammars. It was a real
delight because suddenly everything was really clear and readable. (I
have a Perl background so I'm very used to crazy RegEx.)

Anyway, I figure one reason CMake doesn't already have a full blown
PCRE engine is because of the size and complexity. (I know SWIG
doesn't include PCRE for some reason and encourages you to download it
separately and conditionally compiles (disabling features) based on
whether you have it or not.) So this might be another be another angle
to look at if a Lua effort is serious. (Timing will be a problem
because I suspect the Lua thing is pretty far off. But this is another
angle to consider about what we would want a Lua engine to do for
CMake.) Last I checked, my built LPeg binary was under 50k.
-- 

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] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

On 1/20/16, Brad King <brad.k...@kitware.com> wrote:
> On 01/20/2016 08:48 AM, Eric Wing wrote:
>> I thought maybe setting the internal
>> CMAKE_${lang}_COMPILER_ID_FLAGS_LIST or
>> CMAKE_${lang}_COMPILER_ID_FLAGS
>> to "-version" would fix this.
>>
>> But this did nothing.
>
> Those are internal details of the CMAKE_DETERMINE_COMPILER_ID
> function and are not meant to be set anywhere else.  I think you
> may be looking for something like this:
>
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineFortranCompiler.cmake;hb=v3.4.2#l122
>
> It is used by the CMAKE_DETERMINE_COMPILER_ID_VENDOR fallback when
> the compiler id cannot be extracted from the basic compiler output.
> More work may be needed to also extract a version number through
> the CMAKE_DETERMINE_COMPILER_ID_VENDOR infrastructure.

I need more guidance here. I'm not connecting the dots.
My problem seems to be that the execute_process() in
CMakeDetermineCompilerId.cmake is trying to invoke the command:
'swift CompilerId/main.swift'

This will cause swift to run in REPL mode which won't return.
It is not passing any of the flags I taught CMake to use when trying
to compile a Swift program.

Looking at the execute_process() that gets invoked (final one in the
big if/elseif block of CMAKE_DETERMINE_COMPILER_ID_BUILD), the only
way to get the flags I need are via CMAKE_${lang}_COMPILER_ID_FLAGS.
But there is a block at the top of the file which overwrites the
variables. I was suggesting list(APPEND) instead of set() would fix
that problem, and in fact look suspicious to me since there is no way
to access those values passed to execute_process().

  if(CMAKE_${lang}_FLAGS)
#set(CMAKE_${lang}_COMPILER_ID_FLAGS ${CMAKE_${lang}_FLAGS})
list(APPEND CMAKE_${lang}_COMPILER_ID_FLAGS ${CMAKE_${lang}_FLAGS})
  else()
#set(CMAKE_${lang}_COMPILER_ID_FLAGS $ENV{${flagvar}})
list(APPEND CMAKE_${lang}_COMPILER_ID_FLAGS $ENV{${flagvar}})
  endif()



>
> Yes.  One remaining question is if there is an established convention
> already out there for the name of the SWIFTFLAGS environment variable.
>

I haven't spotted anything so far. Remember that Xcode and anything
GUI based on Mac doesn't use environmental variables. So this isn't a
feature that the existing Apple community would be using.


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] CMake alternative language

[Eric Wing]

Just to answer some of your questions on this...



>
> I think the first step is design brainstorming and discussion to see if
> we can find something acceptable.
>
> IIRC one problem with earlier attempts at introducing Lua was that CMake's
> dynamic scoping is difficult to reconcile with Lua's lexical scoping.  Lua
> cannot be given direct access to CMake variable scopes because Lua data
> structures may outlive the CMake dynamic scopes, leading to dangling
> references.

I don't have a good solution for this. I think the original CMake/Lua
bridge was basically a 1-to-1 API mapping with the CMake API. So the
idea was anything you do in native Lua lives in your Lua state
following the standard Lua lifecycles of things, but communicating
with CMake required going through the CMake public API (via
functions/macros via Lua bindings to the API). For global variables, I
think there was a special Lua table for CMake globals which had a
metamethod which did something similar to set the CMake values.

Thus, I can't remember if there were any dangling data structures. I
think about ADD_LIBRARY or ADD_EXECUTABLE which essentially returns a
TARGET object which has a lifecycle. When returned to Lua, we wrap it
in a userdata. The wrapper could lose its scope and the wrapper could
get garbage collected. But the backend doesn't need to actually
collect or destroy the object so CMake can still manage the resource
itself.

An aside though, I do find the scoping and lifetime rules of CMake
very difficult to work with. I feel like I still don't have a good
intuition or understanding of when many things happen in CMake. Since
we use CMake to compile C/C++/etc which are lexical scoping, I find
this to be challenging, especially since I don't really want to be
focusing on details like this when I'm just trying to get my program
compiled. So figuring out how to better embrace (Lua's) lexical
scoping moving forward might be a win.


> I'd also prefer an approach that allows us to offer newer versions of Lua
> as they come out while still processing old scripts unchanged.  This means
> that all Lua code must lie in a context where CMake knows the version of
> Lua for which it was written.  I'd like to retain the possibility of
> supporting multiple Lua versions to allow future such version transitions.
> (Implementation symbols can be mangled to support multiple versions linked
> in one program.)

This should be possible, though it's not a topic I've carefully
followed myself. I think simply mangling all the API functions
differently should prevent any conflicts. (I don't think Lua has any
global/static shared state internally which avoids those problems.)

I should also point out though that if you are going to support
multiple simultaneous versions of Lua, things could get messy if the
user needs Lua state preserved across multiple calls (i.e. not a
purely functional design). So what happens if the user starts in Lua
5.3 and creates some data, but then calls a script that only works in
Lua 5.1. The VMs can't be mixed.


>
>   cmake_lua( [LOCAL ...] CODE ...)
>
> The  must be "5.2", the Lua language version.

One thing to keep in mind is that for at least Lua 5, most of the
scripting side changes have been pretty minor. Most of the time,
script authors figure out how to write a script that runs across all
versions of Lua 5. So specifying a list of supported versions may be
desirable.




>   number: value is interpreted as a decimal representation of
>   a floating point value to be stored in a Lua number.

One interesting introduction to Lua 5.3 (already out) is integer
subtypes in Lua, so it now has separate float and integer types if
useful.


>
> set(deg 90)
> cmake_lua(5.2 LOCAL number{deg} CODE [[
>   return { sin = math.sin(deg*math.pi) }]])
> message("sin(${deg}') = ${sin}')
>

So I personally imagined writing much bigger chunks in Lua directly
and directly invoking CMake APIs (via bindings, sort of like the
prototype). Not that I disagree with anything here. But I think for my
use case, the time I need Lua the most is for complicated code that is
really unwieldily in the native CMake language, not for little things.

For example, one of the worst parts of CMake code I have right now in
my current project is I need to track all the resource files
(separated into types like images, scripts, dynamic libraries,
plugins) in my project and retain the relative directory hierarchy for
everything so I can reconstruct them in the application
packaging/bundling process (a custom step I have as part of the build)
preserving the layout (but with platform aware adjustments as needed).
Basically, I wanted multi-dimensioned tables, but I don't get those in
CMake, so I'm doing really painful things with global strings and
appending key names to strings to make new unique string lists. It is
a beast of a system right now because so many things have to use it
and the key names are often done with variables there are a lot of

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

On 1/19/16, Brad King <brad.k...@kitware.com> wrote:
> On 01/18/2016 01:51 PM, Eric Wing wrote:
>> So the good news is I have a basic add_executable working with Swift
>> on Linux via the Makefile generator.
>>
>> It works with all Swift files, or intermixed C+Swift files. Bridging
>> header is also supported.
>
> Great!
>
>> - I’m still copying over some CFLAGS to Swift_FLAGS. For example, I
>> couldn’t figure out what was providing the ‘-I’ flag for include
>> paths. Rules like this still need to be rewritten for Swift.
>
> Try adding to CMakeSwiftInformation:
>
>  set(CMAKE_INCLUDE_FLAG_Swift -I)
>
>> - TODO: I need to look at Swift's DEFINE system.
>
> Yes.  After we get things building correctly the first time then we'll
> also need to see about adding needed dependencies to the build system.
>
>> - Note: The new file is Linux-unknown-Swift.cmake. When I compile
>> Swift myself, there is no company or organization identifier (swift
>> --version) unlike the one Apple ships with Xcode, and CMake refers to
>> the identifier as ‘unknown’. I made the file reflect this, but maybe
>> we should rename this later (maybe Swift_org).
>
> In an earlier Swift thread there was discussion about the name of the
> compiler id and ``Apple`` was chosen because that is the vendor of
> their version.  We definitely need to choose an id besides "unknown"
> for this.  Perhaps ``SwiftOrg``?  Also, we need a good way to check
> the id.  We could use `--version` if necessary but do we know whether
> the language provides any kind of identifier for code to use for
> conditional compilation?
>
>> - To answer your question about whether ‘swift’ instead of ’swiftc’
>> can be used for linking, I think the answer is yes, but I have been
>> unable to figure out the correct incantation.
>
> Okay.  Let's go with the ``c`` hack until we
> know more.  I'd prefer not to have to expose a separate setting for
> the link driver only to remove it later.
>
>> - Swift Standard (or Core) Libraries: Swift comes with multiple
>> standard libraries.
> [snip]
>> I think CMake should provide some variables to the full paths to
>> these libraries since users like me will want to refer to them.
>
> Perhaps, but we currently don't do that for any other languages.
> We do provide CMAKE_{C,CXX,Fortran}_IMPLICIT_LINK_DIRECTORIES
> listing directories that may contain the standard libraries.
> This is the same as the information needed to use the C linker
> to mix languages that we previously discussed trying to extract
> for Swift.
>
> -Brad


Thanks for the response. I looking at version related stuff.
I've been trying to get things running on the Raspberry Pi (Raspbian).
I uncovered a few issues.

First, the CMake Swift compiler version check being run was actually
wrong all this time, but somehow got through on my desktop Linux. It
was calling swift without proper flags, so interactive (REPL) mode
should have run and blocked the process. Not sure how that got
through. But on the Pi, the REPL segfaults which made the problem
obvious.

To answer your other question about getting the version from within
Swift, I haven't figured out a way to do this yet. All the examples
are about getting the iOS version number or availability of APIs,
nothing about the language or compiler.

So via command line on Pi:
swift -version
Swift version 2.2-dev (LLVM cb23059150, Clang f66c5bb67b, Swift 7187741628)
Target: armv7-unknown-linux-gnueabihf


So to correct this crash (which is a blocking issue on Pi for CMake),
I want to pass the -version flag during that CMake check. But this
leads to another question.
I thought maybe setting the internal
CMAKE_${lang}_COMPILER_ID_FLAGS_LIST or
CMAKE_${lang}_COMPILER_ID_FLAGS
to "-version" would fix this.

But this did nothing. I tracked the code to the function definition of
CMAKE_DETERMINE_COMPILER_ID. I think there may be a bug:


function(CMAKE_DETERMINE_COMPILER_ID lang flagvar src)


  # Make sure user-specified compiler flags are used.
  if(CMAKE_${lang}_FLAGS)
set(CMAKE_${lang}_COMPILER_ID_FLAGS ${CMAKE_${lang}_FLAGS})
  else()
set(CMAKE_${lang}_COMPILER_ID_FLAGS $ENV{${flagvar}})
  endif()
  string(REPLACE " " ";" CMAKE_${lang}_COMPILER_ID_FLAGS_LIST
"${CMAKE_${lang}_COMPILER_ID_FLAGS}")


The CMAKE_${lang}_COMPILER_ID_FLAGS gets overwritten with generic
flags, not the compiler_id_flags and I don't think the
compiler_id_flags can ever be used.

I think set() in those cases should be list(APPEND ...)
Can you confirm?


Additionally, there seems to be another Swift/ARM bug where the
default target architecture name is slightly wrong. This causes the
compile object files phases to always fail. This isn't a CMake
problem, but to wor

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

On 1/15/16, Brad King <brad.k...@kitware.com> wrote:
> On 01/15/2016 09:47 AM, Eric Wing wrote:
>>> That is the same as for C++.  See CMAKE_PARSE_IMPLICIT_LINK_INFO and
>>
>> I looked at this file, but I still havne't groked what I need to do
>> with this yet.
>
> Somehow we need to get swift to print verbose output about the command
> line it uses to invoke the linker on the small test project CMake uses
> while enabling the language.  Then we need to parse that link line to
> get the list of libraries and link directories.  This can be a later
> step once most other things work though.
>
>> However, I'm heavily debating if 'cc' or 'clang' is the right thing to
>> do here.
>
> If the user sets LINKER_LANGUAGE to "C" and does not have main in Swift
> then CMake will want to link with the C compiler.  FYI, it is not actually
> 'cc' but the CMAKE_C_COMPILER selected, which happens to be 'cc' often.
> Anyway, we should go with CMAKE_Swift_COMPILER for now.
>
>> - First, CMake seems to be passing the flag -rdynamic to the link
>> instructions, and this is causing a "unknown argument" error. I think
>> this needs to be removed. I'm not sure where this flag is coming from.
>>
>> - Second, -Wl,-rpath,/foo/bar is also causing an "unknown argument"
>> error. As shown in the beginning of this thread, swiftc wants each
>> argument to lead with -Xlinker (and there is no -Wl,)
>> -Xlinker -rpath -Xlinker /foo/bar
>
> You'll need to add proper settings in files of the form
>
>  Modules/Platform/--.cmake
>  Modules/Compiler/-.cmake
>
> such as
>
>  Modules/Platform/Linux-Apple-Swift.cmake
>  Modules/Platform/Darwin-Apple-Swift.cmake
>  Modules/Compiler/Apple-Swift.cmake
>
> See Modules/Platform/Linux-NAG-Fortran.cmake for an example that
> changes from -Wl,-rpath to -Xlinker -rpath.  Similarly the
> CMAKE_SHARED_LIBRARY_LINK__FLAGS must not have -rdynamic
> in it.  You're getting the settings from C right now because
> your CMakeSwiftInformation.cmake file is copying them.  Instead
> leave all those out and add them as needed, preferably without
> copying from C.
>
>> Additionally, I realized I should have some other variable besides
>> 
>> Seems like I should have . I'm not sure what the
>> correct way to create this is.
>
> All the languages use CMAKE__COMPILER as the front-end to
> invoke for linking.  There should not need to be a separate linker
> value unless that is new to Swift semantics.
>
>> However, I currently employ a clever cheat. Since the compiler is
>> 'swift', and the linker is 'swiftc', I just do
>> 'c'
>
> So plain 'swift' cannot be used to drive the linker too?
>
>>> Note that for Ninja we actually convert our placeholders to Ninja
>>> rule placeholders and then provide the values on the actual build
>>> statement line.
>>
>> I actually don't' know anything about Ninja. I assume it is just a
>> string translation at this point since I did the other? Any guidance
>> on the mapping?
>
> Let's start with the Makefile generator.  Porting the results to
> the Ninja generator should not be too much work later.
>
>> So I need a new per-target variable in CMake for this and a way to
>> inject it into the compiler flags, maybe something like this:
>>
>>" -frontend -c   
>> -import-objc-header  -primary-file
>>   -emit-module -module-name  -o
>> ")
>>
>> With those two pieces, I think that actually makes add_executable()
>> usable in the Makefile generator.
>
> The values for the placeholders are always determined in the context
> of a specific target, so just "" should be
> fine.
>
> Thanks,
> -Brad
>
>


This email is intended to be positive news, though there will be a lot
of details about what still needs to be done or is not quite right
yet.

So the good news is I have a basic add_executable working with Swift
on Linux via the Makefile generator.

It works with all Swift files, or intermixed C+Swift files. Bridging
header is also supported.

I took one of my small, but non-trivial programs which does a lot with
CMake to package up resources (images, audio, etc) and set rpaths and
has lots of (C) dynamic libraries it links to which also get shipped
with the bundle to make a self-contained app (rpath), and ported the
core parts to Swift. CMake handled this pretty much transparently (had
to enable_language(Swift), set the bridging header, and there are
Swift Standard Library things to sort out later). So overall, I’m
really happy with this.



So now the details.

- I’m still copying over some CFLAGS to Swift_FLAGS. For example, I
couldn’

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

(Ignore the last post. The last message sent accidentally before I was
even close to done. Not sure why it sent. I must have accidentally
discovered a hot key in Gmail. Everything is rewritten here.)


Okay, I think I'm making some good progress. I got a trivial program
built on Mac. I've now switched to Linux. I'm mostly there, but there
are still some things that need to be done. More inline...


>> Anyway, I tried bumping up CMAKE_Swift_LINKER_PREFERENCE to 40. (Same
>> as Java). But it didn't seem to do anything for me.
>
> Where did you add the code to set it?

I got it working. I put it in.
CMakeSwiftCompiler.cmake.in
I figured out I also needed to add:
set(CMAKE_Swift_LINKER_PREFERENCE_PROPAGATES 1)



>> Under the hood, I think the LLVM linker can handle all of these
>> through ld. But I think the thing that is tripping me up is that Swift
>> seems to need to link against some additional libraries which are not
>> needed in the pure C case. The swiftc command seems to know how to
>> automatically link in those extra dependencies (and I don't need to
>> add all the search paths to where the Swift core libraries are
>> located).
>
> That is the same as for C++.  See CMAKE_PARSE_IMPLICIT_LINK_INFO and
> the call to it in "Modules/CMakeDetermineCompilerABI.cmake".  That is
> responsible for extracting the implicit link information passed by a
> given language compiler's front-end.  We'll need to extract that for
> Swift.

I looked at this file, but I still havne't groked what I need to do
with this yet.

However, I'm heavily debating if 'cc' or 'clang' is the right thing to
do here. I'm starting to think 'swiftc' might be the most robust and
correct thing for the linking command. There are several reasons for
this:

- swiftc seems to already do the right thing

- Not using swiftc requires me to set a lot of things, including the
Apple SDK when on Mac. This feels really messy.

- On Linux, I think there is a danger in calling 'cc' because it could
be gcc or it could be an older version of clang. (Officially, clang
3.5 is needed, but the default one on the particular Linux I'm using
is less than that.) Invoking swiftc theoretically side-steps this
problem.


But if I use swiftc, I create a few new complications:

- First, CMake seems to be passing the flag -rdynamic to the link
instructions, and this is causing a "unknown argument" error. I think
this needs to be removed. I'm not sure where this flag is coming from.

- Second, -Wl,-rpath,/foo/bar is also causing an "unknown argument"
error. As shown in the beginning of this thread, swiftc wants each
argument to lead with -Xlinker (and there is no -Wl,)
-Xlinker -rpath -Xlinker /foo/bar

Again, I'm not sure where the old stuff is, and what is involved to
inject the -Xlinker stuff.


Additionally, I realized I should have some other variable besides

Seems like I should have . I'm not sure what the
correct way to create this is.

However, I currently employ a clever cheat. Since the compiler is
'swift', and the linker is 'swiftc', I just do
'c'




>  cmMakefileTargetGenerator::WriteObjectBuildFile
> You should be able to call
>  this->GeneratorTarget->GetObjectSources(objectSources, config);

Okay, I added this code. It seems to be working. Though I'm not
completely sure I fetched config correctly.

My current changes can be found here in the SwiftMakefile branch
https://github.com/ewmailing/CMake/tree/SwiftMakefile


> and the Ninja generator here:
>
>  cmNinjaTargetGenerator::WriteCompileRule
>  cmNinjaTargetGenerator::WriteObjectBuildStatement
>
> Note that for Ninja we actually convert our placeholders to Ninja
> rule placeholders and then provide the values on the actual build
> statement line.
>

I actually don't' know anything about Ninja. I assume it is just a
string translation at this point since I did the other? Any guidance
on the mapping?


> Do we know that there is a one-to-one mapping between libraries
> and Swift modules?

Sorry, I'm still not completely up to speed on Swift modules. My
impression is there are 3 parts: .swiftmodule (which contains the
public interface/definitions), .swiftdoc (for documentation), and a
library (.a, .so). I suspect the .swiftmodule will need to be part of
the compile parameters and the library will be part of the link, but
I'm not sure if there will be additional requirements.


But anyway, I would like to get something building on Linux first, so
I need to fix the swiftc/linker stuff first. Any suggestions?

Then, I would like to enhance the trivial test to support actually
using something from the intermixed C files. This means I need to add
the bridging header parameter.
So I need a new per-target variable in CMake for this and a way to
inject it into the compiler flags, maybe something like this:

  " -frontend -c   
-import-objc-header  -primary-file
  -emit-module -module-name  -o
")


With those two pieces, I think that actually makes add_executable()
usable in the Makefile generator.

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

Okay, I think I'm making some good progress. I got a trivial program
built on Mac. I've now switched to Linux. I'm mostly there, but there
are still some things that need to be done. More inline...


https://github.com/ewmailing/CMake/tree/SwiftMakefile


>> Anyway, I tried bumping up CMAKE_Swift_LINKER_PREFERENCE to 40. (Same
>> as Java). But it didn't seem to do anything for me.
>
> Where did you add the code to set it?

I got it working. I put it in.
CMakeSwiftCompiler.cmake.in
I figured out I also needed to add:
set(CMAKE_Swift_LINKER_PREFERENCE_PROPAGATES 1)



>> Under the hood, I think the LLVM linker can handle all of these
>> through ld. But I think the thing that is tripping me up is that Swift
>> seems to need to link against some additional libraries which are not
>> needed in the pure C case. The swiftc command seems to know how to
>> automatically link in those extra dependencies (and I don't need to
>> add all the search paths to where the Swift core libraries are
>> located).
>
> That is the same as for C++.  See CMAKE_PARSE_IMPLICIT_LINK_INFO and
> the call to it in "Modules/CMakeDetermineCompilerABI.cmake".  That is
> responsible for extracting the implicit link information passed by a
> given language compiler's front-end.  We'll need to extract that for
> Swift.

I looked at this file, but I still havne't groked what I need to do
with this yet.

However, I'm heavily debating if 'cc' or 'clang' is the right thing to
do here. I'm starting to think 'swiftc' might be the most robust and
correct thing for the linking command. There are several reasons for
this:

- swiftc seems to already do the right thing
- Not using swiftc requires me to set a lot of things, including the
Apple SDK when on Mac. This feels really messy.
- On Linux, I think there is a danger in calling 'cc'.




realized I may need to take a step back.


>

>
>> I just tried not filtering the current primary file from the list. It
>> still worked. So maybe we can get away with not filtering that.
>
> Great.  It will be simplest to list all the sources in every call and then
> repeat the one that is current.
>
>> Anyway, it seems like adding SOURCES is the next step. Any hints on
>> how to do that?
>
> The cmLocalGenerator::ExpandRuleVariable method does the placeholder
> substitution.  It relies on values in the RuleVariables structure
> to be populated by the calling generator.  The Makefile generator
> populates that for the compile line here:
>
>  cmMakefileTargetGenerator::WriteObjectBuildFile
>
> and the Ninja generator here:
>
>  cmNinjaTargetGenerator::WriteCompileRule
>  cmNinjaTargetGenerator::WriteObjectBuildStatement
>
> Note that for Ninja we actually convert our placeholders to Ninja
> rule placeholders and then provide the values on the actual build
> statement line.
>
> You should be able to call
>
>  this->GeneratorTarget->GetObjectSources(objectSources, config);
>
> to get the list of source files and then filter it based on
> sf->GetLanguage().
>
> The name "" is not very good because it does not specify
> how any filtering is done.  Perhaps a special case name such as
> "" would be better.
>
> Do we know that there is a one-to-one mapping between libraries
> and Swift modules?
>
> -Brad
>
>


-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
-- 

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

[Eric Wing]

I am hesitant to add more fuel to the fire for this discussion because
it has been discussed many times before through the years and my sense
is that this isn’t what Brad is really interested in pursuing. I
encourage you search the mailing list history.

I’ll try to summarize (off the top of my head) about why Lua (as
opposed to other languages).

- Lua above all other languages was recommended by me and others
because it satisfied all the constraints:
- It is tiny and can be included with the CMake source and doesn’t
impact the size of CMake in any significant way
- Being 100% ANSI C allows it to go everywhere CMake already goes and
satisfies the requirement that only a C++ compiler is needed to
bootstrap it.
- Lua is a language designed to be embedded, for this very kind of 
purpose.
- Lua is sandboxed by default and has a minimal (and optional)
standard library.
- This means users won’t be encouraged to call all sorts of
non-portable library calls like with some other languages. CMake can
control what APIs are exposed addressing those concerns that a full
programming language may allow too much variance and craziness in the
community.
- Lua’s liberal license is compatible with CMake’s liberal license.

- Lua is one of the cleanest, simplest mainstream languages out there
and is incredibly easy to learn, yet still supporting a wide range of
higher-level constructs (functions as first class values, closures,
proper tail recursion). Documentation and tutorials are readily
available.
- Lua’s core data structure is the table, which is a extremely similar
to JSON (which it happens to also predate), which makes lists and
declarative data style very easy and natural to do.
- Lua has proven itself in the video game industry in that C/C++
developers are comfortable dealing with it (not a syntax shell shock
to them, say like LISP, or quite frankly CMake)
- Lua being a full, well designed programming language allows for ways
to write things which is currently really hard in CMake’s language.
Additionally, adding features to CMake’s language is hard in that you
have to think about all the potential side-effects, edge cases, and
inconsistencies. Lua takes this burden away and how to use everything
is well known/documented.

- To prove to us that CMake was already too far down the road and
retrofitting Lua into CMake was not practical, Dr. Ken Martin had a
CMake/Lua proof of concept working in like 13 hours. (Oops.)
- But it was decided that Kitware didn’t want to go down this road.

- We attempted to build off Ken Martin’s experiment to keep it alive,
but that project essentially failed.
- Lack of time, resources, expertise, etc, and this was back in the
CVS days so keeping up with the mainline was hell since merge tracking
is pretty much non-existent.
- There was one interesting thing implemented showing that both
existing CMake script and Lua script could co-exist. And I think there
was even a proof a concept that different language scripts could call
one another.



So just on the constraints/requirements issue, I think we convinced
Brad, that *if* anything should be chosen, it should be Lua, which is
why Lua is still in his head. And these constraints are still in play.
I am constantly fighting dependency hell on platforms. It is nice that
CMake has no external dependencies except a C++ compiler and can
bootstrap itself. I recently did a bunch of work on a Raspberry Pi and
I needed to build CMake; no problem. I just tried to build Swift on
the Pi. I got hit by a bug where the build process pulls in the wrong
version of Python (2 vs 3) if both exist on the system. What a mess.
(And a 9+ hour build cycle to retry.) Not to mention the disk space
problem of needing all these dependencies.

But it sounds like Brad is more interesting in a purely declarative
replacement for CMake.
That would be nice for all the editor-assist reasons. Though I’m also
skeptical of pulling that off (though I hope it can be done in a
useful way). There are other systems like that, yet, I’m using CMake
for a reason. I don’t have any real insight on the problem, but I
recall hacking Ant XML files and just to have a simple conditional
(if/else) was a huge PITA. And as these things cascade with more
conditionals, it becomes a major effort. Antidotally, I watched
several projects try to use Gyp even though there was a CMake
description already written (albeit, not working for the platforms we
needed). I watched from the sidelines as those projects failed to get
Gyp working. I don’t have any insight in why unfortunately. For one
project though, I did later come in and did get the CMake description
working.

I try really hard to keep my CMake really simple. But unfortunately,
it always gets complicated. Just the fact that platforms and
environments are so different always impacts my CMake scripts. But I’m
very glad that CMake seems to get the job done. Lua would help 

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

On 1/12/16, Brad King <brad.k...@kitware.com> wrote:
> On 01/08/2016 06:15 PM, Eric Wing wrote:
>> simple 'swiftc' integration going for ADD_EXECUTABLE, as described in
>> the original post.
>
> Take the generator check out of Modules/CMakeDetermineSwiftCompiler.cmake
> to get rid of the up-front error.  See "Modules/CMakeAddNewLanguage.txt"
> (many of the steps are already done).
>
> Edit Modules/CMakeSwiftInformation.cmake and add settings for variables
> like CMAKE_Swift_COMPILE_OBJECT and CMAKE_Swift_LINK_EXECUTABLE.  See
> the CMake{C,CXX,Fortran}Information.cmake modules for examples.  The
> available placeholders are in cmLocalGenerator::ExpandRuleVariable.
>
> If all the compile/link steps used for C and C++ map well to switfc
> then it should be fairly straightforward.  If other steps are needed
> or the steps have wildly different semantics then more in-depth changes
> to the actual generators may be needed.
>
> -Brad
>


So I got the trivial base case working with swiftc (no library
dependencies, Mac for now but will shift to Linux eventually):
add_exectuable(MyTarget main.swift)

Yay.

So next I wanted to add more files to the mix. And now I have some problems.


Problem 1: Intermixing C and Swift
add_exectuable(MyTarget main.swift some_c.c)
Note: I presume C++ (and Obj-C) could also be in the mix:
add_exectuable(MyTarget main.swift some_c.c some_cpp.cpp some_objc.m)

It looks like the link phase is invoking cc on my system (the C linker
rules?) instead of the Swift linker commands.

If my hunch is correct, how do I tell CMake to ‘promote’ Swift as the
correct tool?
(Perhaps there is a similar existing mechanism already is handling
intermixing C/C++ or C/Obj-C?)

Additional note: I am a little surprised to see cc instead of ld (or
swiftc). Now I may be able to use cc or ld, but I need to figure out
how to adapt and add some additional flags. So it could be that I
could work around this problem. (Kind of working solution at the
bottom.)



Problem 2: Multiple Swift files in the target
add_exectuable(MyTarget main.swift OtherSwift.swift)

With two or more files, I was hoping to do a single one-shot call:
swiftc -c OtherSwift.swift main.swift -module-name MyTarget

But it looks like CMake invokes each file separately. The problem that
creates in the above case is that if main.swift uses stuff from the
other file, it can no longer compile because it is unable to find the
code in OtherSwift because they are treated as separate unconnected
modules. I haven’t figured a way yet around this using swiftc.

However, I can switch to the tool ‘swift’, but it looks like Swift has
a similar constraint which I will discuss shortly.

But before I move on to that, is there a way to get CMake to invoke
all the Swift files in the target together? (It would need to exclude
any non-Swift files in the list.)

I think there may be trade-offs here. On one hand, file-by-file might
get us incremental compilation. But there is a flag called
-whole-module-optimization which suggests treating them as a batch
could allow better code generation.


Now for the 'swift' tool:

So the swift tool can go file-by-file, but the additional constraint
is that all the other Swift files in the target must be listed too. To
distinguish which file is actually being processed, you must use the
-primary-file  . I think this is so
Swift can figure out all the cross-file dependencies since there are
no header files in Swift.

Here is an example of compiling my two files:

# Compile main.swift to main.o
swift -frontend -c -primary-file
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/main.swift
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/OtherSwift.swift
-emit-module -module-name MyTarget  -o CMakeFiles/MyApp.dir/main.o
-emit-module-path CMakeFiles/MyApp.dir/main~partial.swiftmodule

# Compile OtherSwift.swift to OtherSwift.o
swift -frontend -c -primary-file
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/OtherSwift.swift
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/main.swift
-emit-module -module-name MyTarget  -o
CMakeFiles/MyApp.dir/OtherSwift.o -emit-module-path
CMakeFiles/MyApp.dir/OtherSwift~partial.swiftmodule

Other things to notice:
- I am using the CMake Target Name for the -module-name
- There is a basename~partial.swiftmodule being generated. I'm not
completely sure why this is needed, but I see it in the Xcode build
lines and other examples on the web.


Finally, the link line can look like this: (Xcode invokes clang
instead of cc, but they map to the same thing on Mac)

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
 -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/s

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

> For the moment, I like swiftc over swift because it seems a lot
> simpler. I hope this means the least changes for CMake right now.

I need to correct myself on this. While I like swiftc for looking
simpler, I'm actually thinking swift might be fewer changes since the
file-by-file thing is what CMake does today.
It may turn out swift is easier to figure out in the end too when we
eventually look at add_library and linking them (since we can reverse
engineer from the Xcode logs).

But either way, both of them seem to need SOURCES.

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] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

>> If my hunch is correct, how do I tell CMake to ‘promote’ Swift as the
>> correct tool?
>
> See the CMAKE__LINKER_PREFERENCE platform information variable.
> There is also the LINKER_LANGUAGE target property.  For C, C++, and
> Fortran one generally chooses between C++ and Fortran to drive the
> linker based on which language has the entry point (main) in its
> sources.  If we see a "main.swift" then we know Swift should be used.
> If not then I don't know enough about Swift linking requirements to say.

I suspect it is like C++ and C. If there is both, you promote up to C++ linking.
So if there is any .swift file or library in the mix, you need to
promote up to use Swift.

Under the hood, I think the LLVM linker can handle all of these
through ld. But I think the thing that is tripping me up is that Swift
seems to need to link against some additional libraries which are not
needed in the pure C case. The swiftc command seems to know how to
automatically link in those extra dependencies (and I don't need to
add all the search paths to where the Swift core libraries are
located).

Anyway, I tried bumping up CMAKE_Swift_LINKER_PREFERENCE to 40. (Same
as Java). But it didn't seem to do anything for me.

I then added to my test CMakeLists.txt:
set_property(TARGET MyApp PROPERTY LINKER_LANGUAGE Swift)

That then worked, but I'm confused how to get CMake to automatically
do this for me because I expected CMAKE_Swift_LINKER_PREFERENCE to do
this.


>
> This looks like a semantic difference between how the switfc and cc
> compilers work that as I feared in my previous response may require
> C++ changes to CMake to make work.  Before diving into that we need
> to understand the preferred way to compile multiple Swift sources.
> Last time I looked at this the only reference was "what Xcode does".
> Hopefully there is more information out there now.

Unfortunately, there isn't a whole lot more information. The majority
of the examples are hello world programs with one file.

The best write up I've seen is this series:
http://owensd.io/blog/compiling-swift-without-xcode/
http://owensd.io/blog/compiling-individual-files/
http://owensd.io/blog/swift-vs-swiftc/
http://owensd.io/blog/swift-makefiles---take-2/

One interesting note, swiftc is just an alias for swift.


The exception is the Swift Package manager. But this is a convention
based system. Right now it is far from finished and its conventions
are actually incompatible with Xcode. It has its own file format and
also requires all dependency packages be in a Git repo and follow a
certain tagging convention. I also haven't seen any way to directly
mix C+Swift code in a module and they expect you to create a separate
module for C stuff which you then import in. I'm under the impression
they plan to relax a lot of these things, but I find it currently too
incomplete and with too much impedance to be useful right now.

(By the way, I think I'm a little incorrect about main.swift being
special. I'm seeing examples where they name the file anything.swift.
It looks like Swift will automatically create a main entry point for
you when building an executable, especially in the one-shot case. With
swiftc it must be a one-shot otherwise you get duplicate symbols. With
swift -frontend, it some how manages to create one. But with the Swift
Package system, I think main.swift is a convention-requirement.)



> It may be that we're supposed to invoke Swift with all sources at once
> and let it take responsibility for generating the results and doing any
> kind of incremental stuff internally.

So Xcode is using the swift -frontend technique and it looks like it
doing it incrementally. I think the requirement for the list of other
files is so it can resolve the dependencies.


> It shouldn't be too hard to add a  placeholder if needed.  We
> may need it either way because we either list all the sources on one
> call to swift or on every call to swift.

Right.

>> - Also, for the second , I need to remove the one I'm using
>> from my -primary-file. And there shouldn't be any non-Swift files in
>> the list (no C/C++/Obj-C).
>
> That kind of filtering may be harder to define and require custom logic
> in CMake's generators for Swift instead of trying to do it with generic
> placeholders.

I just tried not filtering the current primary file from the list. It
still worked. So maybe we can get away with not filtering that.
However, we do need to filter any C files. That didn't work. (It tried
to compile those .c files as Swift which obviously won't work.)



>> Can you give me some suggestions on what to look at next?
>
> Before proceeding with CMake changes I think we need a better
> understanding of the tools involved in Swift development.  What
> does individual compilation achieve over monolithic compilation?

I'm actually not sure. The monolithic one-shot should avoid any
potential incorrectness problems if a dependent file was changed but a
calling file wasn't recompiled. I don't 

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

> Yes.  A few months ago I spent a few hours looking at the commands Xcode
> uses to build Swift code.  For reference, here are some notes I took
> (not well organized):
>
> 
> MergeSwiftModule produces .swiftmodule files, which seem to be serialized
> copies of swift modules, like binary headers, each covering an entire module
> over multiple source files.  MergeSwiftModule merges partial modules from
> individual sources into one for the whole module.
>
> The .swiftmodule for a shared library can be consumed while compiling
> other projects whose "import" statements search the -I path for the
> .swiftmodule files.  The .swiftmodule file is a binary header for the
> whole shared library.
>
> The compiler leaves in .o files a decl that tells the linker what libraries
> to link.  The linker hopefully tolerates seeing those libraries explicitly
> on the command line too, since CMake will generate those.
>

That article I linked to also mentions the .swiftmodule system via swiftc.

=
swiftc -emit-library translator.swift -module-name translator
-import-objc-header bridgingHeader.h
clang -shared -o libtranslator.so translator.o

# Now, create the module:
swiftc -emit-module -module-name translator translator.swift
-import-objc-header bridgingHeader.h

# This leaves us with three files: libtranslator.so,
translator.swiftmodule, and translator.swiftdoc.


# You must have a translator.swiftmodule in your module search path,
which we add with -I.:
swiftc -I. -c main.swift -import-objc-header bridgingHeader.h

# Let’s link everything together:
swiftc -o translate.exe jsonparse.o main.o -L. -ltranslator -lcurl
-ljson-c -lswiftGlibc -lFoundation
=

I haven't given deep thought to libraries yet (still just trying to
get applications going), I'm thinking ADD_LIBRARY most needs to just
invoke the -emit-library flag on swiftc, and automatically add the -I
(include path) to the output directory for the linking. Maybe
-module-name can be inferred from the TARGET name?




> See the -emit-dependencies and output file map options to control where .d
> files are generated.
>
> swift -help
> swift -help-hidden
> swift -frontend -help
> swift -frontend -help-hidden
>
> If one imports a library written in C/objc then something generates a
> module map pointing to the headers.  It seems to lazily generate from
> the headers a module that can be loaded.  To use a C library from Swift
> one must write a module map explicitly.  Some lib providers may support
> modules directly and provide the module map next to the library file.

It looks like the 'swift' front-end build and packaging system is
still a work in progress and doesn't seem to fully work on Linux yet.


> Swift does have conditional compilation that affects imports.

Yes. I'm wondering at least with a swiftc backend, this is up to the
user to manually specify (mirror) in the CMake description to say what
files are compiled/linked, like they do now with C/C++/Obj-C.

Maybe when the 'swift' front-end gets farther, we can try to make this
more automatic. But since the 'swift' front-end is entangled with git,
and introduces its own package file conventions, it's not something
I've given much thought to.



Anyway, I have a couple of hours on a train this weekend. I was
wondering if you could give me guidance on what I need to do to get a
simple 'swiftc' integration going for ADD_EXECUTABLE, as described in
the original post.

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] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

On 12/24/15, Eric Wing <ewmail...@gmail.com> wrote:
>> set(SWIFT_BRIDGING_HEADER SwiftSDL-Bridging-Header.h)
>
> Quick addendum: Just realized the bridging header should probably be
> per-target.
>

For reference, we have an Xcode specific, per-target variable for the
bridging header: XCODE_ATTRIBUTE_SWIFT_OBJC_BRIDGING_HEADER.

set_property(TARGET ${BLURRR_USER_EXECUTABLE_NAME} PROPERTY
XCODE_ATTRIBUTE_SWIFT_OBJC_BRIDGING_HEADER
"${PROJECT_SOURCE_DIR}/source/MySwiftBridgingHeader.h")
-- 

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] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

> set(SWIFT_BRIDGING_HEADER SwiftSDL-Bridging-Header.h)

Quick addendum: Just realized the bridging header should probably be per-target.
-- 

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] Adding Swift support to CMake

[Eric Wing]

On 7/7/15, Brad King brad.k...@kitware.com wrote:
 On 07/02/2015 07:54 PM, Eric Wing wrote:
 Thank you Brad. When you are ready, let me know how I can help next.

 I have basic support with the Xcode generator done.

 Please try out this commit:

  Add rudimentary support for the Apple Swift language with Xcode
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf112531

 Thanks,
 -Brad



Hi Brad,
I just tried out the July 15th nightly build and it looks like it is
working (Xcode generator). I got a little fancy and did an intermixed
C/Swift test. I have a simple SDL (C) based program with Swift
bindings and I'm able to build/run it and step the Xcode debugger
through the Swift parts.

Cosmetically, the Swift files are not being grouped with the other
C/Obj-C files in the Source Files group. But that is a pretty minor
thing. (There are other things more important to me I would like to
see fixed in the Xcode generator first :))

So is the next step the Makefile generator?

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] Adding Swift support to CMake

[Eric Wing]

On 6/29/15, Brad King brad.k...@kitware.com wrote:
 On 06/25/2015 09:24 AM, Eric Wing wrote:
 I pushed up a couple of repos for everybody to try.

 Thanks.  From that I was able to make some progress with getting
 CMakeDetermineSwiftCompiler to work.

 I've made two tweaks to CMakeDetermineCompilerId to make it easier to
 use from a new CMakeDetermineSwiftCompiler module:

  CMakeDetermineCompilerId: Simplify src reference in IDE projects
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8306108f

  CMakeDetermineCompilerId: Use per-language regex to match Xcode compiler
 tool
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6452291c

 Once these changes test cleanly on nightly builds I will look at
 the rest of the changes for basic Swift + Xcode.

 -Brad


Thank you Brad. When you are ready, let me know how I can help next.

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] Adding Swift support to CMake

[Eric Wing]

Hi Brad,
I pushed up a couple of repos for everybody to try.

First, I have my CMake changes I mentioned before. There are 2
commits. The first commit is the original simple hack. The second
commit removes the hack part and tries to add a new language generator
for Swift, using Java as a starting point. I think both of these work
for the simple case right below.
The branch is called Swift
https://github.com/ewmailing/CMake/tree/Swift

Second, I have a simple, but comprehensive test/example based project
for C calling Swift (which must go through Objective-C), and then once
in Swift, calling C. I refer to this as the full round trip example.
I have two projects, one from a native Xcode project, and another in
CMake with my above CMake patches.

https://github.com/ewmailing/CSwiftRoundTripNativeXcode
https://github.com/ewmailing/SwiftXcodeCMake



 Let's start by getting that to work for the Xcode generator.  Currently
 Modules/CompilerId/Xcode-3.pbxproj.in gets configured by the
 CMAKE_DETERMINE_COMPILER_ID_BUILD function as a small test project
 to compile the C or C++ source for compiler identification.  From
 the output of that build we are able to extract the path to the
 compiler tool.  One would have to do something similar here.  Can
 you provide a minimal pbxproj file and swift source file that
 work together to build an executable?

Okay, I just went through the Xcode New Project wizard and created a
new default Swift project for Cocoa and command line tool (both OS X).
https://github.com/ewmailing/SwiftMinimal
https://github.com/ewmailing/SwiftMinimalCL




 What is the proper sequence of commands to build some C and Swift
 sources and link a single executable?  library?


Here is a minimal Swift executable project created in Xcode that calls
a C function. (One way bridge.)
https://github.com/ewmailing/SwiftAndC

Build target SwiftAndC

CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler
cd /Volumes/DataPartition/Users/ewing/Source/GIT/SwiftAndC

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc
-target x86_64-apple-macosx10.10 -incremental -module-name SwiftAndC
-Onone -sdk 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk
-g -module-cache-path
/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/ModuleCache
-Xfrontend -serialize-debugging-options -I
/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Products/Debug
-F 
/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Products/Debug
-c -j4 
/Volumes/DataPartition/Users/ewing/Source/GIT/SwiftAndC/SwiftAndC/main.swift
-output-file-map
/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/Objects-normal/x86_64/SwiftAndC-OutputFileMap.json
-parseable-output -serialize-diagnostics -emit-dependencies
-emit-module -emit-module-path
/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/Objects-normal/x86_64/SwiftAndC.swiftmodule
-Xcc 
-I/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/swift-overrides.hmap
-Xcc -iquote -Xcc
/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/SwiftAndC-generated-files.hmap
-Xcc 
-I/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/SwiftAndC-own-target-headers.hmap
-Xcc 
-I/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/SwiftAndC-all-target-headers.hmap
-Xcc -iquote -Xcc
/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/SwiftAndC-project-headers.hmap
-Xcc 
-I/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Products/Debug/include
-Xcc 
-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
-Xcc 
-I/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/DerivedSources/x86_64
-Xcc 

[cmake-developers] Adding Swift support to CMake

[Eric Wing]

Hello all,
I wanted to see if I could get the ball rolling on (Apple) Swift
support for CMake.

For more detail, here is the bug I’ve been chatting in:
http://public.kitware.com/Bug/view.php?id=15401

Here is the summary:
- For Apple developers, we need Swift support because it is going to
be increasingly common to have Swift files in the project, often as
backends for the Apple platform specific stuff in cross-platform
projects, just as Objective-C is today.

- Coming this fall, Swift is going to be open sourced, starting with a
Linux port. So we may start seeing more use cases on non-Apple
platforms as well.


To meet these objectives, I see two things we need to do:
- For the first and simplest case, we need to enhance the CMake Xcode
generator so it can handle Swift. Xcode already knows how to handle
Swift files automatically, so we should leverage it by making CMake
generate a correct project for it.

- The next step is to look at the Makefile generator and command line
invocation. With luck, this will work for Mac, Linux, and probably any
other Unix-like platform that gets Swift/LLVM running.


As a first stab to get Xcode support working,
in cmGlobalXCodeGenerator.cxx in the function
GetSourcecodeValueFromFileExtension(), I added swift right after the
Obj-C entries.

  else if (ext == swift)
{
sourcecode += .swift;
}

This correctly set the source code type in Xcode for Swift files.
However, every Swift file was lacking any target association (blank
checkboxes for all targets). This means no Swift files were getting
compiled.

After some random guessing, I found in CMakeCCompiler.cmake.in, adding
swift to the CMAKE_C_SOURCE_FILE_EXTENSIONS, would cause the Swift
files to be correctly associated with a target.
set(CMAKE_C_SOURCE_FILE_EXTENSIONS c;m;swift)


This works pretty well for my initial test case which is a mixture of
C/Obj-C/Swift. But I was told we should be looking at building a
separate language generator instead of this latter hack.



So this is where I’m starting to get lost/overwhelmed, and am hoping
to find other people that might be able to help make this happen.

At the moment, I created 4 new files:
CMakeDetermineSwiftCompiler.cmake
CMakeSwiftCompiler.cmake.in
CMakeSwiftInformation.cmake
CMakeTestSwiftCompiler.cmake

I originally started with C as the template and got lost quickly. I
have since started using Java as the template and have muddled through
a little bit more. In my current Xcode prototype, I’ve been fighting
various flags, e.g. my C flags getting clobbered by Swift, when in
fact I need both. (e.g. lost my @rpath/@loader_path stuff.)

So, I’m still lacking a lot of knowledge on both the CMake side (how
to implement a new language), and also a lot of the reverse
engineering details of how Swift works. Maybe we can layout the
details in this thread.

These are the various details that I’m aware of at the moment:

- The swift compiler is called swiftc

- Swift doesn’t really have a preprocessor or linker in the traditional C sense.

- However, since Swift is designed to operate with C and Obj-C, there
does seem to be a mechanism to create files that can be linked with
C/Obj-C (needed by the Makefile generator; should be automatic by
Xcode)

- I don’t think Swift needs dependency management like in Makefiles
and swift handles everything for you transparently (ignoring
intermixing with C/Obj-C). However, you still need a build system to
handle other things like asset files (images, icons, etc.)

- Swift projects generally need to provide a “bridging header” to be
able to call C/Obj-C code

- Swift projects need a generated Interface Header so C/Obj-C can call
Swift code

- Swift has its own optimization flag settings separate from C/Obj-C

- Swift seems to have its own ‘other flags’

- I think there is a way to build Swift-only modules, but I have not
looked into this. Intermixing C/Obj-C probably means you can fall back
to the clang mechanisms.

- On OSX/iOS, it would be nice to make Swift automatically enabled
since it is kind of a required language now. (Requiring
ENABLE_LANGAUGE(Swift) seems annoying.)

- I’m kind of assuming, but don’t really know, that Obj-C and the
Obj-C runtime will be available with the Linux port of Swift, and that
you will generally want it and might even be required. (Note: I am
being careful to distinguish between Obj-C and libraries like
Foundation.) Being able to call Swift from C requires Obj-C (in my
limited experience). Swift’s easy interoperability with C (in both
directions) I think is a selling point for Swift and expect it to be
used, particularly on Linux where C is prevalent. So I think we need
to make sure this intermixing can be handled by the Makefile
generator.

- Here is the best resource I've found so far on building a Makefile for Swift:
http://owensd.io/2015/01/15/swift-makefiles-take-2.html


So anybody who wants to chime in, please do so!
Let's see if we can make this happen.

Re: [cmake-developers] Support of codesign

[Eric Wing]

Sorry, I'm also very late on this thread, but there was a suggestion
that codesigning should be in CMake instead of CPack. I agree and also
say it needs to be integrated as part of the build process when
specified.

Here's a real world workflow. I use JavaScriptCore in my Mac
application which allows me to run various bits of JavaScript inside
my main application, as you would with other embedded scripting
languages like Lua. Safari has a feature that lets you attach the
Safari built-in debugger to other applications JavaScriptCore contexts
if you set the entitlement com.apple.security.get-task-allow. In order
to set the entitlement, you must codesign. And I want to emphasize,
this is a standard development workflow, not a release workflow which
means this is the common case.

The workflow should be:
- Edit code in your app
- Hit the Xcode run button to recompile and run/test.

CMake's current workflow doesn't work this way and it is annoying.
There are other things on Mac that require codesigning, such as if you
use sandboxing (some APIs behave differently under sandboxing so
testing under non-sandboxing has risks), or if you use certain Apple
services like iCloud, In-App-Purchases, and Game Center.


An additional note, any 3rd party libraries/frameworks embedded in the
app also must be codesigned.

I currently employed my own workarounds for both using a lot of
post_build/custom_command instructions. However my solution is still a
little clumsy with switching between different codesign keys
(Developer ID vs Mac App Store vs none). It would be nicer if you
could pick it in Xcode directly instead of having to regenerate CMake
everytime. Additionally, resigning all the 3rd party frameworks every
single time is kind of slow (my algorithm is kind of stupid), but
there are additional complications when you change the key to sign
with which is partly why my algorithm ended up playing stupid.

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] [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

[Eric Wing]

On 10/31/14, Gilles Khouzam gilles.khou...@microsoft.com wrote:
 We actually have a couple if extra changes that are not fully ready to be
 pushed upstream yet.

 ~Gilles
 Sent from my Windows Phone


Since I have your attention, using CMakeMS, I hit what looks like a
bug in the generation for the Windows Phone simulator. I have not
tested 3.1.0-rc1, but since it is the from the same code base, I'm
assuming it is affected too.

I get a linking failure for only the WinPhone simulator (Win32)
binary. This is the error the linker is spitting out:

vccorlib.lib(compiler.obj) : error LNK2038: mismatch detected for
'vccorlib_lib_should_be_specified_before_msvcrt_lib_to_linker': value
'1' doesn't match '0' in MSVCRT.lib(appinit.obj)
vccorlib.lib(compiler.obj) : error LNK2005: ___crtWinrtInitType
already defined in MSVCRT.lib(appinit.obj)
D:\snip\Release\FlappyBlurrr.exe : fatal error LNK1169: one or more
multiply defined symbols found

This only happens for me with the Win32 simulator binary. I do not
have this problem with the ARM device binary, nor do I have this
problem with the Windows Store x64 binary. (I do not bother with Win32
Windows Store.)


Somebody helped me and told me to add these switches directly to my
Visual Studio project:

- for Debug builds, add: /nodefaultlib:vccorlibd /nodefaultlib:msvcrtd
vccorlibd.lib msvcrtd.lib

- for Release builds, add: /nodefaultlib:vccorlib /nodefaultlib:msvcrt
vccorlib.lib msvcrt.lib

This seemed to make my linking problems go away.

I'm thinking that CMake should automatically be setting these for me
for the Windows Phone simulator.

Thanks,
Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
-- 

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] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

[Eric Wing]

On 11/4/14, Gilles Khouzam gilles.khou...@microsoft.com wrote:
 Hi Eric,

 Can you send me a little more details or an example that exhibits the
 problem? I'd be happy to take a look.


Sure. I'll respond offlist for this.

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] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

[Eric Wing]

Just curious, are the new WinRT changes the same exact changes from CMakeMS?

And if the CMakeMS people are listening, I just want to say you guys
did a terrific job!

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] iOS support

[Eric Wing]

On 9/23/14, Florent Castelli florent.caste...@gmail.com wrote:
 Hi!

 My company is organizing soon a hack week where each employee is able to
 work on any project he wants. So, I've decided to work with Cmake and
 improve support for iOS to help the product team getting rid of manual
 project files, constant merge conflicts and bad project file documentation,
 while improving our tooling possibilities (all that with Cmake!).

 I've had a quick look at the first issue that popped into my mind the other
 day and fixed try_compile by adding another variable to set the executable
 type in the generated project (it has to be MACOSX_BUNDLE) and fixing the
 search path for the resulting binary.
 So this is now working... Providing we are targeting the simulator.
 Due to the nature of Xcode projects that can easily target either the
 simulator or devices, thus using different compilation flags, the resulting
 projects aren't working in both case. There are conflicts between some
 options like the minimum iOS version target and the minimum iOS simulator
 target for example (which you need to build the try_compile binaries
 without signing them).
 Also, the Xcode support is very OSX focused and all variables have MACOSX
 in their name, which is confusing.

 So, has anyone worked on similar issues and can suggest a way to progress
 and improve support for iOS?
 In the end, I'd like to have a working Xcode project with separate settings
 for both simulator and device, Cmake compiler flag detection working, and
 possibly later Make/Ninja projects working too.

 Regards,
 /Orphis


This is off the top of my head, and its late...
Some context...I'm developing a new SDK for game developers. I've been
spending a lot of time with the generators (Windows, Linux, Mac, iOS,
Android, and playing with Windows Phone recently). CMake is the best
game in town for handling all these platforms. But there are also a
ton of things that annoy me. My goal is to help people build apps they
can ship, but much of CMake's thought process is about building apps
locally for your system and the work flow isn't correct in my opinion.
I've done a lot to address these short-comings and I hope to clear
some time to talk about all this and share my changes in the near
future. (Especially the Android stuff...I had to build a lot of crap
to make that work and I would like to fold that back into the CMake
core because it is evil.)

As for iOS (and some Mac), one of my peevs is that the application
bundle process doesn't happen as part of the build. For a normal
Mac/iOS development, you always rebuild your code and your application
bundle. CMake treats this as two discrete steps so what you
develop/test is different from what you ship. (And incidentally in the
Visual Studio case, I discovered it is impossible to launch your app
via the debugger because of this too.)

Additionally, the iOS/CMake stuff is flakey about letting you switch
between device and simulator. You shouldn't have to generate a
completely different project to test between the two. This is not how
iOS developers work nor how the Xcode toolchain is designed. (And now
that we have 32-bit and 64-bit versions of both, it's ridiculous.) I
some how got mine to the point where I can switch targets in the same
project, but it's flakey due to the way CMake injects paths/values
into the Xcode project. It isn't the same exact values as Apple, so
somethings like finding frameworks/libraries cause me to do some
tricks.

Also on that note, just getting CMake to pick the proper Lastest SDK
value by default would be nice. It is hard coding some full path which
seems to work in base cases, but causes me problems in other cases. I
noticed when Xcode versions change, this often is the main culprit for
new breakage.

All the configuration options are blank for me. The Mac one works, but
iOS is blank for me. This means thinks like all my optimization
settings are the same (debug and release have the same values).

I can set these values manually, but I have only been able to do it to
my own targets explicitly. My attempts to set the values globally (at
the root) have not succeeded.


I still haven't dealt with launch images and icons. A proper sized
launch image is required to get the iPhone 5 and iPhone 6 tall
resolutions without letterboxing. I'm not sure what the right thing to
do here is with CMake.


I'm doing my own application bundling to some degree. As I said,
CMake's normal process goes against the grain of the normal workflow
so I changed it to behave like the real thing. I'm having trouble
remembering, but I think the CMake/Mac had better handling than
CMake/iOS. CMake was doing some stuff for me better than iOS, but I
don't fully remember. (May have something to do with listing resources
as part of the target.) But one place I found CMake to be really
annoying was with nested directories and also symlinks. Copying a
framework into a bundle is a good example because it has both. And
ideally, 

Re: [cmake-developers] iOS support

[Eric Wing]

Thought of one more.
I hate how the top, default target is ALL_BUILD. This is problematic
for both Xcode and Visual Studio because when you use the big giant
run button in the UI, the IDE is confused because ALL_BUILD is an
aggregate target and not a real thing that can be run. At least for
Xcode, a bunch of options change dynamically based on the type of
target selected and building/launching to the device/simulator is not
an option when on an aggregate target.

It's an annoyance because it interferes with the normal workflow for
those familiar with the IDEs. And it's an annoyance for those who are
not familiar with the IDEs because the big giant buttons do nothing
and they don't understand the IDEs well enough on how to correct the
issue.

(It's also more work invoking xcodebuild and msbuild because you can't
rely on the default targets.)

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] A goal for a simple Android toolchain file.

[Eric Wing]

On 3/28/14, Stephen Kelly steve...@gmail.com wrote:
 Eric Wing wrote:

 I expect so, but knowing what the needs are helps inform what those
 changes

 might look like.

  http://public.kitware.com/Bug/view.php?id=14539


 I'm not sure either. I recall an old thread about this

 That thread is presumably the first link in the bug report I linked.

 It does. Did you look at the Android.cmake I posted?

 I only skimmed it.

 You are far closer to Android development than me. I think more-useful than

 this discussion would be more-direct and active collaboration on code or
 code snippets, rather than skimming everything. That's why I posted the
 Android.cmake platform file. I have the feeling somehow that you only
 skimmed my initial mail.

 Do you have time/capacity for that collaboration?


Yes, I am interested in collaboration. You caught me at an awkward
time though. For the past year, I've been mostly handling various
Android related disasters. I've been going insane, so I finally got a
block of time to do everything/anything but Android (back to Mac, iOS,
Linux. It can't all be rosy, so I'm being made to suffer with Windows,
though the dose is small enough that its still better than Android).

I'm thinking it will probably be two weeks before I get back to
Android. (If things go really well, maybe late next week.)

I've been meaning to try to figure out how to build SDL for Android
using CMake. So maybe if you want to get a head start on what you are
thinking for your toolchian and see how it works with SDL, that might
be one possible way we can sync up and start collaborating.

Or maybe simpler, try grabbing my ALmixer/HelloWorld
project/documentation and build it using my current technique. Then
see if you can make your toolchain handle it. Then we can sync up, I
can try your toolchain, and start iterating on it.

Thanks,
Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] A goal for a simple Android toolchain file.

[Eric Wing]

On 3/26/14, Stephen Kelly steve...@gmail.com wrote:
 Eric Wing wrote:
 I have been using my fork of the Android-CMake (originally from
 OpenCV) that you want to obsolete. My fork contains a lot of fixes to
 deal with more recent NDK updates and more complicated requirements
 that I have.
 https://bitbucket.org/ewing/android-cmake

 It's great to have someone here who is both familiar with cmake and with
 Android!


 It is completely reliant on the Android standalone toolchain
 technique which I vastly dislike,

 Sorry, I don't know what you're referring to. What is a standalone
 toolchain? This:

 https://www.assembla.com/code/android-gb-for-sharp-is01/git/nodes/debug/ndk/docs/STANDALONE-TOOLCHAIN.html

 ?

 It looks like the primary usefulness of that is to avoid the caller having
 to specify the -sysroot. Do I misunderstand? With CMAKE_SYSROOT in CMake
 3.0, and with the platform file I proposed, I don't see what makes that
 standalone toolchain stuff useful.

 Can you explain?


Yes, I think that one. In the docs/ directory of the Android NDK you
download, you can find the file: STANDALONE-TOOLCHAIN.html

As I understand it, it basically copies selected things out of the
Android NDK into another directory with a layout more consistent with
typical distributions so you can more easily use 3rd party tools like
CMake. Since Android overloads things like the architectures, the
compiler, and the standard libraries, each permutation you care about
must be copied out into a separate standalone toolchain instance. This
is one of the things that is annoying about it; depending on Android
NDK version, you may have 4 different compilers, each with 4 different
C++ standard libraries (all of which are not necessarily compatible
with each other). That means 4x4=16 permutations. If you want to
distinguish between dynamic and static linking, then you may need to
multiply by 2.

Additionally, each architecture is a permutation, so you need to
multiply another 2 or 3. Then if you can about specific ARM features
not available on all chips (e.g. NEON), you add a bunch more for that.
(The current Android-CMake toolchain seems to have some settings for
those which I've mostly ignored so far.)

Oh yeah, I think each API version needs its own standalone toolchain.

It also looks like the latest Android NDK (r9d) made some additions/changes.
https://developer.android.com/tools/sdk/ndk/index.html


I think it is theoretically possible to invoke the Android build
process without using the standalone toolchain, but the file/directory
layout doesn't necessarily follow normal conventions. I think the
original Android-CMake toolchain did support this, but somewhere
around the 64-bit toolchain release, things broke pretty badly and I
never got it to work. Android is free to re-arrange things and rename
things and they seem to be emboldened to do so in the non-standalone
toolchain.

Additionally, because things are overloaded, you need to be very
careful about not invoking the wrong options on the toolchain. I am
mostly in middleware, so I need to build libraries that other people
use. This means I am extremely sensitive to ABI issues and things like
dynamic linking of C++ standard libraries or specific architecture
optimizations that are not portable are huge no-no's and I need to
trust what the toolchain is doing.

There was also an alternative Android/CMake toolchain somebody wrote
which I think didn't use the standalone toolchain and I tried to work
with, but I started hitting a lot of the above problems which is what
led me back to the more complicated OpenCV one.


 So while I'm not opposed to a brand new Android toolchain file, I want
 to assert that it needs to be correct and it does need to handle a
 variety of cases. So learn as much as you can from the existing ones.

 My aim is to put the things which should be in a Android.cmake platform file

 shipped with CMake into such a file. Some things belong in such a file, I
 think, and others belong in a toolchain file maintained externally.

 In my fork, I spent a lot of time re-reverse-engineering the
 standard/default Android flags passed to the compiler. OpenCV took too
 many liberties with changing what Android passes normally which
 resulted in unexpected/broken behavior for some of my other projects.
 I think a very conservative, deferential approach should be taken.

 If you can provide details, I think that would be useful.

I wrote some comments in the changelog history in the comments of the
file. My Mercurial history also has some stuff. There are too many
details for me to remember. However, my general conclusion was try to
match watch Android does by default (i.e. same flags). Another example
is, I would defer to using the official stable compiler unless
overridden. I think it is still gcc 4.6, not 4.8. I presume there is a
reasoning behind the one they pick as the default/stable.


 I
 would also like it to understand multiple architectures which would
 also go

Re: [cmake-developers] A goal for a simple Android toolchain file.

[Eric Wing]

On 3/21/14, Stephen Kelly steve...@gmail.com wrote:

 Hi,

 I'd like it to be this easy to create an Android toolchain file:

  set(CMAKE_SYSTEM_NAME Android)

  set(ANDROID_SDK_ROOT /home/stephen/android/android-sdk-linux/)
  set(ANDROID_NDK_ROOT /home/stephen/android/android-ndk-r9/)
  set(ANDROID_NDK_PLATFORM android-18)

  set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
  set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
  set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
  set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)


 In order to do that, more stuff would need to be in the Android.cmake
 platform file.

 The platform file I'm currently experimenting with is here:

  http://www.steveire.com/Android.cmake

 I would aim to obsolete the toolchain file which is commonly used for
 Android, which is here:

 http://code.google.com/p/android-cmake/source/browse/toolchain/android.toolchain.cmake

 I think part of the solution will need to be an interface in CMake for
 selecting an STL version. That will probably also be usable to select
 between libstdc++ and libc++ when using clang.

 Any comments on adding that kind of thing to the Android toolchain file?

 Thanks,

 Steve.

I have been using my fork of the Android-CMake (originally from
OpenCV) that you want to obsolete. My fork contains a lot of fixes to
deal with more recent NDK updates and more complicated requirements
that I have.
https://bitbucket.org/ewing/android-cmake

It is completely reliant on the Android standalone toolchain
technique which I vastly dislike, but it works and does solve the
problem of selecting between gcc 4.6, gcc 4.8, clang 3.3 (or whatever
versions they have), as well as dealing with stlport, gnu libstdc++,
clang libc++ and so forth. And I can at least brute force the multiple
architecture builds (armv5, armv7, x86) with this technique.


I am using it to build multiple projects, two of which I actually documented:
ALmixer
https://bitbucket.org/ewing/hello-android-almixer
JavaScriptCore (this one is a nightmare to build correctly and I will
be very unhappy with any new Android CMake toolchain that doesn't
handle this.)
https://github.com/appcelerator/hyperloop/wiki/Building-JavaScriptCore-for-Android

So while I'm not opposed to a brand new Android toolchain file, I want
to assert that it needs to be correct and it does need to handle a
variety of cases. So learn as much as you can from the existing ones.
In my fork, I spent a lot of time re-reverse-engineering the
standard/default Android flags passed to the compiler. OpenCV took too
many liberties with changing what Android passes normally which
resulted in unexpected/broken behavior for some of my other projects.
I think a very conservative, deferential approach should be taken.


My wish list is that it would not require the standalone toolchain.
This would go a long way to simplifying the end-user experience. I
would also like it to understand multiple architectures which would
also go a long way to simplifying the end-user experience, though I'm
worried this might take deeper CMake changes.


  set(ANDROID_SDK_ROOT /home/stephen/android/android-sdk-linux/)
  set(ANDROID_NDK_ROOT /home/stephen/android/android-ndk-r9/)

It should also handle the semi-blessed/official Android environmental
variables like ANDROID_SDK_ROOT and ANDROID_NDK_ROOT so you don't have
to explicitly set them in CMake scripts.

  set(ANDROID_NDK_PLATFORM android-18)

It should automatically detect and use the latest Android target API
if it is not explicitly specified. There also may need to be a setting
to set the minSdkVersion, though that may fall outside of this since
CMake is currently limited to deal only with the NDK side.

I've ranted in multiple places about why the latest Android target API
should be used. My most recent public post is here:
https://forums.libsdl.org/viewtopic.php?p=42622sid=ce5cec7c0379740c39bd3819a914b99d

Thanks,
Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [Generator] Android.mk

[Eric Wing]

On 1/10/14, Stephen Kelly steve...@gmail.com wrote:
 Vince Harron wrote:

 Android.mk files allow you to target multiple processor
 architectures/variants in one make invocation without any reconfiguring
 or
 multiple build folders.  All of those binaries are embedded into one
 fat
 apk file that will run on any supported Android device.

 Sounds interesting.

 Modules/Platform/Android.cmake

 I've just started playing with it like this as my Android.cmake

 include(Platform/Linux)

 But it's critical to have Android as a separate CMAKE_SYSTEM_NAME because
 there are many differences that you might want to switch on.

 Indeed. Disabling SONAME is another apparently:

  http://public.kitware.com/Bug/view.php?id=14602

 Why does that link also say that Android.mk files are only for creating
 shared and static libraries? Am I missing something here?

 All Android applications start life as Java processes.  A java process
 can
 load a native shared library and invoke code within it.  To emit a C/C++
 executable on Android is the same as to emit a shared library, but linked
 to something called the native_app_glue module.

 Interesting. What is the entry point?


 I don't decide whether such a generator gets in or not, but I don't see why

 it would not be accepted.

 Thanks,

 Steve.


I agree that we should have a “native” Android NDK build generator.
There are some things that are harder to do outside the native build
process (some which have already been identified in this thread)

- Multiple architecture support (armeabi, armeabi-v7a, x86, mips).
Though these aren’t “fat” binaries in the NeXT/Apple model. They
merely introduce an extra subdirectory layer of indirection and place
each binary in the properly named folder. However, since the Android
model knows how to handle this, it would be very nice to have (because
my current workaround is to invoke CMake for each architecture and
then glue everything with my own post build scripts written in bash or
Perl…yuck).

- I’m not sure if this is the SONAME example mentioned, but Android
can’t handle the .so version numbering scheme where version numbers
are put in the file name and symlinks are used to point a version-less
file to a specific version. The NDK design is to use Java’s
System.loadLibrary to load NDK modules, and it turns out that
loadLibrary can’t handle symlinks.

- gdb debugging does some voodoo that is technically open, but not
really well documented or fully understood. I’ve some people try to
recreate it and document it for external tools like CMake, but it’s
work. The native system generally sets this up for you. (Though I have
a lot of problems getting regular Android stuff to ‘just work’.)



However, as a counterpoint, I will say that the NDK is a
broken/incomplete piece of $%#!, and in most respects, CMake’s generic
makefile system is vastly better. So I would actually like to see
CMake’s generic generator extended for Android.

- For example, did you know that compiling for size (-Os) is not
supported by the NDK? This is the stupid platform that limits you to
50MB .apk’s. What the $%$ are they thinking? I have the misfortune of
porting JavaScriptCore to Android and just getting it to build (and
verify it), the time involved has been measured in weeks spanning
months. Currently I’m trying to shrink the binaries because JSCore is
huge. Currently, the smallest I can get each architecture is about
30MB each. I’m building with CMake, so I can at least get access to
the -Os flags and actually control many build flags the NDK won’t let
me access. I would be totally screwed without this.

- Android introduced -mhard-float for processors that support it.
However, one serious problem is that you can’t use that on any code
that touches/crosses the Java JNI layer (because I think the Java VM
doesn’t expect arguments to be in float registers). Since Android
forces you to always go through Java, you always have to cross the JNI
layer somewhere. So, the obvious workaround is to specify CFLAGS per
file. But this is not possible with the native NDK build system. (I
haven’t checked r9c yet, which just came out.)

- Google hasn’t answered the question about how the NDK is going to
work with their switch to Gradle and IntelliJ. Honestly, Google has a
terrible track record with the NDK and I trust CMake a lot more than I
trust Google. (There's another story about Gyp lurking in here in
prior attempts to build JSCore before my involvement.)


This all said, I’ve forked the Android-CMake cross-compiler chain
(originally developed by the OpenCV people I believe) to keep it going
for the latest NDKs. I haven’t had much success with the direct
toolchain, but I have been very successful with the standalone
toolchain. I would like to rally more support to improve this
toolchain as well and maybe even get it included in some form in the
official CMake distribution. While it works, there are still lots of
pain points like multiple architectures which I already 

Re: [cmake-developers] lua bindings?

[Eric Wing]

On 8/3/12, Doug douglas.lin...@gmail.com wrote:
 Sorry, lots of talk. Tangibly I imagine something like this:


I recommend you skim the CMakeLua group for the old posts. (There
aren't that many.)
https://groups.google.com/forum/?fromgroups#!forum/cmakelua

If I recall, Peter Kümmel had some interesting ideas/code for
interoperating/mixing with existing CMake scripts. This may impact the
direction you take the Lua side of the bridge syntax/semantics, but
has the advantage of being able to coexist with and leverage the
existing CMake ecosystem.

https://groups.google.com/forum/?fromgroups#!topic/cmakelua/aVx3K-Y7H6M


-Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] lua bindings?

[Eric Wing]

On 8/2/12, Doug douglas.lin...@gmail.com wrote:
 I'm quite curious about the possibility of writing a lua binding for cmake.

 There are two possible ways to go:

 1) Create a set of discrete lua bindings which actually invoke cmake
 itself.

 2) Integrate lua into cmake itself.


Yes, there was a big long thread on the CMake lists back in 2008-ish
(CMake and Lua
 ). It prompted Dr. Ken Martin (Kitware) to try an experiment of
embedding Lua in CMake which actually successfully proved the binding
concept. Unfortunately, Kitware decided they didn't want to put the
resources into it. A few of us forked the project, but we failed to
continue to finish it. But the source is still out there.

Some info is here:
http://playcontrol.net/ewing/jibberjabber/cmake_lua.html
and
http://www.cmake.org/Wiki/CMake:Experiments_With_Lua

I am still very interested in seeing this happen, but I had to pick to
between binding Lua to Cocoa (LuaCocoa) or CMake and I did LuaCocoa.
And now, I am now preoccupied with porting LuaCocoa to iOS. (And we
also have a lot of pain right now with CMake and the
ever-changing/breaking Xcode.)


-Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
--

Powered by www.kitware.com

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

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

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