[CMake] Mac Xcode 11 Generator bug/problem with CODE_SIGN_IDENTITY default

2019-10-14 Thread Eric Wing
I hit a problem with the CMake/Xcode Generator using Xcode 11. (I
think this problem started in Xcode 10 actually, but now I'm blocked
really hard and need to solve this.)


By default, Xcode is now trying to do "Sign to run locally" for the
Code Signing Identity (CODE_SIGN_IDENTITY) property, by default.



For trivial apps with no embedded libraries/frameworks, this seems to
get through. However, for my real, more complicated projects, I have
bundled libraries/frameworks. But since CMake doesn't really have full
support for Xcode signing, the embedded libraries/frameworks are not
signed, and the code sign process to local sign the .app fails.


So to workaround this, I would like to tell Xcode to disable code
signing entirely.

Unfortunately, the only way to disable this seems to be to set the
CODE_SIGN_IDENTITY to "", i.e. make the field completely blank. The
following link shows all the steps with pictures, but basically you
set the box to "Other" and then submit a completely blank input box.
This internally in the Xcode project sets CODE_SIGN_IDENTITY to "".

https://stackoverflow.com/a/54296008


But my problem in CMake is that when I try to set the Xcode property
to "", it ignores the setting and defer to Xcode's default value of
"Sign to run locally".

# This has no effect
set_property(TARGET ${my_app} PROPERTY XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "")


How can I force this property to be overridden with ""?

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] CMake on Raspberry Pi

2018-05-21 Thread Eric Wing
On 5/20/18, Shawn G  wrote:
>  Hi there, im having some troubles installing CMake on raspberry pi 3
> running raspbian stretch.
> I keep getting this error message when i run the command "sudo apt-get
> install build-essential cmake pkg-config"
> The error message:
> " Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package CMake is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
>
> E: Package 'cmake' has no installation candidate "
>
> I've tried other installation methods like "pip install cmake" & "sudo
> apt-get install -y cmake" but all to no avail. Could you guys help me out?
> Is there a library i can extract from?
>
> Thank you in advance.
>

Try running:
sudo apt-get update

Then try again, i.e.
sudo apt-get install cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] How to build CMake so it works on an older Linux?

2018-04-06 Thread Eric Wing
On 4/5/18, Robert Maynard  wrote:
> The official CMake binaries do the same thing as you and build with a
> static libstdc++ and libgcc.
> As far as dependencies we use static builds of those too, with most
> being the version provided inside CMake, and an external openssl.
>
> You can find the more information on the exact flags we are using at:
> https://gitlab.kitware.com/cmake/cmake/blob/master/Utilities/Release/linux64_release.cmake
>

Thank you.
-- 

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:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] How to build CMake so it works on an older Linux?

2018-04-05 Thread Eric Wing
Thanks for the responses. Yes, I just need this to run on Ubuntu 12.04
(and some other old Linux's in that era). Yes, I think the probably is
the libstdc++ dependency.

As pointed out, it is really hard to get a newer compiler on Ubuntu
12.04. I've been down this road before, and if memory serves, the gcc
bootstrapping process to get a newer compiler doesn't seem to work
with a compiler older than gcc 4.8. Same goes for clang, which also
weirdly relies on gcc 4.8 to bootstrap itself.

Anyway, CMake seems to already know how to ship binaries that work
across Linux distros. I'm pretty sure they just statically linked
libstdc++ and libgcc. In fact, I just built it with -static-libstdc++
-static-libgcc on a newer Linux and tested it on 12.04 and it seemed
to work.

But I wanted to know for sure how CMake is building their own binaries
in case there are subtle problems with what I did, and they have a
completely different way of building it, e.g. statically libmusl for C
and libc++ for C++, avoiding gcc entirely.

Also, I did not take care of the libssl, libcrypto, and libz
dependencies. I'm curious in practice how much trouble these are. (My
recollection with zlib is that it is extremely stable and they care a
great deal about not breaking backwards compatibility. I don't know
about the others.)

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:
https://cmake.org/mailman/listinfo/cmake


[CMake] How to build CMake so it works on an older Linux?

2018-04-04 Thread Eric Wing
I just discovered that CMake no longer builds on my Ubuntu 12.04. I
need to build binaries that are compatible with that ABI.

I see that your binary distribution of CMake 3.11 still works on
Ubuntu 12.04. Can you tell me what you do to achieve this? What are
you doing for your official builds?

Are you just using -static-libstdc++ -static-libgcc for
CMAKE_CXX_FLAGS, or is there more?

(I just noticed that ldd shows that you don't have dependencies on
libssl, libcrypto, and libz, whereas I do.)

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:
https://cmake.org/mailman/listinfo/cmake


[CMake] Swift Makefile/Ninja generator: trying to bring up to date

2018-03-11 Thread Eric Wing
Hi, I know it’s been awhile since I last posted anything about this.
Since my last post, I had quietly added to the Ninja backend to bring
it to par with the initial work I did on the Makefile generator. This
was partly done because I was trying to get compatibility with Android
which uses the CMake/Ninja generator.

Anyway, the CMake/Android support has come a long way in the past
year. I see that there is now even a way to specify an external CMake
in local.properties as long as it is 3.7 (or greater I presume).

I really need to be leveraging all the new support in Android Studio,
so I need to update my version of CMake. Unfortunately, my Swift work
started before 3.7, and I just tried a merge with the latest, but the
merge went very badly. It looks like cmLocalGenerator.cxx has been
significantly rewritten in passing time, and I am no longer certain
how to integrate my original changes.

Can some of you CMake guru’s clue me in on how I should change my
original patch to now work with the current CMake source? Is
cmLocalGenerator.cxx my only problem, or are there other architectural
changes I need to be aware of to make all the other changes in other
files also work?


There are 10 small commits I made in a separate branch for my original
change, which can be seen at the top of the page at GitHub:
https://github.com/ewmailing/CMake/commits/SwiftMakefile

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:
https://cmake.org/mailman/listinfo/cmake


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

2017-08-17 Thread 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

2017-08-17 Thread 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

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

On systems the provide first class native 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

2017-08-16 Thread Eric Wing
> How easy is it to ship binaries which work on any platform without also
> shipping all of the necessary platform backends as well?

So on Windows and Mac, there is only one backend, the native one. And
so there is nothing to manage.

On the remaining Unix's with IUP you pick one when you build it.
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

2017-08-16 Thread 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

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

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


On 8/15/17, Raffi 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] CMake + Gradle for Android

2017-08-08 Thread Eric Wing
On 8/8/17, Jom O'Fisher  wrote:
> Yeah, we'd like to support any CMake more recent than 3.7.0 (which is the
> first version to support server mode). So your fork would need to be based
> on a somewhat recent CMake. We probably wouldn't support a path directly in
> build.gradle since that is typically a source controlled artifact. We'd let
> you set a file path in local.properties and/or specify a CMake version
> number in build.gradle where we'd search for it in some well-known
> locations.

I think I could live with local.properties. Any chance you could fast
track this and get it in soon?

Somewhat coincidentally, my fork of CMake happened close to the time
of where the Google fork seemed to happen. I tried the merge. I got
tons of conflicts for other things, not my changes. I'm about half-way
resolving them...but my changeset is relatively small so I've been
thinking I might just manually repatch on yours or try the
cherry-picking feature of Git.

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


Re: [CMake] CMake + Gradle for Android

2017-08-08 Thread Eric Wing
Hi Jom,

I'm glad to hear Android's CMake will eventually catch up.

But since you are here, can you add a feature that allows a user to
specify an alternate location for where CMake is located? There are
two useful cases for this.

1) Users daring or desperate enough to try using a more recent CMake
while they wait (perhaps they could have merged with Google's branch
manually)

2) In my case, I'm trying to implement new features into CMake (Swift
compiler support). It's not going to be mainlined anytime soon since
it is a long project, so even when you catch up, I still need to be
able to call my fork of CMake.

I don't want to overwrite anything in the Android distribution, and I
have people using my stuff and helping me, so we need a way to
collaborate. A simple gradle argument that lets me specify an
alternative path to CMake would fix my problem. (The other things I
need are specifying a toolchain file which I think you already support
and an Initial Cache (-C switch) which maybe is implicitly supported
since it is just a generic CMake command line argument.


Right now, I am doing the alternative method of calling CMake myself
through Gradle/Groovy scripts as people used to do. But I never
figured out how to get debugger integration with Android Studio as a
consequence. I would really like to move to the official Google/CMake
support, but I can't do that unless I can invoke a different CMake. (I
did pull the Google fork of CMake and I think my changes are
mergable.)

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


Re: [cmake-developers] Linking Apple frameworks

2017-08-08 Thread 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

2017-08-07 Thread 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

2017-08-05 Thread 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)

2016-10-31 Thread 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] CMake integration in Gradle (Android Studio)

2016-10-31 Thread 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

Re: [CMake] How to codesign .msi from WIX/CPack?

2016-09-08 Thread Eric Wing
On 9/7/16, David Cole  wrote:
> There may be a hook at the CPack level you can implement, but I'd have to
> dig to figure out what it is and if it even presently exists.
>
> The easy thing to do would be to implement a custom target which does two
> custom commands: the first the same as CPack (the built-in package target)
> and the second, a custom command to sign the generated .msi file.
>
>
> David
>

Thanks David. If you happen to find the hook, please let me know as I
am interested in that. Most of my users are not familiar with CMake,
so all the different built-in targets are already kind of confusing to
them already. I'm not keen on adding another if I can avoid it
(especially one that has fussy external dependencies, such as keyfiles
and passwords).

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


[CMake] How to codesign .msi from WIX/CPack?

2016-09-06 Thread Eric Wing
I'm finally trying the WIX/CPack MSI generator. Pretty nice!

One thing I need to do is instruct the build process to codesign via
signtool.exe. I've managed to figure out how to codesign my .exe via a
POST_BUILD add_custom_command step.

But now I would like to make sure the .msi that gets generated also
gets code signed. But I can't figure out how to do it.


I seem to need at least two things:

1) A post-build hook into the PACKAGE target (add_custom_command
doesn't seem to do anything when I try to refer to this target).

2) The name and location of the .msi that CPack/WIX generated so I can
refer to it with the signtool command.


Any advice?

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


Re: [CMake] OSX Code Signing best practice

2016-07-15 Thread Eric Wing
On 7/12/16, Harry Mallon  wrote:
> Hello all,
>
> What is the current best practice for code signing OSX .apps and binaries? I
> am using:
>
> 1. MAC_OSX_BUNDLE for my .app targets.
> 2. unix style executables
> 3. dylibs
> 4. A prefpane (which I haven't got working yet) using something like the
> below:
>
> add_library(prefpane MODULE
> ${sourceFiles}
> )
>
> set_target_properties(codexprefpane PROPERTIES
> BUNDLE YES
> BUNDLE_EXTENSION prefPane
> XCODE_ATTRIBUTE_WRAPPER_EXTENSION prefPane
> MACOSX_BUNDLE_INFO_PLIST ${prefpane_plist_file}
> )
>
> I am not using the CPackBundle generator so I cannot use the signing in
> that. I have tried:
>
> 1. Using set_target_properties(  "XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY"
> "${SIGN_ID}")
> 2. Using an add_custom_command step. This code signs before all the
> Resources are copied in so the signatures are invalid
>
> Any ideas?
> Harry
>

I do something similar. I also don't use CPack and need the build
process to respect normal Xcode run/debug/profile workflows where the
app bundle is built correctly on build and not through separate CMake
target steps.

I have a add_custom_command as a POST_BUILD to copy and sign my
frameworks, dylibs, and plugins. Then I use
XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY to get Xcode to sign the rest of
the bundle through the normal Xcode mechanisms.

It works. I do find having to set the
XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY annoying. I kind of wish the CMake
generator could ignore that field and leave it to whatever the user
ends up setting (and not overwrite on every update regeneration)
because there are different identities you need depending on the
situation and changing this all the time in CMake scripts is annoying.
And I wish Xcode itself would automatically recursively sign
dependencies so I don't need to copy and sign manually.

-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


Re: [CMake] Mac OS X framework building

2016-06-05 Thread Eric Wing
On 6/5/16, Bill Somerville  wrote:
> On 24/05/2016 21:55, Bill Somerville wrote:
>> I am trying to make a framework using a shared library. The docs say
>> that the target property PUBLIC_HEADER should be a list of interface
>> header files that install(TARGET ...) will populate
>> .../.framework/Headers/ with but I cannot get that to happen.
>> I have set the target property FRAMEWORK to TRUE and the target is a
>> SHARED library. The framework gets created with the Versions and
>> Resources directories etc. and the .plist file and the dylib is added
>> with all the relevant symlinks. No headers are being added and the
>> Headers directory is not being created.
>>
>> Can anyone help with what I am missing or provide a link to a project
>> that creates a Mac OS X framework successfully using install(TARGETS
>> ...)?
>

I use Frameworks all the time. But you need to use PUBLIC_HEADER in
SET_TARGET_PROPERTIES. It is part of the actual build, not part of
INSTALL.

Try referring to ALmixer as one example.
https://bitbucket.org/ewing/almixer

-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


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

2016-05-25 Thread 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] How to deal with generated source files (w/ dependency tracking) for globs

2016-04-14 Thread Eric Wing
On 4/6/16, iosif neitzke  wrote:
> I think it depends on when you want the output files from Nim
> generated and which files are the most frequently developed.
> If it is usually a one-time generation per clean development session,
> the simplest case, where the *.NIM source files are not the files
> most likely to be changed, I would think execute_process should
> work okay?
>

Thanks for the responses. In this case, the common use case would be
writing/changing the NIM files, which in turn require the C files to
be rewritten. (The users are writing in NIM, and C generation to them
is just an implementation detail and means to an end.)

It sounds like this is going to be a pain.

I appreciate everybody's responses on 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


Re: [CMake] How to deal with generated source files (w/ dependency tracking) for globs

2016-04-06 Thread Eric Wing
On 4/4/16, Nicholas Braden  wrote:
> I haven't tested this myself, but instead of using a glob, you could
> have a build step that generates a CMake script file with the list of
> generated files in it (e.g. via execute_process to run another CMake
> script whose only job is to generate the CMake script inception-style)
> and just include the generated file - CMake will see that the CMake
> file has been modified during every build but will still handle source
> file changes correctly. Worth a shot.
>

Thanks for the reply. So if I understand this correctly, this is what
the workflow is going to feel like.

- User adds their Nim file to the CMakeLists.txt
- CMake detects a change and a bootstrap generate/update takes place,
and my stuff re-runs the Nim compiler.
- Also during this phase, I need to generate another CMake script
which contains the list of files the Nim compiler output.
- Since this other script is also under CMake change tracking, this
will trigger another CMake change detection and
bootstrap/generate/update.
- Now the generated build system has the updated list of generated .c
files to compile and will finally compile it.

Does this sound right?

My major concern is that the two bootstrap phases kind of break the
flow. What I mean by that is that in Xcode for example, when a
bootstrap/generate/update happens, it actually causes your Build/Run
(run button) action to abort midway through. You sit there expecting
it to build, but CMake's regeneration was the only thing that
happened. You must hit the Run button again to actually build/run.
Kind of annoying and also really confusing for people who don't
understand this because it isn't obvious why this happened.

But in the above example, there are now two bootstrap phases. So
assuming this works, I think the user will have to hit the Run button
at least 3 times before something actually builds/runs. I think this
is going to feel real broken and feel like dumb luck something
actually built.

So I was hoping to find a one-step bootstrap solution instead of two-step.

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


[CMake] How to deal with generated source files (w/ dependency tracking) for globs

2016-04-04 Thread Eric Wing
Hi, this is kind of a side problem that was asked of me. I'm not sure
how many hoops I actually want to jump through to solve this. But,
here's the situation.

I have a really nice, traditional C based project in CMake. All my
dependency tracking works really well for cross-platform and IDE
integration and even have resources/bundling/codesigning working
nicely in the single build step.

Now somebody throws me a curve ball and wants to use the Nim language.
The specifics of the Nim language itself is not that important to this
topic, but the key piece of information is that the Nim compiler can
generate C files as output.

So the question is, how can I invoke Nim to compile a list of
pre-known Nim source files, and then slurp in the generated output C
files and build them as part of my normal CMake build process.

The curve ball is this: I don't know all the names or how many files
the Nim compiler generates. If I know all the names beforehand, I
think I know how to deal with this situation. But instead, I get a
directory of C files. The names seem to be dependent on which library
features were used and also what the user's source files were named. I
suspect the standard library could theoretically change too so future
versions of Nim may have different files.

I know file globs with CMake don't auto-track changes and I think the
problem gets more trickier because of the indirection to invoke Nim.
(i.e. When I first glob the files, the directory is empty, then the
Nim compiler is invoked later and the files appear, but it is too late
for CMake to see without a regeneration).

Anyway, I was wondering what the best approach is.

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


Re: [CMake] Best way to show/include CMake files in IDE

2016-03-07 Thread Eric Wing
On 3/7/16, Eric Wing <ewmail...@gmail.com> wrote:
> On 3/7/16, David Cole <dlrd...@aol.com> wrote:
>> If you include those files in the source list for a library, executable,
>> or
>> custom target, they should show up in IDE projects, and they should be
>> ignored by Makefile type projects. Have you tried that?
>>
>>
>> David
>>
>
> I haven't tried it yet since I was wondering what the best approach was :)
> Since some of my files are somewhat project oriented instead of target
> oriented, I wasn't sure if putting them the library/executable targets
> was best. But if it is, I'll try that.
>
> Thanks,
> Eric
>

Well, I gave it a try. So far, it looks good.

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


Re: [CMake] Best way to show/include CMake files in IDE

2016-03-07 Thread Eric Wing
On 3/7/16, David Cole  wrote:
> If you include those files in the source list for a library, executable, or
> custom target, they should show up in IDE projects, and they should be
> ignored by Makefile type projects. Have you tried that?
>
>
> David
>

I haven't tried it yet since I was wondering what the best approach was :)
Since some of my files are somewhat project oriented instead of target
oriented, I wasn't sure if putting them the library/executable targets
was best. But if it is, I'll try that.

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


[CMake] Best way to show/include CMake files in IDE

2016-03-07 Thread Eric Wing
I have a bunch of .cmake support files in my project that I have split
off from CMakeLists.txt (using INCLUDE to combine them) to separate
concerns. (Source files, application assets, script files, platform
settings, codesigning, etc.)

This works, but they don't show up in IDEs (Visual Studio, Xcode,
etc). I realized it would be nice to see these files in the IDE and be
able to edit them there. (I assume the CMake bootstrap will still just
work.)

What is the best way to include/show these files in the IDE (and won't
break the Makefile or other non-IDE generators)?

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


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

2016-02-29 Thread 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

2016-02-19 Thread 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

[CMake] Video glimpse of how I'm using CMake with Swift (and CMake in general)

2016-02-18 Thread Eric Wing
I thought some of you might find this video I made interesting. It is
a teaser video for a new 2D cross-platform game SDK I've been working
on. It makes aggressive use of CMake for the build system.

https://youtu.be/w8ftI9mpGdY

The video goes by fast since is a time-lapse style. But hopefully the
gist comes through.

This video is using the Swift support put in for Xcode last year, and
the experimental stuff I've been adding for Makefiles. (Still work to
be done.)

I also use CMake to integrate all the resource and dynamic library
management so you can actually just hit Run and things work as you
expect. (This is different than what most(?) people are doing today.)

There is a Quick Introduction 3 part video from the website that shows
stuff in more detail if you want more.

Also, some feedback I've already been getting from testers... The
number one trip up is the ALL_BUILD target which always has to be
changed to the real application target in order for the Build/Run
button to work. This trips up everybody. And if you don't, the result
and error message in Visual Studio is confusing. Xcode isn't much
better.

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


Re: [cmake-developers] Drop support for older Xcode versions?

2016-02-10 Thread 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?

2016-02-06 Thread 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] [cmake-developers] Drop support for older Xcode versions?

2016-02-06 Thread 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


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

2016-02-05 Thread 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

2016-01-29 Thread 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

2016-01-29 Thread 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

2016-01-29 Thread 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] XCode Generation Issue

2016-01-21 Thread Eric Wing
On 1/21/16, David Morsberger  wrote:
> Eric,
>
> I went down a rabbit hole and pulled myself back out. I narrowed it down to
> the following.
>
> We are using cmake to check if the linker supports -Wl,—as-needed. The test
> compile (and link?) command cmake builds using ‘cmake -G Xcode’  does not
> fail.
>
> The command from ‘cmake -G’ has been narrowed down to the following:
>
> $
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> \
>  -Qunused-arguments \
>  -DWS_LD_FLAG_VALID0 \
>  -Wl,--as-needed \
>  -c src.c \
>  -o src.o
> $
>
> The following modified command generates an error:
>
> $
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> \
>  -Qunused-arguments \
>  -DWS_LD_FLAG_VALID0 \
>  -Wl,--as-needed \
>  src.c
>
> ld: unknown option: --as-needed
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> $
>
> It appears the linker isn’t called when the -c and the -o options are
> present. The following warning is generated when the ‘-Qunused-arguments’ is
> removed.
>
> clang: warning: -Wl,--as-needed: 'linker' input unused
>
> The cmake logic in CMakeLists.txt is basically:
>
>SET(CMAKE_REQUIRED_FLAGS "${_FLAG}")
>CHECK_C_SOURCE_RUNS(“int main() { return 0;}" ${_RESULT})
>
> where _FLAG is set to ‘-DWS_LD_FLAG_VALID0 -Wl,—-as-needed’
>
>
> So, how/where is the clang compile/link command generated and why isn’t it
> being setup for clang to link?
>
>

Sorry, these are internals I'm not very familiar with. I'm just
starting to get up to speed on the CMake internals for the Makefile
generator (Linux focus) because I'm trying to add a Swift backend.

My impression has always been (this could be wrong) that the Xcode
generator has more deference to Xcode than CMake actively getting
involved. I probably helped push this attitude too because Apple tries
to handle a lot of specific details through Xcode that they feel is
too arcane to expect/require their developers to know about. In
general, I find this to be the right thing, because ultimately getting
stuff that works well with Obj-C (CMake makefiles have a bug where
they compile as Obj-C++), all the packaging and codesigning, and
working with the iOS simulator are platform specific and somewhat
private/changing implementation details they don't want us to manually
hardcode.


Anyway, to your question, I almost never use CHECK_ commands so I'm not sure.
CHECK_C_SOURCE_RUNS is something I would never use because 'running'
is a serious problem for cross-compilation (Mac was
PowerPC/Intel/32-bit/64-bit, iOS is armv6/armv7(s)/arm64/i386).
Cross-compilation is kind of built-into Xcode's thinking now because
there are so many targets. I don't even know how LLVM bitcode factors
into this now, but hopefully the idea of deference to Xcode is that I
mostly won't need to care.

Are there separate CHECK_ commands for compilation and linking
(without running)?

-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

Re: [CMake] XCode Generation Issue

2016-01-20 Thread Eric Wing
On 1/20/16, David Morsberger <d...@morsberger.com> wrote:
>
>> On Jan 19, 2016, at 10:11 PM, Eric Wing <ewmail...@gmail.com> wrote:
>>
>> On 1/19/16, David Morsberger <d...@morsberger.com> wrote:
>>> Any help would be appreciated.
>>>
>>> In particular I’d like to know how the default compiler arguments are
>>> set
>>> when ‘cmake -G Xcode’ is executed. The attached file contains the cmake
>>> test
>>> compile extracted and reformatted from CMakeOutput.log that should have
>>> failed. Again, what is setting all the clang compiler options when this
>>> is
>>> executed?
>>>
>>>
>>>
>>> All help is appreciated
>>>
>>>> On Jan 18, 2016, at 2:58 PM, David Morsberger <d...@morsberger.com>
>>>> wrote:
>>>>
>>>> I’m having an issue generating and using a XCode project using cmake
>>>> -G.
>>>>
>>>> cmake —version
>>>>cmake version 3.4.1
>>>>
>>>> Xcode Version 7.2 (7C68)
>>>>
>>>> Mac OS 10.11.
>>>>
>>>>
>>>> My CMakeLists.txt has a clang option that fails during the -G Xcode
>>>> pass
>>>> but fails when linking within XCode.
>>>>
>>>> The compiler / linker option is ‘-Wl,—as-needed’
>>>>
>>>> The test compile/link step in ‘cmake -G Xcode' creates a long clang
>>>> command with arguments ‘-Wl,—as-needed’ plus ‘—serialize-diagnostics
>>>> >>> to .dia file>’
>>>>
>>>> The link step within Xcode after the project created has the
>>>> ‘-Wl,—as-needed’ argument and does not have the ‘—serialize-diagnostics
>>>> ’ argument. The link fails because ‘-Wl,—as-needed’
>>>> isn’t supported.
>>>>
>>>> If copy and execute the long clang command from the ‘cmake -G Xcode’
>>>> command and remove the ‘—serialize-diagnostics ’
>>>> then
>>>> it successfully fails with ‘-Wl, —as-needed’ isn’t supported.
>>>>
>>>> Finally, when I use cmake to generate unix makefiles it works meaning
>>>> cmake determines ‘-Wl—as-needed’ isn’t supported and doesn’t add it to
>>>> the
>>>> argument list.
>>>>
>>>> Questions:
>>>> - Where is the ‘—serialized-diagnostics’ argument coming from when
>>>> executing ‘cmake -G Xcode’?
>>>>
>>>> - What is a .dia file and how do I read it?
>>>>
>>>> - What’s the preferred / recommended way of detecting the non-supported
>>>> ‘-Wl,—as-needed’ argument during the ‘cmake -G Xcode’ phase? One option
>>>> might to be to remove the ‘—serialize-diagnostics’ argument during the
>>>> generation phase.
>>>>
>>>> I can provide more details on request.
>>>>
>>>> David
>>>>
>>>>
>>>>
>>
>>
>> I just spot checked one of my Xcode compile logs. I see the
>> —serialize-diagnostics flag, but I don't have —as-needed anywhere.
>> Maybe one of your CMake scripts is adding that in, or you have set
>> some kind of environment variable that clang or Xcode is picking up?
>> (This recently happened to me on Linux.)
>
> Ed,
>
> In this case cmake is attempting to determine if ‘—as-needed' is a supported
> option and the build should fail.
>
> I have searched (grep’d) everything I can think of for the string
> ’serialize-diagnostics’ with zero hits.
>
> I can easily add an ‘if( Xcode )’ around the setting in CMakeLists.txt
> however I’m trying to figure out what is exactly going on. The best
> solutions are chosen when you know what is going on under the hood.
>
>
>

I believe the serialize-diagnostics flag is added by Xcode itself. I
see it (along with many other flags) in a native (non-CMake generated)
Xcode project.

-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

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

2016-01-20 Thread 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] XCode Generation Issue

2016-01-19 Thread Eric Wing
On 1/19/16, David Morsberger  wrote:
> Any help would be appreciated.
>
> In particular I’d like to know how the default compiler arguments are set
> when ‘cmake -G Xcode’ is executed. The attached file contains the cmake test
> compile extracted and reformatted from CMakeOutput.log that should have
> failed. Again, what is setting all the clang compiler options when this is
> executed?
>
>
>
> All help is appreciated
>
>> On Jan 18, 2016, at 2:58 PM, David Morsberger 
>> wrote:
>>
>> I’m having an issue generating and using a XCode project using cmake -G.
>>
>> cmake —version
>> cmake version 3.4.1
>>
>> Xcode Version 7.2 (7C68)
>>
>> Mac OS 10.11.
>>
>>
>> My CMakeLists.txt has a clang option that fails during the -G Xcode pass
>> but fails when linking within XCode.
>>
>> The compiler / linker option is ‘-Wl,—as-needed’
>>
>> The test compile/link step in ‘cmake -G Xcode' creates a long clang
>> command with arguments ‘-Wl,—as-needed’ plus ‘—serialize-diagnostics > to .dia file>’
>>
>> The link step within Xcode after the project created has the
>> ‘-Wl,—as-needed’ argument and does not have the ‘—serialize-diagnostics
>> ’ argument. The link fails because ‘-Wl,—as-needed’
>> isn’t supported.
>>
>> If copy and execute the long clang command from the ‘cmake -G Xcode’
>> command and remove the ‘—serialize-diagnostics ’ then
>> it successfully fails with ‘-Wl, —as-needed’ isn’t supported.
>>
>> Finally, when I use cmake to generate unix makefiles it works meaning
>> cmake determines ‘-Wl—as-needed’ isn’t supported and doesn’t add it to the
>> argument list.
>>
>> Questions:
>>  - Where is the ‘—serialized-diagnostics’ argument coming from when
>> executing ‘cmake -G Xcode’?
>>
>>  - What is a .dia file and how do I read it?
>>
>>  - What’s the preferred / recommended way of detecting the non-supported
>> ‘-Wl,—as-needed’ argument during the ‘cmake -G Xcode’ phase? One option
>> might to be to remove the ‘—serialize-diagnostics’ argument during the
>> generation phase.
>>
>> I can provide more details on request.
>>
>> David
>>
>>
>>


I just spot checked one of my Xcode compile logs. I see the
—serialize-diagnostics flag, but I don't have —as-needed anywhere.
Maybe one of your CMake scripts is adding that in, or you have set
some kind of environment variable that clang or Xcode is picking up?
(This recently happened to me on Linux.)
-- 

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

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

2016-01-18 Thread 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

2016-01-15 Thread 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

2016-01-15 Thread 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

2016-01-14 Thread 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

2016-01-13 Thread 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

2016-01-13 Thread 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

2016-01-13 Thread 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

2016-01-08 Thread 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

2016-01-07 Thread 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

2015-12-24 Thread 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] [cmake-developers] CMake IR

2015-07-30 Thread Eric Wing
Disclaimer: My name is attached to the failed CMake/Lua attempt.

In principle, I like the idea of what you propose. However, in
practice, I think it might be too big and too ambitious.

Here are some quick thoughts I have:

- I am in the camp that I do not like the CMake language. And it is
often the hardest selling point in my experience, even when you
convince them that CMake can do all the cross-platform stuff. (I’m
seeing more competition from Gyp these days, but in my limited
personal experience, people still have not been able to port highly
complex projects to as many target platforms with Gyp, whereas CMake
could handle them (and the perceived gains of Gyp disappeared in these
complex scenarios)).

- Along those lines, part of the problem we seemed to hit was that
pure declarative build instructions didn’t hold up well in the complex
case. I haven’t done much with Gyp in this manner, but those around me
that were trying seemed to hit the wall pretty fast in this. But I
have used Ant, and that was a terrible experience for anything that
required conditionals.


- I would definitely like to see better interoperability with IDEs and
tools. I would personally love a simple cross-platform gui project
manager that basically allowed you to create targets, add/remove files
to be compiled to a target, and set specific compile/link flags on a
per-target or per-file basis, sort of like you can do in most IDEs
(but if you tried using CMake, your changes get clobbered in the next
regeneration…though even better would be able to do this directly in
the native IDEs).

- I am little concerned about encouraging people to add on any
arbitrary language. There are two different problems that this could
potentially cause: (1) CMake bloat, (2) Dependency hell

- CMake currently can bootstrap itself with just a C++ compiler. That
is a good thing. I recently had to get CMake up on a Raspberry Pi. I
was fortunate that CMake had few dependencies and was relatively
small. (Not counting Qt which was an unmitigated disaster.)

- Building other projects using CMake can be painful depending on
their dependency chain. While this is not technically CMake’s
responsibility, encouraging users to use non-canonical tools can make
things a nightmare. CMake has been pretty good about providing
fundamental mechanisms you need that work on all platforms. But if
users are encouraged to say, “I’ll just use Perl+CPAN or Ruby with
these gems”, instead of the standard CMake mechanisms, things get
awful quickly. (I finally just reproduced a build of JavaScriptCore
for Windows after over a year of trying…it has dependencies on Perl,
Python, Ruby, and a bunch of other things I can’t remember, all of
which are a terrible pain to get working on Windows.)

- In that same line of thought, the reason Lua was a good candidate is
because it its tiny which avoids adding bloat, it is pure ANSI C,
which means it compiles everywhere CMake already compiles, and it was
designed to be an embedded scripting language doing the exact type of
things that the current CMake language is asked to do. (Dr. Ken Martin
said they were impressed with Lua and would have used it if they had
known about it originally.)

(By the way, if you haven,t already, I encourage you to read through
the old Lua threads circa 2008.)

- Incidentally, the Lua table is pretty much the same
concept/pre-cursor to JSON in JavaScript. Lua lends it self to both
data driven formats as well as custom DSLs pretty well. If Lua were
part of the core, you could build a  the data-oriented format files
without any additional dependencies.


- I don’t think the IR will help anything related to the work of
adding new languages like Swift. The hard part there is not really the
CMake language as much as understanding the overall system
design/architecture. No matter what language you pick, that part will
always be hard.


- Mostly, I’m concerned that this project is too big and ambitious in
scope to see completion unless you have funding and a team to drive
it. The Lua attempt is a failure, but not for technical reasons. It
was a manpower problem. Dr. Ken Martin proved the concept could work
in something like 13 hours. But at the time Kitware said they weren’t
going to go down that road, so anybody still interested in it was left
to make it happen ourselves. We gave it a shot, but none of us really
had the time to commit to finish the task, which is much smaller than
the one you are proposing. (Granted, we wasted a lot of time trying to
bridge CVS (which CMake was still using at the time) with DVCS, so you
at least won’t have to worry about constant merge-hell.)


-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 

[CMake] Possible to dynamically construct macro/function names to invoke?

2015-07-19 Thread Eric Wing
I would like to dynamically construct a macro or function name to
invoke. I basically have a core CMake system I want users to be able
to extend/plug stuff into without knowing about a lot of the core
CMake implementation. Callback functions would be an easy way for me
to accomplish this.

As an example,

# In my core code, I have a macro designed to callback other macros
macro(DO_PACKAGE _TARGET_NAME)
foreach(callback ${DO_PACKAGE_CALLBACK_LIST})
DO_PACKAGE_FOR_${callback}(${_TARGET_NAME})
endforeach()
endmacro(BLURRR_PACKAGE_EXTRAS)


### Also in my core code, I pick an appropriate time to trigger my
macro to call user callbacks
DERIVE_SOME_NAME()
ADD_EXECUTABLE(${SOME_NAME} ...)
DO_PACKAGE(${SOME_NAME})



# So in user modules provided by others, they follow a convention where
# they define a macro DO_PACKAGE_ appended by their module name.
macro(DO_PACKAGE_FOR_MYMODULE _TARGET_NAME)
MESSAGE(in mymod callback)
# do stuff
endmacro()

# And I make them add their module name to a global list so I can call
it back at the right time
list(APPEND DO_PACKAGE_CALLBACK_LIST MYMODULE)


So in my attempts to do this, I'm getting errors like:
Parse error.  Expected a command name, got unquoted argument with text

Is there way to do this (or something similar)?

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


Re: [cmake-developers] Adding Swift support to CMake

2015-07-15 Thread 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

2015-07-02 Thread 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

2015-06-25 Thread 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 

Re: [CMake] iOS multi-arch library target and xcodebuild

2015-06-25 Thread Eric Wing
 * iOS toolchains I'm using: https://github.com/ruslo/polly (used to
 switch between different SDKs + to add some flags, like -std=c++11)

Do you have to use a different toolchain for every different variant
and different OS version? That's rather unfortunate if so. My current
tweaks don't require this.

 * when I run Archive for preparing my application for uploading to
 AppStore Xcode uses only device architectures. Just set Build Active
 Architecture Only to NO and universal application for device will be built

I think I saw this mentioned elsewhere and am employing that. Still,
I'm a little concerned this might be a hack that is working around a
more underlying problem that could break.

 * I see no point of using frameworks for managing 3rd parties. Plain
 `root/include` and `root/lib` layout works for iOS (and for all
 others platforms like MSVC, MinGW, ...)

Frameworks vs. dylibs isn't the issue at all here and completely
misses the point. The point is the way FIND_LIBRARIES anchors absolute
paths to everything. This won't work with SYSTEM framewoks because the
paths dynamically change depending on device or simulator.  3rd party
fat binaries installed in a single location regardless of frameworks
or dylibs. This is annoying because you must remember whether you are
dealing with a system provided library or a third party library in the
way you write your CMake files now.

A disgression: my understanding is that for iOS, officially for 3rd
party dynamic libraries, only frameworks and not dylibs are supported.



 * Hunter automatically set CMAKE_PREFIX_PATH and package_ROOT to the
 root directory of 3rd party libraries so `find_package` works fine

Okay, I think I've done something similar by setting the
CMAKE_ROOT_PATH to look in the CMAKE_PREFIX_PATH, CMAKE_LIBRARY_PATH,
CMAKE_INCLUDE_PATH. I needed this for Android's NDK Module system
convention too.



 * toolchain used to switch between different SDK's. You just need to set
 environment variable IOS_X_Y_DEVELOPER_DIR. See
 https://github.com/ruslo/polly/wiki/Toolchain-list#ios

Okay, I think my tweaks have done better than this. I don't need to
set any environmental variable changes. I can use the built-in Xcode
UI to switch between SDKs and my tweaks are mostly agnostic to which
iOS SDK version you have. (It always detects the default installed.)
My concerns are not merely one-shot automation builds. I do manual,
every day development in Xcode and expect/follow a mostly natural
Xcode developer work flow and other developers on the platform expect
the same. Being able to switch between simulator and device without a
roundtrip CMake generation is extremely useful (and expected), along
with being able to test the different architecture variants (32-bit,
64-bit).


I plan to do a write up of some kind to show my workflow and present
my tweaks I made to try to improve things for all the platforms I work
on to make the every day workflows more natural for each respective
platform.


But I do suspect the fat device/simulator binary build patch would be
very useful to have.

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


Re: [CMake] iOS multi-arch library target and xcodebuild

2015-06-24 Thread Eric Wing
On 6/24/15, Ruslan Baratov via CMake cmake@cmake.org wrote:
 On 24-Jun-15 23:03, Bill Hoffman wrote:
 What is in the patched CMake?
 * workaround for bug: http://public.kitware.com/Bug/view.php?id=12506
 * installing universal simulator + device library
 CMake already supports mulit-arch libraries on the Apple platform.
 As far as I know you can build two libraries: one for simulator, like [
 i386 + x86_64 ] and one ARM, like [ armv7 + armv7s + arm64 ]. Patched
 CMake version run some extra CMake commands to link them together into [
 armv7 + armv7s + arm64 + i386 + x86_64 ] fat library.

 On 25-Jun-15 00:00, headupinclouds wrote:
 I had thought that the iOS simulator x86_64 architecture was not
 supported in the same FAT library as the arm architectures without the
 patch, but I could be wrong.
 Exactly
 --

Ooh. This sounds really interesting. Does this also mean that CMake
doesn't need to use an external iOS toolchain anymore?

So to clarify, these were some of the problems I have (had?) with CMake on iOS:

- Almost all the problems stem from how the SDK root is defined in CMake.

- iOS simulator and iOS device use different SDKs and Xcode is
supposed to dynamically switch them depending on your current Xcode
selection (either in the GUI or command line invocation).

- iOS treats these as separate SDKs with completely different paths
for both inputs (e.g. headers, dynamic libraries, etc), and outputs
(build products)

- iOS doesn't combine simulator and device binaries into fat binaries
and instead opts for two completely different paths for everything.
This has created extraordinary pain for 3rd party middleware
developers or people wanting to use pre-built frameworks. Apple has
done pretty much nothing to make this situation bearable.

- As such, developers make their own fat binaries by manually
combining the device and simulator binaries together with lipo.

- Apple engineers have warned not to do that. However, their lack of
providing any other reasonable solution after 7 years just makes them
seem obstinate. (I suspect they want to keep room open for a mythical
x86 iOS device, and refuse to solve our real problems of today.)

- The new iOS framework feature throws another monkey wrench for the
manual lipo workaround because in building the final app, the
framework gets bundled as-is, with all the architectures in place.
Without manual intervention, you will attempt to ship an iOS app to
the store that contains simulator binaries and will likely be
rejected. (There was a recent mailing list thread asking how to solve
this...no good solution was found.)



- Anyway, CMake has trouble with singular SDK root.

- FIND_LIBRARY is problematic for system frameworks because the path
needs to change depending on device or simulator. My workaround is to
manually write -framework Foo instead of using FIND_LIBRARY for
Apple system frameworks. (I can continue to use FIND_LIBRARY for 3rd
party frameworks, but must make sure they are fat.)

- I believe I had to tweak my toolchain to write values that matched
Xcode more closely, otherwise switching between device and simulator
wouldn't work.

- Because Xcode/xcodebuild put products in different directories for
device vs simulator, I end up manually running standalone shell
scripts to find these products and lipo them.

- I would like to be able to write shell scripts that get run as part
of Xcode's built-in shell-script phase because certain useful Xcode
environmental variables are set/available when you do that. But CMake
doesn't have a mechanism to do this as far as I know, so I have to
hard code things that are variable by Xcode and subject to change.


Then there are other CMake problems not directly related to this, such
as switching codesigning keys, invoking the Archive feature (kind of
needed for deploying), setting entitlements, and still clumsy areas
where the CMake generated Xcode UI is missing stuff from a normal
Xcode project. (Setting things like entitlements, Game Center stuff,
orientation settings, and just being able to quick add a framework for
experimentation.) And many of these are problems for Mac too now.

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


[cmake-developers] Adding Swift support to CMake

2015-06-17 Thread 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.



[CMake] How do I set an Xcode property on the global/root project?

2015-06-14 Thread Eric Wing
I have been successful at setting Xcode properties on specific targets
with CMake via:

set_property (TARGET ${TARGET} PROPERTY
XCODE_ATTRIBUTE_${XCODE_PROPERTY} ${XCODE_VALUE})

But I have been unable to set properties on the global/root project.
Is there a way to do this?


Much of the time, I want to set a property on all my targets. I can
manually set each target, but visually inspecting the Xcode project is
more confusing this way because you have to understand how overrides
work. It's nice to just look at the root. (And I haven't figured out
how to set the built-in aggregate targets.)

But more annoyingly, sometimes I'm in places in the build system where
it is too early for a target or I don't have easy access to the target
name. It would be much easier to just set the global project and not
worry about needing a target to pass.

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


Re: [CMake] How do I set an Xcode property on the global/root project?

2015-06-14 Thread Eric Wing
On 6/14/15, Gregor Jasny gja...@googlemail.com wrote:
 Hi Eric,

 On 14/06/15 14:38, Eric Wing wrote:
 I have been successful at setting Xcode properties on specific targets
 with CMake via:

 set_property (TARGET ${TARGET} PROPERTY
 XCODE_ATTRIBUTE_${XCODE_PROPERTY} ${XCODE_VALUE})

 But I have been unable to set properties on the global/root project.
 Is there a way to do this?

 The excellent CMake documentation has the answer. The XCODE_ATTRIBUTE
 help page here:
 http://www.cmake.org/cmake/help/v3.2/prop_tgt/XCODE_ATTRIBUTE_an-attribute.html

 Would have pointed you to CMAKE_XCODE_ATTRIBUTE
 http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_XCODE_ATTRIBUTE_an-attribute.html

 Hope that helps,
 Gregor


Can you elaborate on this? I can't make this work. (I remember that I
tried this before and failed.)

Here's an example of how I'm trying to invoke it:

set_property(GLOBAL PROPERTY
CMAKE_XCODE_ATTRIBUTE_SWIFT_OBJC_INTERFACE_HEADER_NAME
BlurrrSwiftInterfaceHeader.h)

This seems to get ignored. (But if I use a per-target setting, then it works.)

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


Re: [CMake] cmake iOS application + framework link error

2015-04-29 Thread Eric Wing
On 4/25/15, David Hirvonen dhirvo...@elucideye.com wrote:
 I'm hitting a link error when linking an iOS application with an internally
 created framework/library using the the CMake Xcode generator and an iOS
 toolchain.  I've put together a minimal CMakeLists.txt example here:

 https://github.com/headupinclouds/cmake_framework_test/

 The problem is described in detail in the the README, and reproduced here
 in the email for completeness.

 The repository is intended as a simple unit test to illustrate an apparent
 link and build location mismatch when linking a framework to an iOS
 application using the standard iOS toolchain
 https://code.google.com/p/ios-cmake/ (I realize this toolchain isn't
 provided with CMake). I've included the ios toolchain in this repository to
 make it easy to reproduce the issue. I've include both the iOS application
 that reproduces the link error, and an OS X application, which links to the
 library in correct framework location. I'm looking for a CMakeLists.txt fix
 or possible workaround. There are two top level convenience bash scripts
 for building the applications with cmake using an xcode generator.  The
 CMake version is 3.2.1.

 cmake --version
 cmake version 3.2.1

 https://github.com/headupinclouds/cmake_framework_test/blob/master/README.md#ios-framework-and-application-erroriOS
 framework and application error:

 bash -fx ./test-ios.sh
 + NAME=_builds/ios
 + cmake -GXcode -H. -B_builds/ios -DCMAKE_TOOLCHAIN_FILE=iOS.cmake

 snip
 clang: error: no such file or directory:
 '/Users/dhirvonen/devel/cmake_framework_test/_builds/ios/Debug-iphoneos/TF.framework/Versions/A/TF'
 ** BUILD FAILED **
 The following build commands failed:
 Ld _builds/ios/Debug-iphoneos/testa.app/testa normal armv7
 (1 failure)
 library path:  _builds/ios/Debug-iphoneos/TF.framework/TF

 This produces a flat framework layout (ignoring the FRAMEWORK_VERSION
 property (which is fine with me if I can get it to work)). It looks like
 this:

 tree _builds/ios/Debug-iphoneos/TF.framework
 _builds/ios/Debug-iphoneos/TF.framework
 ├── Info.plist
 ├── TF
 └── _CodeSignature
 └── CodeResources

 But when it reaches the link command for the ios application:

 target_link_libraries(testa TF)

 it fails, since it seems to expect the library to be two directories down
 within a versioned framework layout:

 TF.framework/Versions/A/TF

 instead the directory is here:

 TF.framework/TF

 I'm looking for a solution to either:

- correct the TF link path to use the actual (non versioned) framework
layout that is currently generated, or
- correct the framework so that it uses the versioned layout to make
that consistent with the link path

 https://github.com/headupinclouds/cmake_framework_test/blob/master/README.md#os-x-framework-and-application-successOS
 X framework and application success:

 When I build this for OS X it seems to work fine.

 bash -fx ./test-osx.sh
 + NAME=_builds/osx
 + cmake -GXcode -H. -B_builds/osx
 snip
 ** BUILD SUCCEEDED **
 library path: _builds/osx/Debug/TF.framework/Versions/A/TF

 This produces a framework with the following layout:

 tree _builds/osx/Debug/
 _builds/osx/Debug/
 ├── TF.framework
 │   ├── Resources - Versions/Current/Resources
 │   ├── TF - Versions/Current/TF
 │   └── Versions
 │   ├── A
 │   │   ├── Resources
 │   │   │   └── Info.plist
 │   │   ├── TF
 │   │   └── _CodeSignature
 │   │   └── CodeResources
 │   └── Current - A
 └── testb

 and the call to

 target_link_libraries(testb TF)

 picks up the TF library in the correct location.

 I'm curious if there is a variable or property that needs to be set for the
 iOS example to give the same framework layout.



I have not tried this (yet), but my guess is that CMake needs to be
patched to understand iOS frameworks. iOS frameworks are new as of iOS
8. 3rd parties were not allowed to make frameworks before that.
Additionally, CMake's framework support was implemented for Mac like a
decade ago. Because the iOS framework structure (and .app structure
for another matter) is different, CMake will likely need to be taught
how to make a proper structure for iOS.

If you do any work on this, I am interested in your results.
Eventually, I would like to support iOS frameworks, though I'm
probably at least 6 months from that since I need iOS 7 to drop off
the face of the earth, which means after iOS 9 is released.

(Note to non-iOS developers reading this: iOS does not allow flat
.dylib files for shared libraries. You must build a framework.)

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

Re: [cmake-developers] Support of codesign

2015-03-20 Thread 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] xcode generator's use of explicitFileType vs lastKnownFileType

2014-12-18 Thread Eric Wing
On 12/18/14, Radu Margarint rad...@raduma.com wrote:
 Greetings,

 I hope I'm asking this in correct place. I have recently been running
 into some issues using the xcode project files generated though cmake,
 and I have traced them down to PBXFileReference nodes using
 explicitFileType attributes (vs lastKnownFileType).

 The projects generated are some fairly vanilla mac static libs +
 console apps, with a file count of ~500ish, about a dozen targets in
 all. Nothing I would consider complex. However, attempting to open the
 generated project files in xcode results in xcode hanging for about
 3-4 minutes parsing the project file, at open time or whenever it
 decides it should reparse it. (Sampling it indicates that it's
 spending it's time calling [PBXFileReference
 _getEffectiveFileType:fileProperties:] over and over and over).
 Eventually it finishes and wakes up.

 Though a lot of trial and error manually mucking with the generated
 project files, I've traced the slowdown to the use of
 explicitFileType on the file reference nodes. A simple replace to
 lastKnownFileType fixes the issue and xcode opens the project
 instantly.

 I'm wondering if anyone has seen this before, and if there are any
 fixes recommended. (The obvious one being I can patch my cmake
 generator locally to use the desired attribute, though I'm hoping that
 maybe there are some known root causes and better fixes). (FWIW, the
 slow down occurs on both Xcode 5.x and 6.x, on a couple of machines
 across Yosemite and Mavericks).

 Thanks
 --radu
 --


I have experienced the extremely long and 100% CPU utilization of
Xcode indexing. And in Xcode 5, there seemed to be conditions where it
would completely hang and you have to force kill Xcode. And it seems
to be random luck on whether it freezes again; certain computers seem
to be more susceptible to freezing here. (So far Xcode 6 doesn't seem
to need killing, but the CPU taxing is still painful.) And this
problem I'm hitting is for relatively small projects, not necessarily
large ones.

I had not been able to look into this problem and don't know any of
the backend details, so I'm happy to hear you found something. This is
one of my most worrisome concerns about the Xcode generator right now.
(And moving forward, I see it unlikely that the Makefile generator
will be sufficient for real Mac  iOS development and we need a much
better Xcode generator.)

Another thing I just came across is that the internal $SRCROOT
directory maps to the root CMakeList.txt directory instead of where
the Xcode project resides. Right now, I think this is confusing the
OSX entitlements file feature which is causing me pain.


I don't have any recommendations, except whatever you find/fix is
probably good and well needed.

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


Re: [CMake] Copying shared libraries in a post-build step

2014-12-09 Thread Eric Wing
On 12/9/14, Walter Gray chrysal...@gmail.com wrote:
 Hey all,
 I'm working on a module that will allow me to automatically copy all the
 required .dll files as defined by well-formed import library targets to
 the appropriate location (same folder for windows, Frameworks folder for
 OSX bundle, ect).  I've got the code that scans an executable's
 INTERFACE_LINK_LIBRARIES property recursively to find all such shared
 library, however I'm running into a small problem.  I really like using
 file globbing in higher level source directories to add all appropriate
 sub-directories, but this means that sometimes a dependency will not be
 fully defined yet. This is normally fine since these things are usually
 resolved at *generation* time, but since I'm doing a manual traversal of
 the list of link libraries at config time that's not really acceptable.
 I realize I could just not do the globbing and just make sure the
 directories were setup in the correct order, but I really don't like
 making the add_subdirectory calls order dependent.

 One solution I've come up with is to add the targets I want to do this
 to to a global list, then iterate over that list as the last step in my
 top-level cmake lists file, but that has the issue that I can no longer
 use add_custom_command on those targets at that point.  I'm wondering 3
 things:

 1)What is the reasoning behind not allowing add_custom_command on
 targets not defined in the current directory? Especially now that SOURCE
 can be modified, the restriction seems very arbitrary.

 2)How stupid would it be to reserve the command using something like
 add_custom_command(TARGET ${target} POST_BUILD COMMAND
 $TARGET_PROPERTY:COPY_SHARED_LIBS_COMMAND)
   then use set_property(TARGET ${target} APPEND PROPERTY
 COPY_SHARED_LIBS_COMMAND to add more copy steps to the command?

 3) Am I completely missing something and there's already a totally well
 supported way of making sure that an executable's shared library
 dependencies end up in the correct directory?  I couldn't find a really
 satisfactory answer on stack overflow or the archives.

 Thanks!



I think this is a good idea if you can pull it off. I recently wrote a
lot of excruciating CMake code to do this for me. (I also was dealing
with resource and plugin code which shares similar issues.) This
actually took me a very long time to implement and it would be better
if CMake handled this automatically. Here is a list of ideas that I
needed to deal with:

- My motivation was to build a runnable product when you build. On
Visual Studio, you can't run through the debugger because none of the
.dlls are in place. Similarly on Mac, iOS, Android, and now WinRT,
there is no separation/distinction between compiling the executable
and packaging the contents. This is in my opinion of the most
problematic design issues in CMake. I also strongly feel that having
to run the install target is very wrong because it violates the normal
workflow on all these platforms and you also end up developing/testing
something different than what you ship to testers/users.

- The fix_bundle_utils didn't work for me because it did stuff in the
install stage (too late). Also, it didn't handle my usage of Mac
@rpath (not sure if that was fixed since) so I gave up on it early.


- I needed an explicit declaration mechanism to describe which
libraries needed to be bundled (or which did not). Some are system
libraries while others need to be redistributed with the app. And some
might be static libraries which you don't copy. (A .lib/.dll on Visual
Studio and a .framework on iOS is ambiguous to whether they are static
or dynamic.)

- There was also both implicit knowledge about where they go for
each platform (had to make decisions about Linux and RPATH_ORIGIN),
and also made decisions when they were nested in subdirectories. (I
preserve the layout.)

- For Visual Studio, that explicit mechanism had to be aware that
you link with .libs, but copy the .dll.

- I didn't do an explicit scan of the libraries for dependencies
for multiple reasons. One important reason to me though is I want the
build to be as fast as possible (ideally on par with Xcode normally
does which is apples-to-apples in this case).

- I don't think scanning INTERFACE_LINK_LIBRARIES is
sufficient because it won't capture what libraries each of those might
depend on. For example, I deal with a pre-build SDL_image library on
Windows which depends on libtiff, libjpeg, libpng. libpng then in turn
depends on zlib.

- The complexity of recursively walking the dependencies,
and then also knowing which ones are system supplied libraries and
which are not is really hard, which is another reason I went the
explicit declaration route. (And shipping Linux binaries is a
nightmare; you have to make hard decisions about what is a system
library and what you need to need to ship yourself.)

- Mac/iOS framework copies were a pain because they are bundles
(directory 

Re: [CMake] Copying shared libraries in a post-build step

2014-12-09 Thread Eric Wing
On 12/9/14, J Decker d3c...@gmail.com wrote:
 This is all handled by install.

I already addressed INSTALL. I know you can change the directory. That
is irrelevant to the point which I already addressed.



 Sounds really like you're working to build a package, which install is
 intended to do.

Another problem which I didn't make explicit was that Xcode's
codesigning and entitlements phase will not work with INSTALL because
it signs when you build via Xcode. And there are cases where you must
develop and test with codesigning and entitlements enabled, like
testing App Store purchases, Game Center, or want to use the new
built-into-Safari JavaScriptCore debugger if you have a JSContext in
your app.

Also, iOS/Android/WinRT, the INSTALL target is useless.

The INSTALL thing is a hack in my opinion that we as a community have
accepted as a solution. I'm now calling it out as a design problem in
CMake, especially as the winds have shifted to more platforms focusing
on shipping binaries than the former and now treat packaging as a
first class citizen. It is an impediment to the natural workflow on
those platforms, it is an impediment to people adopting CMake, and it
is an impediment to people wanting to deal with native languages
because build systems are too complicated. (The scripts I wrote are
intended to deal with all those things in a new middleware product I'm
developing and hopefully bring native crossplatform development to
people that otherwise wouldn't touch it before.)


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


Re: [CMake] Copying shared libraries in a post-build step

2014-12-09 Thread Eric Wing
 Your scripts would still only work for one target... since you'd have to
 pick one to build the rest of the package around, so if I have a build
 product that has a dozen utilities, rather than having one place they can
 all work from, I have now to either duplicate all files to all runnable
 targets or have a central one that would be the only one to work.   This is
 more of a hack.

I don't think this is true at all. My scripts do the right thing
when you build and they are efficient.  But I still respect INSTALL
and you can still install. I still use INSTALL and PACKAGE,
particularly the latter on Windows for creating an NSIS installer.

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


Re: [CMake] CPack: .desktop files with tar.gz maker?

2014-11-09 Thread Eric Wing
On 11/7/14, Clinton Stimpson clin...@elemtech.com wrote:
 On Friday, November 07, 2014 03:50:32 PM Eric Wing wrote:
 I have a build and packaging system where I can distribute (mostly)
 standalone apps for Linux desktop. I am using the default CPack
 installer which creates .tar.gz, .Z, and .sh files.

 I like this opposed to the .deb/.rpm package systems because users
 don't need root access to install/use my stuff (and can place
 anywhere), and I only need a single package for all Linux desktops.

 But it's pretty plain-Jane and it would be nice to provide an icon or
 something. So I was wondering if anybody had
 suggestions/advice/strategies on supporting .desktop files. As far as
 I can tell, I need paths to the icon and the executable, which is
 completely variable based on where the user puts it. And I'm not sure
 where this file is supposed to be written to. (Remember that I don't
 use root access.)

 Thanks,
 Eric

 Perhaps you can do this:

 Include the .desktop file in your installation.

 To add, your installer can call
 xdg-desktop-menu install install/share/applications/MyApp.desktop

 To remove, your installer can call
 xdg-desktop-menu uninstall install/share/applications/MyApp.desktop

 If xdg-desktop-menu is called as root, it'll copy the .desktop file to the
 system location.  If it is called as a non-root user, it'll copy the file to

 the user specific desktop area.  xdg-desktop-menu also takes care of
 refreshing
 the icons in the launcher.

 During uninstall, it'll remove the copy.

 By the way, we do .rpm and .deb, but also give instructions for users to
 extract the files if they want their own installation directory.

 The above .desktop support can be put in a script and added to the postinst

 and prerm scripts for rpm and deb.

 This makes things more automatic for the majority of our users (basically
 download-click-and-run).

 Clint



Thanks for the information. Based on that, I wrote a script that is
bundled with the contents and when run, will generate the correct
.desktop file with the correct absolute paths needed and invoke
xdg-desktop-menu install.

I noticed that the CPack tarball generator also generates a
self-extracting .sh ball. Is there anyway to hook into that to add a
postinst like stage so I can invoke my script?

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


[CMake] CPack: .desktop files with tar.gz maker?

2014-11-07 Thread Eric Wing
I have a build and packaging system where I can distribute (mostly)
standalone apps for Linux desktop. I am using the default CPack
installer which creates .tar.gz, .Z, and .sh files.

I like this opposed to the .deb/.rpm package systems because users
don't need root access to install/use my stuff (and can place
anywhere), and I only need a single package for all Linux desktops.

But it's pretty plain-Jane and it would be nice to provide an icon or
something. So I was wondering if anybody had
suggestions/advice/strategies on supporting .desktop files. As far as
I can tell, I need paths to the icon and the executable, which is
completely variable based on where the user puts it. And I'm not sure
where this file is supposed to be written to. (Remember that I don't
use root access.)

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


Re: [cmake-developers] [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

2014-11-04 Thread 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!

2014-11-04 Thread 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] [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

2014-11-04 Thread 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


Re: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui

2014-11-04 Thread Eric Wing
Bump. With CMake 3.1 on the horizon, I was wondering if there was any
progress on this.

This would be really useful to me. I am basically invoking command
line cmake.exe so I can pass all the right options, including my own
CMake Initial Cache file. I ship an entire self-contained SDK of
sorts which has all the prebuilt library dependencies in a place
relative to a .bat or .sh script used to invoke cmake.exe, which makes
project generation for all of my platforms essentially a turn-key
operation.

However, my projects have a couple of configurable options (e.g. I
don't need to link in OpenAL), And it would be nice if I could present
the CMake gui first so they can uncheck the options before generation.
(I copy some things into the build directory on generation which means
they get stuff they may not want if they can't uncheck the option
first.)

I think basically the behavior I want is essentially the same as
ccmake, except have a proper GUI (a lot of Windows and newer users
don't grok the curses thing).

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


Re: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

2014-11-04 Thread 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


[CMake] Using CMake to build an Emscripten output?

2014-11-04 Thread Eric Wing
Not that I really have time to fix this, but I was experimenting with
my C based codebase to see if I could compile it with Emscripten so it
could run in a browser.

After working around a lot of scary compiler bugs, I got it to work.
But I invoked the build process by hand. So the next thing on my mind
is how to leverage CMake (since all my other platforms use it
already).

My incantation for my test project is pretty straight foward and looks
very much like a clang invocation. The major difference is that all my
assets needed to be part of the compile process using the
--preload-file flag. (A minor difference is the output file ends in
.html)


 ~/Source/GIT/emscripten/emcc -O2 --js-opts 0 -g4 CircularQueue.c
TimeTicker.c  main_c.c  -I/opt/local/emscripten/include
-I/opt/local/emscripten/include/SDL2  -I
/opt/local/emscripten/include/chipmunk
/opt/local/emscripten/lib/libSDL2_ttf.a
/opt/local/emscripten/lib/libfreetype.a
/opt/local/emscripten/lib/libSDL2_image.a
/opt/local/emscripten/lib/libpng.a /opt/local/emscripten/lib/libz.a
/opt/local/emscripten/lib/libALmixer.a
/opt/local/emscripten/lib/libchipmunk.a
/opt/local/emscripten/lib/libSDL2.a   -o FlappyBlurrr.html
--preload-file fly2.png --preload-file fly1.png  --preload-file
fly0.png  --preload-file VeraMono.ttf --preload-file
gamecontrollerdb.txt --preload-file coin_ding.wav  --preload-file
background.png --preload-file bush.png  --preload-file clouds.png
--preload-file ground.png --preload-file pipe_bottom.png
--preload-file pipe_top.png --preload-file
davedes_fastsimplechop5b.wav --preload-file
LeftHook_SoundBible_com-516660386.wav --preload-file SlideWhistle.wav
--preload-file 14609__man__swosh.wav --preload-file acknowtt.ttf
--preload-file MedalBackground.png --preload-file
momoko_Bronze_Medallion.png --preload-file momoko_Silver_Medallion.png
--preload-file momoko_Gold_Medallion.png --preload-file
momoko_Platinum_Medallion.png --preload-file Placeholder_Medallion.png
--preload-file playbutton.png --preload-file quitbutton.png
--preload-file 04B_19__.TTF -s ASSERTIONS=1


Anybody used CMake with Emscripten for this purpose? Or any thoughts
on what I should do? (I also have some concerns the preload-file list
is going to get too long. Perhaps I'm missing something with
Emscripten.)


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


Re: [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

2014-10-30 Thread 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] [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

2014-10-30 Thread 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


Re: [cmake-developers] iOS support

2014-09-30 Thread 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

2014-09-30 Thread 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] cmake 3.0.0 generating VS sln file default target machine type x86 (UNCLASSIFIED)

2014-09-26 Thread Eric Wing
On 9/26/14, Su, Simon M CTR USARMY ARL (US) simon.m.su@mail.mil wrote:
 Classification: UNCLASSIFIED
 Caveats: NONE

 For some reason, when running cmake in VS2013 (express) x64 Cross Tools
 Command Prompt is not picking up the Visual Studio 12 2013 Win64 generator
 by
 default for this project. But when I added

 -G Visual Studio 12 2013 Win64

 To cmake, it generated x64 project files and I am able to generate 64bit
 library from command line with msbuild command.

 Thanks
 -simon



In my experience, CMake always generates the 32-bit version by default
(and the generator doesn't let you switch in the project). I consider
this extremely annoying. I only have 1 Visual Studio version installed
so it can't be picking up other versions.

 -G Visual Studio 12 2013 Win64

I always have to use that switch. Aside from picking 64-bit by default
or getting a project generator that correctly allows switching within
the project, I wish there was a way I could just request 64-bit with a
command line switch independently of the Visual Studio version. In the
case where I am working with people with different versions of Visual
Studio and we share build scripts, I have no easy way of controlling
64-bit without knowing exactly which Visual Studio version is
installed.


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


[CMake] How do I create a dependency to copy (touched) resource files when building an executable?

2014-06-30 Thread Eric Wing
I need to copy resource files from the source directory to the binary
directory with the creation of my executable. I want CMake's
dependency tracking to handle (re)copying these files whenever the
source has been touched.

Looking at other similar questions like:
http://stackoverflow.com/questions/17018477/cmake-adding-custom-resources-to-build-directory
and the CMake FAQ: How can I add a dependency to a source file which
is generated in a subdirectory?
http://www.cmake.org/Wiki/CMake_FAQ

I expected the following (simplified) code to work, but it doesn't. I
see the add_custom_target processed in the make chain, but the
add_custom_command never triggers.



project(foo)

cmake_minimum_required(VERSION 2.8)

add_executable(fooexe
${CMAKE_SOURCE_DIR}/foo.c
${CMAKE_SOURCE_DIR}/asset1.lua
#   ${CMAKE_SOURCE_DIR}/subdir/subasset1.lua
)

add_custom_command(
OUTPUT ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INT}/asset1.lua
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${CMAKE_SOURCE_DIR}/asset1.lua
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INT}/
DEPENDS ${CMAKE_SOURCE_DIR}/asset1.lua
COMMENT Copying asset1.lua
)

# files are only copied if a target depends on them
add_custom_target(fooresources ALL DEPENDS ${CMAKE_SOURCE_DIR}/asset1.lua
COMMENT fooresources custom target
)
ADD_DEPENDENCIES(fooexe fooresources)



Would somebody explain to me the correct way to handle 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


Re: [CMake] How do I create a dependency to copy (touched) resource files when building an executable?

2014-06-30 Thread Eric Wing
Thanks for the reply. So the usage case is that people are going to be
modifying the resources in the source directory. (These changes have
to be checked into revision control.) So I'm having trouble seeing how
depending on the binary directory is going to work. (The reason I must
copy the resources to the binary directory is it is impossible to
launch the application through the debugger or otherwise.)

Thanks,
Eric


On 6/30/14, Petr Kmoch petr.km...@gmail.com wrote:
 Hi Eric.

 It seems to me that you're copying from source dir to binary dir, but all
 dependencies are on the source dir file only. Therefore, there is nothing
 to trigger the generation of the binary-dir file. Perhaps you wanted
 'fooresources' to depend on the binary-dir file instead?

 Petr


 On Mon, Jun 30, 2014 at 3:20 PM, Eric Wing ewmail...@gmail.com wrote:

 I need to copy resource files from the source directory to the binary
 directory with the creation of my executable. I want CMake's
 dependency tracking to handle (re)copying these files whenever the
 source has been touched.

 Looking at other similar questions like:

 http://stackoverflow.com/questions/17018477/cmake-adding-custom-resources-to-build-directory
 and the CMake FAQ: How can I add a dependency to a source file which
 is generated in a subdirectory?
 http://www.cmake.org/Wiki/CMake_FAQ

 I expected the following (simplified) code to work, but it doesn't. I
 see the add_custom_target processed in the make chain, but the
 add_custom_command never triggers.



 project(foo)

 cmake_minimum_required(VERSION 2.8)

 add_executable(fooexe
 ${CMAKE_SOURCE_DIR}/foo.c
 ${CMAKE_SOURCE_DIR}/asset1.lua
 #   ${CMAKE_SOURCE_DIR}/subdir/subasset1.lua
 )

 add_custom_command(
 OUTPUT ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INT}/asset1.lua
 COMMAND ${CMAKE_COMMAND} -E copy_if_different
 ${CMAKE_SOURCE_DIR}/asset1.lua
 ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INT}/
 DEPENDS ${CMAKE_SOURCE_DIR}/asset1.lua
 COMMENT Copying asset1.lua
 )

 # files are only copied if a target depends on them
 add_custom_target(fooresources ALL DEPENDS
 ${CMAKE_SOURCE_DIR}/asset1.lua
 COMMENT fooresources custom target
 )
 ADD_DEPENDENCIES(fooexe fooresources)



 Would somebody explain to me the correct way to handle 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




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


Re: [CMake] How do I create a dependency to copy (touched) resource files when building an executable?

2014-06-30 Thread Eric Wing
Okay, I switched just the add_custom_target DEPENDS to the binary
directory (but left the add_custom_command alone). That seems to be
doing what I need. I think I'm still not fully understanding the
reasoning behind it, but problem solved I guess.

Thanks,
Eric


On 6/30/14, Eric Wing ewmail...@gmail.com wrote:
 Thanks for the reply. So the usage case is that people are going to be
 modifying the resources in the source directory. (These changes have
 to be checked into revision control.) So I'm having trouble seeing how
 depending on the binary directory is going to work. (The reason I must
 copy the resources to the binary directory is it is impossible to
 launch the application through the debugger or otherwise.)

 Thanks,
 Eric


 On 6/30/14, Petr Kmoch petr.km...@gmail.com wrote:
 Hi Eric.

 It seems to me that you're copying from source dir to binary dir, but all
 dependencies are on the source dir file only. Therefore, there is nothing
 to trigger the generation of the binary-dir file. Perhaps you wanted
 'fooresources' to depend on the binary-dir file instead?

 Petr


 On Mon, Jun 30, 2014 at 3:20 PM, Eric Wing ewmail...@gmail.com wrote:

 I need to copy resource files from the source directory to the binary
 directory with the creation of my executable. I want CMake's
 dependency tracking to handle (re)copying these files whenever the
 source has been touched.

 Looking at other similar questions like:

 http://stackoverflow.com/questions/17018477/cmake-adding-custom-resources-to-build-directory
 and the CMake FAQ: How can I add a dependency to a source file which
 is generated in a subdirectory?
 http://www.cmake.org/Wiki/CMake_FAQ

 I expected the following (simplified) code to work, but it doesn't. I
 see the add_custom_target processed in the make chain, but the
 add_custom_command never triggers.



 project(foo)

 cmake_minimum_required(VERSION 2.8)

 add_executable(fooexe
 ${CMAKE_SOURCE_DIR}/foo.c
 ${CMAKE_SOURCE_DIR}/asset1.lua
 #   ${CMAKE_SOURCE_DIR}/subdir/subasset1.lua
 )

 add_custom_command(
 OUTPUT ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INT}/asset1.lua
 COMMAND ${CMAKE_COMMAND} -E copy_if_different
 ${CMAKE_SOURCE_DIR}/asset1.lua
 ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INT}/
 DEPENDS ${CMAKE_SOURCE_DIR}/asset1.lua
 COMMENT Copying asset1.lua
 )

 # files are only copied if a target depends on them
 add_custom_target(fooresources ALL DEPENDS
 ${CMAKE_SOURCE_DIR}/asset1.lua
 COMMENT fooresources custom target
 )
 ADD_DEPENDENCIES(fooexe fooresources)



 Would somebody explain to me the correct way to handle 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




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



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


Re: [CMake] Cygwin drive paths are killing me

2014-06-16 Thread Eric Wing
On 6/14/14, David Cole dlrd...@aol.com wrote:

 You are persistent... One of the keys to your success, I'm sure. But,
 out of curiosity... if you have Linux and Mac environments all set up
 already, why not build the Android stuff from one of those platforms??
 Why go through all the pain of getting an Android build working from
 Windows?


To answer your question David, I'm working on a new middleware product
to help people build their own cross-platform applications
(specifically games). I've decided to use CMake as the foundation
layer for the build system and resource management.
But this has several implications, one of which is users expect this
stuff to work on the platforms they want to use. Since Android
*technically* supports Windows, I've felt obligated to try to make
this work, even though the Android NDK is total crap.

I'm definitely putting disclaimers in about how they should use Mac or
Linux. I'm guessing they won't listen at first, but just the regular
Android/Windows setup process is painful so maybe they'll fatigue and
then listen. But having something that works helps, instead of people
assuming I don't know what I'm doing. (You don't know how often I get
this in middleware from higher-level Android developers who have been
so insulated by the products I've worked on, that don't understand how
terrible Android is.)

A side note, one positive thing I found was in a survey we did about a
year ago, 90% of the people were using Macs to develop for Android.
Unfortunately, Linux was a rounding error and the remaining 10% was
Windows.


I tend to agree with your statements about not using Unix environments
on Windows. It's Windows. Go run a real Unix if you want Unix. I've
been burned by Cygwin in the past too so I've gone out of my way to
not use it. Unfortunately, Android always finds new ways to make me
suffer.

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


Re: [CMake] Cygwin drive paths are killing me

2014-06-13 Thread Eric Wing
I finally got it working. Here's a summary of my findings in case
anybody finds this useful. (I think this will ultimately be useful
info in trying to build a proper Android generator for CMake.)

- I ditched Cygwin. (But I learned that CMake later on for Unix
Makefiles complains about Cygwin sh.exe being in my path, and
uninstalling Cygwin is kind of hard.)

- I got MSYS to work in the base case of simply getting through generation.

- But MSYS turned out to be a problem for me because the way I
integrate it with Android Studio/Gradle, I need to execute a command
line task to invoke CMake. Since Android Studio/Gradle don't know
anything about the MSYS environment, it fails because the standard
CMD.exe process doesn't understand MSYS Makefiles. And I could not
figure out a way to get Gradle/Groovy to start an MSYS process and
also run a script. (At best I could launch an MSYS shell, but it just
sits there waiting for input.)

- So I moved to pure Windows (no Unix stuff). It turns out you *must*
have something Unix-y to generate the standalone toolchain. I suspect
this and some other tools in Android are still Unix only and that's
why Google says Cygwin is required. However, once I generated the
standalone toolchain, I did not need Unix again.

- For the native generation, I needed to generate Unix Makefiles.

- For this to work, I needed to download a prebuilt, standalone GNU
Make.exe which I pass the path to explicitly when I generate.
(Additionally my Groovy callbacks  need to find this path information
to invoke Make when you build from Studio/Gradle.)

- I moved CMake to the first step in the build process since I make
CMake also responsible for managing assets. CMake copies the assets to
a place Studio/Gradle expect

- I let Android Studio/Gradle deal with the Java and creating the apk
(with assets). So install and packaging targets are bypassed in my
CMake scripts.

- I still struggled with the backslash vs forward slash path issues in
a few places. Generally speaking, I found it better to convert all
backslashes to forward slashes because backslashes kept triggering
escape sequences in CMake. However, this technique broke in some
places, like where I need to invoke a task in Groovy, but I was
reading values passed (and converted) from CMake. So I had to convert
back to backslashes in some cases.

This whole thing took more time to set up than Mac + iOS + Linux +
Windows combined. But it works so I'm relieved.

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


Re: [CMake] What do Visual Studio users do so they can run/debug their programs when using 3rd party .dlls?

2014-06-11 Thread Eric Wing
Thanks everybody for the answers. I finally got it working more or
less to my satisfaction by writing it manually.

Mike, I grabbed some of your install stuff. Thanks for that.

J Decker, thanks for reminding me about CMAKE_CFG_INTDIR. I knew about
it, but it's easy to forget. (That's why I didn't want to have to
write this...too much detail work)

Jean-Christophe Fillion-Robin: The launcher stuff I've never heard of
before. I'm going to have to look at that in more detail. Thanks.

Klaim - Joël Lamotte, I pretty much agree with all the stuff you
listed. And I agree the install step doesn't make a lot of sense,
particularly when you need to launch/run via the Visual Studio
debugger. Unfortunately, I can't use Python, so I had to write it in
CMake. I agree the installer is useful for building a package, but I
see these two things as different. Additionally, the installer stuff
is becoming increasingly dated as everything is moving towards
iOS-like app stores that have very different packaging semantics.


I'm building a fairly elaborate system using CMake targeting
developers, not end consumers of apps. However, these are not
traditional native code developers and thus I'm trying to make the
CMake user experience much friendlier. I think I should do a
post-mortem once I'm done because a lot of areas like this I think can
be improved.

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://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Mac @loader_path for @rpath questions

2014-06-11 Thread Eric Wing
On 5/24/14, clin...@elemtech.com clin...@elemtech.com wrote:


 - Original Message -
 I have a bunch of libraries and frameworks that properly use @rpath.
 Now I am trying to build an application that uses those library and
 frameworks via CMake.

 From this blog:
 http://www.kitware.com/blog/home/post/510
 I see I am supposed to do:
 set(CMAKE_MACOSX_RPATH 1)

 The above should be set before declaring an @rpath target, which is one that
 has an install name with @rpath.

Okay, the ordering was one thing I screwed up. That was a major reason
it didn't work for me.




 Setting CMAKE_BUILD_WITH_INSTALL_RPATH should have an effect, if set before
 any targets that link with the @rpath libraries.
 Can you provide an example of what you are doing, so we can find out why its
 not working for you?

That was my ordering screw up. It's working now.


 I understand drag-and-drop, but it doesn't work for my situations.  I have
 several 3rd party libraries that are not in system locations, and are not
 part of the build tree, so setting CMAKE_BUILD_WITH_INSTALL_RPATH breaks my
 builds.  Install time is where I get a complete .app bundle.

So 3rd party libraries should be bundled in the .app. This avoids that
problem. Notice that a real/native Xcode project always does this copy
phase. I have this working for my stuff now with CMake using some
aggressive code I wrote. (Similar to the Visual Studio thread I was
in.)


 With a list.
 set_target_properties(bar PROPERTIES INSTALL_RPATH
  @loader_path/../Frameworks;@loader_path/../lib)

Didn't think of that. Thanks that worked.



 3) What is the common way people copy their frameworks into their .app
 bundle now-a-days?

 I do it at install time by setting the install destination to be inside the
 .app bundle.

Incidentally, I found BundleUtilities/fix_up_bundle, but it seems to
break if you use @rpath. It doesn't seem to do build time, but install
time, which is another problem for me.


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://www.cmake.org/mailman/listinfo/cmake


[CMake] Cygwin drive paths are killing me

2014-06-11 Thread Eric Wing
I am currently in this unholy trinity of needing to use Android on
Windows through Cygwin.
Basically, the Android NDK requires Cygwin if you want to run it on
Windows. I'm using my fork of the Android-CMake toolchain originally
from OpenCV and trying to generate Unix Makefiles with CMake. I
provide a -C initial_cache list to try to pre-populate my dependency
list since this is a cross-compile.

This is really ugly stuff. I thought I was on the verge of finally
getting it working, but I keep bouncing back and forth between file
path problems:

- Cygwin returns absolute paths like /cygdrive/c/Program Files (x86)
- But CMake can't seem to resolve the /cygdrive/c part and when trying
to access files in this form, it fails with 'file not found'

If I change the representation to:
C:\Program Files (x86), then a lot of CMake functions seem to get
confused by the backslashes because they are escape sequences in
strings.

I figured out I can use forward slashes,
C:/Program Files (x86)
which helps the problem a little bit.

But sometimes when I change strings to make CMake happy, then if it
gets passed back to Cygwin to invoke some process, Cygwin dies.

I've been slowly going case by case to use one or the other. I finally
got my Makefiles generated. But now I gave the problem that the
Makefiles contain the C:\ form to get past CMake's problems. But when
I invoke make, Cygwin chokes with
*** target pattern contains no `%'
I think this is because of the colon characters in the make file from
the drive letters.


Also, I think there is a bug. CMake thinks strings like C:/Program
Files (x86) are relative paths, not absolute. Calling file(string ...)
keeps turning the path I pass into a relative path and prepends a full
relative path which makes the string turn into complete nonsense (I
get to drive letter markers in the string).


Anyway, am I overlooking something? I know Cygwin is supposed to work.
How am I supposed to deal with the /cygdrive/c vs C:\ and colon issue?

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://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Cygwin drive paths are killing me

2014-06-11 Thread Eric Wing
Thanks everybody for the replies.

- I am using the native CMake, not the cygwin one. I didn't realize
there was a difference. I'll try that and hope that works.

- The Android NDK page itself says Cygwin 1.7 is required. Maybe it is
BS, but I don't know.

Required development tools
* For Windows, Cygwin 1.7 or higher is required. The NDK will not
work with Cygwin 1.5 installations.

- I need the standalone toolchain because I never got the base NDK
to work with the android.toolchain.cmake after a certain NDK revision.
They have documentation on how to build and use it for Mac and Linux
but not Windows and it looks very Unix-y, so I assumed this was one of
the places that required Cygwin.

- Additionally, I need to build multiple architectures which CMake
doesn't know how to do, so I needed to wrap the entire (CMake) build
process in what turned out to be a fairly complex script in another
language, hence I made the problem worse since I needed this for
multiple platforms and don't know if I could port something this
complex to a .bat file.

- Furthermore, I'm building the full APK which means I need SDK
integration. After over a year fighting Ant/Eclipse and all the stupid
limitations it and the NDK have (e.g. the NDK_MODULE_PATH can't handle
any spaces which Google puts the blame on GNU Make for), I've
transitioned to Gradle/Android Studio. It turns out their NDK support
in Gradle/Android Studio is completely non-existent at this time, but
can be compensated for by writing some functions in your Gradle script
(via Groovy) code to execute processes (which is still less painful
than dealing with XML/Ant). I'm using this to invoke a script that
invokes make for each architecture I need to build in the NDK.

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://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Cygwin drive paths are killing me

2014-06-11 Thread Eric Wing
So I tried the Cygwin CMake, and while it allowed me to remove most of
my hacks, the final Makefile was still not usable because it appears
the standalone gcc wants a Windows path and not /cygdrive/.

So let's pretend I can do this without any Unix tools...

- Am I still generating Unix Makefiles?
- It looks like all the standalone tools like gcc may map correctly
- But how do I run 'make' to build? Are the make files generated
compatible with the GNUMake that ships with the NDK?

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://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Cygwin drive paths are killing me

2014-06-11 Thread Eric Wing
Yes, I will probably try MSYS next. Then I will see if I can remove
MSYS entirely. (Though I'll need to rewrite my helper script which is
mostly Perl.) I'll look into that standalone Make 3.8.1.

The helper script basically does the CMake generation 3 times
(armeabi, armeabi-v7a, x86). The script has conventions and smarts to
find my 3rd party libraries and where the per-arch subdirectories.
This sets variables which are passed to CMake and used in the -C
initial_cache so everything is automatically configured in one shot.

The other trick/pitfall is that CMake also manages the resources (to
make sure they get put in the right place to be bundled in the apk).
This has several tricky consequences...first, since CMake is run 3
times, each build instance reproduces (wastes) this work. This also
means there is a layer of indirection because there needs to be a
real common build directory that is shared/common to the
per-architecture build instance directories, so additional variables
are passed through CMake to alert these build stages where they need
to copy the assets too. Copying the libs also has to be aware of this
plus making sure to place it in the correct architecture subdirectory
to avoid clobbering.

There are additional details the build process needs to handle. The
goal is to make this almost turn-key/automatic, as if this is what
CMake should already be doing. (I do plan to share my scripts/results
once I'm done hoping we can figure out how to make CMake do all this
natively.) But this is why it's not quite so trivial.


I use the standalone toolchain because I couldn't get the
Android-CMake toolchain to work with the regular NDK. I was under the
impression it may have worked in r7 or maybe earlier, but it's now r9d
and that's a really long time ago (like over 10 releases).
Additionally, I am most on Mac, but need to support Mac, Linux, and
Windows. I think the existing toolchain did not understand Mac well.

Additionally, I had to audit it and a lot of the flags the chain was
passing did not match the real NDK, so I fixed most of them, but only
tested on the standalone since it was the only one working. Also, x86
was really weak or non-existent so I had to do a bunch of stuff for
that.

And I don't yet understand how the regular toolchain deals with the
different C++ standard libraries that can be selected. I have had to
interoperate with other prebuilt binaries and have been slammed hard
on all the C++ unstable/incompatible ABI issues which Android has made
into a minefield.

I would love to ditch the standalone toolchain, but unless I can get
one that actually works and that I can trust is doing the right thing,
I'm stuck. (I did try fixing it, but that is a really complicated
script.)


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://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] What do Visual Studio users do so they can run/debug their programs when using 3rd party .dlls?

2014-05-23 Thread Eric Wing
On 5/23/14, Dan Kegel d...@kegel.com wrote:
 You can add the directory containing the 3rd party DLLs to the global
 PATH environment variable, I bet.

So I'm looking for a CMake way to deal with this. I don't want to
change the system environment. My stuff is highly distributed among
lots of different people and systems, and I need to reproduce on VMs,
etc, and in some cases, I have conflicting versions of things across
multiple projects which would introduce a DLL hell so I just want a
work-out-of-the-box solution with CMake doing local copies.


 As for how to ship the Microsoft DLLs,
 http://msdn.microsoft.com/en-us/library/ms235299.aspx
 might be a good place to start reading?

I've read that. This is my goal which I want to do with CMake.
you can directly install redistributable Visual C++ DLLs in the
application local folder

I'm sick of Microsoft's DLL hell and the fact that they make you run
an installer (which needs admin permissions) instead of shipping with
the OS for the fundamental C and C++ runtimes is ridiculous.

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://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] What do Visual Studio users do so they can run/debug their programs when using 3rd party .dlls?

2014-05-23 Thread Eric Wing
On 5/23/14, Dan Kegel d...@kegel.com wrote:
 On Fri, May 23, 2014 at 4:38 PM, Eric Wing ewmail...@gmail.com wrote:
 On 5/23/14, Dan Kegel d...@kegel.com wrote:
 You can add the directory containing the 3rd party DLLs to the global
 PATH environment variable, I bet.

 ... I just want a
 work-out-of-the-box solution with CMake doing local copies.

 So... copy the DLLs to the same folder as your test app?

So that's what I think I want, unless there is a smarter way. (As I
said, changing the global environment isn't really a good option...a
local per-project setting would be cool though.) Since Visual Studio
can change these directories depending on the configuration, is there
a robust CMake way that most of the community already uses to solve
this?


 http://msdn.microsoft.com/en-us/library/ms235299.aspx
 I've read that. This is my goal which I want to do with CMake.
 you can directly install redistributable Visual C++ DLLs in the
 application local folder

 http://msdn.microsoft.com/en-us/library/dd293565.aspx is a bit more
 explicit.

Copy the appropriate MFC and C Run-Time (CRT) library files--for
example, for an x86 platform and Unicode support, copy mfc100u.dll and
msvcr100.dll from \Program Files\Microsoft Visual Studio
10.0\VC\redist\x86\--and then paste them in the \Release\ folder of
your MFC project.

So again, is there something that already exists that the CMake
community is using? Finding both the path to the Visual Studio version
you are using and the CMake/Visual Studio build directory (what if I
want MinSizeRel instead of Release) is going to be full of little
gotchas that I know I will screw up if I have to write everything from
scratch. I am kind of hoping there is already a pre-canned solution
CMake users are using since this is a common issue.

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://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] CMake for Android projects

2014-05-06 Thread Eric Wing
So I have 4 examples I actually tried to document.
These all use my fork/derivative of the Android-CMake toolchain, which
I believe comes from OpenCV. (It had grown stale with later NDKs and I
hit problems). All of these rely heavily on the external NDK module
system (NDK_MODULE_PATH).

The first and easiest (most self contained) is:
https://bitbucket.org/ewing/hello-android-almixer
This one invokes ant via shell scripts outside CMake.

I then recently got SDL building with CMake using the same techniques.
https://bitbucket.org/ewing/sdl_android_cleanup
This one doesn't invoke ant because it builds only a library. There
was actually an intermediate project I helped build after ALmixer that
this also drew from, JavaScriptCore, and I documented my procedure
here:
https://github.com/appcelerator/hyperloop/wiki/Building-JavaScriptCore-for-Android


Once you have SDL built, and you set your NDK_MODULE_PATH directly, I
have an Ant example and Gradle example. The ant one is just like
Hello-Android-ALmixer.
https://bitbucket.org/ewing/helloandroidsdl-ant
https://bitbucket.org/ewing/helloandroidsdl-gradle

The Gradle one is a lot of hacks. Google is ditching Ant/Eclipse for
Gradle/IntelliJ, but their NDK support is even worse in the latter
right now.

Again, once you leave the NDK, all these things live outside CMake. I
think it would be interesting to make CMake handle all of this, but I
can't visualize it yet. But I hope others might be able to build on my
work, like how I've built on Android-CMake.

An aside, I noticed Gradle is painfully slow. Depending on how one
does CMake integration, I'm not sure I want it. Just to invoke it and
for it to figure out no real work needs to be done is measured in
seconds for me.


Thanks,
Eric



On 5/6/14, J Decker d3c...@gmail.com wrote:
 This is a page on building to android; mostly it's about my library, but
 names can be replaced where required
 https://code.google.com/p/c-system-abstraction-component-gui/wiki/BuildingForAndroid

 I went wit the separate cmake projects because I end up with multiple
 android projects from the same libraries; but really it could be appended
 all-together


 On Tue, May 6, 2014 at 2:32 PM, Robert Dailey
 rcdailey.li...@gmail.comwrote:

 Well to be clear, the NDK libraries are compiled in eclipse after I
 generate eclipse makefiles in CMake. Ideally, I want the CMake script
 to also configure ant execution so that it builds java and links in
 the NDK libraries. You say just use the libraries, but I'm not sure
 what this looks like as far as CMake script is concerned.

 Also I think we're using the android glue stuff in our existing
 project, but I'm not really sure what android glue is or if it is
 relevant to the CMake setup.

 On Tue, May 6, 2014 at 2:45 PM, J Decker d3c...@gmail.com wrote:
  If you've built the sources into libs, you can just use the lib; my
 sources
  are much too complex of a tree for ndk to support to build as sources..
 
  The java sources are compiled at the 'ant debug/release' step... there
 is a
  step before that I do that is 'android.bat update project --target
  android-14 --path' which makes a few other files from the build.xml.
 
 
  On Tue, May 6, 2014 at 8:42 AM, Robert Dailey
  rcdailey.li...@gmail.com
  wrote:
 
  There is also the question of how to handle the NDK sources and
  integrate them into the eclipse workspace. For example, I believe NDK
  sources must be under the 'jni' directory, but they won't be
  structured that way in the source tree. So I'm not sure if the jni
  directory is required. I realize there's some reference material out
  there but I'm not sure what to pay attention to. Would be nice to get
  some overview steps that I can read along with the reference material
  so I know the order in which to look at things, essentially.
 
  On Tue, May 6, 2014 at 10:32 AM, Bill Hoffman
  bill.hoff...@kitware.com
 
  wrote:
   You can look at what we did for VES:
   http://www.kitware.com/blog/home/post/642
  
  
   -Bill
  
  
  
   --
  
   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://www.cmake.org/mailman/listinfo/cmake
  --
 
  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: 

Re: [CMake] Linking to Mac OS X frameworks

2014-04-17 Thread Eric Wing
On 4/17/14, Aggelos Kolaitis neoagge...@gmail.com wrote:
 Short: Is linking to Mac OS X frameworks with Xcode generator totally
 broken, or am I just doing something wrong?

 Long: I use CMake as the build system for my project[1], and I use
 this [2] module to find SDL2 in the user's system. find_library() opts
 for the SDL2.framework on Mac OS X, which is located (in my system) in
 /Library/Frameworks/SDL2.framework. In the cache, I can see the
 following entries:

 SDL2_INCLUDE_DIR: /Library/Frameworks/SDL2.framework/Headers
 SDL2_LIBRARY   : /Library/Frameworks/SDL2.framework;-framework Cocoa

 I can successfully generate the Xcode project, but during the build
 process, I get an error that 'SDL2: framework not found'. I have
 currently found two workarounds:

 1). Change SDL2_LIBRARY to point to the actual SDL2 library and not
 the framework:

 SDL2_LIBRARY: /Library/Frameworks/SDL2.framework/SDL2;-framework
 Cocoa

 2). Use the makefile generator. The error only occurs with Xcode.

 So what is wrong? I can't really test much more on a Mac OS X system
 (because I use a friend's Macbook for testing and he's away). This is
 CMake 2.8.12, downloaded from the CMake download page.

 Thanks in advance,
 Aggelos Kolaitis


I think there is a combination of some things broken in CMake and some
things broken with the FindSDL module.

We need a new module for SDL2. The trailing -framework Cocoa is a
reminder of old hacks that we used to do that I don't think are needed
any more. (And now that bundling all assets including frameworks, is
even more critical, trying to use SDL2_LIBRARY to list files that need
to be bundled won't work as long as it combines build flags with
files.)

The other problem I've seen is that Apple no longer automatically
searches /Library/Frameworks and ~/Library/Frameworks. You need to
specify the -F switch, i.e. -F/Library/Frameworks explicitly so the
compiler will see your SDL2.framework. I think this needs to be fixed
in CMake. (Ironically, I think we removed it a long time ago because
it used to cause problems when Apple automatically searched the
directory.)


Below is my new FindSDL2.cmake replacement. (A work in progress.)

find_path(SDL_INCLUDE_DIR NAMES SDL.h
PATH_SUFFIXES include/SDL2 include/SDL include
  DOC The SDL include directory
)

find_library(SDL_LIBRARY NAMES SDL2 sdl2 SDL sdl2 sdl-2.0
  DOC The SDL library
)

if(WIN32)
find_library(SDL_LIBRARY_MAIN NAMES SDL2main sdl2main
DOC The SDLmain library needed on some platforms when builing 
an
application (opposed to a library)
)
else()
set(SDL_LIBRARY_MAIN )
endif()


# handle the QUIETLY and REQUIRED arguments and set SDL_FOUND to TRUE if
# all listed variables are TRUE
include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(SDL
  REQUIRED_VARS SDL_LIBRARY SDL_INCLUDE_DIR
  VERSION_VAR SDL_VERSION_STRING)


-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://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Write CMakeLists in another programming language?

2014-04-04 Thread Eric Wing
On 4/3/14, Clark Wang dearv...@gmail.com wrote:
 I've been using cmake for some time but still I'm confused about the
 syntax. Following are 2 examples from me:

  - http://www.cmake.org/pipermail/cmake/2013-September/055924.html
  - http://www.cmake.org/pipermail/cmake/2013-October/056036.html

 Someone ever told me cmake 3.0 may do some language cleanup work to address
 this kind of problems but it did not happen. So my idea is can we use
 another programming language syntax to write the CMakeLists file. (For
 example, we can write CMakeLists in Tcl which is clean and simple.)

 I'm not a language expert. Just want to get some feedback from others.

 -clark


There was a very serious and long discussion about this back in 2007
which led to a little Lua experiment which had a lot of promise.
Unfortunately, the project never went anywhere because people like me
were too busy and didn't finish it. I dream of finishing it someday.
But the internet has archived a lot of the discussion. Here are some
links. (There are others not listed here.) The CMake mailing list
thread was pretty long so you'll be following it down for awhile.

http://lua-users.org/lists/lua-l/2008-02/msg00403.html
http://www.cmake.org/pipermail/cmake/2007-November/017971.html
http://www.cmake.org/Wiki/CMake:Experiments_With_Lua

-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://www.cmake.org/mailman/listinfo/cmake


  1   2   >