[CMake] Mac Xcode 11 Generator bug/problem with CODE_SIGN_IDENTITY default
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
On 5/20/18, Shawn Gwrote: > 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?
On 4/5/18, Robert Maynardwrote: > 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?
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?
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
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
> 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
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
> 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
> 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
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
On 8/15/17, Daniel Pfeiferwrote: > 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
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 Enficiaudwrote: > 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
On 8/8/17, Jom O'Fisherwrote: > 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
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
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
On 8/7/17, Brad Kingwrote: > 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
On 8/5/17, Craig Scottwrote: > 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)
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)
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?
On 9/7/16, David Colewrote: > 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?
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
On 7/12/16, Harry Mallonwrote: > 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
On 6/5/16, Bill Somervillewrote: > 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
On 5/25/16, Harry Mallonwrote: > 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
On 4/6/16, iosif neitzkewrote: > 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
On 4/4/16, Nicholas Bradenwrote: > 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
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
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
On 3/7/16, David Colewrote: > 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
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
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
>> >>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, Marcwrote: > 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)
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?
On 2/9/16, Davy Durhamwrote: > 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?
On 2/6/16, Gregor Jasny via cmake-developerswrote: > 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?
On 2/6/16, Gregor Jasny via cmake-developerswrote: > 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
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
On 1/29/16, Brad Kingwrote: > 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
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
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
On 1/21/16, David Morsbergerwrote: > 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
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
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
On 1/19/16, David Morsbergerwrote: > 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
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
(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
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
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
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
> 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
>> 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
> 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
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
> 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
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?
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
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
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
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
* 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
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
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?
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?
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
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
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
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
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
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
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?
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?
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!
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!
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!
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
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!
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?
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!
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!
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
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
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)
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?
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?
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?
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
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
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?
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
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
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
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
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
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?
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?
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
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
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?
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