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

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

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

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

Re: [cmake-developers] Future of ccmake and cmake-gui 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

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

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 experienc

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

On 8/15/17, Daniel Pfeifer wrote: > Hi, > > With !977 merged, it is possible to base ccmake and cmake-gui on top of the > cmake server. > For demonstration, I copied the contents of the Source/CursesDialog > directory and added a proxy implementation of the classes `cmake`

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

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

Re: [cmake-developers] Linking Apple frameworks

On 8/7/17, Brad King wrote: > On 08/05/2017 07:58 PM, Craig Scott wrote: >> target_link_libraries(foo PRIVATE "-framework AppKit") >> >> Strangely, with the library quoted as above, the embedded space >> is not escaped, leading to the (desirable but surprising) result >

Re: [cmake-developers] Linking Apple frameworks

On 8/5/17, Craig Scott wrote: > I'm exploring the behaviour of target_link_libraries() where the library to > be linked is an Apple framework. As part of this, I noticed that the > following does not work: > > target_link_libraries(foo PRIVATE -framework AppKit) > > >

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

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

On 5/25/16, Harry Mallon wrote: > I have quite a specific problem with find_path where > "find_path(IOKIT_INCLUDE_DIR "IOKit/pci/IOPCIDevice.h")" returns > "/System/Library/Frameworks/Kernel.framework/Headers/IOKit/pci" rather than >

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

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

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

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

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

On 2/6/16, Gregor Jasny via cmake-developers wrote: > Hello, > > I'd like to get your feedback on deprecating or dropping support for > older Xcode versions. During changes on the Xcode generator it gets > harder and harder to test against old and very old Xcode

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 co

Re: [cmake-developers] [ANNOUNCE] cmake-unit - A new unit testing framework for CMake

On 1/29/16, Brad King wrote: > On 01/25/2016 11:01 AM, Sam Spilsbury wrote: >> Over the last two years I've been working on a new unit testing >> framework for CMake. I started this project because I've been writing >> some other fairly complex CMake modules and I kept

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

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

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

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 y

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

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

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

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 &

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

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 >

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,

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

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

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

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

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

[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

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

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

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

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:

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

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,

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

On 3/28/14, Stephen Kelly steve...@gmail.com wrote: Eric Wing wrote: I expect so, but knowing what the needs are helps inform what those changes might look like. http://public.kitware.com/Bug/view.php?id=14539 I'm not sure either. I recall an old thread about this That thread

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

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

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

On 3/21/14, Stephen Kelly steve...@gmail.com wrote: Hi, I'd like it to be this easy to create an Android toolchain file: set(CMAKE_SYSTEM_NAME Android) set(ANDROID_SDK_ROOT /home/stephen/android/android-sdk-linux/) set(ANDROID_NDK_ROOT /home/stephen/android/android-ndk-r9/)

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

On 1/10/14, Stephen Kelly steve...@gmail.com wrote: Vince Harron wrote: Android.mk files allow you to target multiple processor architectures/variants in one make invocation without any reconfiguring or multiple build folders. All of those binaries are embedded into one fat apk file that

Re: [cmake-developers] lua bindings?

On 8/3/12, Doug douglas.lin...@gmail.com wrote: Sorry, lots of talk. Tangibly I imagine something like this: I recommend you skim the CMakeLua group for the old posts. (There aren't that many.) https://groups.google.com/forum/?fromgroups#!forum/cmakelua If I recall, Peter Kümmel had some

Re: [cmake-developers] lua bindings?

On 8/2/12, Doug douglas.lin...@gmail.com wrote: I'm quite curious about the possibility of writing a lua binding for cmake. There are two possible ways to go: 1) Create a set of discrete lua bindings which actually invoke cmake itself. 2) Integrate lua into cmake itself. Yes, there was a