> 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
On 8/17/17, Alan W. Irwin wrote:
> On 2017-08-17 04:15-0700 Eric Wing wrote:
>
>> 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.
&g
> I must be lucky then, because just using macdeployqt copies all the
> dependencies for me and
> updates all the install paths correctly whether I use Qt's own build or
> brew's.
Yes you were.
There are actually multiple problems, not just one.
One problem is release management. Too often I've
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
> 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
> 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
On 8/16/17, Jean-Michaël Celerier wrote:
> @Eric Wing
>> I am not making a strong push for this, but I want to bring it up to
> at least get people thinking about this... I am disturbed by the size
> and complexity of Qt. My past experiences have not been good and I
> find it
On 8/15/17, Daniel Pfeifer wrote:
> Hi,
>
> With !977 merged, it is possible to base ccmake and cmake-gui on top of the
> cmake server.
> For demonstration, I copied the contents of the Source/CursesDialog
> directory and added a proxy implementation of the classes `cmake` and
> `cmState`. The res
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 Enfi
On 8/8/17, Brad King 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 dyna
On 8/7/17, Brad King wrote:
> On 08/05/2017 07:58 PM, Craig Scott wrote:
>> target_link_libraries(foo PRIVATE "-framework AppKit")
>>
>> Strangely, with the library quoted as above, the embedded space
>> is not escaped, leading to the (desirable but surprising) result
>
> Link flags starting i
On 8/5/17, Craig Scott wrote:
> I'm exploring the behaviour of target_link_libraries() where the library to
> be linked is an Apple framework. As part of this, I noticed that the
> following does not work:
>
> target_link_libraries(foo PRIVATE -framework AppKit)
>
>
> This fails because the link c
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
On 5/25/16, Harry Mallon wrote:
> I have quite a specific problem with find_path where
> "find_path(IOKIT_INCLUDE_DIR "IOKit/pci/IOPCIDevice.h")" returns
> "/System/Library/Frameworks/Kernel.framework/Headers/IOKit/pci" rather than
> "/System/Library/Frameworks/Kernel.framework/Headers/".
>
> It i
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
>>
>>If we're starting with support for a new language then we should
>>add it properly as a first-class language. Eric and Michael (in Cc)
>>have been working on this for Swift and C# recently. Likely there
>>is some overlap in design space.
>>
On 2/19/16, CHEVRIER, Marc wrote:
> I agree. The
On 2/9/16, Davy Durham wrote:
> I'll say that in my line of work, we still have to support OS X 10.6
> (just dropped 10.5 support) .. And we're doing this at Apple's own
> request/demand! It's not fun. I've had to hack tools around to get
> somewhat newer tool chains to continue to work, but it'
On 2/6/16, Gregor Jasny via cmake-developers wrote:
> Hello,
>
> I'd like to get your feedback on deprecating or dropping support for
> older Xcode versions. During changes on the Xcode generator it gets
> harder and harder to test against old and very old Xcode versions like 3
> and 4.
>
> Are th
On 2/4/16, Brad King 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:
>> '
Hi, I'm curious about this. Would you explain the difference between
the .msi and the installer? (I don't have a very good understanding of
Windows installers.) What are the trade-offs, if any? Was the old
installer using NSIS? What is the .msi using? Does this mean CPack can
build .msi now?
Thank
This has been an ongoing nuisance for me, so I thought I would finally
ask. Is there a way I can force soname versioning without modifying
everybody's CMake build scripts?
The main problem is Android. Using soname versioning on Android will
basically cause things to break at runtime. It would be n
On 1/29/16, Brad King wrote:
> On 01/25/2016 11:01 AM, Sam Spilsbury wrote:
>> Over the last two years I've been working on a new unit testing
>> framework for CMake. I started this project because I've been writing
>> some other fairly complex CMake modules and I kept making mistakes
>> which wou
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 l
On 1/20/16, Brad King 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 d
On 1/19/16, Brad King 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
>> he
On 1/15/16, Brad King 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
(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 switc
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_L
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 hea
> 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 C
>> 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
>
On 1/12/16, Brad King 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
> 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,
On 12/24/15, Eric Wing 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 t
> 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
Hi,
This is kind of a continuation of the thread “Adding Swift support to CMake”.
Now that Swift is officially open source and already available for
Linux, I started looking at the build process on Linux which I hope we
can figure out how to incorporate into the CMake Makefile generator.
To start
On 7/7/15, Brad King 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 th
On 6/29/15, Brad King 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 CMa
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 p
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 incre
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 allo
On 11/4/14, Gilles Khouzam 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 FA
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 w
On 10/31/14, Gilles Khouzam 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
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/
> Ideally a toolchain file should have only settings specific to
> the local machine where it will be used, such as the paths to
> staging prefixes where dependencies built for the target arch
> may be installed. All information that is general to the iOS
> platform should be in a module that come
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
On 9/23/14, Florent Castelli 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 co
On 3/28/14, Stephen Kelly 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
>>>
On 3/26/14, Stephen Kelly 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
>
On 3/21/14, Stephen Kelly wrote:
>
> Hi,
>
> I'd like it to be this easy to create an Android toolchain file:
>
> set(CMAKE_SYSTEM_NAME Android)
>
> set(ANDROID_SDK_ROOT "/home/stephen/android/android-sdk-linux/")
> set(ANDROID_NDK_ROOT "/home/stephen/android/android-ndk-r9/")
> set(ANDROID_ND
On 1/10/14, Stephen Kelly 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 wil
On 8/3/12, Doug wrote:
> Sorry, lots of talk. Tangibly I imagine something like this:
>
I recommend you skim the CMakeLua group for the old posts. (There
aren't that many.)
https://groups.google.com/forum/?fromgroups#!forum/cmakelua
If I recall, Peter Kümmel had some interesting ideas/code for
i
On 8/2/12, Doug wrote:
> I'm quite curious about the possibility of writing a lua binding for cmake.
>
> There are two possible ways to go:
>
> 1) Create a set of discrete lua bindings which actually invoke cmake
> itself.
>
> 2) Integrate lua into cmake itself.
>
Yes, there was a big long thread
On 7/26/11, Alexander Neundorf wrote:
> Hi,
>
> I just had a look at FindGIF.cmake and FindFreetype.cmake.
> Both have similar code:
>
> FIND_LIBRARY(GIF_LIBRARY
> NAMES ${POTENTIAL_GIF_LIBS}
> HINTS
> $ENV{GIF_DIR}
> PATH_SUFFIXES lib64 lib
> PATHS
> ~/Library/Frameworks
> /Library/
55 matches
Mail list logo
