From brad.king at kitware.com Tue Aug 1 16:29:39 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 1 Aug 2017 16:29:39 -0400 Subject: [cmake-developers] UseSWIG and enable_language(Java) In-Reply-To: References: Message-ID: <663d4aa1-505e-e221-778e-b8daed4a7a60@kitware.com> On 07/26/2017 06:02 AM, Alan W. Irwin wrote: > enable_language(Java) FWIW this language support is quite limited, is not well tested, and has long been superseded by `UseJava.cmake`. I suggest porting away from it in PLplot. That will fix this too. > 62c4cb4b6f0cdb2be2729362133f850d6fe96c20 is the first bad commit > UseSWIG: Record generated java files as custom command outputs Hmm. That causes swig_add_library's call to add_library to include the generated .java source file as a source (since it is the output of a custom command we want to run). However, with `enable_language(Java)` CMake thinks it is supposed to compile the .java file as part of the (module) library. That's why it looks for CMAKE_Java_CREATE_SHARED_MODULE. Please try the patch below. -Brad diff --git a/Modules/UseSWIG.cmake b/Modules/UseSWIG.cmake index 456a6bd63d..48d6a5b4af 100644 --- a/Modules/UseSWIG.cmake +++ b/Modules/UseSWIG.cmake @@ -121,8 +121,9 @@ macro(SWIG_GET_EXTRA_OUTPUT_FILES language outfiles generatedpath infile) endif() foreach(it ${SWIG_${language}_EXTRA_FILE_EXTENSIONS}) - set(${outfiles} ${${outfiles}} - "${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}${it}") + set(extra_file "${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}${it}") + list(APPEND ${outfiles} ${extra_file}) + set_property(SOURCE "${extra_file}" PROPERTY LANGUAGE "") endforeach() endmacro() From brad.king at kitware.com Tue Aug 1 16:42:24 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 1 Aug 2017 16:42:24 -0400 Subject: [cmake-developers] Module macros/function names with single leading underscore In-Reply-To: References: Message-ID: On 07/23/2017 10:20 AM, Craig Scott wrote: > maybe it's worth considering renaming these single underscore > internal macros and functions? Projects that rely on the undocumented feature depend on being able to call the original function by prepending the single underscore. We can't change the renaming convention without breaking them. Even a policy for this may be tricky due to function definitions being visible globally and therefore skipping across policy scopes. The infinite recursion case you mentioned has long been known and may have a few issue tracker entries. We haven't really dealt with it because the feature is undocumented and meant for debugging. If anyone can come up with a compatible fix (e.g. explicit diagnostic) that would be great. Side note: One day I'd like to see a policy that changes function/macro definition scopes to be directory-based. I haven't thought about the correctness or side-effects of that in detail though. -Brad From irwin at beluga.phys.uvic.ca Tue Aug 1 21:53:42 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 1 Aug 2017 18:53:42 -0700 (PDT) Subject: [cmake-developers] UseSWIG and enable_language(Java) In-Reply-To: <663d4aa1-505e-e221-778e-b8daed4a7a60@kitware.com> References: <663d4aa1-505e-e221-778e-b8daed4a7a60@kitware.com> Message-ID: On 2017-08-01 16:29-0400 Brad King wrote: > On 07/26/2017 06:02 AM, Alan W. Irwin wrote: > [...] >> 62c4cb4b6f0cdb2be2729362133f850d6fe96c20 is the first bad commit >> UseSWIG: Record generated java files as custom command outputs > > Hmm. That causes swig_add_library's call to add_library to include > the generated .java source file as a source (since it is the > output of a custom command we want to run). > > However, with `enable_language(Java)` CMake thinks it is supposed > to compile the .java file as part of the (module) library. That's > why it looks for CMAKE_Java_CREATE_SHARED_MODULE. > > Please try the patch below. > > > diff --git a/Modules/UseSWIG.cmake b/Modules/UseSWIG.cmake > index 456a6bd63d..48d6a5b4af 100644 > --- a/Modules/UseSWIG.cmake > +++ b/Modules/UseSWIG.cmake > @@ -121,8 +121,9 @@ macro(SWIG_GET_EXTRA_OUTPUT_FILES language outfiles generatedpath infile) > > endif() > foreach(it ${SWIG_${language}_EXTRA_FILE_EXTENSIONS}) > - set(${outfiles} ${${outfiles}} > - "${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}${it}") > + set(extra_file "${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}${it}") > + list(APPEND ${outfiles} ${extra_file}) > + set_property(SOURCE "${extra_file}" PROPERTY LANGUAGE "") > endforeach() > endmacro() Hi Brad: Thanks for your response. Yes, that patch works for PLplot. In particular, our multiple sets of ~30 standard examples written in Python, Java, and ~10 other languages produce the same PostScript plot files as the corresponding set of standard examples written in C. So that is a pretty good test. Furthermore, if I am understanding its logic correctly this patch empties the LANGUAGE property for these extra Java and Python files to force these files NOT to be compiled (which would make no sense in any case because swig-generated bindings are implemented as C or C++ modules). That forcing is actually not needed in the Python case because Python is a scripting language, but that forcing is needed for Java precisely because that language can be compiled. So my understanding of the purpose of this patch is consistent with my experience (our Python binding works regardless of whether this patch is applied or not and our Java binding only works when the patch is applied). However, if I got something wrong in this explanation of the patch, please correct! Assuming you are going to commit this patch is it something that needs further extensive testing or will it go into one of the CMake-3.9.x releases? Second related topic: [out of order] >> enable_language(Java) > > FWIW this language support is quite limited, is not well tested, > and has long been superseded by `UseJava.cmake`. I suggest porting > away from it in PLplot. Let me give you some additional PLplot use case background information before commenting on your suggestion. I haven't been paying much attention to the java-related part of our build system since it was almost entirely implemented a decade ago and normally it has "just worked" during that time. But a quick review of it now indicates it is quite primitive (probably because of the limited CMake Java support a decade ago). It uses ${CMAKE_Java_COMPILER} (which is set to /usr/bin/javac for my current system) in a custom command to compile *.java files into *.class files for both our Java binding and Java examples. Collecting all those binding and examples *.class results into a jar file using ${CMAKE_Java_ARCHIVE} (which is set to /usr/bin/jar for my current system) is an afterthought. Apparently, both CMAKE_Java_COMPILER and CMAKE_Java_ARCHIVE are determined when our build system executes "enable_language(Java)". So that command is required at the moment. But I think we are only using its find capabilities so we could simply drop using it and substitute instead the appropriate find commands to find the needed javac and jar directly or call find_package(Java) to do the same. So that is likely what I will implement in the short term to avoid any other issues with the poorly supported "enable_language(Java)" command. It also appears from the UseJava.cmake documentation, that that module allows us to build our jar file directly, thus allowing replacement of all those primitive custom commands. But making that change appears to be quite a bit of work, and there is no urgency for switching since we have the above alternative. But if the required CMake code is truly at lot higher level and therefore more compact, then we should consider trying this suggestion in the long term, although see below. Different, but related third topic: PLplot developers might want to implement an option to use gcj directly without the -C option (rather than its javac wrapper which always uses the gcj -C option) to compile our *.java files into ordinary machine object code that is stored in an ordinary library. Of course, modifying our present primitive approach to do that should be entirely straightforward. But it appears UseJava.cmake does not support such machine code capability which is a possible strike against that approach from our perspective. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From brad.king at kitware.com Wed Aug 2 11:55:11 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 2 Aug 2017 11:55:11 -0400 Subject: [cmake-developers] UseSWIG and enable_language(Java) In-Reply-To: References: <663d4aa1-505e-e221-778e-b8daed4a7a60@kitware.com> Message-ID: <53339892-680e-8ed2-27d4-ee20ffb7fe8b@kitware.com> On 08/01/2017 09:53 PM, Alan W. Irwin wrote: > Yes, that patch works for PLplot. Great, thanks for testing. > Assuming you are going to commit this patch is it something that > needs further extensive testing or will it go into one of the > CMake-3.9.x releases? Yes: https://gitlab.kitware.com/cmake/cmake/merge_requests/1095 -Brad From jeanmichael.celerier at gmail.com Wed Aug 2 19:13:33 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Thu, 3 Aug 2017 01:13:33 +0200 Subject: [cmake-developers] Module macros/function names with single leading underscore In-Reply-To: References: Message-ID: > It's probably going to be an uncommon situation https://www.google.fr/search?q="macro(_"+site%3A%3Ahttps%3A%2F%2Fgithub.com A lot are namespaced but skimming a bit through the result, there is also stuff like *_*INTERNAL_PARSE_FLAGS_ARGS, *_*fixup_target, *_*LSB_RELEASE, *_*plugin_target_name which may be at risk for the problem you're exposing. Best, ------- Jean-Micha?l Celerier http://www.jcelerier.name On Tue, Aug 1, 2017 at 10:42 PM, Brad King wrote: > On 07/23/2017 10:20 AM, Craig Scott wrote: > > maybe it's worth considering renaming these single underscore > > internal macros and functions? > > Projects that rely on the undocumented feature depend on being > able to call the original function by prepending the single > underscore. We can't change the renaming convention without > breaking them. Even a policy for this may be tricky due to > function definitions being visible globally and therefore > skipping across policy scopes. > > The infinite recursion case you mentioned has long been known > and may have a few issue tracker entries. We haven't really > dealt with it because the feature is undocumented and meant > for debugging. If anyone can come up with a compatible fix > (e.g. explicit diagnostic) that would be great. > > Side note: One day I'd like to see a policy that changes > function/macro definition scopes to be directory-based. > I haven't thought about the correctness or side-effects of > that in detail though. > > -Brad > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sat Aug 5 19:58:22 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 6 Aug 2017 09:58:22 +1000 Subject: [cmake-developers] Linking Apple frameworks Message-ID: 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?* 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. This is mentioned in the find_library() docs: If the library found is a framework, then will be set to the full > path to the framework /A.framework. When a full path to a > framework is used as a library, CMake will use a -framework A, and a > -F to link the framework to the target. > So it is clear why the find_library() approach works, but the behaviour of directly specifying the framework without find_library() seems somewhat surprising. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Sat Aug 5 23:15:49 2017 From: ewmailing at gmail.com (Eric Wing) Date: Sat, 5 Aug 2017 20:15:49 -0700 Subject: [cmake-developers] Linking Apple frameworks In-Reply-To: References: Message-ID: On 8/5/17, Craig Scott wrote: > I'm exploring the behaviour of target_link_libraries() where the library to > be linked is an Apple framework. As part of this, I noticed that the > following does not work: > > target_link_libraries(foo PRIVATE -framework AppKit) > > > This fails because the link command ends up with -framework -lAppKit > instead of -framework AppKit. Maybe that's expected, but then the following > DOES work: > > target_link_libraries(foo PRIVATE "-framework AppKit") > > > Strangely, with the library quoted as above, the embedded space is not > escaped, leading to the (desirable but surprising) result -framework AppKit > in > the linker command line (i.e. the space isn't escaped and the two words are > not quoted). *Which of these is the correct way (if either) and are both > behaving as expected?* I would argue both of the above are incorrect. For some history, people passing explicit flags (e.g. -l and -L) was the exact problem we fought in the first place many years ago. Most people's scripts wouldn't work when porting to Mac because they weren't using the CMake abstractions to inform CMake was going on, but instead bypassing them by setting flags explicitly. So when brought to Mac, things didn't necessarily work because there were a bunch of explicit flags written in the scripts (including the Find*.cmake scripts.) (There was actually a similar problem when porting to Visual Studio too.) Then when Apple brought (back) Universal binaries for Intel and then 64-bit, the flags needed to handle the build process got more complicated. People passing their own flags at the wrong place could cause problems. (A similar problem occurred as Apple pushed the SDK model.) Then (when not talking about system supplied frameworks), when iOS came, they forbidded dynamic linking for the longest time, so everything had to be as static libraries. So -framework flags would not work. Obeying the normal CMake abstractions prevents problems here too since it knows what to do for static libraries vs. frameworks. And I would argue this is still wrong today because CMake will have a harder time understanding there is a library involved here because you didn't declare it with find_library. Particularly with the Xcode generator, this information is very useful because the information isn't always explicitly passed down to a command line invocation. Sometimes it needs to be declarative so for the Xcode recognizes that a framework is involved and allows Xcode to handle the correct behavior. Already there exists a problem in the Xcode generator that it doesn't completely use all the framework and library built-in mechanisms, and this is currently causing me problems for apps that need to be codesigned. Xcode has a copy-frameworks-and-codessign phase which CMake does not use. I hope this can be fixed, but I suspect it would never work with the above two approaches you are asking about. -Eric From ivamprettimn at gmail.com Sun Aug 6 16:52:13 2017 From: ivamprettimn at gmail.com (Ivam Pretti) Date: Sun, 6 Aug 2017 17:52:13 -0300 Subject: [cmake-developers] C++ IDE Message-ID: Can you recomend an IDE to code in C/C++? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Sun Aug 6 16:57:40 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sun, 06 Aug 2017 22:57:40 +0200 Subject: [cmake-developers] C++ IDE In-Reply-To: References: Message-ID: <5670422.vUE5rY7Ezz@daneel.sf-tec.de> Am Sonntag, 6. August 2017, 17:52:13 schrieb Ivam Pretti: > Can you recomend an IDE to code in C/C++? KDevelop. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From konstantin at podsvirov.pro Sun Aug 6 18:42:33 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Mon, 07 Aug 2017 01:42:33 +0300 Subject: [cmake-developers] [ISSUES 17125] CPackIFW doesn't work properly on OSX Message-ID: <299581502059353@web7j.yandex.ru> An HTML attachment was scrubbed... URL: From konstantin at podsvirov.pro Sun Aug 6 19:11:15 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Mon, 07 Aug 2017 02:11:15 +0300 Subject: [cmake-developers] [ISSUES 17125] CPackIFW doesn't work properly on OSX In-Reply-To: <299581502059353@web7j.yandex.ru> References: <299581502059353@web7j.yandex.ru> Message-ID: <101331502061075@web8j.yandex.ru> Hello dear CMake developers! Interested in your opinion and the proposal to issue settings CPack generator. https://gitlab.kitware.com/cmake/cmake/issues/17125 As it turned out CPack IFW generator capable of creating output in different formats, and it's not only files but also folders. PS: Removed unnecessary formatting. Regards, Konstantin Podsvirov From jeanmichael.celerier at gmail.com Mon Aug 7 04:20:32 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Mon, 7 Aug 2017 10:20:32 +0200 Subject: [cmake-developers] C++ IDE In-Reply-To: <5670422.vUE5rY7Ezz@daneel.sf-tec.de> References: <5670422.vUE5rY7Ezz@daneel.sf-tec.de> Message-ID: QtCreator is nice. ------- Jean-Micha?l Celerier http://www.jcelerier.name On Sun, Aug 6, 2017 at 10:57 PM, Rolf Eike Beer wrote: > Am Sonntag, 6. August 2017, 17:52:13 schrieb Ivam Pretti: > > Can you recomend an IDE to code in C/C++? > > KDevelop. > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Aug 7 09:34:26 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 7 Aug 2017 09:34:26 -0400 Subject: [cmake-developers] Linking Apple frameworks In-Reply-To: References: Message-ID: 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 From ewmailing at gmail.com Mon Aug 7 17:27:17 2017 From: ewmailing at gmail.com (Eric Wing) Date: Mon, 7 Aug 2017 14:27:17 -0700 Subject: [cmake-developers] Linking Apple frameworks In-Reply-To: References: Message-ID: On 8/7/17, Brad King wrote: > On 08/05/2017 07:58 PM, Craig Scott wrote: >> target_link_libraries(foo PRIVATE "-framework AppKit") >> >> Strangely, with the library quoted as above, the embedded space >> is not escaped, leading to the (desirable but surprising) result > > Link flags starting in `-` are treated as a raw part of the command > line. That's how it evolved historically. > >> As extra context, a correct final linker command line can also be achieved >> like this: >> >> find_library(APPKIT_LIB AppKit) >> target_link_libraries(foo PRIVATE ${APPKIT_LIB}) >> >> In this case, while APPKIT_LIB contains a full absolute path to the >> framework, CMake manages to recognise it as a framework and shortens >> the linker flags to just -framework AppKit. > > There is special case logic for this, but IMO it was a mistake. > Ideally when find_library finds a framework library it should > return the absolute path to the library file within the framework, > e.g. `/path/to/foo.framework/foo`. Then no special logic would > be needed to recognize it and the library file can be passed > directly on link lines. All the Modules/Find*.cmake modules > that provide imported targets have special logic to transform > the find_library result in this way. Perhaps we should fix this > with a policy. > > Also the points raised in Eric Wing's response are valid concerns. > > -Brad I think that would be a mistake because it seems that the only purpose of this change would be so you could bypass CMake and try to directly invoke some kind of command line invocation on the dynamic library inside the .framework bundle. This seems to encourage the wrong kind of behavior and there is almost no real world use case in the native Apple world where you should ever do that (I can contrive a couple in my head for iOS but they are esoteric cases.). In general, you should be treating the framework bundle as a whole because all parts of it are designed to be useful. The bundle assets like any .nib files and the Info.plist are sometimes critical components of the framework. So things like copying the whole framework and embedding them in the app bundle are important things to do. And I mentioned the current problem of codesigning an app bundle. But right now, getting the path to the entire framework is more useful so you can at least manually do these things with CMake. Changing that would only complicate this process in that now you have to play guessing games on what the framework?s internal layout looks like. (Mac and iOS differ, and there are esoteric corner cases if you have to deal with a framework that ships multiple versions.) (And you can imagine this kind of change will break a ton of my scripts that currently do all this missing steps.) But if you did decide to change this, I think it should only happen in conjunction of solving the rest of the needed functionality for dealing with frameworks, i.e. copying the entire framework bundle into the app bundle, codesigning the framework in the app bundle, and using the built in Xcode functionality for this with the Xcode generator. Also making this a little easier to automatically setup in CMake would be welcome, and could include things like setting the @rpath on the frameworks and install_name on the app as part of the process (since these things always go together with bundling the framework). And possibly some mechanism that can handle create fat binaries for deploying an iOS framework but including stripping the simulator architectures for a release app. A slight tangent, but kind of related example of the problem is Android?s new AAR library bundle format. AAR is still horribly broken and incomplete when it comes to the NDK side (and by looking at the current rate of progress may never get fixed), but does solve some serious problems for Android libraries in general so I?m starting to find they are unfortunately the best solution despite the PITA they are. AARs share some concepts of the .framework in that they are container packages that contain a lot of different important components beyond just the dynamic library stub your native code needs to link to. Two of the most important features is that it can merge the R.java resource system and the AndroidManifest.xml that the library declares it needs to use into your final app. (The way Android works, all this stuff must be put directly into your app and libraries don?t officially get their own notion of these things. This makes integrating/using any library a PITA on Android, so AAR finally starts automating this process.) But of course the consequence is that once again, we have an alien library format that CMake doesn?t know how to deal with yet. I think CMake can eventually be taught, but it requires that users not be making too many direct assumptions about the build and linking process, and especially direct invocations of flags. (And another slight tangent?I?m still working on the Swift/CMake support. I have the basics for apps working on both Makefiles and Ninja, but the next step is I need to do a massive overhaul for module support which I fear is going to require non-trivial internal changes to CMake. I haven?t worked out all the details yet, but I think it is likely I will have to deal with frameworks and I suspect I?m going to have to deal with more than just the dynamic library inside of it.) Thanks, Eric From raffi.enficiaud at mines-paris.org Tue Aug 8 08:08:50 2017 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Tue, 8 Aug 2017 14:08:50 +0200 Subject: [cmake-developers] iOS: direction to official support and questions Message-ID: Hi CMake ML, I am quite new to the topic of making toolchain files. However I need to build a not so trivial application for iOS and I want to do it with CMake, and if possible walk toward an official support of iOS in CMake. I have looked a bit to the Android toolchains, and I have to say I found those quite complicated as a first reading :) The target application I am building uses Qt and Boost. So far, I have managed to have an IOS toolchain file that is generating a looking good XCode project, that I can compile properly (up until signing). I can share the toolchain file: it is a collection of things I have found on the internet, but trimmed from what I think was not necessary. It is still in a not so nice state, but I am currently cleaning it. There are things that I think are weird though: * I need to have: ``` set(CMAKE_FIND_ROOT_PATH ${CMAKE_IOS_DEVELOPER_ROOT} ${CMAKE_IOS_SDK_ROOT} ${CMAKE_PREFIX_PATH} /path/to/boost_1_64_0_build/install CACHE string "iOS find search path root") ``` 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_SYSTEM_FRAMEWORK_PATH ${CMAKE_IOS_SDK_ROOT}/System/Library/Frameworks ${CMAKE_IOS_SDK_ROOT}/System/Library/PrivateFrameworks ${CMAKE_IOS_SDK_ROOT}/Developer/Library/Frameworks ) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) ``` this looks ok to me, as we are cross compiling. Is this a problem of FindBoost, or the combinations of the options that are not ok? * I need to add: ``` set(CMAKE_MACOSX_BUNDLE YES) set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED "NO") ``` and this comes from https://public.kitware.com/Bug/view.php?id=15329 . 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. Some people made a workaround by short-cutting the compiler checks, which is to me a wrong direction to take. As mentioned in this ticket, the right solution would be that the try_compile commands not to require signing of the binaries (or sthg similar). This is explained here: http://public.kitware.com/Bug/view.php?id=12288 * is this one https://cmake.org/Bug/view.php?id=12640 addressed? * I am seeing exchanges concerning the IOS_INSTALL_COMBINED. Does this has something to do with toolchain? What is meant by "installation" in this case? Sorry for my naive question, but I do not understand the workflow very well. * how can I have unit tests of the toolchain in a CI fashion. Ideally, I would like to have a target cross-compiled with this toolchain, and then running the iPhoneSimulator, and check the result (return code, process, command whatever). Does anyone have experience with this? Thanks, Raffi From brad.king at kitware.com Tue Aug 8 09:08:24 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 8 Aug 2017 09:08:24 -0400 Subject: [cmake-developers] Linking Apple frameworks In-Reply-To: References: Message-ID: 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 From ewmailing at gmail.com Tue Aug 8 20:10:01 2017 From: ewmailing at gmail.com (Eric Wing) Date: Tue, 8 Aug 2017 17:10:01 -0700 Subject: [cmake-developers] Linking Apple frameworks In-Reply-To: References: Message-ID: 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 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 From wesley.hoke at gmail.com Thu Aug 10 00:38:44 2017 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed, 9 Aug 2017 21:38:44 -0700 Subject: [cmake-developers] C++ IDE In-Reply-To: References: Message-ID: I have been really impressed with VSCode . On Sun, Aug 6, 2017 at 1:52 PM, Ivam Pretti wrote: > Can you recomend an IDE to code in C/C++? > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Aug 10 11:04:57 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Aug 2017 11:04:57 -0400 Subject: [cmake-developers] iOS: direction to official support and questions In-Reply-To: References: Message-ID: <8ca578c0-5e58-a0b7-b563-4577d39a1085@kitware.com> 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 :) This note may help: https://gitlab.kitware.com/cmake/cmake/issues/16708#note_300971 I don't think iOS will need all the toolchain and stl selection logic. Ideally CMake would gain iOS platform modules such that one could set CMAKE_SYSTEM_NAME to `iOS`. > set(CMAKE_FIND_ROOT_PATH > ${CMAKE_IOS_DEVELOPER_ROOT} > ${CMAKE_IOS_SDK_ROOT} > ${CMAKE_PREFIX_PATH} > /path/to/boost_1_64_0_build/install > CACHE string "iOS find search path root") > ``` > > 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. > set(CMAKE_MACOSX_BUNDLE YES) Is it possible to build any binary of any form on iOS without this? If not then the iOS platform modules should set something to tell the generators that this should always be enabled. > set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED "NO") Similarly for this, but perhaps only during `try_compile`. I'm not familiar enough with iOS development to answer the rest of your questions. -Brad From robert.maynard at kitware.com Thu Aug 10 12:17:35 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 10 Aug 2017 12:17:35 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.9.1 available for download Message-ID: We are pleased to announce that CMake 3.9.1 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ * The "find_" command "PACKAGE_ROOT" search path group added by CMake 3.9.0 has been removed for the 3.9 series due to regressions caused by new use of "_ROOT" variables. The behavior may be re-introduced in the future in a more-compatible way. Thanks for your support! ------------------------------------------------------------------------- Changes in 3.9.1 since 3.9.0: Bj?rn Esser (2): Utilities/Sphinx: Restore compatibility with Sphinx pre-1.2 Help: Silence warning about document not included in toctree Brad King (8): UseSWIG: Fix when Java is enabled as a language VS: Fix VCTargetsPath detection Android: Fix support for CMAKE_SYSROOT without CMAKE_SYSROOT_COMPILE expat: Update script to get Expat 2.2.3 expat: Update CMake build for 2.2.3 Tests: Simplify RunCMake.find_package PackageRoot case regexes find_*: Disable the PACKAGE_ROOT search path group for CMake 3.9 CMake 3.9.1 Chuck Atkins (3): find_package: Add missing PACKAGE_ROOT_PATH search path implementation. find_package: Fix PACKAGE_ROOT test to check find_pacakge(CONFIG) mode. find_package: Split PACKAGE_ROOT tests to work with smaller regex Craig Scott (1): FindJava: Allow early access version trailing string to be mixed case Cristian Adam (1): FindBoost: pop policy stack before returning Expat Upstream (1): expat 2017-08-02 (97c6bd01) Laurent Rineau (1): server: Fix crash on missing cache entries Rechi Rechi (1): FindJava: fix hint for windows jre 1.6 Ruslan Baratov (1): Help: Fix module and function names in CMP0069 examples Sebastian Holtermann (1): Autogen: Always create AUTOMOC/AUTOUIC include directory From khirniy1991 at gmail.com Fri Aug 11 03:18:11 2017 From: khirniy1991 at gmail.com (=?UTF-8?B?0JLQsNC70LXQvdGC0LjQvSDQpdC40YDQvdGL0Lk=?=) Date: Fri, 11 Aug 2017 10:18:11 +0300 Subject: [cmake-developers] Developing Compiler files. Message-ID: Hello. I've tried to prepare cmake configuration file for Embarcadero bcc64 compiler. For my practice I chose the name Embarcadero64 for new compiler because bcc64 is clang based compiler. I've prepared file fo determining compiler in the ...\CMake\share\cmake-3.9\Modules\Compiler folder (analog of theEmbarcadero-DetermineCompiler.cmake) Then added my new compiler in an orderedcompilerlis in the CMakeCompilerIdDetection.cmake. And finally I created the Windows-Embarcadero64.cmake, Windows-Embarcadero64-C.cmake end Windows-Embarcadero64-CXX.cmake And get a lot of troubles with variables. Please share some links to usefull resources about containing of files in the ...\CMake\share\cmake-3.9\Modules\Platform\. Thanks. Best regards. Valentyn -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Aug 11 08:39:00 2017 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Aug 2017 08:39:00 -0400 Subject: [cmake-developers] Developing Compiler files. In-Reply-To: References: Message-ID: On 08/11/2017 03:18 AM, ???????? ?????? wrote: > I've tried to prepare cmake configuration file for Embarcadero bcc64 compiler. > For my practice I chose the name Embarcadero64 for new compiler because > bcc64 is clang based compiler. Does `bcc64` have a radically different command line interface from `bcc32` that justifies a separate compiler id? I don't think we have a distinction in compiler id based on the target architecture for any other compiler. Thanks, -Brad From khirniy1991 at gmail.com Fri Aug 11 10:22:18 2017 From: khirniy1991 at gmail.com (=?UTF-8?B?0JLQsNC70LXQvdGC0LjQvSDQpdC40YDQvdGL0Lk=?=) Date: Fri, 11 Aug 2017 17:22:18 +0300 Subject: [cmake-developers] Developing Compiler files. In-Reply-To: References: Message-ID: Hello. Yes, the bcc32 is provided by Borland and has Borland options and the bcc64 provided by Embarcadero and it is clang based and has Clang options but with old linker. The bcc32c is provided by Embarcadero and it is clang based but has Borland options wrapper. Actually I don't interested in Embarcadero itself but in content of files placed in the .../Modules/Platform folder. And search some usefully info about the cmake options passed to compiler and linker. Also I have tryed to find some info about this files but haven't found anything about them. Please share some links or docs if you have. Thanks. Valentyn. On Aug 11, 2017 15:39, "Brad King" wrote: > On 08/11/2017 03:18 AM, ???????? ?????? wrote: > > I've tried to prepare cmake configuration file for Embarcadero bcc64 > compiler. > > For my practice I chose the name Embarcadero64 for new compiler because > > bcc64 is clang based compiler. > > Does `bcc64` have a radically different command line interface from `bcc32` > that justifies a separate compiler id? I don't think we have a distinction > in compiler id based on the target architecture for any other compiler. > > Thanks, > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffi.enficiaud at mines-paris.org Sun Aug 13 11:36:29 2017 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Sun, 13 Aug 2017 17:36:29 +0200 Subject: [cmake-developers] Passing lists with generator expression through add_custom_command Message-ID: Hi CMake ML, I have a small issue concerning the way generator expressions are resolved when calling another process. Suppose I have this set(ALL_DEPENDENCIES_FILES) foreach(_device IN LISTS ALL_DEVICES) list(APPEND ALL_DEPENDENCIES_FILES $) endforeach() that creates a list containing generator expressions for locating a target, and then I use this list as an argument to execute process: add_custom_command( TARGET my_target POST_BUILD COMMAND ${CMAKE_COMMAND} -DAPPFOLDER=$/../.. -DBOOST_FOLDER="${BOOST_LIB_PATH}" -DQT_BIN_DIR="${QT_BIN_PATH}" -DQML_DIR="${CMAKE_SOURCE_DIR}" -DDEPLOY_LIB_DIR="${CMAKE_RUNTIME_OUTPUT_DIRECTORY}" -DALL_DEPENDENCIES="${ALL_DEPENDENCIES_FILES}" -P ${CMAKE_SOURCE_DIR}/cmake/osx_bundle.cmake) when I trace the content of ALL_DEPENDENCIES_FILES at the location where the add_custom_command happens, I have this: message(STATUS "ALL_DEPENDENCIES_FILES CALL '${ALL_DEPENDENCIES_FILES}'") gives ALL_DEPENDENCIES_FILES CALL '$;$' which indicates that this is a proper list, where each element is separated by ";". However, inside the called script osx_bundle.cmake, I see the target location resolved but separated with a space: message(STATUS "ALL_DEPENDENCIES: '${ALL_DEPENDENCIES}'") gives: ALL_DEPENDENCIES: '/Users/raffi/Code/my_target/build_make/bin/libmock_emotiv.dylib /Users/raffi/Code/my_target/build_make/bin/libeeg_lsl.dylib' Why does the list loose its type when passing to the second cmake script through 'add_custom_command' ? Thanks! Raffi From craig.scott at crascit.com Mon Aug 14 06:09:17 2017 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 14 Aug 2017 20:09:17 +1000 Subject: [cmake-developers] Fwd: [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: References: Message-ID: Devs, It shouldn't be an issue having non-static Qt libs linked to cmake-gui, but as reported on the CMake users mailing list, it can be a problem when the directory cmake-gui is in is on the PATH. If CMake's bin directory appears on the PATH, the Qt DLL's bundled with it can take precedence over other applications' own Qt DLLs. The cmake and ccmake executables have a reasonable case for being on the PATH, but cmake-gui is typically going to be started via a desktop or menu icon and doesn't really need to be on the PATH. Rather than forcing static Qt libs to be used (I'm not aware of the reason for the change from static to dynamic Qt libs), we could instead move cmake-gui out of the bin directory so that it isn't in the same directory as the cmake and ccmake executables. This top level directory should never be added to the PATH, so it would resolve problems like the above. It is not unusual for the main executable to be in the top level directory of an installation rather than in a bin subdirectory. What do people think of moving cmake-gui and the Qt DLL's up to the top level? This may just be for Windows, other platforms could stay as they are now. Would obviously have to adjust not just the install location but also any internal code that tries to work out where other files are located relative to the cmake-gui executable. Things like the qt.conf file would also probably need some adjustment. Thoughts? ---------- Forwarded message ---------- From: Craig Scott Date: Mon, Aug 14, 2017 at 7:47 PM Subject: Re: [CMake] cmake-gui on windows and qt5 dlls To: Christian Ehrlicher Cc: CMake This is a common problem, not just with CMake. I'm wondering if there's any real need for cmake-gui to be on the PATH at all, since it will usually be invoked by a desktop or menu icon. At the moment though, it is in the same directory as the cmake and ccmake executables which have a much stronger case for being on the PATH. There's a reasonable argument that cmake-gui should be in a different directory, then it wouldn't be an issue if shared Qt libs were used rather than static. I'll bring this up on the developer mailing list and see what discussions yield. On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher wrote: > Hi, > > I recently upgraded from cmake 3.3 to 3.9 on windows and got some problems > during my build because it looks like the pre-compile binaries for windows > are now shipping Qt5 - dlls instead static compile libs (since 3.5 afaics). > The problem is, that I had the path to cmake *before* the path to my own > Qt5 libaries. So during the build / run of my application, the wrong > libraries were loaded and I got a symbol lookup error. > Would it be possible to use the static Qt5 libs instead or maybe prefix > the Qt5 libs shipped with cmake-gui somehow? > > Thx, > Christian > > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia https://crascit.com -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ianmalcom at gmail.com Mon Aug 14 06:35:38 2017 From: ianmalcom at gmail.com (Manu) Date: Mon, 14 Aug 2017 12:35:38 +0200 Subject: [cmake-developers] Windows symbolic links handling Message-ID: Hello, Recently I migrated from cmake 2.8.12 to cmake 3.8 and FILE(TIMESTAMP ...) behaviour changed. Now it reports symbolic link timestamp instead of pointed file timestamp. Looking through CMake documentation, it seems I could workaround this issue using the command get_filename_component which documentation states there is a parameter that seems to fix my problem: REALPATH = Full path to existing file with symlinks resolved However, it does not resolves symlinks under Windows. I am working on a patch to fix both get_filename_compoment and FILE(TIMESTAMP ...) and make their behaviour consistent among architectures (under unix systems symlinks are resolve in the refered commands). What troubles me is that symlink under Windows is a feature introduced in Windows Vista and the change for handling them will break Windows XP compatibility. Is this acceptable? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Aug 14 09:18:35 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 14 Aug 2017 09:18:35 -0400 Subject: [cmake-developers] Fwd: [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: References: Message-ID: <20170814131835.GA2910@megas.kitware.com> On Mon, Aug 14, 2017 at 20:09:17 +1000, Craig Scott wrote: > It shouldn't be an issue having non-static Qt libs linked to cmake-gui, but > as reported on the CMake users mailing list, it can be a problem when the > directory cmake-gui is in is on the PATH. If CMake's bin directory appears > on the PATH, the Qt DLL's bundled with it can take precedence over other > applications' own Qt DLLs. The cmake and ccmake executables have a > reasonable case for being on the PATH, but cmake-gui is typically going to > be started via a desktop or menu icon and doesn't really need to be on the > PATH. > > Rather than forcing static Qt libs to be used (I'm not aware of the reason > for the change from static to dynamic Qt libs), we could instead move > cmake-gui out of the bin directory so that it isn't in the same directory > as the cmake and ccmake executables. This top level directory should never > be added to the PATH, so it would resolve problems like the above. It is > not unusual for the main executable to be in the top level directory of an > installation rather than in a bin subdirectory. What do people think of > moving cmake-gui and the Qt DLL's up to the top level? This may just be for > Windows, other platforms could stay as they are now. Would obviously have > to adjust not just the install location but also any internal code that > tries to work out where other files are located relative to the cmake-gui > executable. Things like the qt.conf file would also probably need some > adjustment. > > Thoughts? Git splits it between bin/ and cmd/ where cmd/ is meant to be in PATH. Then the structure doesn't need to change either. --Ben From konstantin at podsvirov.pro Mon Aug 14 16:22:25 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Mon, 14 Aug 2017 23:22:25 +0300 Subject: [cmake-developers] Fwd: [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: <20170814131835.GA2910@megas.kitware.com> References: <20170814131835.GA2910@megas.kitware.com> Message-ID: <885571502742145@web16g.yandex.ru> 14.08.2017, 16:18, "Ben Boeckel" : > On Mon, Aug 14, 2017 at 20:09:17 +1000, Craig Scott wrote: >> ?It shouldn't be an issue having non-static Qt libs linked to cmake-gui, but >> ?as reported on the CMake users mailing list, it can be a problem when the >> ?directory cmake-gui is in is on the PATH. If CMake's bin directory appears >> ?on the PATH, the Qt DLL's bundled with it can take precedence over other >> ?applications' own Qt DLLs. The cmake and ccmake executables have a >> ?reasonable case for being on the PATH, but cmake-gui is typically going to >> ?be started via a desktop or menu icon and doesn't really need to be on the >> ?PATH. >> >> ?Rather than forcing static Qt libs to be used (I'm not aware of the reason >> ?for the change from static to dynamic Qt libs), we could instead move >> ?cmake-gui out of the bin directory so that it isn't in the same directory >> ?as the cmake and ccmake executables. This top level directory should never >> ?be added to the PATH, so it would resolve problems like the above. It is >> ?not unusual for the main executable to be in the top level directory of an >> ?installation rather than in a bin subdirectory. What do people think of >> ?moving cmake-gui and the Qt DLL's up to the top level? This may just be for >> ?Windows, other platforms could stay as they are now. Would obviously have >> ?to adjust not just the install location but also any internal code that >> ?tries to work out where other files are located relative to the cmake-gui >> ?executable. Things like the qt.conf file would also probably need some >> ?adjustment. >> >> ?Thoughts? > > Git splits it between bin/ and cmd/ where cmd/ is meant to be in PATH. > Then the structure doesn't need to change either. +1 Add script (.bat) to `cmd` subfolder to invoke tools from `bin` on Windows (and add to PATH variable if needed). > --Ben > -- > > 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 Regards, Konstantin Podsvirov From brad.king at kitware.com Tue Aug 15 10:39:28 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 15 Aug 2017 10:39:28 -0400 Subject: [cmake-developers] Fwd: [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: <885571502742145@web16g.yandex.ru> References: <20170814131835.GA2910@megas.kitware.com> <885571502742145@web16g.yandex.ru> Message-ID: On 08/14/2017 04:22 PM, Konstantin Podsvirov wrote: > 14.08.2017, 16:18, "Ben Boeckel" : >> On Mon, Aug 14, 2017 at 20:09:17 +1000, Craig Scott wrote: >>> moving cmake-gui and the Qt DLL's up to the top level? This may just be for >>> Windows, other platforms could stay as they are now. Would obviously have >>> to adjust not just the install location but also any internal code that >>> tries to work out where other files are located relative to the cmake-gui >>> executable. Things like the qt.conf file would also probably need some >>> adjustment. >> >> Git splits it between bin/ and cmd/ where cmd/ is meant to be in PATH. >> Then the structure doesn't need to change either. > > +1 Add script (.bat) to `cmd` subfolder to invoke tools from `bin` > on Windows (and add to PATH variable if needed). One could move `cmake-gui.exe` and `*.dll` files to some other out-of-the-way location and then have `bin/cmake-gui.exe` be a launcher that sets up the environment and runs the real `cmake-gui.exe`. -Brad From brad.king at kitware.com Tue Aug 15 10:43:19 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 15 Aug 2017 10:43:19 -0400 Subject: [cmake-developers] Windows symbolic links handling In-Reply-To: References: Message-ID: On 08/14/2017 06:35 AM, Manu wrote: > Recently I migrated from cmake 2.8.12 to cmake 3.8 and FILE(TIMESTAMP ...) > behaviour changed. Now it reports symbolic link timestamp instead of pointed > file timestamp. Can you track down when that happened? > patch to fix both get_filename_compoment and FILE(TIMESTAMP ...) > > What troubles me is that symlink under Windows is a feature introduced in > Windows Vista and the change for handling them will break Windows XP > compatibility. Is this acceptable? We still support running on XP. If any newer Windows APIs are needed they need to be looked up dynamically. Also, behavior changes for existing commands may need a policy. See also https://gitlab.kitware.com/cmake/cmake/issues/16926 for discussion of symbolic link APIs. -Brad From brad.king at kitware.com Tue Aug 15 10:48:52 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 15 Aug 2017 10:48:52 -0400 Subject: [cmake-developers] Passing lists with generator expression through add_custom_command In-Reply-To: References: Message-ID: <2acce5ff-0c5b-11e8-7ce6-778fdb7aedf8@kitware.com> On 08/13/2017 11:36 AM, Raffi Enficiaud wrote: > -DALL_DEPENDENCIES="${ALL_DEPENDENCIES_FILES}" That is actually an unquoted argument whose value contains literal quotes. See the cmake-language(7) manual for details on the syntax. Switch it to "-DALL_DEPENDENCIES=${ALL_DEPENDENCIES_FILES}" to quote the argument so that add_custom_command receives it unexpanded. Then use the VERBATIM option to add_custom_command to make sure it is re-escaped for the shell properly. -Brad From raffi.enficiaud at mines-paris.org Tue Aug 15 10:50:07 2017 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Tue, 15 Aug 2017 16:50:07 +0200 Subject: [cmake-developers] Passing lists with generator expression through add_custom_command In-Reply-To: <2acce5ff-0c5b-11e8-7ce6-778fdb7aedf8@kitware.com> References: <2acce5ff-0c5b-11e8-7ce6-778fdb7aedf8@kitware.com> Message-ID: Le 15.08.17 ? 16:48, Brad King a ?crit : > On 08/13/2017 11:36 AM, Raffi Enficiaud wrote: >> -DALL_DEPENDENCIES="${ALL_DEPENDENCIES_FILES}" > > That is actually an unquoted argument whose value contains literal quotes. > See the cmake-language(7) manual for details on the syntax. Switch it to > > "-DALL_DEPENDENCIES=${ALL_DEPENDENCIES_FILES}" > > to quote the argument so that add_custom_command receives it unexpanded. > Then use the VERBATIM option to add_custom_command to make sure it is > re-escaped for the shell properly. > > -Brad > Ahh, thanks! and sorry for the noise! Raffi From daniel at pfeifer-mail.de Tue Aug 15 16:33:04 2017 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Tue, 15 Aug 2017 22:33:04 +0200 Subject: [cmake-developers] Future of ccmake and cmake-gui Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffi.enficiaud at mines-paris.org Tue Aug 15 20:45:21 2017 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Wed, 16 Aug 2017 02:45:21 +0200 Subject: [cmake-developers] iOS: direction to official support and questions In-Reply-To: <8ca578c0-5e58-a0b7-b563-4577d39a1085@kitware.com> References: <8ca578c0-5e58-a0b7-b563-4577d39a1085@kitware.com> Message-ID: 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 :) > > This note may help: > > https://gitlab.kitware.com/cmake/cmake/issues/16708#note_300971 Hi, Thanks for the link and the answers! > I don't think iOS will need all the toolchain and stl selection logic. > > Ideally CMake would gain iOS platform modules such that one could > set CMAKE_SYSTEM_NAME to `iOS`. > >> set(CMAKE_FIND_ROOT_PATH >> ${CMAKE_IOS_DEVELOPER_ROOT} >> ${CMAKE_IOS_SDK_ROOT} >> ${CMAKE_PREFIX_PATH} >> /path/to/boost_1_64_0_build/install >> CACHE string "iOS find search path root") >> ``` >> >> 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. > >> 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. > If not then the iOS platform modules should set something to tell > the generators that this should always be enabled. > >> set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED "NO") > > Similarly for this, but perhaps only during `try_compile`. What I understand from this variable is that, it sets the default of CODE_SIGNING_REQUIRED to "NO", and this can be overriden per target by setting the XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED target property to something else. Is that correct? I believe that for iOS developments, the default should rather be the opposite, and the try_compile should be informed of not trying to sign the app, via "some mechanism" as you suggested. Concerning this "some mechanism" part, what do you have in mind? Would it be an extra variable like CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED_IN_TRY_COMPILE ? What I fail to understand here, is the purpose of the "try_compile" that is performed at the beginning. Isn't this try_compile supposed to compile source files only, without trying to link nor bundle anything? If this is the case, signing the result is irrelevant, and I do not understand why this fails. If you have an idea, good, otherwise I believe this is secondary right now. > I'm not familiar enough with iOS development to answer the rest of > your questions. Me neither :) 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. The switching means changing the target architecture, as well as changing the SYSROOT. I checked the command lines emitted by XCode, and it changes the "-isysroot" flag based on the type of target. From the posts I can read online, this is causing a lot of troubles, especially when linking with libraries. For users' libraries, the workaround is to have fat libraries by combining all the target archs into one with lipo. The compilation is done with different "-isysroot" then. What I understood is that Apple is discouraging this, and this is for me not a proper solution neither, but might work. The real problem seems to be when linking to system libraries, those that are under sysroot, and I cannot find a good answer to this. Example: Suppose in the toolchain file, we have something like this, where CMAKE_IOS_SDK_ROOT depends on the fact that we use the simulator or not: ''' set(CMAKE_FIND_ROOT_PATH ${CMAKE_IOS_DEVELOPER_ROOT} ${CMAKE_IOS_SDK_ROOT} ${CMAKE_PREFIX_PATH} /some/other/path CACHE string "iOS find search path root") # set up the default search directories for frameworks set (CMAKE_SYSTEM_FRAMEWORK_PATH ${CMAKE_IOS_SDK_ROOT}/System/Library/Frameworks ${CMAKE_IOS_SDK_ROOT}/System/Library/PrivateFrameworks ${CMAKE_IOS_SDK_ROOT}/Developer/Library/Frameworks ) ''' and later in our CMakeLists, we have eg. ''' find_package(ZLIB REQUIRED) ''' The selection of the SYSROOT is done then on the cmd line given to CMake, and set up once. The library that is found by ZLIB are related to CMAKE_IOS_SDK_ROOT, that is a constant in a build tree. Although Xcode can reroot the SYSROOT depending on the target device/arch (simulator/non-simulator). Even if later XCode is able to switch sysroots on the command line, depending on the target, the libraries we are linking to are constant, and not honoring the dynamically determined sysroot anymore. I believe this problem is going beyond XCode itself, as eg. Visual starts integrating more technologies (Xamarin, Android, Arduino, etc) to their IDE, and at some point the developers will want to use a simulator for those developments. My current concerns are about the design of CMake. Do you think the current design of CMake can possibly address this issue nicely, or the only possibilities are workarounds? * The fact that we have nice generator expressions can be used to change the location of external libraries (and the overall link interface) on the fly. I believe that might be used, we need to intercept the IDE variable that encodes the current target, and we might be able to use that variable jointly with the generator expressions. * can we teach find_package/find_library to look for all similar libraries in a set of sysroots? taking back the same example of find_package(ZLIB), if I have, several sysroots: CMAKE_FIND_ROOT_PATH_IOS = /sysroot/1 CMAKE_FIND_ROOT_PATH_IOS_SIMULATOR = /sysroot/2 and a new variable listing all the target platforms: CMAKE_SYSROOT_NAMES = "IOS;IOS_SIMULATOR" I can think of a mechanism that teaches find_library to look for the same library in all of those SYSROOTS. Concerning the variable sent by the IDE and that might encode the current target, we have for instance this as a prelude to the compilation shell script: * for iPhone SDK export PATH="/Applications/Xcode8.1.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode8.1.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin" * for iPhoneSimulatorSDK: export PATH="/Applications/Xcode8.1.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode8.1.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin" That is a poor solution for finding out for what current target platform we are compiling, and I hope it would be possible to retrieve the current ZLIB library we should link to based on $PATH. But I do not know if generator expressions are that flexible. This happens right before the compiler is executed, and cmake cannot be involved or called there. I am not even sure that we can modify the scripts that XCode generate for compilation. As you can see, those problems are not that Xcode or iOS specific, and maybe there is an elegant solution already in place, but I cannot find any. Thanks, Raffi From craig.scott at crascit.com Tue Aug 15 21:00:36 2017 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 16 Aug 2017 11:00:36 +1000 Subject: [cmake-developers] iOS: direction to official support and questions In-Reply-To: References: <8ca578c0-5e58-a0b7-b563-4577d39a1085@kitware.com> Message-ID: There's discussions related to problems with linking and multiple architectures in the following recent thread too: http://public.kitware.com/pipermail/cmake-developers/2017-August/030192.html Eric highlights a number of similar issues to those you've mentioned. Have a read through the whole thread to get a deeper understanding, but it sounds like you're already familiar with at least some of the problems. On Wed, Aug 16, 2017 at 10:45 AM, Raffi Enficiaud < raffi.enficiaud at mines-paris.org> wrote: > Le 10.08.17 ? 17:04, Brad King a ?crit : > >> On 08/08/2017 08:08 AM, Raffi Enficiaud wrote: >> >>> I have looked a bit to the Android toolchains, and I have to say I found >>> those quite complicated as a first reading :) >>> >> >> This note may help: >> >> https://gitlab.kitware.com/cmake/cmake/issues/16708#note_300971 >> > > Hi, > Thanks for the link and the answers! > > > I don't think iOS will need all the toolchain and stl selection logic. >> >> Ideally CMake would gain iOS platform modules such that one could >> set CMAKE_SYSTEM_NAME to `iOS`. >> >> set(CMAKE_FIND_ROOT_PATH >>> ${CMAKE_IOS_DEVELOPER_ROOT} >>> ${CMAKE_IOS_SDK_ROOT} >>> ${CMAKE_PREFIX_PATH} >>> /path/to/boost_1_64_0_build/install >>> CACHE string "iOS find search path root") >>> ``` >>> >>> 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. >> >> 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. > > If not then the iOS platform modules should set something to tell >> the generators that this should always be enabled. >> >> set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED "NO") >>> >> >> Similarly for this, but perhaps only during `try_compile`. >> > > What I understand from this variable is that, it sets the default of > CODE_SIGNING_REQUIRED to "NO", and this can be overriden per target by > setting the XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED target property to > something else. > > Is that correct? > > I believe that for iOS developments, the default should rather be the > opposite, and the try_compile should be informed of not trying to sign the > app, via "some mechanism" as you suggested. > > Concerning this "some mechanism" part, what do you have in mind? Would it > be an extra variable like CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED_IN_TRY_COMPILE > ? > > What I fail to understand here, is the purpose of the "try_compile" that > is performed at the beginning. Isn't this try_compile supposed to compile > source files only, without trying to link nor bundle anything? If this is > the case, signing the result is irrelevant, and I do not understand why > this fails. > > If you have an idea, good, otherwise I believe this is secondary right now. > > I'm not familiar enough with iOS development to answer the rest of >> your questions. >> > > Me neither :) > > 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. > > The switching means changing the target architecture, as well as changing > the SYSROOT. I checked the command lines emitted by XCode, and it changes > the "-isysroot" flag based on the type of target. > > From the posts I can read online, this is causing a lot of troubles, > especially when linking with libraries. > > For users' libraries, the workaround is to have fat libraries by combining > all the target archs into one with lipo. The compilation is done with > different "-isysroot" then. What I understood is that Apple is discouraging > this, and this is for me not a proper solution neither, but might work. > > The real problem seems to be when linking to system libraries, those that > are under sysroot, and I cannot find a good answer to this. > > Example: > > Suppose in the toolchain file, we have something like this, where > CMAKE_IOS_SDK_ROOT depends on the fact that we use the simulator or not: > > ''' > set(CMAKE_FIND_ROOT_PATH > ${CMAKE_IOS_DEVELOPER_ROOT} > ${CMAKE_IOS_SDK_ROOT} > ${CMAKE_PREFIX_PATH} > /some/other/path > CACHE string "iOS find search path root") > > # set up the default search directories for frameworks > set (CMAKE_SYSTEM_FRAMEWORK_PATH > ${CMAKE_IOS_SDK_ROOT}/System/Library/Frameworks > ${CMAKE_IOS_SDK_ROOT}/System/Library/PrivateFrameworks > ${CMAKE_IOS_SDK_ROOT}/Developer/Library/Frameworks > ) > ''' > > and later in our CMakeLists, we have eg. > > ''' > find_package(ZLIB REQUIRED) > ''' > > The selection of the SYSROOT is done then on the cmd line given to CMake, > and set up once. > > The library that is found by ZLIB are related to CMAKE_IOS_SDK_ROOT, that > is a constant in a build tree. Although Xcode can reroot the SYSROOT > depending on the target device/arch (simulator/non-simulator). > > Even if later XCode is able to switch sysroots on the command line, > depending on the target, the libraries we are linking to are constant, and > not honoring the dynamically determined sysroot anymore. > > I believe this problem is going beyond XCode itself, as eg. Visual starts > integrating more technologies (Xamarin, Android, Arduino, etc) to their > IDE, and at some point the developers will want to use a simulator for > those developments. > > My current concerns are about the design of CMake. Do you think the > current design of CMake can possibly address this issue nicely, or the only > possibilities are workarounds? > > * The fact that we have nice generator expressions can be used to > change the location of external libraries (and the overall link > interface) on the fly. I believe that might be used, we need to > intercept the IDE variable that encodes the current target, and > we might be able to use that variable jointly with the generator > expressions. > * can we teach find_package/find_library to look for all > similar libraries in a set of sysroots? taking back the same > example of find_package(ZLIB), if I have, several sysroots: > > CMAKE_FIND_ROOT_PATH_IOS = /sysroot/1 > CMAKE_FIND_ROOT_PATH_IOS_SIMULATOR = /sysroot/2 > > and a new variable listing all the target platforms: > > CMAKE_SYSROOT_NAMES = "IOS;IOS_SIMULATOR" > > I can think of a mechanism that teaches find_library to look > for the same library in all of those SYSROOTS. > > > Concerning the variable sent by the IDE and that might encode the current > target, we have for instance this as a prelude to the compilation shell > script: > > * for iPhone SDK > export PATH="/Applications/Xcode8.1.app/Contents/Developer/Platform > s/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode8. > 1.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/ > bin:/usr/sbin:/sbin" > > * for iPhoneSimulatorSDK: > export PATH="/Applications/Xcode8.1.app/Contents/Developer/Platform > s/iPhoneSimulator.platform/Developer/usr/bin:/Application > s/Xcode8.1.app/Contents/Developer/usr/bin:/usr/local/ > bin:/usr/bin:/bin:/usr/sbin:/sbin" > > That is a poor solution for finding out for what current target platform > we are compiling, and I hope it would be possible to retrieve the current > ZLIB library we should link to based on $PATH. But I do not know if > generator expressions are that flexible. This happens right before the > compiler is executed, and cmake cannot be involved or called there. I am > not even sure that we can modify the scripts that XCode generate for > compilation. > > As you can see, those problems are not that Xcode or iOS specific, and > maybe there is an elegant solution already in place, but I cannot find any. > > Thanks, > Raffi > > > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ianmalcom at gmail.com Wed Aug 16 05:35:18 2017 From: ianmalcom at gmail.com (Manu) Date: Wed, 16 Aug 2017 11:35:18 +0200 Subject: [cmake-developers] Windows symbolic links handling In-Reply-To: References: Message-ID: 2017-08-15 16:43 GMT+02:00 Brad King : > On 08/14/2017 06:35 AM, Manu wrote: > > Recently I migrated from cmake 2.8.12 to cmake 3.8 and FILE(TIMESTAMP > ...) > > behaviour changed. Now it reports symbolic link timestamp instead of > pointed > > file timestamp. > > Can you track down when that happened? > > I happened in release 3.1.0, back 2014. The commit which changed behaviour was this: https://github.com/Kitware/CMake/commit/9571214e55cb8b86dadb26b6b1d696ef488bdd4b In source file Source/cmTimestamp.cxx, stat call was replaced by kwsys ModifiedTime call. kwsys relies in system function GetFileAttributesExW which do not resolve symlinks, however stat does (in spite of not being documentented in MSDN). Removing the #ifdef WIN32 clause in ModifiedTime and using stat call resolves the problem, nevertheless, this change does not resolves get_filename_compoment symlinks issue in Windows. The problem here is again in kwsys, which uses system call GetFullPathNameW (which do not resolves symlinks) instead of GetFinalPathNameByHandleW (which does). Despite of being two different commands, I think they are very related in this issue and the change should be make together. > > patch to fix both get_filename_compoment and FILE(TIMESTAMP ...) > > > > What troubles me is that symlink under Windows is a feature introduced in > > Windows Vista and the change for handling them will break Windows XP > > compatibility. Is this acceptable? > > We still support running on XP. If any newer Windows APIs are needed they > need to be looked up dynamically. Also, behavior changes for existing > commands > may need a policy. > > I did not dig into cmake policies development but I am willing to submit a patch which includes a new policy as soon I can piece it up all together. > See also https://gitlab.kitware.com/cmake/cmake/issues/16926 for > discussion > of symbolic link APIs. > > -Brad > Manuel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Wed Aug 16 10:27:45 2017 From: ewmailing at gmail.com (Eric Wing) Date: Wed, 16 Aug 2017 07:27:45 -0700 Subject: [cmake-developers] iOS: direction to official support and questions In-Reply-To: References: <8ca578c0-5e58-a0b7-b563-4577d39a1085@kitware.com> Message-ID: I've been using a derivative of the iOS toolchain for many years that you probably can find easily with a Google search. It has a lot of shortcomings, but it generally works. And most of the shortcomings I think are only solvable by properly fixing/modifying the CMake core. On 8/15/17, Raffi Enficiaud wrote: > Le 10.08.17 ? 17:04, Brad King a ?crit : >> On 08/08/2017 08:08 AM, Raffi Enficiaud wrote: >>> I have looked a bit to the Android toolchains, and I have to say I found >>> those quite complicated as a first reading :) >> I personally think the Android toolchain is way more complicated than the iOS toolchain. Among the reasons are that every NDK release broke something different as they kept changing the compiler and conventions (the gcc to clang move was the most recent biggie, but old-timers might remember the standalone toolchain difficulties.). Then you have to pick different API levels because the each NDK release ships a separate API subtarget for all prior versions of Android. Then add all the multiple architectures (mips, arm, x86, 64-bit) and the subvariants (armv5, armv7, armv7+NEON, etc), 4 different C++ standard libraries you have to choose from, and other nuisances like Android on Windows...makes the whole thing a mess. >> Ideally CMake would gain iOS platform modules such that one could >> set CMAKE_SYSTEM_NAME to `iOS`. >>> where this path is hard coded, and points to the fat static libraries >>> prefix path of boost. If I remove this path, FindBoost does not find the >>> boost libraries anymore (of course I am passing BOOST_ROOT). In >>> addition, I have this: >>> >>> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY) >>> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) >>> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) >> >> These last three lines tell the find commands to only look at >> paths re-rooted under CMAKE_FIND_ROOT_PATH and CMAKE_SYSROOT. >> If boost is not under one of those then it won't be found. >> That sounds right. The general problem is you don't want to accidentally pick up OSX stuff on your system. I've generally used a combination of two things. I modified my toolchain to have special new root paths which I can define and I put all my iOS stuff there, and/or I use the -C initial cache feature of CMake to prespecify the locations. (And sometimes my initial caches use my new root path variables so the initial cache is flexible and not hard coded.) >>> set(CMAKE_MACOSX_BUNDLE YES) >> >> Is it possible to build any binary of any form on iOS without this? > > You're right, I do not think this is possible. As far as I know, it always must be a bundle. > As I understand it, this is a problem of try_compile: as signing of application is required for generating a binary for iOS, this one fails very early when CMake discovers the capabilities of the compiler. I have not encountered this. I don't think it is true, but I rarely use try_compile. Building iOS static libraries are not signed. And I don't think simulator targets require signing either. Signing is required for running on device. That said, there are a ton of other problems related to signing which are completely broken with CMake. Right now, the biggest pain point for me is the new Automatic Code signing. Prior to Xcode 8, you could set a CMake Xcode attribute to explicitly set the key to use. But this now conflicts with the new Automatic Code signing, and this his cannot be controlled by a CMake attribute and it breaks everything. And even if that were fixed, Xcode needs a second property, the Team. While this can be set by an attribute, the problem is just about every user has a different team and it is not easy to know. Xcode has a way of finding out what teams are available so you can pick it in a drop-down list (same with the keys). But for a CMake user, this is nearly impossible to know apriori. I think the only way to fix this is to modify CMake to 1) try to defer to Xcode's built-in behavior & 2) if the user sets this, some how don't let CMake overwrite/clobber just that setting when the project regenerates on an update. Semi-related is the Mac OS X entitlements system which is connected to code signing and shipping on the Mac App Store. It has a lot of these same problems and I think it needs to be fixed in the same fashion. The entitlements are supposed to show up in a dedicated tab in the project settings, but CMake projects tend to be blank in this area. And related to that is the iOS device orientation and launch screen setting which is the same story. > > Currently the main issue I am seeing is the multiarch/multisysroot > target of XCode that is kind of lost when using CMake. By > multiarch/multisysroot, I mean that Xcode is able to switch from > iPhoneSimulatorXY to iPhoneXY without changing the project, and within > the same view. Yes, that is a huge problem. I've found this to be very fragile. However for the moment, it kind of works. FIND_LIBRARY(APPLE_UIKIT_LIBRARY "UIKit") I think this was something I did to my toolchain, but I honestly can't remember the specifics. It might have had something to do with SYSROOT. I think the default one out there was setting something too aggressively. By removing it, it allowed Xcode to do it's normal things when switching between simulator and device targets (i.e. switch the SDK paths), and it still worked. However, I think the real solution is again to fix CMake so libraries & frameworks use te exact same built-in mechanism Xcode uses. That way Xcode takes control of everything in this situation because it looks no different than a hand-crafted Xcode project in this case. Additionally, bundling (copying resources) and code signing are another huge problem. Xcode formally recognizes that libraries and frameworks must be copied into the bundle during the build process. There is an explicit settings tab for this now. And it also knows that it must codesign everything after this step. And all this is an atomic operation as part of the regular build. When you hit the build/run/profile buttons in Xcode, all this stuff happens in one step and also includes the launch in that step. CMake has been resistant to this workflow for years, and it is a huge problem because this how the entire process is designed to operate and not supporting this breaks stuff badly. So again, if we can modify CMake to fully utilize the built-in Xcode features for libraries & frameworks, I think this problem gets fixed. Though there is one more nasty problem with the simulator vs. device switching. For 3rd party (dynamic) frameworks which were just finally allowed a few years ago, Apple has failed to give developers a good solution for dealing with pre-built libraries. Unlike a static library, Apple doesn't strip the dynamic libraries you don't use in your bundled framework. So if you built a fat framework with both simulator and device binareis, you get rejected by the App Store. But if you don't build a fat framework, there is no Apple supported way to switch between simulator and device targets on the fly. So in summary, my feeling is that to fix this, these are the top items that must be addressed: 1) A way to turn off Automatic Code signing or a way to fully embrace it so it just works (may need a way to not clobber manual user settings for key selection on regenerate) 2) Fix manual code signing (similar to above) 3) Make CMake fully embrace native Xocde mechanisms for libraries & frameworks (which includes the atomic build/bundle/codesign/run) 4a) Make it easier to build fat binaries and then strip out the unused ones on the final app build or 4b) We need CMake to recognize a system where when the user switches between simulator and device targets, it can also switch 3rd-party SDK directories which contain separate targets. 5) Fix proper integration for entitlements and device settings * Extra: I haven't dealt with AppleTV and Apple Watch yet. I don't know what extra things may be needed besides the LLVM IR "BitCode" option. -Eric P.S. I'm reaching a point where the codesiging is becoming a big enough problem for me that I'm interested in fixing it. And I might be able to dedicate some time to it. I saw some other people are already ahead of me on this and have looked at it in more detail. I'm willing to help out or collaborate. From ben.boeckel at kitware.com Wed Aug 16 10:29:48 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 16 Aug 2017 10:29:48 -0400 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: References: Message-ID: <20170816142948.GA9412@megas.kitware.com> On Tue, Aug 15, 2017 at 22:33:04 +0200, Daniel Pfeifer wrote: > 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. Well, not sure that I want *100%* compatible with ccmake if we're rewriting bits of it; there are lots of improvements that could be made ;) . > 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`. The make_shared function is there, but make_unique is missing in C++11. --Ben From daniel at pfeifer-mail.de Wed Aug 16 10:33:57 2017 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Wed, 16 Aug 2017 16:33:57 +0200 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: <20170816142948.GA9412@megas.kitware.com> References: <20170816142948.GA9412@megas.kitware.com> Message-ID: On Wed, Aug 16, 2017 at 4:29 PM, Ben Boeckel wrote: > On Tue, Aug 15, 2017 at 22:33:04 +0200, Daniel Pfeifer wrote: > > 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. > > Well, not sure that I want *100%* compatible with ccmake if we're > rewriting bits of it; there are lots of improvements that could be made > ;) . +1. Separating the code base simplifies these improvements. > > > 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`. > > The make_shared function is there, but make_unique is missing in C++11. > Of course. That is what I meant. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Aug 16 10:42:38 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 16 Aug 2017 10:42:38 -0400 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: References: Message-ID: <29929f7c-9c02-5cd7-eb07-59923da81d14@kitware.com> On 08/15/2017 04:33 PM, Daniel Pfeifer wrote: > With !977 merged, it is possible to base ccmake and cmake-gui on top > of the cmake server....Shall we proceed in this direction? Yes! That will be a nice separation. It will also reduce the number of places we have to set up `class cmake` instances in the code. Thanks, -Brad From ewmailing at gmail.com Wed Aug 16 12:16:24 2017 From: ewmailing at gmail.com (Eric Wing) Date: Wed, 16 Aug 2017 09:16:24 -0700 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: References: Message-ID: On 8/15/17, Daniel Pfeifer wrote: > Hi, > > With !977 merged, it is possible to base ccmake and cmake-gui on top of the > cmake server. > For demonstration, I copied the contents of the Source/CursesDialog > directory and added a proxy implementation of the classes `cmake` and > `cmState`. The result is 100% compatible with `ccmake`. The same would be > possible with cmake-gui. > > Shall we proceed in this direction? > > To make the server available everywhere, we should backport the code from > C++14 to C++11. I think this is limited to replacing `std::make_shared`. > > For cmake-gui, the proxies could use Qt functionality (QProcess, > QJsonDocument, etc.). As a result, cmake-gui would not have any build > dependencies apart from Qt. > > It might be worth considering to move ccmake and cmake-gui to their own > repositories. > > Cheers, Daniel > If this is a new rewrite... I am not making a strong push for this, but I want to bring it up to at least get people thinking about this... I am disturbed by the size and complexity of Qt. My past experiences have not been good and I find it a massive chore to get an environment setup (especially on Mac and Windows...and building Qt on Raspberry Pi is a nightmare). And the binary sizes are large. (I do ship CMake to my users and its size with the GUI is non-trivial.) CMake's actual GUI isn't that complex. Have you considered something lighter-weight? As one alternative, there is IUP: http://webserver2.tecgraf.puc-rio.br/iup/ (it's from the same university that created Lua...in fact I think one of the original authors of the white paper/project went on to become one of the Lua authors.) IUP differs from Qt in that is is focused on wrapping native GUI widgets (in constrast to Qt which creates its own non-native widgets). Hence, the library is really small since it only depends on each platform's native libraries. The core library is about 1MB. I just ported (rewrote) a simple Qt based app to IUP. The Qt version was almost 40MB. The IUP RAM usage is also many times smaller. It has native backends for Windows, GTK2, GTK3, Motif, Haiku. Because it historically didn't have a Mac OS X backend, most people overlooked it. However...I've been implementing a native Mac OS X backend. It's not finished, but there is a lot implemented and I'm actually shipping a simple app with it this week. Since CMake's GUI usage is also pretty simple, I *think* there might already be enough implemented to do the CMake-GUI...or it's close enough that I probably could finish those needed features. Also, I implemented a CMake build system for IUP. IUP is MIT licensed. Now IUP only does GUI (which is another reason it stays small), so you will need to fill in the JSON and Process requirements. But there are tons of JSON libraries. Off the top of my head, cJSON is a really fast, tiny, and simple to use JSON library. It's a single C file and header, so you can drop it right in the project. (Also MIT). It also has a CMake build system if you really want it. And a cross-platform create process...those I've seen everywhere and I've actually written my own too. I think Apache Runtime is only measured in hundreds of kilobytes even with all the stuff you don't need. A quick Google search turned up this one C++ (MIT) https://github.com/eidheim/tiny-process-library So IUP + some JSON + some Process should be around 1MB-2MB. This is in contrast to the Qt frameworks I have right now in my CMake bundle for Mac. Anyway, I know this is going to be outside peoples' comfort-zone which is why I'm not going to push hard on it. But in general, I would like something smaller, easier to build, and lighter on system resources (and real native GUIs generally provide a better user experience). So I'm hoping to at least get you thinking about that irrespective of any particular framework. And if there is interest in IUP, I'm happy to discuss more or help. Thanks, Eric From konstantin at podsvirov.pro Wed Aug 16 14:42:20 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 16 Aug 2017 21:42:20 +0300 Subject: [cmake-developers] Fwd: [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: References: <20170814131835.GA2910@megas.kitware.com> <885571502742145@web16g.yandex.ru> Message-ID: <139461502908940@web58o.yandex.ru> 15.08.2017, 17:39, "Brad King" : > On 08/14/2017 04:22 PM, Konstantin Podsvirov wrote: >> ?14.08.2017, 16:18, "Ben Boeckel" : >>> ?On Mon, Aug 14, 2017 at 20:09:17 +1000, Craig Scott wrote: >>>> ??moving cmake-gui and the Qt DLL's up to the top level? This may just be for >>>> ??Windows, other platforms could stay as they are now. Would obviously have >>>> ??to adjust not just the install location but also any internal code that >>>> ??tries to work out where other files are located relative to the cmake-gui >>>> ??executable. Things like the qt.conf file would also probably need some >>>> ??adjustment. >>> >>> ?Git splits it between bin/ and cmd/ where cmd/ is meant to be in PATH. >>> ?Then the structure doesn't need to change either. >> >> ?+1 Add script (.bat) to `cmd` subfolder to invoke tools from `bin` >> ?on Windows (and add to PATH variable if needed). > > One could move `cmake-gui.exe` and `*.dll` files to some other out-of-the-way > location and then have `bin/cmake-gui.exe` be a launcher that sets up the > environment and runs the real `cmake-gui.exe`. Brad, let me disagree with you. Real CMake's tools (cmake, ctest, cpack, ccmake, cmake-gui) have always been in the `bin` subfolder, and this suits many. This is also not a problem on Windows for such projects as msys2: http://www.msys2.org and my DaD's House: https://dad.podsvirov.pro/house These projects use a single environment for both building user projects and for building development tools. It seems to me that using the git experience on Windows will be more correct: 1. Tools in `bin` subfolder (with depends and dll) 2. Launcher apps or scripts in `cmd` subfolder. It still seems to me that we do not need to create launcher apps, but just use a simple script like: run/cmake-gui.bat: >@rem Distributed under the OSI-approved BSD 3-Clause License. See accompanying >@rem file Copyright.txt or https://cmake.org/licensing for details. > >@rem Launch cmake-gui >@start "cmake-gui" "%~dp0\..\bin\cmake-gui.exe" %* Craig Scott, can you test this script? :-) > -Brad Regards, Konstantin Podsvirov -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-gui.bat Type: text/x-msdos-batch Size: 227 bytes Desc: not available URL: From ben.boeckel at kitware.com Wed Aug 16 15:17:27 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 16 Aug 2017 15:17:27 -0400 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: References: Message-ID: <20170816191727.GA13206@megas.kitware.com> On Wed, Aug 16, 2017 at 09:16:24 -0700, Eric Wing wrote: > 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. How easy is it to ship binaries which work on any platform without also shipping all of the necessary platform backends as well? > 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. There's already a JSON library in CMake: jsoncpp. > 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 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. --Ben From jeanmichael.celerier at gmail.com Wed Aug 16 17:02:52 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Wed, 16 Aug 2017 23:02:52 +0200 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: <20170816191727.GA13206@megas.kitware.com> References: <20170816191727.GA13206@megas.kitware.com> Message-ID: @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. 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 > And the binary sizes are large. (I do ship CMake to my users and its size with the GUI is non-trivial.) 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). @Ben Boeckel : > The idea for process creation is to migrate to libuv once all of the dependencies are supported. Quick question : why not asio instead ? it's bound to end up in the standard library at some point (e.g. https://github.com/chriskohlhoff/networking-ts-impl) and already has an event loop. Or even Qt's event loop since it's already here. Best, Jean-Micha?l ------- Jean-Micha?l Celerier http://www.jcelerier.name On Wed, Aug 16, 2017 at 9:17 PM, Ben Boeckel wrote: > On Wed, Aug 16, 2017 at 09:16:24 -0700, Eric Wing wrote: > > 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. > > How easy is it to ship binaries which work on any platform without also > shipping all of the necessary platform backends as well? > > > 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. > > There's already a JSON library in CMake: jsoncpp. > > > 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 > > 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. > > --Ben > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pfeifer-mail.de Wed Aug 16 18:05:47 2017 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Thu, 17 Aug 2017 00:05:47 +0200 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: References: Message-ID: On Wed, Aug 16, 2017 at 6:16 PM, Eric Wing wrote: > On 8/15/17, Daniel Pfeifer wrote: > > Hi, > > > > With !977 merged, it is possible to base ccmake and cmake-gui on top of > the > > cmake server. > > For demonstration, I copied the contents of the Source/CursesDialog > > directory and added a proxy implementation of the classes `cmake` and > > `cmState`. The result is 100% compatible with `ccmake`. The same would be > > possible with cmake-gui. > > > > Shall we proceed in this direction? > > > > To make the server available everywhere, we should backport the code from > > C++14 to C++11. I think this is limited to replacing `std::make_shared`. > > > > For cmake-gui, the proxies could use Qt functionality (QProcess, > > QJsonDocument, etc.). As a result, cmake-gui would not have any build > > dependencies apart from Qt. > > > > It might be worth considering to move ccmake and cmake-gui to their own > > repositories. > > > > Cheers, Daniel > > > > If this is a new rewrite... > It is not. Both ccmake and cmake-gui use the use the `cmake` class as a facade to the cmakelib. In my prototype I re-implemented the `cmake` class as a client to the cmake-server using json-cpp and libuv. This allows separating ccmake and cmake-gui from the cmakelib without further changes to the rest of the code. The same client implementation might be used for ccmake and cmake-gui, but cmake-gui might as well use Qt facilities instead. 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. Sounds interesting. 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 That would not be necessary. A cache editor build on IUP could use the same cmake client implementation as ccmake. 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. > The good thing is that a new CMake GUI does not need to link against cmakelib. Hence, it does not need to live in CMake's repository. You may copy the cmake client implementation from https://github.com/purpleKarrot/nccmake and build a CMake GUI using IUP. Cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Aug 16 20:43:00 2017 From: DLRdave at aol.com (David Cole) Date: Wed, 16 Aug 2017 20:43:00 -0400 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: References: Message-ID: This is great to see CMake continuing to evolve like this! What's next, a web page CMake UI connected to cmake server instances on multiple platforms? ;-) On Wed, Aug 16, 2017 at 6:05 PM, Daniel Pfeifer wrote: > On Wed, Aug 16, 2017 at 6:16 PM, Eric Wing wrote: >> >> On 8/15/17, Daniel Pfeifer wrote: >> > Hi, >> > >> > With !977 merged, it is possible to base ccmake and cmake-gui on top of >> > the >> > cmake server. >> > For demonstration, I copied the contents of the Source/CursesDialog >> > directory and added a proxy implementation of the classes `cmake` and >> > `cmState`. The result is 100% compatible with `ccmake`. The same would >> > be >> > possible with cmake-gui. >> > >> > Shall we proceed in this direction? >> > >> > To make the server available everywhere, we should backport the code >> > from >> > C++14 to C++11. I think this is limited to replacing `std::make_shared`. >> > >> > For cmake-gui, the proxies could use Qt functionality (QProcess, >> > QJsonDocument, etc.). As a result, cmake-gui would not have any build >> > dependencies apart from Qt. >> > >> > It might be worth considering to move ccmake and cmake-gui to their own >> > repositories. >> > >> > Cheers, Daniel >> > >> >> If this is a new rewrite... > > > It is not. Both ccmake and cmake-gui use the use the `cmake` class as a > facade to the cmakelib. > In my prototype I re-implemented the `cmake` class as a client to the > cmake-server using json-cpp and libuv. > This allows separating ccmake and cmake-gui from the cmakelib without > further changes to the rest of the code. > > The same client implementation might be used for ccmake and cmake-gui, but > cmake-gui might as well use Qt facilities instead. > >> 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. > > > Sounds interesting. > >> 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 > > > That would not be necessary. A cache editor build on IUP could use the same > cmake client implementation as ccmake. > >> 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. > > > The good thing is that a new CMake GUI does not need to link against > cmakelib. Hence, it does not need to live in CMake's repository. You may > copy the cmake client implementation from > https://github.com/purpleKarrot/nccmake and build a CMake GUI using IUP. > > Cheers, Daniel > > -- > > 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 From ewmailing at gmail.com Wed Aug 16 21:34:29 2017 From: ewmailing at gmail.com (Eric Wing) Date: Wed, 16 Aug 2017 18:34:29 -0700 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: References: <20170816191727.GA13206@megas.kitware.com> Message-ID: 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 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 From ewmailing at gmail.com Wed Aug 16 21:48:16 2017 From: ewmailing at gmail.com (Eric Wing) Date: Wed, 16 Aug 2017 18:48:16 -0700 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: <20170816191727.GA13206@megas.kitware.com> References: <20170816191727.GA13206@megas.kitware.com> Message-ID: > 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 From irwin at beluga.phys.uvic.ca Thu Aug 17 01:03:55 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 16 Aug 2017 22:03:55 -0700 (PDT) Subject: [cmake-developers] Future of ccmake and cmake-gui and internationalization In-Reply-To: References: Message-ID: On 2017-08-16 09:16-0700 Eric Wing wrote: > 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. 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. However, it is a very strong point that a light-weight API is much nicer to use than a heavy-weight API. So your post and that open-source license got me quite interested in IUP (which I had frankly never heard of before). One of my fundamental criteria for a graphics library is it must have complete internationalization support, i.e., the library must support both unicode (preferably in the utf-8 encoding of unicode) and Complex Text Layout (CTL). Just for fun, I tested this cmake-gui capability using a utf-8 encoded Arabic word "???" (for "Peace" since that is about the only Arabic word I know) to temporarily document one of the PLplot cache variables and got good results (e.g., when I hovered over the "TEST_PEACE" option the "???" documentation of that option was laid out in the correct right-to-left order by the current Qt-based cmake-gui because Qt (as well as at least GTK+, wxWidgets, and GDI/GDI+/Uniscribe, Direct2D/DirectWrite on Windows and preumably Mac OS X graphics as well) support both unicode and CTL. I also tried naming the option itself "???" rather than TEST_PEACE, and that rendered correctly as well. Note the above Arabic word for "Peace" may not be rendered correctly (or at all) by your mailer, but if you dump this e-mail to a file and look at it with less, or some unicode-aware editor like emacs or vi (but not jed (!) I just discovered), it will be rendered correctly just as in the PLplot Peace flag example, . Also, if you use the cmake application instead of cmake-gui, the resulting cache file CMakeCache.txt has the correct rendering of "???" if viewed with the correct unicode-aware application. So both the cmake and cmake-gui applications currently support unicode and CTL, but the question on my mind is if cmake-gui is changed to use IUP rather than Qt will that nice result continue for that application? So to help answer that question I did a google search for the terms unicode site:http://webserver2.tecgraf.puc-rio.br/iup/ and it appears from those 10 hits that IUP completely supports the utf-8 encoding of unicode and since CTL capability is completely in the domain of the backend libraries, I am virtually positive that IUP supports both unicode and CTL for at least its GTK+ backend and likely its Windows backend. However, since those capabilities are so important (at least in my opinion) to cmake-gui can you please confirm this positive speculation concerning IUP for these two backends for me (and also your new Mac OS X backend). That test simply requires you to modify the first IUP tutorial example to use "???" to see whether that Arabic word is rendered in the correct right-to-left order in the IUP GUI. Also, if the other IUP backends such as Motif and Haiku don't deal with the CTL issue properly, then I think that would be a fairly important justification for sticking with Qt instead for cmake-gui. 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. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From ewmailing at gmail.com Thu Aug 17 02:27:10 2017 From: ewmailing at gmail.com (Eric Wing) Date: Wed, 16 Aug 2017 23:27:10 -0700 Subject: [cmake-developers] Future of ccmake and cmake-gui and internationalization In-Reply-To: References: Message-ID: > 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 From irwin at beluga.phys.uvic.ca Thu Aug 17 04:00:08 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 17 Aug 2017 01:00:08 -0700 (PDT) Subject: [cmake-developers] Future of ccmake and cmake-gui and internationalization In-Reply-To: References: Message-ID: On 2017-08-16 23:27-0700 Eric Wing wrote: >> >> 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. Hi Eric: I knew nothing about UTF-8 and unicode ~10 years ago, but it is essential developer knowledge that is well worth having (even if you only have knowledge of one human language, which is my case). Furthermore, it is actually quite simple to pick up this unicode and CTL knowledge these days (compared to a decade ago). The reason for that simplicity is for any decent editor such as emacs or vi you can cut and paste any UTF-8 string right from any website directly into your source code, and it normally "just works". So my advice to test your Mac OS backend for CTL capability is instead of the simple test case given at use instead #include #include int main(int argc, char **argv) { IupOpen(&argc, &argv); IupMessage("Hello World 1 ???", "Hello world from IUP ???."); IupClose(); return EXIT_SUCCESS; } where the only change I have made to the original is I have appended the utf-8 encoded "???" to each of those IupMessage string arguments. If your mailer is not unicode or CTL aware so you cannot see that utf-8 encoded Arabic Peace word in this e-mail, cut and paste that word from the third word in the line that starts with "Pace" in into the two IupMessage string arguments. Then build that modified app and see whether the GUI renders that word in the same character order that word is rendered by your browser for . (Browsers such as firefox and konqueror are typically the gold standard for being CTL-aware.) If that rendering is in the correct order (right-to-left) as given by firefox you have passed this simple CTL support test for whichever backend you are using. Also, you can test the CTL capability of cmake-gui (as well as the cmake application) by using option("???" "???" ON) in a simple test project where those two utf-8 strings are cut and pasted from the above "pace" website. The result of that test here is the letters in those words are rendered in the same order as in the above "pace" website both in the GUI (for the cmake-gui case) and in CMakeCache.txt (for both the cmake and cmake-gui cases). And, of course, if/when an IUP-based cmake-gui is developed, the same CTL test should be applied to that result as well. Note also, you don't have to limit your tests just to the word for Peace in Arabic. For example, there are some good test words in that can be cut and pasted. Finally, in my last post I stated that it would be bad news for IUP if any of its backends failed the CTL test, but in retrospect that is too strong a statement. For example, if the CTL capabilities of IUP are fine for GTK+, Windows, and Mac OS X backends, but the Motif backend (used on commercial Unices) is not capable of CTL, then that only affects the internationalization capabilities of cmake-gui for a minority platform (Commercial Unices). And given that the only bad result if CTL fails is the characters are rendered in the wrong order in the cmake-gui GUI display (with the CMakeCache.txt result completely unaffected), I think that rendering failure in that Motif corner case would be completely acceptable. Of course, CTL rendering failure is a more serious problem if it occurs for any of the majority platforms (i.e., Linux GTK+, Windows, or Mac OS X). However, I am pretty sure that CTL should be well supported by IUP on each of those 3 platforms, and if you can confirm that it should be sufficient to put this CTL support question for IUP immediately to rest. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From sflees at suse.de Thu Aug 17 04:11:35 2017 From: sflees at suse.de (Simon Lees) Date: Thu, 17 Aug 2017 17:41:35 +0930 Subject: [cmake-developers] Undocumented change in behavior in cmake 3.9.X (SWIG) Message-ID: Hi, We at openSUSE have noticed a change in behavior presumably in swig_link_libraries in one package cproton_perl.so is now being generated rather then libcproton_perl.so I presume the lines generating the library are below (I am not familiar with the package) swig_add_module(cproton_perl perl perl.i) swig_link_libraries(cproton_perl ${BINDING_DEPS} ${PERL_LIBRARY} -lpthread -lm) changing to the non depreciated swig_add_libraries caries this same change. I have a full build log available at [1] and a build on my system should you require more info. I guess the question we have is was this change intentional and accidentally undocumented (unless I missed it) or is there a deeper issue with cmake that needs fixing here. Thanks -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From jeanmichael.celerier at gmail.com Thu Aug 17 05:31:48 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Thu, 17 Aug 2017 11:31:48 +0200 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: References: <20170816191727.GA13206@megas.kitware.com> Message-ID: > 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. 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. > 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. this is false. brew uses xcode & clang on your system. > Similar problem for Windows...Visual Studio is the requirement. I don't know if you are talking about Chocolatey or Qt but neither require Visual Studio on windows. Qt even comes with MinGW if you wish. > And Mac doesn't have configure/autotools by defaul. but... "configure" has nothing to do with autotools. It's just a shell script (which is sometimes generated *from* autotools; this is not the case with Qt AFAIK). > 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. science can help us here :p two tools are very nice for this : * bloaty mcbloatface for binary bloat for file in /usr/lib/libQt5*.so ; do (echo $file; bloaty $file| grep -A3 'text') ; done tells us stuff like /usr/lib/libQt5Core.so 55.4% 2.75Mi .text 2.75Mi 55.5% 23.5% 1.16Mi .rodata 1.16Mi 23.5% 7.3% 372Ki .eh_frame 372Ki 7.4% 4.1% 210Ki .dynstr 210Ki 4.2% /usr/lib/libQt5Gui.so 70.0% 3.82Mi .text 3.82Mi 70.2% 7.8% 438Ki .eh_frame 438Ki 7.9% 6.1% 342Ki .dynstr 342Ki 6.1% 5.1% 286Ki .rodata 286Ki 5.1% A bit surprising to see .eh_frame; I thought Qt was compiled with -fno-exceptions but maybe that's just my distro. Quite a bunch of .rodata in Qt5Core too, I wonder why. Further examination through readelf -x .rodata /usr/lib/libQt5Core.so | less seems to show up a lot of locale-specific calendar text & such, e.g. names of the months in twenty languages, currencies, time zones, etc * And then, runtime examination: for this I tried making a minimal gui program: #include #include int main(int argc, char**argv) { QApplication app(argc, argv); QMainWindow w; w.show(); return app.exec(); } compiled with g++ -DQT_NO_DEBUG -fPIC -I/usr/include/qt/ -I/usr/include/qt/QtCore -I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui main.cpp -lQt5Core -lQt5Widgets and then use the wonderful Heaptrack (https://github.com/KDE/heaptrack) : heaptrack ./a.out which then greets us with http://imgur.com/a/eYjaL As you can see, "peak heap memory consumption" is at a bit less than 400 *kilobytes*. So the Qt memory usage that you see is clearly due only to binary bloat. And indeed (sorry for shitty bash skills): $ ldd a.out | cut -d '=' -f1 | awk '{print "/usr/lib/" $1;}' | xargs readlink | awk '{print "/usr/lib/" $1;}' | xargs du -csh | sort -h 16K /usr/lib/libdl-2.25.so 16K /usr/lib/libXau.so.6.0.0 24K /usr/lib/libXdmcp.so.6.0.0 32K /usr/lib/librt-2.25.so 64K /usr/lib/libdouble-conversion.so.1.0.0 68K /usr/lib/libbz2.so.1.0.6 72K /usr/lib/libGLX.so.0.0.0 72K /usr/lib/libXext.so.6.4.0 80K /usr/lib/liblz4.so.1.7.5 84K /usr/lib/libgpg-error.so.0.22.0 92K /usr/lib/libz.so.1.2.11 144K /usr/lib/libpthread-2.25.so 152K /usr/lib/liblzma.so.5.2.3 164K /usr/lib/libxcb.so.1.1.0 176K /usr/lib/libgraphite2.so.3.0.1 216K /usr/lib/libpng16.so.16.31.0 444K /usr/lib/libpcre2-16.so.0.5.0 460K /usr/lib/libpcre.so.1.2.9 536K /usr/lib/libsystemd.so.0.19.0 548K /usr/lib/libharfbuzz.so.0.10400.5 552K /usr/lib/libGL.so.1.0.0 600K /usr/lib/libGLdispatch.so.0.0.0 796K /usr/lib/libfreetype.so.6.14.0 1,1M /usr/lib/libglib-2.0.so.0.5200.3 1,1M /usr/lib/libm-2.25.so 1,2M /usr/lib/libgcrypt.so.20.2.0 1,3M /usr/lib/libX11.so.6.3.0 1,7M /usr/lib/libicuuc.so.59.1 1,9M /usr/lib/libc-2.25.so 2,5M /usr/lib/libicui18n.so.59.1 5,0M /usr/lib/libQt5Core.so.5.9.1 5,5M /usr/lib/libQt5Gui.so.5.9.1 6,4M /usr/lib/libQt5Widgets.so.5.9.1 12M /usr/lib/libstdc++.so.6.0.24 26M /usr/lib/libicudata.so.59.1 69M total So there's 17 megabytes of Qt in here; hopefully the rest would already be loaded by your system. Best, Jean-Micha?l On Thu, Aug 17, 2017 at 3:34 AM, Eric Wing wrote: > 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sflees at suse.de Thu Aug 17 05:59:25 2017 From: sflees at suse.de (Simon Lees) Date: Thu, 17 Aug 2017 19:29:25 +0930 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: References: <20170816191727.GA13206@megas.kitware.com> Message-ID: <06e9afe4-a4b3-426d-b3ce-5cecbd322fed@suse.de> On 17/08/17 19:01, Jean-Micha?l Celerier wrote: >> And Mac doesn't have configure/autotools by defaul. > > but... "configure" has nothing to do with autotools. > It's just a shell script (which is sometimes generated *from* autotools; > this is not the case with Qt AFAIK). > Yes Qt's configure is a stand alone script unrelated to autotools. Qt uses its own build system thats shipped with it. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From irwin at beluga.phys.uvic.ca Thu Aug 17 06:23:19 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 17 Aug 2017 03:23:19 -0700 (PDT) Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: <06e9afe4-a4b3-426d-b3ce-5cecbd322fed@suse.de> References: <20170816191727.GA13206@megas.kitware.com> <06e9afe4-a4b3-426d-b3ce-5cecbd322fed@suse.de> Message-ID: On 2017-08-17 19:29+0930 Simon Lees wrote: > > > On 17/08/17 19:01, Jean-Micha?l Celerier wrote: >>> And Mac doesn't have configure/autotools by defaul. >> >> but... "configure" has nothing to do with autotools. >> It's just a shell script (which is sometimes generated *from* autotools; >> this is not the case with Qt AFAIK). >> > > Yes Qt's configure is a stand alone script unrelated to autotools. Qt > uses its own build system thats shipped with it. I can confirm that. Also, I have built Qt5 a couple of times, and I was not particularly happy with the regidity of their build system when attempting to drop components I was not using. And I was also not happy with how the options for that configuration script changed so drastically from one Qt5 version to the next. So it is always a big disappointment to me that Qt5 does not have a flexible, user-friendly CMake-based build system following what the KDE developers have done for years. So this is another "minor" project for Alex. :-) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From sflees at suse.de Thu Aug 17 06:30:02 2017 From: sflees at suse.de (Simon Lees) Date: Thu, 17 Aug 2017 20:00:02 +0930 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: References: <20170816191727.GA13206@megas.kitware.com> <06e9afe4-a4b3-426d-b3ce-5cecbd322fed@suse.de> Message-ID: On 17/08/17 19:53, Alan W. Irwin wrote: > On 2017-08-17 19:29+0930 Simon Lees wrote: > >> >> >> On 17/08/17 19:01, Jean-Micha?l Celerier wrote: >>>> And Mac doesn't have configure/autotools by defaul. >>> >>> but... "configure" has nothing to do with autotools. >>> It's just a shell script (which is sometimes generated *from* autotools; >>> this is not the case with Qt AFAIK). >>> >> >> Yes Qt's configure is a stand alone script unrelated to autotools. Qt >> uses its own build system thats shipped with it. > > I can confirm that. Also, I have built Qt5 a couple of times, and I > was not particularly happy with the regidity of their build system > when attempting to drop components I was not using. And I was also > not happy with how the options for that configuration script changed > so drastically from one Qt5 version to the next. So it is always a > big disappointment to me that Qt5 does not have a flexible, > user-friendly CMake-based build system following what the KDE > developers have done for years. > > So this is another "minor" project for Alex. :-) > The way we tended to handle that at my previous job was to build almost everything (except the slow stuff like web) then only ship to our customers the libs we actually used. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ewmailing at gmail.com Thu Aug 17 07:15:51 2017 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 17 Aug 2017 04:15:51 -0700 Subject: [cmake-developers] Future of ccmake and cmake-gui and internationalization In-Reply-To: References: Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: IupLabelPeace.png Type: image/png Size: 15952 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IupMessagePeace.png Type: image/png Size: 31019 bytes Desc: not available URL: From cliffyapp at gmail.com Thu Aug 17 08:06:15 2017 From: cliffyapp at gmail.com (Clifford Yapp) Date: Thu, 17 Aug 2017 08:06:15 -0400 Subject: [cmake-developers] Future of ccmake and cmake-gui and internationalization In-Reply-To: References: Message-ID: On Thu, Aug 17, 2017 at 2:27 AM, Eric Wing wrote: >> 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.) 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. From ewmailing at gmail.com Thu Aug 17 08:15:24 2017 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 17 Aug 2017 05:15:24 -0700 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: References: <20170816191727.GA13206@megas.kitware.com> Message-ID: > 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 seen developers ship a binary that only works on their system because they installed something and whatever build process didn't catch it. And I've seen this hapen way too much, even though developers always try to convince me otherwise. I actually had a conversation with another developer who was trying to convince me otherwise, and like this one time and the other developer made the exact mistake like a month later with a release build. The most public one was ImageMagik. I don't know if it was Brew, Fink, MacPorts or what, but the general problem is the same. As for the macdeployqt script, my last stint with Qt was about 2 years ago. (I seem to have to revist Qt every so many years for different projects.) At the time, the script seemed to be broken in at least two places. The first seemed to get borked if you had any library that used @rpath instead of @executable_path. The second was I think the script actually missed a bunch of QML plugins (QtQuick) so you would get failures at launch time or things wouldn't work as expected or something. I think the Windows script had similar problems. I don't remember finding a Linux script, but by this point, I had already learned how to manually assemble my own distribution. > > I don't know if you are talking about Chocolatey or Qt but neither require > Visual Studio on windows. > Qt even comes with MinGW if you wish. > Sorry, I meant my requirement is Visual Studio. MinGW is not a benefit to me. >> And Mac doesn't have configure/autotools by defaul. > > but... "configure" has nothing to do with autotools. > It's just a shell script (which is sometimes generated *from* autotools; > this is not the case with Qt AFAIK). Ah, I stand corrected. > science can help us here :p two tools are very nice for this : > > * bloaty mcbloatface for binary bloat > > So there's 17 megabytes of Qt in here; hopefully the rest would already be > loaded by your system. > Thank you for taking the time to write up that analysis. That was really informative and I learned a bunch of things. Thanks, Eric From ben.boeckel at kitware.com Thu Aug 17 08:46:07 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 17 Aug 2017 08:46:07 -0400 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: References: <20170816191727.GA13206@megas.kitware.com> Message-ID: <20170817124607.GA18506@megas.kitware.com> On Wed, Aug 16, 2017 at 23:02:52 +0200, Jean-Micha?l Celerier wrote: > @Ben Boeckel : > > The idea for process creation is to migrate to libuv once all of the > dependencies are supported. > Quick question : why not asio instead ? it's bound to end up in the > standard library at some point (e.g. > https://github.com/chriskohlhoff/networking-ts-impl) and already has an > event loop. CMake uses curl for networking (all sync), but libuv was added for the server mode's event loop. It also comes with process execution, some filesystem helpers and other things that kwsys does today that we can drop once we move to it. AFAICT, asio looks like it's mostly a networking library and doesn't overlap well with libuv and CMake's requirements. > Or even Qt's event loop since it's already here. Qt isn't required by core CMake, just cmake-gui. --Ben From ben.boeckel at kitware.com Thu Aug 17 08:48:18 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 17 Aug 2017 08:48:18 -0400 Subject: [cmake-developers] Undocumented change in behavior in cmake 3.9.X (SWIG) In-Reply-To: References: Message-ID: <20170817124818.GB18506@megas.kitware.com> On Thu, Aug 17, 2017 at 17:41:35 +0930, Simon Lees wrote: > We at openSUSE have noticed a change in behavior presumably in > swig_link_libraries in one package cproton_perl.so is now being > generated rather then libcproton_perl.so I presume the lines generating > the library are below (I am not familiar with the package) > > swig_add_module(cproton_perl perl perl.i) > swig_link_libraries(cproton_perl ${BINDING_DEPS} ${PERL_LIBRARY} > -lpthread -lm) > > changing to the non depreciated swig_add_libraries caries this same > change. I have a full build log available at [1] and a build on my > system should you require more info. > > I guess the question we have is was this change intentional and > accidentally undocumented (unless I missed it) or is there a deeper > issue with cmake that needs fixing here. Looks like it was added here: https://gitlab.kitware.com/cmake/cmake/merge_requests/767 as part of this commit: https://gitlab.kitware.com/brad.king/cmake/commit/8ed663791bdda4e726f7b3764bc75f8856724d6f --Ben From irwin at beluga.phys.uvic.ca Thu Aug 17 08:49:44 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 17 Aug 2017 05:49:44 -0700 (PDT) Subject: [cmake-developers] Future of ccmake and cmake-gui and internationalization In-Reply-To: References: Message-ID: 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. > The second is from your MessageBox line. Yes, I confirm those two PNG images have that Arabic Peace word rendered in the correct right-to-left order. So that settles the question for what I assume is your Mac OS X native graphics back end. Can you (or some other IUP developer) do that same simple test for Linux native graphics (probably GTK+) backend and native Windows graphics backend? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From j.david.berger at gmail.com Thu Aug 17 10:49:23 2017 From: j.david.berger at gmail.com (Justin Berger) Date: Thu, 17 Aug 2017 08:49:23 -0600 Subject: [cmake-developers] Future of ccmake and cmake-gui In-Reply-To: <20170817124607.GA18506@megas.kitware.com> References: <20170816191727.GA13206@megas.kitware.com> <20170817124607.GA18506@megas.kitware.com> Message-ID: I think asio being on track to be included in the standard library is a strong point in its favor, but in my opinion there are two strong reasons to prefer libuv: - libuv is entirely a C library. I don't think this is a hard requirement but most of kwsys is C and I suspect there is a reason for this; although maybe it's entirely historical. - asio is header only; and a lot of headers at that. With essentially identical functionality, I don't think it makes sense to take the build time hit; which as far as I can tell is substantial. If/when ASIO gets into the standard, I think it'd make sense to re-evaluate that, but we are a long time away from that, and even when it gets into the standard it'll take a maddeningly long time for that standard to be properly supported for all the supported platforms for cmake. - Justin On Thu, Aug 17, 2017 at 6:46 AM, Ben Boeckel wrote: > On Wed, Aug 16, 2017 at 23:02:52 +0200, Jean-Micha?l Celerier wrote: > > @Ben Boeckel : > > > The idea for process creation is to migrate to libuv once all of the > > dependencies are supported. > > Quick question : why not asio instead ? it's bound to end up in the > > standard library at some point (e.g. > > https://github.com/chriskohlhoff/networking-ts-impl) and already has an > > event loop. > > CMake uses curl for networking (all sync), but libuv was added for the > server mode's event loop. It also comes with process execution, some > filesystem helpers and other things that kwsys does today that we can > drop once we move to it. AFAICT, asio looks like it's mostly a > networking library and doesn't overlap well with libuv and CMake's > requirements. > > > Or even Qt's event loop since it's already here. > > Qt isn't required by core CMake, just cmake-gui. > > --Ben > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Thu Aug 17 11:55:57 2017 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 17 Aug 2017 08:55:57 -0700 Subject: [cmake-developers] Future of ccmake and cmake-gui and internationalization In-Reply-To: References: Message-ID: 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. >> The second is from your MessageBox line. > > Yes, I confirm those two PNG images have that Arabic Peace word rendered > in the correct right-to-left order. > > So that settles the question for what I assume is your Mac OS X native > graphics back end. Can you (or some other IUP developer) do that same > simple test for Linux native graphics (probably GTK+) backend and > native Windows graphics backend? > > Alan > ___ I think it works. Attached are screenshots from Ubuntu 12.04LTS with the GTK2 backend, and Windows. -Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: IupArabicPeaceUbuntu12Gtk2.png Type: image/png Size: 12814 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IupArabicPeaceWindows.png Type: image/png Size: 1824 bytes Desc: not available URL: From ewmailing at gmail.com Thu Aug 17 12:11:23 2017 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 17 Aug 2017 09:11:23 -0700 Subject: [cmake-developers] Future of ccmake and cmake-gui and internationalization In-Reply-To: References: Message-ID: > 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 From tinlun123 at gmail.com Thu Aug 17 12:20:19 2017 From: tinlun123 at gmail.com (Anh Huynh) Date: Thu, 17 Aug 2017 16:20:19 +0000 Subject: [cmake-developers] Best practice for providing inputs to find modules Message-ID: Hi everyone, I am developing a module to find OpenACC. If I want the user to provide inputs to select GPU targets, and use that input in the find module to provide the correct flag for the user, what is the best practice to do that? For example, PGI compilers use -ta=tesla or -ta=multicore to select targets. It would be great if the user can specify the target without having to add the flag manually. Should I have the user set a definition before using find_package and checking for that definition? Should I simply have the user add the relevant flags themselves? Should I provide some variable that would contain the correct flag so the user can use it to append to his flags? Thank you in advance! Tin Huynh -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivamprettimn at gmail.com Thu Aug 17 13:34:27 2017 From: ivamprettimn at gmail.com (Ivam Pretti) Date: Thu, 17 Aug 2017 14:34:27 -0300 Subject: [cmake-developers] List of commands Message-ID: Hi there I am new at coding with cmake and I would like to know if there is a list of commands avaiable. Thanks anyway. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Aug 17 13:54:05 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 17 Aug 2017 13:54:05 -0400 Subject: [cmake-developers] List of commands In-Reply-To: References: Message-ID: <20170817175405.GA29573@megas.kitware.com> On Thu, Aug 17, 2017 at 14:34:27 -0300, Ivam Pretti wrote: > Hi there I am new at coding with cmake and I would like to know if there is > a list of commands avaiable. Thanks anyway. The cmake-commands(7) manpage has a listing of the builtin commands. They're also available in the HTML documentation: https://cmake.org/cmake/help/latest/manual/cmake-commands.7.html --Ben From irwin at beluga.phys.uvic.ca Thu Aug 17 14:54:52 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 17 Aug 2017 11:54:52 -0700 (PDT) Subject: [cmake-developers] Future of ccmake and cmake-gui and internationalization In-Reply-To: References: Message-ID: On 2017-08-17 08:55-0700 Eric Wing wrote: > 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. >>> The second is from your MessageBox line. >> >> Yes, I confirm those two PNG images have that Arabic Peace word rendered >> in the correct right-to-left order. >> >> So that settles the question for what I assume is your Mac OS X native >> graphics back end. Can you (or some other IUP developer) do that same >> simple test for Linux native graphics (probably GTK+) backend and >> native Windows graphics backend? >> >> Alan >> ___ > > I think it works. > Attached are screenshots from Ubuntu 12.04LTS with the GTK2 backend, > and Windows. I confirm that (rho-like character rendered on the left, omega-like character rendered on the right) which should put this CTL concern to rest. Thanks for your help answering this critical question (from my perspective) for the three separate platforms. By the way, could you let me know if/when your CMake-based build system is completed to your satisfaction and ideally accepted into official IUP? I am prejudiced toward using CMake-based build system alternatives whenever possible so official acceptance by IUP developers of your build-system work will likely be the occasion when I first give an IUP build a try. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From konstantin at podsvirov.pro Thu Aug 17 15:05:16 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 17 Aug 2017 22:05:16 +0300 Subject: [cmake-developers] [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: References: <5991a6bd.d8a0df0a.adc85.7614@mx.google.com> Message-ID: <245101502996716@web35o.yandex.ru> Hello Cl?ment Gregoire! 17.08.2017, 21:55, "Cl?ment Gregoire" : > So the following worked for me: > > move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder > > create a batch file named > > cmake-gui.bat > > with the following content > > @echo off > start "" /B "%~dp0\gui\cmake-gui.exe" %* > > And modify qt.conf so that the plugin directory is correct : > > from????? Plugins = ../plugins???? to??? Plugins = ../../plugins > > I'm not (yet) on the dev mailing list, so feel free to transfer the solution there. Please review dev mailing list archive too: http://public.kitware.com/pipermail/cmake-developers/2017-August/030228.html (may be I forgot /B option) > 2017-08-14 15:33 GMT+02:00 Lectem : >> Right, as mentionned by Craig Scott, a script might do the trick?? Just a cmake-gui.bat that calls cmake-gui.exe should work. >> >> De?: Robert Maynard >> Envoy? le?:lundi 14 ao?t 2017 15:24 >> ??: Craig Scott >> Cc?: Cl?ment Gregoire; CMake >> Objet?:Re: [CMake] cmake-gui on windows and qt5 dlls >> >> More importantly symlinks are restricted to administrator accounts >> >> only in Windows Vista/7/8. Windows 10 with Developer Mode activated >> >> allows none-elevated accounts to create symlinks. >> >> This is important as CMake does ship non-installer windows binaries. >> >> On Mon, Aug 14, 2017 at 9:00 AM, Craig Scott wrote: >> >>> >> >>> >> >>> On Mon, Aug 14, 2017 at 9:05 PM, Cl?ment Gregoire wrote: >> >>>> >> >>>> Wouldn't it be possible to move it to a subfolder with the DLLs and put a >> >>>> link next to cmake and ccmake? Executables look for DLLs in their directory >> >>>> and it wouldn't pollute the PATH >> >>> >> >>> >> >>> Symlinks are available on NTFS filesystems from Vista onwards. If the user >> >>> installed CMake on, say, a FAT filesystem instead or on an old XP box (CMake >> >>> appears to still try to support that), then symlinks wouldn't be available >> >>> from what I can make out. One could potentially use a forwarding script of >> >>> some kind though to achieve essentially the same thing. >> >>> >> >>> >> >>>> I personally like to be able to launch it through the command line, it is >> >>>> faster than looking for it and then browse for the folder. >> >>>> >> >>>> >> >>>> Le lun. 14 ao?t 2017 ? 11:48, Craig Scott a >> >>>> ?crit : >> >>>>> >> >>>>> This is a common problem, not just with CMake. I'm wondering if there's >> >>>>> any real need for cmake-gui to be on the PATH at all, since it will usually >> >>>>> be invoked by a desktop or menu icon. At the moment though, it is in the >> >>>>> same directory as the cmake and ccmake executables which have a much >> >>>>> stronger case for being on the PATH. There's a reasonable argument that >> >>>>> cmake-gui should be in a different directory, then it wouldn't be an issue >> >>>>> if shared Qt libs were used rather than static. I'll bring this up on the >> >>>>> developer mailing list and see what discussions yield. >> >>>>> >> >>>>> >> >>>>> On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher >> >>>>> wrote: >> >>>>>> >> >>>>>> Hi, >> >>>>>> >> >>>>>> I recently upgraded from cmake 3.3 to 3.9 on windows and got some >> >>>>>> problems during my build because it looks like the pre-compile binaries for >> >>>>>> windows are now shipping Qt5 - dlls instead static compile libs (since 3.5 >> >>>>>> afaics). >> >>>>>> The problem is, that I had the path to cmake *before* the path to my own >> >>>>>> Qt5 libaries. So during the build / run of my application, the wrong >> >>>>>> libraries were loaded and I got a symbol lookup error. >> >>>>>> Would it be possible to use the static Qt5 libs instead or maybe prefix >> >>>>>> the Qt5 libs shipped with cmake-gui somehow? >> >>>>>> >> >>>>>> Thx, >> >>>>>> Christian >> >>>>>> >> >>>>>> -- >> >>>>>> >> >>>>>> 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 >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Craig Scott >> >>>>> Melbourne, Australia >> >>>>> https://crascit.com >> >>>>> -- >> >>>>> >> >>>>> 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 >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Craig Scott >> >>> Melbourne, Australia >> >>> https://crascit.com >> >>> >> >>> -- >> >>> >> >>> 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 > ,-- > > 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 Regards, Konstantin Podsvirov From bill.hoffman at kitware.com Thu Aug 17 16:09:29 2017 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 17 Aug 2017 16:09:29 -0400 Subject: [cmake-developers] Future of ccmake and cmake-gui and internationalization In-Reply-To: References: Message-ID: <1ebc31de-ecd9-9e44-0e6d-99b254cd1bc0@kitware.com> On 8/17/2017 12:11 PM, Eric Wing wrote: > 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. CMake originally had an FLTK GUI it was dropped for the Qt one. :) This happened around the time Qt changed licenses. I am not that interested in dropping Qt for something else at this point. Computers have big disks/memory so the bloat does not bother me that much. There are folks maintaining the Qt cmake-gui and there seems to be enough Qt knowledge around to keep that going. -Bill From craig.scott at crascit.com Thu Aug 17 16:23:48 2017 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 18 Aug 2017 06:23:48 +1000 Subject: [cmake-developers] [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: <245101502996716@web35o.yandex.ru> References: <5991a6bd.d8a0df0a.adc85.7614@mx.google.com> <245101502996716@web35o.yandex.ru> Message-ID: On Fri, Aug 18, 2017 at 5:05 AM, Konstantin Podsvirov < konstantin at podsvirov.pro> wrote: > Hello Cl?ment Gregoire! > > 17.08.2017, 21:55, "Cl?ment Gregoire" : > > So the following worked for me: > > > > move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder > > > > create a batch file named > > > > cmake-gui.bat > > > > with the following content > > > > @echo off > > start "" /B "%~dp0\gui\cmake-gui.exe" %* > > > > And modify qt.conf so that the plugin directory is correct : > > > > from Plugins = ../plugins to Plugins = ../../plugins > > > > I'm not (yet) on the dev mailing list, so feel free to transfer the > solution there. > > Please review dev mailing list archive too: > http://public.kitware.com/pipermail/cmake-developers/2017- > August/030228.html > (may be I forgot /B option) > Side note: really weird, but that email you've linked to never made it to my inbox (can't explain it, checked my trash and spam folders too), so I never saw your request to ask to test! In the past, one problem I've run into with using simple batch files as launcher scripts is that they can flash up a console window briefly before starting the real app. This can look suspicious and distracting to the user, so it is something to avoid. I think at one past employer we ended up using something like wscript instead, which allowed us to avoid that problem and it worked on all Windows versions without any extra software dependencies. Maybe we just didn't have good enough batch-file-fu, maybe things work differently now, I don't know. Been a number of years since I've looked at that specific problem. Some context, but only basic extra info: https://stackoverflow.com/a/9062764/1938798 -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Thu Aug 17 17:03:58 2017 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 18 Aug 2017 07:03:58 +1000 Subject: [cmake-developers] [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: References: <5991a6bd.d8a0df0a.adc85.7614@mx.google.com> <245101502996716@web35o.yandex.ru> Message-ID: On Fri, Aug 18, 2017 at 6:23 AM, Craig Scott wrote: > > > On Fri, Aug 18, 2017 at 5:05 AM, Konstantin Podsvirov < > konstantin at podsvirov.pro> wrote: > >> Hello Cl?ment Gregoire! >> >> 17.08.2017, 21:55, "Cl?ment Gregoire" : >> > So the following worked for me: >> > >> > move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder >> > >> > create a batch file named >> > >> > cmake-gui.bat >> > >> > with the following content >> > >> > @echo off >> > start "" /B "%~dp0\gui\cmake-gui.exe" %* >> > >> > And modify qt.conf so that the plugin directory is correct : >> > >> > from Plugins = ../plugins to Plugins = ../../plugins >> > >> > I'm not (yet) on the dev mailing list, so feel free to transfer the >> solution there. >> >> Please review dev mailing list archive too: >> http://public.kitware.com/pipermail/cmake-developers/2017-Au >> gust/030228.html >> (may be I forgot /B option) >> > > Side note: really weird, but that email you've linked to never made it to > my inbox (can't explain it, checked my trash and spam folders too), so I > never saw your request to ask to test! > > In the past, one problem I've run into with using simple batch files as > launcher scripts is that they can flash up a console window briefly before > starting the real app. This can look suspicious and distracting to the > user, so it is something to avoid. I think at one past employer we ended up > using something like wscript instead, which allowed us to avoid that > problem and it worked on all Windows versions without any extra software > dependencies. Maybe we just didn't have good enough batch-file-fu, maybe > things work differently now, I don't know. Been a number of years since > I've looked at that specific problem. Some context, but only basic extra > info: > > https://stackoverflow.com/a/9062764/1938798 > Let me clarify the above (sorry, recalling more of the original problem we had years back). The flashing up of a console window would occur if you ran the launcher from somewhere other than an existing console window. For example, if you double-clicked the launcher in Windows Explorer or via a menu shortcut. In our case, we were using the script to set some environment variables before launching the real app, so you always wanted to use the launcher. In the discussion here about cmake-gui, you don't really need that, you just want a way to forward the call to start the app so you can avoid putting the real app and its DLLs on the PATH. So I guess a batch file would be okay in this instance, since we would only be expecting people to use it from a console window anyway (menu shortcuts, etc. could still invoke the real cmake-gui app directly). -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sflees at suse.de Thu Aug 17 20:41:10 2017 From: sflees at suse.de (Simon Lees) Date: Fri, 18 Aug 2017 10:11:10 +0930 Subject: [cmake-developers] Undocumented change in behavior in cmake 3.9.X (SWIG) In-Reply-To: <20170817124818.GB18506@megas.kitware.com> References: <20170817124818.GB18506@megas.kitware.com> Message-ID: <523f8892-da6c-6832-f7bb-b91a31f326c0@suse.de> On 17/08/17 22:18, Ben Boeckel wrote: > On Thu, Aug 17, 2017 at 17:41:35 +0930, Simon Lees wrote: >> We at openSUSE have noticed a change in behavior presumably in >> swig_link_libraries in one package cproton_perl.so is now being >> generated rather then libcproton_perl.so I presume the lines generating >> the library are below (I am not familiar with the package) >> >> swig_add_module(cproton_perl perl perl.i) >> swig_link_libraries(cproton_perl ${BINDING_DEPS} ${PERL_LIBRARY} >> -lpthread -lm) >> >> changing to the non depreciated swig_add_libraries caries this same >> change. I have a full build log available at [1] and a build on my >> system should you require more info. >> >> I guess the question we have is was this change intentional and >> accidentally undocumented (unless I missed it) or is there a deeper >> issue with cmake that needs fixing here. > > Looks like it was added here: > > https://gitlab.kitware.com/cmake/cmake/merge_requests/767 > > as part of this commit: > > https://gitlab.kitware.com/brad.king/cmake/commit/8ed663791bdda4e726f7b3764bc75f8856724d6f > > --Ben > Thanks I'll update the cmake files in that package. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From raffi.enficiaud at mines-paris.org Fri Aug 18 05:15:28 2017 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Fri, 18 Aug 2017 11:15:28 +0200 Subject: [cmake-developers] iOS: direction to official support and questions In-Reply-To: References: <8ca578c0-5e58-a0b7-b563-4577d39a1085@kitware.com> Message-ID: Le 16.08.17 ? 16:27, Eric Wing a ?crit : > 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. Hi, thanks for your answer. I also found several examples online, some of them are good, but I cannot just copy-paste them :) I need to understand what is going on, and sometimes things are done not in a good way. > > > On 8/15/17, Raffi Enficiaud wrote: >> Le 10.08.17 ? 17:04, Brad King a ?crit : >>> On 08/08/2017 08:08 AM, Raffi Enficiaud wrote: >>>> I have looked a bit to the Android toolchains, and I have to say I found >>>> those quite complicated as a first reading :) >>> > > I personally think the Android toolchain is way more complicated than > the iOS toolchain. Among the reasons are that every NDK release broke > something different as they kept changing the compiler and conventions > (the gcc to clang move was the most recent biggie, but old-timers > might remember the standalone toolchain difficulties.). Then you have > to pick different API levels because the each NDK release ships a > separate API subtarget for all prior versions of Android. Then add all > the multiple architectures (mips, arm, x86, 64-bit) and the > subvariants (armv5, armv7, armv7+NEON, etc), 4 different C++ standard > libraries you have to choose from, and other nuisances like Android on > Windows...makes the whole thing a mess. Right now, I am completely discarding whatever has been done for Android :) > > >>> 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. It appears that this is too restrictive. For instance, I compiled boost and made fat libraries in an installation folder, and I am not being able to pick them up. By removing them, FindBoost works fine. But the problem is that it is unclear to me what should be allowed and what not, and where are the problems: * specifically for the FindBoost problem mentioned above, is it a limitation of FindBoost that is not honouring cross compilation well? I believe that if I provide a BOOST_ROOT, then it should be used no matter what default configuration is provided by the toolchain file * another example: I need eg. the python interpreter to run some tests. If I remove the lines above, the host interpreter is found. In the case of my project, it is ok, because I use that for running some tests. In some other projects I have, I think this is not ok because I may use the interpreter for finding other libraries on the OS (cython, numpy, etc). The question is: what is the best practice for letting the developer do his job right? Preventing accessing some paths when searching for a binary or a shared/library is limiting. Especially, it is not easy to know if a library that is found is part of the cross-compilation toolchain that can run on the host (say "codesign", "clang", "python" etc) or part of the bundle we want to create (eg boost_something.dylib, that is a fat binary containing also the architecture of the host - because of the iOS simulator). As of today, find_library or find_program does not make any distinction, but in case of cross-compilation, I would like to have ideally a "CROSS_COMPILATION_TOOLCHAIN" property that I may use in the CMake scripts. For instance, I need to find a library that will be integrated in the target platform binary: -------- find_library(MyLIB NAMES my_lib_arch_arm TARGET_PLATFORM) # or TARGET_PLATFORM implicit add_executable(MyFinalBundle ... TARGET_PLATFORM) target_link_library(MyFinalBundle MyLIB) # check for consistency: all dependencies should be TARGET_PLATFORM as well -------- In this case, the find_library will look into the sysroot that is provided by the toolchain file, plus some given by the user and that are specific to the module (BOOST_ROOT for instance) OTOH: -------- find_library(MyToolchainLib NAMES my_toolchainlib HOST_PLATFORM) find_program(my_other_toolchain_program HOST_PLATFORM) add_executable(my_intermediade_tool HOST_PLATFORM) target_link_library(my_intermediade_tool MyToolchainLib) add_custom_command( OUTPUT output output2 COMMAND my_intermediade_tool input output COMMAND my_other_toolchain_program input2 output2) -------- Those binaries are compiled on the host with the host architecture, or looked for inside the platform default toolchain (eg codesign), and are then being part of the overall toolchain that is being used. Tools like qtautomoc for instance can be part of this, and we know often for sure if a program is part of the build process or the target. > 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.) That is interesting, do you have an example of the -C thinggy? > >>>> 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. The examples I have found on the Internet are forcing the compiler checks. Example: --------- include (CMakeForceCompiler) set(CMAKE_C_COMPILER clang Clang) set(CMAKE_CXX_COMPILER clang++ Clang) set(CMAKE_AR ar CACHE FILEPATH "" FORCE) # Skip the platform compiler checks for cross compiling set (CMAKE_CXX_COMPILER_WORKS TRUE) set (CMAKE_C_COMPILER_WORKS TRUE) --------- I would like to avoid this, this is why I want to delegate the compiler checks to CMake, as it does it well. The problem I had is that CMake emits several try_compile, and one of those apparently is trying to build a bundle, which causes an error because of the final required signing. > Building iOS static libraries are not signed. And I don't think > simulator targets require signing either. Right now I am not being able to install on the simulator precisely because of the signing ... Maybe I am doing it wrong > > 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. Signing is also an issue for me: - right now I disabled anything automatic done by Xcode. It just does it wrong all the time - I have the private key and the associated certificate in my keychain - I select the right signing certificate from Xcode detailed options - I indicate the team ID manually - I indicate the provisioning file manually and then signing is part of the build that happens automatically by XCode as a last post-build step. For preparing the bundle, I created a post-build script to copy all the relevant dylibs in the final bundle and correct for the @rpath, and it seems to work fine. The signing happens after, on all dylibs and frameworks that are contained in the bundle. I need to set CODE_SIGNING_REQUIRED attribute to YES though manually as well, as it is inherited by the CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED of the toolchain. XCode needs to access the private key that will be used for signing anyway. I will not be happy with distributing a private key on my build machines, so I am fine with having the signing thinggy manual. >> 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. > FIND_LIBRARY(APPLE_UIKIT_LIBRARY "UIKit") > I think this was something I did to my toolchain, but I honestly can't > remember the specifics. It might have had something to do with > SYSROOT. I think the default one out there was setting something too > aggressively. By removing it, it allowed Xcode to do it's normal > things when switching between simulator and device targets (i.e. > switch the SDK paths), and it still worked. I am not sure to understand what problem the FIND_LIBRARY(APPLE_UIKIT_LIBRARY "UIKit") addresses. Are you saying that, by just adding that, Xcode would be able to eg. find libz in different sysroots? I am not sure to understand. > However, I think the real solution is again to fix CMake so libraries > & frameworks use te exact same built-in mechanism Xcode uses. That way > Xcode takes control of everything in this situation because it looks > no different than a hand-crafted Xcode project in this case. I also believe that we should take this path: - different sysroots, as we handle different configuration (debug/release). I believe however that this is not semantically the same as a build configuration, and OTOH increasing exponentially the number of variables is not a good idea in the end. - something that indicates that we are targeting the host or target platform (see above) for better cross-compilation support > Additionally, bundling (copying resources) and code signing are > another huge problem. Xcode formally recognizes that libraries and > frameworks must be copied into the bundle during the build process. > There is an explicit settings tab for this now. And it also knows that > it must codesign everything after this step. And all this is an atomic > operation as part of the regular build. When you hit the > build/run/profile buttons in Xcode, all this stuff happens in one step > and also includes the launch in that step. CMake has been resistant to > this workflow for years, and it is a huge problem because this how the > entire process is designed to operate and not supporting this breaks > stuff badly. So again, if we can modify CMake to fully utilize the > built-in Xcode features for libraries & frameworks, I think this > problem gets fixed. > > > Though there is one more nasty problem with the simulator vs. device > switching. For 3rd party (dynamic) frameworks which were just finally > allowed a few years ago, Apple has failed to give developers a good > solution for dealing with pre-built libraries. Unlike a static > library, Apple doesn't strip the dynamic libraries you don't use in > your bundled framework. So if you built a fat framework with both > simulator and device binareis, you get rejected by the App Store. But > if you don't build a fat framework, there is no Apple supported way to > switch between simulator and device targets on the fly. I haven't been in a state to push to app-store yet, and I am pretty sure a lot of new problem will arise there. From what I understood from "-fembed-bitcode" option of clang, this should let Apple to do the work of preparing the binary to a specific device. > So in summary, my feeling is that to fix this, these are the top items > that must be addressed: > 1) A way to turn off Automatic Code signing or a way to fully embrace > it so it just works > (may need a way to not clobber manual user settings for key selection > on regenerate) > 2) Fix manual code signing (similar to above) > 3) Make CMake fully embrace native Xocde mechanisms for libraries & > frameworks (which includes the atomic build/bundle/codesign/run) > 4a) Make it easier to build fat binaries and then strip out the unused > ones on the final app build > or > 4b) We need CMake to recognize a system where when the user switches > between simulator and device targets, it can also switch 3rd-party SDK > directories which contain separate targets. > 5) Fix proper integration for entitlements and device settings The more I explore this, the more things are piling up :) and I believe the roadmap for better handling is quite huge. What I would be tempted to suggest is, if we can come up with a toolchain file that is general enough and properly document all the current shortcomings or the best practices, then it will gather attention and bring more people and resources into the discussion. This would be my first step * having different build trees for different sysroots is a workaround that should normally work * maybe promoting apple frameworks instead of "find_library" commands is the way to go for developing for iOS * fixing the small bugs there and there from the proposed toolchain will take time (eg. the try_compile thing that requires signing: I believe this should be a try_compile that understand that it is not meant for the final project but for an intermediate check, and signing in that case should not be required) * being able to distinguish program/libraries that are part of the build and the others that are part of the toolchain is currently not possible, without creating a dedicated toolchain file (maybe already in the documentation) etc etc. > * Extra: I haven't dealt with AppleTV and Apple Watch yet. I don't > know what extra things may be needed besides the LLVM IR "BitCode" > option. > > -Eric > > > P.S. I'm reaching a point where the codesiging is becoming a big > enough problem for me that I'm interested in fixing it. And I might be > able to dedicate some time to it. I saw some other people are already > ahead of me on this and have looked at it in more detail. I'm willing > to help out or collaborate. Please try what I suggested above. If that works for you, maybe we do not need to deal with that but rather have the right options in Xcode and have a consistent way for preparing the bundles. From csiga.biga at aol.com Fri Aug 18 06:04:06 2017 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Fri, 18 Aug 2017 12:04:06 +0200 Subject: [cmake-developers] C++ IDE In-Reply-To: References: Message-ID: Impressed with VSCode?? If I saw this post anywhere else than the CMake mailing list, I?d understand, but VSCode with CMake is horrible. The fact that in 2017 I have to set include directories, compiler definitions and target paths manually to have proper IntelliSense (Code navigation and syntax higlight) is absurd. As far as I saw Visual Studio 2017 has the best C/C++ experience with CMake. (Google: Visual Studio Open Folder support with CMake) Felad?: Wesley Smith Elk?ldve: 2017. augusztus 10., cs?t?rt?k 6:38 C?mzett: Ivam Pretti M?solatot kap: cmake-developers at cmake.org T?rgy: Re: [cmake-developers] C++ IDE I have been really impressed with VSCode. ? On Sun, Aug 6, 2017 at 1:52 PM, Ivam Pretti wrote: Can you recomend an IDE to code in C/C++? -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.anger at gmail.com Fri Aug 18 06:13:22 2017 From: matthew.anger at gmail.com (Matt Anger) Date: Fri, 18 Aug 2017 06:13:22 -0400 Subject: [cmake-developers] C++ IDE In-Reply-To: <20170818100907.5E26717B1@public.kitware.com> References: <20170818100907.5E26717B1@public.kitware.com> Message-ID: CLion works well. On Fri, Aug 18, 2017 at 6:04 AM, Nagy-Egri M?t? Ferenc via cmake-developers wrote: > Impressed with VSCode?? If I saw this post anywhere else than the CMake > mailing list, I?d understand, but VSCode with CMake is horrible. The fact > that in 2017 I have to set include directories, compiler definitions and > target paths manually to have proper IntelliSense (Code navigation and > syntax higlight) is absurd. > > > > As far as I saw Visual Studio 2017 has the best C/C++ experience with > CMake. (Google: Visual Studio Open Folder support with CMake) > > > > *Felad?: *Wesley Smith > *Elk?ldve: *2017. augusztus 10., cs?t?rt?k 6:38 > *C?mzett: *Ivam Pretti > *M?solatot kap: *cmake-developers at cmake.org > *T?rgy: *Re: [cmake-developers] C++ IDE > > > > I have been really impressed with VSCode . > > > > > On Sun, Aug 6, 2017 at 1:52 PM, Ivam Pretti > wrote: > > Can you recomend an IDE to code in C/C++? > > > -- > > 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 > > > > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanmichael.celerier at gmail.com Fri Aug 18 09:37:00 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Fri, 18 Aug 2017 15:37:00 +0200 Subject: [cmake-developers] C++ IDE In-Reply-To: <20170818100907.5E26717B1@public.kitware.com> References: <20170818100907.5E26717B1@public.kitware.com> Message-ID: > Visual Studio 2017 has the best C/C++ experience with CMake IMHO, Visual Studio's CMake integration is a joke in comparison to QtCreator and CLion. ------- Jean-Micha?l Celerier http://www.jcelerier.name On Fri, Aug 18, 2017 at 12:04 PM, Nagy-Egri M?t? Ferenc via cmake-developers wrote: > Impressed with VSCode?? If I saw this post anywhere else than the CMake > mailing list, I?d understand, but VSCode with CMake is horrible. The fact > that in 2017 I have to set include directories, compiler definitions and > target paths manually to have proper IntelliSense (Code navigation and > syntax higlight) is absurd. > > > > As far as I saw Visual Studio 2017 has the best C/C++ experience with > CMake. (Google: Visual Studio Open Folder support with CMake) > > > > *Felad?: *Wesley Smith > *Elk?ldve: *2017. augusztus 10., cs?t?rt?k 6:38 > *C?mzett: *Ivam Pretti > *M?solatot kap: *cmake-developers at cmake.org > *T?rgy: *Re: [cmake-developers] C++ IDE > > > > I have been really impressed with VSCode . > > > > > On Sun, Aug 6, 2017 at 1:52 PM, Ivam Pretti > wrote: > > Can you recomend an IDE to code in C/C++? > > > -- > > 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 > > > > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Fri Aug 18 11:45:44 2017 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri, 18 Aug 2017 11:45:44 -0400 Subject: [cmake-developers] C++ IDE In-Reply-To: References: <20170818100907.5E26717B1@public.kitware.com> Message-ID: <1194d4ab-ae8b-bc64-3b1e-9092dac7f86e@kitware.com> On 8/18/2017 9:37 AM, Jean-Micha?l Celerier wrote: > > IMHO, Visual Studio's CMake integration is a joke in comparison to > QtCreator and CLion. Microsoft has been working to fix that. https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-studio/ MS is shipping a version of CMake with VS, and are using the cmake-server to talk to CMake. They continue to improve this, so with new versions of VS, it should continue to get better. -Bill From mluparu at microsoft.com Fri Aug 18 13:40:41 2017 From: mluparu at microsoft.com (Marian Luparu) Date: Fri, 18 Aug 2017 17:40:41 +0000 Subject: [cmake-developers] C++ IDE In-Reply-To: <1194d4ab-ae8b-bc64-3b1e-9092dac7f86e@kitware.com> References: <20170818100907.5E26717B1@public.kitware.com> <1194d4ab-ae8b-bc64-3b1e-9092dac7f86e@kitware.com> Message-ID: Thanks Bill. With every update of Visual Studio 2017 (2017.3 is the latest as of this moment), we're striving to improve the experience. For a shorter summary of the advantages of using Visual Studio for CMake projects, you can also check the deep-link https://blogs.msdn.microsoft.com/visualstudio/2017/07/05/7-reasons-to-move-your-cpp-code-to-visual-studio-2017/#openfolder . We do have a few more things in the pipeline as we speak, so stay tuned on our blog in the next weeks. Jean-Micha?l, we're also always listening for feedback so if you think there are things missing in the experience today, do let us know! Hopefully we can pleasantly surprise you in the near future ? (if you prefer, you can DM me on twitter @mluparu or send me email at @microsoft.com). Thanks, Marian Luparu C++ Team / Visual Studio -----Original Message----- From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Bill Hoffman Sent: Friday, August 18, 2017 8:46 AM To: cmake-developers at cmake.org Subject: Re: [cmake-developers] C++ IDE [You don't often get email from BILL.HOFFMAN at KITWARE.COM, which appears similar to someone who has previously sent you email, but may not be that person. Learn why this may be a problem at http://aka.ms/LearnAboutSenderIdentification.] On 8/18/2017 9:37 AM, Jean-Micha?l Celerier wrote: > > IMHO, Visual Studio's CMake integration is a joke in comparison to > QtCreator and CLion. Microsoft has been working to fix that. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblogs.msdn.microsoft.com%2Fvcblog%2F2016%2F10%2F05%2Fcmake-support-in-visual-studio%2F&data=02%7C01%7Cmluparu%40microsoft.com%7Cf94f340e9a5d4796458a08d4e6503bd5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636386679731177870&sdata=ETfP9P0cSGG%2BBu6e0%2FtiiwisPPrkzdAYSEUmtJJpvH0%3D&reserved=0 MS is shipping a version of CMake with VS, and are using the cmake-server to talk to CMake. They continue to improve this, so with new versions of VS, it should continue to get better. -Bill -- Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Cmluparu%40microsoft.com%7Cf94f340e9a5d4796458a08d4e6503bd5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636386679731177870&sdata=cobIkEWZyrS9zrReufMU5MA7CoBiqNXJA1%2BCR6p6hoQ%3D&reserved=0 Please keep messages on-topic and check the CMake FAQ at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cmake.org%2FWiki%2FCMake_FAQ&data=02%7C01%7Cmluparu%40microsoft.com%7Cf94f340e9a5d4796458a08d4e6503bd5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636386679731177870&sdata=thV47vz%2BivPyXgeNXAejvVp5vtfCz6zm76QYbAlEoOQ%3D&reserved=0 Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fsupport.html&data=02%7C01%7Cmluparu%40microsoft.com%7Cf94f340e9a5d4796458a08d4e6503bd5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636386679731177870&sdata=eLnsgK%2BNwUalQJmisJ5T5vaYcTSd%2F%2Bc9XTTno9K2qGA%3D&reserved=0 CMake Consulting: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fconsulting.html&data=02%7C01%7Cmluparu%40microsoft.com%7Cf94f340e9a5d4796458a08d4e6503bd5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636386679731177870&sdata=UuLfbdA5en0kp7zG%2BvycOYWsgSMmZ2UwihFtVmmJ%2Fow%3D&reserved=0 CMake Training Courses: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Ftraining.html&data=02%7C01%7Cmluparu%40microsoft.com%7Cf94f340e9a5d4796458a08d4e6503bd5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636386679731177870&sdata=U1%2F3i5Sm1SmlsxhAFFoHfW6iToseZlZndBScuaWFNeo%3D&reserved=0 Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Cmluparu%40microsoft.com%7Cf94f340e9a5d4796458a08d4e6503bd5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636386679731177870&sdata=P%2Bvp0nAyvEwr7%2BDjPkHlxznlf%2BxREEwji9S1JuUFPo0%3D&reserved=0 Follow this link to subscribe/unsubscribe: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fcmake-developers&data=02%7C01%7Cmluparu%40microsoft.com%7Cf94f340e9a5d4796458a08d4e6503bd5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636386679731177870&sdata=wFxnD5rZLaX5BT%2Bz1fBLkz0wJvMbosynqJNzSZ27Q%2Bw%3D&reserved=0 From ivamprettimn at gmail.com Sat Aug 19 17:00:16 2017 From: ivamprettimn at gmail.com (Ivam Pretti) Date: Sat, 19 Aug 2017 18:00:16 -0300 Subject: [cmake-developers] Ram Memory Map Message-ID: Could you tell me where can I find a memory map for computers to put at a pointers adress? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Aug 21 07:47:10 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Aug 2017 07:47:10 -0400 Subject: [cmake-developers] Best practice for providing inputs to find modules In-Reply-To: References: Message-ID: On 08/17/2017 12:20 PM, Anh Huynh wrote: > If I want the user to provide inputs to select GPU targets [snip]> Should I have the user set a definition before using find_package> and checking for that definition? Yes. Document it as an input variable that can be set prior to the call. Either the calling package or even the end user running CMake could set it. > Should I simply have the user add the relevant flags themselves? Ideally not. The caller of find_package(OpenACC) is always free to ignore your results and add its own flags. It shouldn't have to know all the flags for various toolchains. > Should I provide some variable that would contain the correct flag> so the user can use it to append to his flags? Yes. The caller of find_package(OpenACC) should use the variable to add the flags to relevant parts of the project. -Brad From seblist at xwmw.org Mon Aug 21 09:53:11 2017 From: seblist at xwmw.org (Sebastian Holtermann) Date: Mon, 21 Aug 2017 15:53:11 +0200 Subject: [cmake-developers] C++11 all features available? Message-ID: <4321953.VCFRNCmHch@blauwal> Hi, it looks like C++11 is now a requirement for CMake itself. That's good news. But does this mean *all* the nice features from the std library can be used? I'm especially interested in - std::array - std::basic_regex (and friends) - std::thread (and friends) - std::atomic_flag -Sebastian From brad.king at kitware.com Mon Aug 21 10:04:28 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Aug 2017 10:04:28 -0400 Subject: [cmake-developers] C++11 all features available? In-Reply-To: <4321953.VCFRNCmHch@blauwal> References: <4321953.VCFRNCmHch@blauwal> Message-ID: <6dba0869-e20d-4c8d-194b-31d36f454578@kitware.com> On 08/21/2017 09:53 AM, Sebastian Holtermann wrote: > it looks like C++11 is now a requirement for CMake itself. Yes. We just merged this: https://gitlab.kitware.com/cmake/cmake/merge_requests/1132 but you beat us to the announcement. > But does this mean *all* the nice features from the std library can be used? Not all. We're still limited by some of the older C++11 compilers. We'll have to see how things go on nightly builds. As limitations are found they can be documented in `Help/dev/source.rst`. We will require std::unique_ptr at least. > - std::array I think so but haven't tried it. > - std::basic_regex (and friends) We still support GCC 4.8. IIRC its standard library doesn't have the implementations in place. > - std::thread (and friends) No, at least not yet. For now we're using libuv's thread primitives instead. Either way anything that needs to build during bootstrap may not be able to use this. > - std::atomic_flag Not sure. -Brad From ben.boeckel at kitware.com Mon Aug 21 10:12:26 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 21 Aug 2017 10:12:26 -0400 Subject: [cmake-developers] C++11 all features available? In-Reply-To: <4321953.VCFRNCmHch@blauwal> References: <4321953.VCFRNCmHch@blauwal> Message-ID: <20170821141226.GA32063@megas.kitware.com> On Mon, Aug 21, 2017 at 15:53:11 +0200, Sebastian Holtermann wrote: > - std::array I don't see why not. > - std::basic_regex (and friends) Note that we require backwards compat with the old regex engine, so this one needs to be used carefully and only on internal uses. > - std::thread (and friends) > - std::atomic_flag CMake uses threads? ;) --Ben From seblist at xwmw.org Mon Aug 21 10:32:56 2017 From: seblist at xwmw.org (Sebastian Holtermann) Date: Mon, 21 Aug 2017 16:32:56 +0200 Subject: [cmake-developers] C++11 all features available? In-Reply-To: <6dba0869-e20d-4c8d-194b-31d36f454578@kitware.com> References: <4321953.VCFRNCmHch@blauwal> <6dba0869-e20d-4c8d-194b-31d36f454578@kitware.com> Message-ID: <6481911.x988HAQUDo@blauwal> Am Montag, 21. August 2017, 10:04:28 CEST schrieben Sie: > On 08/21/2017 09:53 AM, Sebastian Holtermann wrote: > > it looks like C++11 is now a requirement for CMake itself. > > Yes. We just merged this: > > https://gitlab.kitware.com/cmake/cmake/merge_requests/1132 > > but you beat us to the announcement. I saw the MR last week and was delighted. The iterator type naming in `for` loops drove me mad. > > But does this mean *all* the nice features from the std library can be > > used? > Not all. We're still limited by some of the older C++11 compilers. > We'll have to see how things go on nightly builds. As limitations > are found they can be documented in `Help/dev/source.rst`. > > We will require std::unique_ptr at least. > > > - std::array > > I think so but haven't tried it. > > > - std::basic_regex (and friends) > > We still support GCC 4.8. IIRC its standard library doesn't have > the implementations in place. That's a pitty, because cmsys::RegularExpression isn't thread safe. Although it might be possible to make it so in a reasonable amount of time > > - std::thread (and friends) > > No, at least not yet. For now we're using libuv's thread primitives > instead. Either way anything that needs to build during bootstrap > may not be able to use this. > > > - std::atomic_flag Thread support would be nice because Autogen could be parallelized perfectly. Only it would require several utility methods to be thread safe as well. Many likely aren't though. I'll have a look at libuv. -Sebastian From seblist at xwmw.org Mon Aug 21 10:46:56 2017 From: seblist at xwmw.org (Sebastian Holtermann) Date: Mon, 21 Aug 2017 16:46:56 +0200 Subject: [cmake-developers] C++11 all features available? In-Reply-To: <20170821141226.GA32063@megas.kitware.com> References: <4321953.VCFRNCmHch@blauwal> <20170821141226.GA32063@megas.kitware.com> Message-ID: <1941834.TPad8vUZWG@blauwal> Am Montag, 21. August 2017, 10:12:26 CEST schrieb Ben Boeckel: > On Mon, Aug 21, 2017 at 15:53:11 +0200, Sebastian Holtermann wrote: > > - std::array > > I don't see why not. > > > - std::basic_regex (and friends) > > Note that we require backwards compat with the old regex engine, so this > one needs to be used carefully and only on internal uses. > > > - std::thread (and friends) > > - std::atomic_flag > > CMake uses threads? ;) Well, a search for "thread" didn't return much. I was toying with the idea to parallelize Autogen but I couldn't find a proper solution that uses the existing target/custom_command primitives. So why not doing it all in the FOO_autogen target itself, which is a black box to the user anyway. Thread pools are an option here. But as mentioned in an other post, that would required several of CMake's utility functions to be thread safe as well... -Sebastian From jeanmichael.celerier at gmail.com Mon Aug 21 11:05:02 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Mon, 21 Aug 2017 17:05:02 +0200 Subject: [cmake-developers] C++11 all features available? In-Reply-To: <6481911.x988HAQUDo@blauwal> References: <4321953.VCFRNCmHch@blauwal> <6dba0869-e20d-4c8d-194b-31d36f454578@kitware.com> <6481911.x988HAQUDo@blauwal> Message-ID: > Thread support would be nice because Autogen could be parallelized perfectly. oh please yes. moc generation is almost 10% of my build time. ------- Jean-Micha?l Celerier http://www.jcelerier.name On Mon, Aug 21, 2017 at 4:32 PM, Sebastian Holtermann wrote: > Am Montag, 21. August 2017, 10:04:28 CEST schrieben Sie: > > On 08/21/2017 09:53 AM, Sebastian Holtermann wrote: > > > it looks like C++11 is now a requirement for CMake itself. > > > > Yes. We just merged this: > > > > https://gitlab.kitware.com/cmake/cmake/merge_requests/1132 > > > > but you beat us to the announcement. > > I saw the MR last week and was delighted. The iterator type naming in `for` > loops drove me mad. > > > > But does this mean *all* the nice features from the std library can be > > > used? > > Not all. We're still limited by some of the older C++11 compilers. > > We'll have to see how things go on nightly builds. As limitations > > are found they can be documented in `Help/dev/source.rst`. > > > > We will require std::unique_ptr at least. > > > > > - std::array > > > > I think so but haven't tried it. > > > > > - std::basic_regex (and friends) > > > > We still support GCC 4.8. IIRC its standard library doesn't have > > the implementations in place. > > That's a pitty, because cmsys::RegularExpression isn't thread safe. > Although it might be possible to make it so in a reasonable amount of time > > > > - std::thread (and friends) > > > > No, at least not yet. For now we're using libuv's thread primitives > > instead. Either way anything that needs to build during bootstrap > > may not be able to use this. > > > > > - std::atomic_flag > > Thread support would be nice because Autogen could be parallelized > perfectly. > Only it would require several utility methods to be thread safe as well. > Many > likely aren't though. I'll have a look at libuv. > > -Sebastian > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forumer at smartmobili.com Mon Aug 21 16:16:28 2017 From: forumer at smartmobili.com (Forumer 4umer) Date: Mon, 21 Aug 2017 22:16:28 +0200 Subject: [cmake-developers] Update on toolset Clang with Microsoft CodeGen (v140_clang_c2) debug is broken Message-ID: Hi, I posted on 2016/05/02 about the fact that when generating Visual projects for clang_c2 debug was broken. The answer was: "Basically we need to have a different flag table for each possible toolset. Also it looks like additional special handling may be needed for PDBs and perhaps other limitations of the Clang/C2 toolchain." I just wanted to know if you had any progress about that ? I suppose that only a few people in the world are using it or need to debug but in my case I am wasting too much time with this. Thanks From egor.pugin at gmail.com Mon Aug 21 19:09:43 2017 From: egor.pugin at gmail.com (Egor Pugin) Date: Tue, 22 Aug 2017 02:09:43 +0300 Subject: [cmake-developers] Update on toolset Clang with Microsoft CodeGen (v140_clang_c2) debug is broken In-Reply-To: References: Message-ID: Clang/C2 is abandoned by MS. Look for some reddit posts by STL there. Clang/LLVM (5.0+) must be used with the VS2017(.3?) and higher. On older versions you can easily get endless list of errors. CMake needs to be tuned in terms of command line flags. I saw the same issue today. See ticket https://gitlab.kitware.com/cmake/cmake/issues/17193 On 21 August 2017 at 23:16, Forumer 4umer wrote: > Hi, > > I posted on 2016/05/02 about the fact that when generating Visual projects > for clang_c2 debug was broken. > The answer was: > > "Basically we need to have a different flag table for each possible > toolset. Also it looks like additional special handling may be > needed for PDBs and perhaps other limitations of the Clang/C2 > toolchain." > > I just wanted to know if you had any progress about that ? > I suppose that only a few people in the world are using it or need to debug > but in my case I am wasting too much time with this. > > Thanks > -- > > 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 -- Egor Pugin From csiga.biga at aol.com Tue Aug 22 03:03:18 2017 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Tue, 22 Aug 2017 09:03:18 +0200 Subject: [cmake-developers] C++ IDE In-Reply-To: References: <20170818100907.5E26717B1@public.kitware.com> Message-ID: I do not find it to be a joke, rather than being one of the best out there (if not THE best). I tried CLion just 2 weeks ago. It was a nice experience when it came to CMake, but it?s C++ IntelliSense capabilities seem to be lacking. (Truth be told, I did try with the experimental MSVC support, so I do plan to revisit CLion once that is baked.) The thing I did not like about CLion is that it tries to cater the click-click way of getting a build ready, but does not go all the way (nor even half the way). I tried getting a build ready of one ?src/Main.cpp? and a ?inc/Header.hpp? (I believe this is the most common source file organization), but I failed to add the ?target_include_directories? statement through the UI. So, if CLion caters those who wish to add source files through the UI, which even prompts for a CMake variable to add the source file to, and even follows along the lines of changing the CMake script when one relocates files through the UI? then why can?t I set something as simple as an include directory through the UI??? I believe the problem CLion got caught in is that it is very hard (if not impossible) to wrap a UI around a stateful, imperative language with also letting the user edit the CMakeLists.txt file. VS had a much easier job with MSBuild (an XML-based build system), but with CMake, it?s much harder. This was one of the reasons I suggested roughly a year ago to create an IR for CMake (to decouple generators from the front-end, and also facilitate IDE interop). So all in all, I considered VS to be a nicer, more consistent overall experience than the one in CLion. I have not tried Qt Creator yet (I know it was among the first to adopt cmake-server), but will do soon, as I will also revisit CLion once they call the MSVC experience baked. ps.: I found it strange that CLion still seems to rely on Codeblock NMake Makefiles for both executing a build AND also hooking the IntelliSense experience into the IDE. Correct me if I?m wrong, but I thought CLion will be the first to adopt cmake-server. ps2.: Big brother VS is already at executing builds with Ninja by default. ps3.: once this (link) issue is fixed in relation to the cmake-tools extension, I?ll consider VS Code for serious work. It has other nice benefits that big brother VS does not. Felad?: Jean-Micha?l Celerier Elk?ldve: 2017. augusztus 18., p?ntek 15:37 C?mzett: Nagy-Egri M?t? Ferenc M?solatot kap: CMake Developers T?rgy: Re: [cmake-developers] C++ IDE > Visual Studio 2017 has the best C/C++ experience with CMake IMHO, Visual Studio's CMake integration is a joke in comparison to QtCreator and CLion. ------- Jean-Micha?l Celerier http://www.jcelerier.name On Fri, Aug 18, 2017 at 12:04 PM, Nagy-Egri M?t? Ferenc via cmake-developers wrote: Impressed with VSCode?? If I saw this post anywhere else than the CMake mailing list, I?d understand, but VSCode with CMake is horrible. The fact that in 2017 I have to set include directories, compiler definitions and target paths manually to have proper IntelliSense (Code navigation and syntax higlight) is absurd. ? As far as I saw Visual Studio 2017 has the best C/C++ experience with CMake. (Google: Visual Studio Open Folder support with CMake) ? Felad?: Wesley Smith Elk?ldve: 2017. augusztus 10., cs?t?rt?k 6:38 C?mzett: Ivam Pretti M?solatot kap: cmake-developers at cmake.org T?rgy: Re: [cmake-developers] C++ IDE ? I have been really impressed with VSCode. ? ? On Sun, Aug 6, 2017 at 1:52 PM, Ivam Pretti wrote: Can you recomend an IDE to code in C/C++? -- 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 ? ? -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pfeifer-mail.de Tue Aug 22 17:57:45 2017 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Tue, 22 Aug 2017 23:57:45 +0200 Subject: [cmake-developers] C++11 all features available? In-Reply-To: <6481911.x988HAQUDo@blauwal> References: <4321953.VCFRNCmHch@blauwal> <6dba0869-e20d-4c8d-194b-31d36f454578@kitware.com> <6481911.x988HAQUDo@blauwal> Message-ID: On Mon, Aug 21, 2017 at 4:32 PM, Sebastian Holtermann wrote: > Am Montag, 21. August 2017, 10:04:28 CEST schrieben Sie: > > On 08/21/2017 09:53 AM, Sebastian Holtermann wrote: > > > it looks like C++11 is now a requirement for CMake itself. > > > > Yes. We just merged this: > > > > https://gitlab.kitware.com/cmake/cmake/merge_requests/1132 > > > > but you beat us to the announcement. > > I saw the MR last week and was delighted. The iterator type naming in `for` > loops drove me mad. Feel free to use `auto`, but you will need to hold off range based for loops. > > > But does this mean *all* the nice features from the std library can be > > > used? > > Not all. We're still limited by some of the older C++11 compilers. > > We'll have to see how things go on nightly builds. As limitations > > are found they can be documented in `Help/dev/source.rst`. > Please have a look at the nightly testers on https://open.cdash.org/index.php?project=CMake and compare the feature availability here: Please see http://en.cppreference.com/w/cpp/compiler_support Currently CMake is still built with Visual Studio 2010, ie. MSVC 16.0. That means we should be able to use auto, nullptr, lambdas, std::array, std::function, type traits, trailing return types, r-values, ... Cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From seblist at xwmw.org Wed Aug 23 04:41:11 2017 From: seblist at xwmw.org (Sebastian Holtermann) Date: Wed, 23 Aug 2017 10:41:11 +0200 Subject: [cmake-developers] C++11 all features available? In-Reply-To: References: <4321953.VCFRNCmHch@blauwal> <6481911.x988HAQUDo@blauwal> Message-ID: <5470057.iyn36OP1qd@blauwal> > > > > it looks like C++11 is now a requirement for CMake itself. > > > > > > Yes. We just merged this: > > > https://gitlab.kitware.com/cmake/cmake/merge_requests/1132 > > > > > > but you beat us to the announcement. > > > > I saw the MR last week and was delighted. The iterator type naming in > > `for` > > loops drove me mad. > > Feel free to use `auto`, but you will need to hold off range based for > loops. Okay, that's nice. Just to say, even without auto for (const std::string& item : lst) { ... } is easier to comprehend than for (std::vector::const_iterator it = lst.begin(); it != lst.end(); ++it) { const std::string& item = *it; ... } which is as C++(98) as can be. > > > > But does this mean *all* the nice features from the std library can be > > > > used? > > > > > > Not all. We're still limited by some of the older C++11 compilers. > > > We'll have to see how things go on nightly builds. As limitations > > > are found they can be documented in `Help/dev/source.rst`. > > Please have a look at the nightly testers on > https://open.cdash.org/index.php?project=CMake and compare the feature > availability here: Please see > http://en.cppreference.com/w/cpp/compiler_support > > Currently CMake is still built with Visual Studio 2010, ie. MSVC 16.0. > > That means we should be able to use auto, nullptr, lambdas, std::array, > std::function, type traits, trailing return types, r-values, ... Very nice. C++11 was such a great improvement to the language. It's much more fun to work with. Even with the slightly limited feature set available in CMake. -Sebastian From craig.scott at crascit.com Wed Aug 23 05:15:44 2017 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 23 Aug 2017 17:15:44 +0800 Subject: [cmake-developers] C++11 all features available? In-Reply-To: <5470057.iyn36OP1qd@blauwal> References: <4321953.VCFRNCmHch@blauwal> <6481911.x988HAQUDo@blauwal> <5470057.iyn36OP1qd@blauwal> Message-ID: Probably just asking what a number of people are now thinking, but if we're now requiring C++11 to build CMake, how long until we up the minimum Visual Studio version from 2010 to at least 2013? Seems a bit optimistic to still be trying to support 2010 as the minimum standard and also state C++11 as a minimum. On Wed, Aug 23, 2017 at 4:41 PM, Sebastian Holtermann wrote: > > > > > it looks like C++11 is now a requirement for CMake itself. > > > > > > > > Yes. We just merged this: > > > > https://gitlab.kitware.com/cmake/cmake/merge_requests/1132 > > > > > > > > but you beat us to the announcement. > > > > > > I saw the MR last week and was delighted. The iterator type naming in > > > `for` > > > loops drove me mad. > > > > Feel free to use `auto`, but you will need to hold off range based for > > loops. > > Okay, that's nice. > Just to say, even without auto > > for (const std::string& item : lst) { > ... > } > > is easier to comprehend than > > for (std::vector::const_iterator it = lst.begin(); > it != lst.end(); ++it) { > const std::string& item = *it; > ... > } > > which is as C++(98) as can be. > > > > > > But does this mean *all* the nice features from the std library > can be > > > > > used? > > > > > > > > Not all. We're still limited by some of the older C++11 compilers. > > > > We'll have to see how things go on nightly builds. As limitations > > > > are found they can be documented in `Help/dev/source.rst`. > > > > Please have a look at the nightly testers on > > https://open.cdash.org/index.php?project=CMake and compare the feature > > availability here: Please see > > http://en.cppreference.com/w/cpp/compiler_support > > > > Currently CMake is still built with Visual Studio 2010, ie. MSVC 16.0. > > > > That means we should be able to use auto, nullptr, lambdas, std::array, > > std::function, type traits, trailing return types, r-values, ... > > Very nice. C++11 was such a great improvement to the language. > It's much more fun to work with. Even with the slightly limited > feature set available in CMake. > > -Sebastian > > -- > > 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 > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Aug 23 07:32:02 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Aug 2017 07:32:02 -0400 Subject: [cmake-developers] C++11 all features available? In-Reply-To: References: <4321953.VCFRNCmHch@blauwal> <6481911.x988HAQUDo@blauwal> <5470057.iyn36OP1qd@blauwal> Message-ID: <4f14fb18-71c0-87f3-ba69-44b766efa80c@kitware.com> On 08/23/2017 05:15 AM, Craig Scott wrote: > how long until we up the minimum Visual Studio version from 2010 > to at least 2013? That's only blocked on me finding time to update the nightly testing infrastructure. It requires moving several builds to other machines. -Brad From maikelvandenhurk at hotmail.com Wed Aug 23 09:56:03 2017 From: maikelvandenhurk at hotmail.com (maikel van den Hurk) Date: Wed, 23 Aug 2017 13:56:03 +0000 Subject: [cmake-developers] Extend CMAKE__FLAGS(_) from a CMake Toolchain Message-ID: I was wondering why there is no ability to define CMAKE__FLAGS(_) within a CMake Toolchain file, but still benefit from the CMAKE__INIT_FLAGS(_) detected from CMake internals. Is certain extension considered before? Or are then any reasons to not do this? Would be interested to hear if this is possible or not? If yes would this be a welcome addition in the CMake core. Thanks, Maikel -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Aug 23 10:18:57 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Aug 2017 10:18:57 -0400 Subject: [cmake-developers] Extend CMAKE__FLAGS(_) from a CMake Toolchain In-Reply-To: References: Message-ID: On 08/23/2017 09:56 AM, maikel van den Hurk wrote: > I was wondering why there is no ability to define CMAKE__FLAGS(_) within a CMake Toolchain file, but still benefit from the CMAKE__INIT_FLAGS(_) detected from CMake internals. This has been possible since commit v3.7.0-rc1~392^2 (Honor CMAKE__FLAGS[_]_INIT set in toolchain files, 2016-07-05). See the CMake 3.7 release notes: https://cmake.org/cmake/help/v3.9/release/3.7.html#variables "Toolchain files may now set a CMAKE__FLAGS_INIT variable to initialize the CMAKE__FLAGS cache entry the first time a language is enabled in a build tree." See documentation here: https://cmake.org/cmake/help/v3.9/variable/CMAKE_LANG_FLAGS_INIT.html -Brad From maikelvandenhurk at hotmail.com Wed Aug 23 11:27:44 2017 From: maikelvandenhurk at hotmail.com (maikel van den Hurk) Date: Wed, 23 Aug 2017 15:27:44 +0000 Subject: [cmake-developers] Extend CMAKE__FLAGS(_) from a CMake Toolchain In-Reply-To: References: , Message-ID: Thanks I was exactly looking for this in particularly, must have searched wrongly! Though I wonder for example how could I for example change in my toolchain file which is setting up a GCC based compiler for example in release context the optimisation from O3 (CMake internal setting) to O2. It seems that there is mainly done appending instead of prepending to the FLAGS_INIT. Where generally speaking in context of GCC the last defined flag will be used, so how to deal properly with that? ________________________________ Van: Brad King Verzonden: woensdag 23 augustus 2017 16:18 Aan: maikel van den Hurk; cmake-developers at cmake.org Onderwerp: Re: [cmake-developers] Extend CMAKE__FLAGS(_) from a CMake Toolchain On 08/23/2017 09:56 AM, maikel van den Hurk wrote: > I was wondering why there is no ability to define CMAKE__FLAGS(_) within a CMake Toolchain file, but still benefit from the CMAKE__INIT_FLAGS(_) detected from CMake internals. This has been possible since commit v3.7.0-rc1~392^2 (Honor CMAKE__FLAGS[_]_INIT set in toolchain files, 2016-07-05). See the CMake 3.7 release notes: https://cmake.org/cmake/help/v3.9/release/3.7.html#variables CMake 3.7 Release Notes ? CMake 3.9.1 Documentation cmake.org Generators ? The Ninja generator learned to conditionally support Fortran when using a ninja tool that has the necessary features. See generator documentation for ... "Toolchain files may now set a CMAKE__FLAGS_INIT variable to initialize the CMAKE__FLAGS cache entry the first time a language is enabled in a build tree." See documentation here: https://cmake.org/cmake/help/v3.9/variable/CMAKE_LANG_FLAGS_INIT.html CMAKE__FLAGS_INIT ? CMake 3.9.0 Documentation cmake.org CMAKE__FLAGS_INIT? Value used to initialize the CMAKE__FLAGS cache entry the first time a build tree is configured for language . -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Aug 23 11:33:25 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Aug 2017 11:33:25 -0400 Subject: [cmake-developers] Extend CMAKE__FLAGS(_) from a CMake Toolchain In-Reply-To: References: Message-ID: <449043b8-72b2-52de-ba0c-020bd671c4ab@kitware.com> On 08/23/2017 11:27 AM, maikel van den Hurk wrote: > change ... optimisation from O3 (CMake internal setting) to O2. If you want to change the default flags instead of only adding (prepending) to them then you need to set all the flags by setting the cache entry directly. A toolchain file that wants such control should be setting all the flags anyway. -Brad From maikelvandenhurk at hotmail.com Wed Aug 23 12:51:56 2017 From: maikelvandenhurk at hotmail.com (maikel van den Hurk) Date: Wed, 23 Aug 2017 16:51:56 +0000 Subject: [cmake-developers] Extend CMAKE__FLAGS(_) from a CMake Toolchain In-Reply-To: <449043b8-72b2-52de-ba0c-020bd671c4ab@kitware.com> References: , <449043b8-72b2-52de-ba0c-020bd671c4ab@kitware.com> Message-ID: That would mean a lot of duplication for just redefining a particular value. Each compiler will have likely a way too handle the definition of multiple flags with the same purpose and based on that prepending or adding could be performed internally. ________________________________ Van: Brad King Verzonden: woensdag 23 augustus 2017 17:33:25 Aan: maikel van den Hurk CC: cmake-developers at cmake.org Onderwerp: Re: [cmake-developers] Extend CMAKE__FLAGS(_) from a CMake Toolchain On 08/23/2017 11:27 AM, maikel van den Hurk wrote: > change ... optimisation from O3 (CMake internal setting) to O2. If you want to change the default flags instead of only adding (prepending) to them then you need to set all the flags by setting the cache entry directly. A toolchain file that wants such control should be setting all the flags anyway. -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From seblist at xwmw.org Wed Aug 23 17:56:54 2017 From: seblist at xwmw.org (Sebastian Holtermann) Date: Wed, 23 Aug 2017 23:56:54 +0200 Subject: [cmake-developers] PRE_BUILD misconception Message-ID: <1564642.3qDOF2BNQy@blauwal> It seems that in CMake 3.9/AUTOGEN the VS generator uses the *_autogen target more often than necessary (it could use PRE_BUILD instead). Let's assume a target `B` that depends on - a *GENERATED* file `FA` - a linked library `LA` - a utility target `TA` (via `add_dependencies()`) Using the VS generator, will `FA`, `LA` and `TA` be built completely before target B executes it's PRE_BUILD? I'm asking because it's important to know when to PRE_BUILD can be used for AUTOGEN. -Sebastian From ianmalcom at gmail.com Thu Aug 24 03:19:42 2017 From: ianmalcom at gmail.com (Manu) Date: Thu, 24 Aug 2017 09:19:42 +0200 Subject: [cmake-developers] Windows symbolic links handling In-Reply-To: References: Message-ID: Hello, I have fixed it but I am struggling with the new policy. The behaviour change goes into cmSystemTools::GetRealPath implementation and SystemTools has no context, so I am not sure how to check the policy. Mimicking policy CMP0067 usage, I could create an old and a new version of GetRealPath and check for the policy prior calling it all along the code. On the other hand, I could pass the policy status as a parameter to every GetRealPath call. Which is the proper way? To perform a pull request, should I previously open an issue about this or it is enough with the discusion here in the mailing list. Regards. 2017-08-16 11:35 GMT+02:00 Manu : > > > 2017-08-15 16:43 GMT+02:00 Brad King : > >> On 08/14/2017 06:35 AM, Manu wrote: >> > Recently I migrated from cmake 2.8.12 to cmake 3.8 and FILE(TIMESTAMP >> ...) >> > behaviour changed. Now it reports symbolic link timestamp instead of >> pointed >> > file timestamp. >> >> Can you track down when that happened? >> >> > I happened in release 3.1.0, back 2014. The commit which changed behaviour > was this: > > https://github.com/Kitware/CMake/commit/9571214e55cb8b86dadb26b6b1d696 > ef488bdd4b > > In source file Source/cmTimestamp.cxx, stat call was replaced by kwsys ModifiedTime > call. kwsys relies in system function GetFileAttributesExW which do not > resolve symlinks, however stat does (in spite of not being documentented in > MSDN). > > Removing the #ifdef WIN32 clause in ModifiedTime and using stat call > resolves the problem, nevertheless, this change does not resolves > get_filename_compoment symlinks issue in Windows. The problem here is again > in kwsys, which uses system call GetFullPathNameW (which do not resolves > symlinks) instead of GetFinalPathNameByHandleW (which does). > > Despite of being two different commands, I think they are very related in > this issue and the change should be make together. > > >> > patch to fix both get_filename_compoment and FILE(TIMESTAMP ...) >> > >> > What troubles me is that symlink under Windows is a feature introduced >> in >> > Windows Vista and the change for handling them will break Windows XP >> > compatibility. Is this acceptable? >> >> We still support running on XP. If any newer Windows APIs are needed they >> need to be looked up dynamically. Also, behavior changes for existing >> commands >> may need a policy. >> >> > I did not dig into cmake policies development but I am willing to submit a > patch which includes a new policy as soon I can piece it up all together. > > >> See also https://gitlab.kitware.com/cmake/cmake/issues/16926 for >> discussion >> of symbolic link APIs. >> >> -Brad >> > > Manuel. > -- La victoria puede ser creada - Sun Tzu. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Aug 24 07:48:48 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 24 Aug 2017 07:48:48 -0400 Subject: [cmake-developers] PRE_BUILD misconception In-Reply-To: <1564642.3qDOF2BNQy@blauwal> References: <1564642.3qDOF2BNQy@blauwal> Message-ID: On 08/23/2017 05:56 PM, Sebastian Holtermann wrote: > It seems that in CMake 3.9/AUTOGEN the VS generator uses the *_autogen > target more often than necessary (it could use PRE_BUILD instead). > > Let's assume a target `B` that depends on > - a *GENERATED* file `FA` > - a linked library `LA` > - a utility target `TA` (via `add_dependencies()`) > > Using the VS generator, will `FA`, `LA` and `TA` be built completely before > target B executes it's PRE_BUILD? Target-level dependencies will be completely finished, including their POST_BUILD if any, before the PRE_BUILD of a dependent target begins. In your list above, `LA` and `TA` will definitely be built before `B` starts. For the generated file `FA`, it depends whether the custom command is attached to `B` or not. If it is inside `B` then it won't generate until after PRE_BUILD is done. PRE_BUILD in VS means "if any files associated with this .vcxproj are about to be built due to updated dependencies or missing outputs, then run this pre-build command first". -Brad From brad.king at kitware.com Thu Aug 24 07:55:11 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 24 Aug 2017 07:55:11 -0400 Subject: [cmake-developers] Windows symbolic links handling In-Reply-To: References: Message-ID: <816dc2a0-e576-3155-48b2-f038a238c805@kitware.com> On 08/24/2017 03:19 AM, Manu wrote: > I have fixed it but I am struggling with the new policy. The > behaviour change goes into cmSystemTools::GetRealPath implementation > and SystemTools has no context, so I am not sure how to check the policy. The policy would have to be checked higher in the stack and used to choose alternative implementations. > Mimicking policy CMP0067 usage, I could create an old and a new version > of GetRealPath and check for the policy prior calling it all along the code. > On the other hand, I could pass the policy status as a parameter to every > GetRealPath call. Which is the proper way? Likely a second API would be needed. The KWSys GetRealPath could be taught to handle symlinks on Windows. If it turns out a policy is needed then a cmSystemTools:: alternative in CMake only could be added. > To perform a pull request, should I previously open an issue about > this or it is enough with the discusion here in the mailing list. For reference, this issue has been opened: https://gitlab.kitware.com/cmake/cmake/issues/17206 I think we can try this without a policy first. Thanks, -Brad From seblist at xwmw.org Thu Aug 24 08:04:20 2017 From: seblist at xwmw.org (Sebastian Holtermann) Date: Thu, 24 Aug 2017 14:04:20 +0200 Subject: [cmake-developers] PRE_BUILD misconception In-Reply-To: References: <1564642.3qDOF2BNQy@blauwal> Message-ID: <2466323.4fZTRVQBpO@blauwal> Am Donnerstag, 24. August 2017, 07:48:48 CEST schrieb Brad King: > On 08/23/2017 05:56 PM, Sebastian Holtermann wrote: > > It seems that in CMake 3.9/AUTOGEN the VS generator uses the *_autogen > > target more often than necessary (it could use PRE_BUILD instead). > > > > Let's assume a target `B` that depends on > > > > - a *GENERATED* file `FA` > > - a linked library `LA` > > - a utility target `TA` (via `add_dependencies()`) > > > > Using the VS generator, will `FA`, `LA` and `TA` be built completely > > before > > target B executes it's PRE_BUILD? > > Target-level dependencies will be completely finished, including their > POST_BUILD if any, before the PRE_BUILD of a dependent target begins. > In your list above, `LA` and `TA` will definitely be built before `B` > starts. For the generated file `FA`, it depends whether the custom > command is attached to `B` or not. If it is inside `B` then it won't > generate until after PRE_BUILD is done. Okay, thanks. That will help to fix https://gitlab.kitware.com/cmake/cmake/issues/17205 -Sebastian From eric.noulard at gmail.com Fri Aug 25 09:53:30 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 25 Aug 2017 15:53:30 +0200 Subject: [cmake-developers] Dependency graph in server mode? Message-ID: Hi there, Is it possible to get the dependency graph one can get with the --graphviz option when running in server mode. >From my understanding the current "codeModel" message does not contain such information. Am I right? If I wanted to add the dependency information would it be better to create a new server mode message or put that into current "codeModel"? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Fri Aug 25 12:21:50 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 25 Aug 2017 11:21:50 -0500 Subject: [cmake-developers] Should configuration package files define module package variables? Message-ID: So I've been studying the find_package[1] and "creating packages"[2] documentation, as well as the CMakePackageConfigHelpers[3] page. Based on the current offerings of configuration packages, I do not understand the need for the relocatable config.cmake file when all it really contains is: include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake) However, what I'm wondering is even though the import targets should contain all information about include directories, libraries, etc, should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES variables? Example of what foo-config.cmake would be like: include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake) set( Foo_INCLUDE_DIRS "... path here...." ) set( Foo_LIBRARIES "List of libraries here..." ) Is this necessary? Honestly the learning curve for creating packages for find_package is very steep. I did not see any general advice on this kind of stuff. It seems like Module packages are being deprecated in favor of Config packages, because it puts the responsibility of maintaining find package logic on the upstream maintainer (config package) instead of on CMake (module packages it ships with). Thanks in advance for any help. From rcdailey.lists at gmail.com Fri Aug 25 12:22:52 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 25 Aug 2017 11:22:52 -0500 Subject: [cmake-developers] Should configuration package files define module package variables? In-Reply-To: References: Message-ID: Doh, forgot the links I intended to reference in my original email: [1]: https://cmake.org/cmake/help/v3.6/command/find_package.html [2]: https://cmake.org/cmake/help/v3.6/manual/cmake-packages.7.html#creating-packages [3]: https://cmake.org/cmake/help/v3.6/module/CMakePackageConfigHelpers.html On Fri, Aug 25, 2017 at 11:21 AM, Robert Dailey wrote: > So I've been studying the find_package[1] and "creating packages"[2] > documentation, as well as the CMakePackageConfigHelpers[3] page. > > Based on the current offerings of configuration packages, I do not > understand the need for the relocatable config.cmake file when all it > really contains is: > > include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake) > > However, what I'm wondering is even though the import targets should > contain all information about include directories, libraries, etc, > should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES > variables? Example of what foo-config.cmake would be like: > > include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake) > set( Foo_INCLUDE_DIRS "... path here...." ) > set( Foo_LIBRARIES "List of libraries here..." ) > > > Is this necessary? Honestly the learning curve for creating packages > for find_package is very steep. I did not see any general advice on > this kind of stuff. It seems like Module packages are being deprecated > in favor of Config packages, because it puts the responsibility of > maintaining find package logic on the upstream maintainer (config > package) instead of on CMake (module packages it ships with). > > Thanks in advance for any help. From tobias.hunger at gmail.com Fri Aug 25 16:27:17 2017 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Fri, 25 Aug 2017 22:27:17 +0200 Subject: [cmake-developers] Dependency graph in server mode? In-Reply-To: References: Message-ID: Hi Eric, On Fri, Aug 25, 2017 at 3:53 PM, Eric Noulard wrote: > Is it possible to get the dependency graph one can get with the --graphviz > option when running in server mode. Not yet:-) > From my understanding the current "codeModel" message does not contain such > information. Am I right? Yes, that kind of information is not in the codeModel. > If I wanted to add the dependency information would it be better to create a > new server mode > message or put that into current "codeModel"? Please put that into a separate message. Best Regards, Tobias From taylorcholberton at gmail.com Sun Aug 27 14:24:29 2017 From: taylorcholberton at gmail.com (Taylor Holberton) Date: Sun, 27 Aug 2017 11:24:29 -0700 Subject: [cmake-developers] Mini Make Message-ID: Hello! I just finished the first release of a cross platform, minimalistic Make implementation. It was made specifically to run CMake generated Makefiles on Linux and Windows (haven't tested on macOS yet). It's on GitHub and it's called Mini Make. Sorry for the self promotion! If there's anyway you think it can contribute to the CMake project, feel free to email me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Aug 28 15:41:57 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Aug 2017 15:41:57 -0400 Subject: [cmake-developers] Mini Make In-Reply-To: References: Message-ID: On 08/27/2017 02:24 PM, Taylor Holberton wrote: > I just finished the first release of a cross platform, minimalistic > Make implementation. > > It was made specifically to run CMake generated Makefiles on Linux > and Windows (haven't tested on macOS yet). > > It's on GitHub and it's called Mini Make. Neat. I suggest adding more to the readme: * Distinguish the instructions for building Mini Make using CMake from using Mini Make for building another project with CMake. * Explain the motivation and benefits of using Mini Make over another make tool on each system. (Parallel "make" with MSVC?) -Brad From rcdailey.lists at gmail.com Tue Aug 29 10:27:25 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 09:27:25 -0500 Subject: [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: Message-ID: I want to clarify my post since I've spent some more time on this. find_package() doesn't seem to work intuitively on Windows. On Linux, for example, installation prefixes are like "/usr/local", so if I'm building & installing a library in linux, you'd get a structure like: /usr/local/include /usr/local/lib /usr/local/bin On Windows, if I make the prefix "C:/Program Files", then you get: C:/Program Files/include C:/Program Files/lib C:/Program Files/bin This is not the idiomatic way to install libraries on windows. Instead, it should be: C:/Program Files/MyLibrary/include C:/Program Files/MyLibrary/lib C:/Program Files/MyLibrary/bin I can achieve this during installation by setting my CMAKE_INSTALL_PREFIX to "C:/Program Files/MyLibrary", however CMAKE_INSTALL_PREFIX seems like it should be different when used with find_package(). After doing tons of reading, the search behavior for find_package() is very confusing outside of linux. Combined with CMAKE_FIND_ROOT_PATH, I have no idea what the heck these should be on Windows. Suppose I want to use a super build to build a lot of third party libraries and install them relative to my CMAKE_BINARY_DIR, and completely ignore system root paths for find_package() searching. My first instinct would be to do this: -D CMAKE_FIND_ROOT_PATH=${CMAKE_BINARY_DIR}/installed_libraries -D CMAKE_INSTALL_PREFIX=${name_of_library} Note that there are two goals: 1. The library being built must install its files to ${CMAKE_BINARY_DIR}/installed_libraries/${name_of_library} 2. Any find_package() invocations made by the library being built should search within ${CMAKE_BINARY_DIR}/installed_libraries I'm relying on the two variables above to control this behavior, but CMAKE_INSTALL_PREFIX doesn't work well for both purposes. I can't make it relative on Windows because it puts it somewhere random on my filesystem, I think in program files. I'm not sure what CMAKE_INSTALL_PREFIX does if it isn't an absolute path (but based on linux behavior it should just append to the end of CMAKE_FIND_ROOT_PATH I think?) How can I get the proper install & find_package behavior on Windows based on the requirements above? On Sun, Aug 27, 2017 at 2:55 PM, Robert Dailey wrote: > So I'm trying to get CMake to find a package, and it isn't finding it. > I am setting CMAKE_PREFIX_PATH to try to get it to find it. Is there a > way I can view the search paths & prefixes that CMake is using with > each find_package() call? I tried enabling debug and trace output, but > neither of these seem to show any detail of what happens internally > with find_package() searches. > > Thanks in advance. From brad.king at kitware.com Tue Aug 29 10:33:57 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Aug 2017 10:33:57 -0400 Subject: [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: Message-ID: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> On 08/29/2017 10:27 AM, Robert Dailey wrote: > I'm relying on the two variables above to control this behavior, but > CMAKE_INSTALL_PREFIX doesn't work well for both purposes. Use CMAKE_PREFIX_PATH, not CMAKE_INSTALL_PREFIX, to control the set of prefixes that find commands search. -Brad From rcdailey.lists at gmail.com Tue Aug 29 10:48:54 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 09:48:54 -0500 Subject: [cmake-developers] Debugging find_package() search behavior? In-Reply-To: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> Message-ID: I am doing that. Here is a live example: Library is zlib, installed here: E:\code\frontend\msvc_2015\third_party\installed\zlib (has include, lib, bin, share inside it) I set the following variables (Using the set() command (non-cache) inside my CMake script, before the find_package calls): CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed And then the find_package() command is executed: find_package( ZLIB 1.2.11 EXACT REQUIRED ) And fails with: CMake Error at E:/Program Files/CMake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR) (Required is exact version "1.2.11") Call Stack (most recent call first): E:/Program Files/CMake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE) E:/Program Files/CMake/share/cmake-3.9/Modules/FindZLIB.cmake:112 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) Core/ThirdParty/zlib/CMakeLists.txt:6 (find_package) On Tue, Aug 29, 2017 at 9:33 AM, Brad King wrote: > On 08/29/2017 10:27 AM, Robert Dailey wrote: >> I'm relying on the two variables above to control this behavior, but >> CMAKE_INSTALL_PREFIX doesn't work well for both purposes. > > Use CMAKE_PREFIX_PATH, not CMAKE_INSTALL_PREFIX, to control > the set of prefixes that find commands search. > > -Brad From brad.king at kitware.com Tue Aug 29 10:55:28 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Aug 2017 10:55:28 -0400 Subject: [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> Message-ID: <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> On 08/29/2017 10:48 AM, Robert Dailey wrote: > CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed > CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with drive letters on Windows. -Brad From brad.king at kitware.com Tue Aug 29 10:56:34 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Aug 2017 10:56:34 -0400 Subject: [cmake-developers] Debugging find_package() search behavior? In-Reply-To: <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: On 08/29/2017 10:55 AM, Brad King wrote: > On 08/29/2017 10:48 AM, Robert Dailey wrote: >> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed > > I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with > drive letters on Windows. Oops, sent too soon. CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling to re-root paths like `/usr` into some prefix on the host. -Brad From rcdailey.lists at gmail.com Tue Aug 29 11:01:33 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 10:01:33 -0500 Subject: [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: > On 08/29/2017 10:55 AM, Brad King wrote: >> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >> >> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >> drive letters on Windows. > > Oops, sent too soon. > > CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling > to re-root paths like `/usr` into some prefix on the host. > > -Brad Ok but even if I remove that, find_package() still isn't working...... From DLRdave at aol.com Tue Aug 29 11:06:34 2017 From: DLRdave at aol.com (David Cole) Date: Tue, 29 Aug 2017 11:06:34 -0400 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey wrote: > On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >> On 08/29/2017 10:55 AM, Brad King wrote: >>> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>> >>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>> drive letters on Windows. >> >> Oops, sent too soon. >> >> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >> to re-root paths like `/usr` into some prefix on the host. >> >> -Brad > > Ok but even if I remove that, find_package() still isn't working...... > -- > > 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 From rcdailey.lists at gmail.com Tue Aug 29 11:11:36 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 10:11:36 -0500 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: What I'm hoping for is that find_package() follows the rules it documents here: https://cmake.org/cmake/help/v3.6/command/find_package.html Specifically, it states it searches these paths (and that is treated case-insensitive): / (W) /(cmake|CMake)/ (W) /*/ (W) /*/(cmake|CMake)/ (W) /(lib/|lib|share)/cmake/*/ (U) /(lib/|lib|share)/*/ (U) /(lib/|lib|share)/*/(cmake|CMake)/ (U) If this is true, then the 3rd one from the top should be a match, because is set to: E:/code/frontend/msvc_2015/third_party/installed And is set to ZLIB in find_package() first argument, so it should be adding that to the end. I need to keep CMAKE_PREFIX_PATH pointing to the parent directory ("installed") because I have other libraries that get installed in that directory, each with their own directory to contain their installation files. If find_package() is appending to like it says it should, it should find each one of them without switching the value of CMAKE_PREFIX_PATH. Am I misunderstanding something? On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: > Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? > > On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey > wrote: >> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >>> On 08/29/2017 10:55 AM, Brad King wrote: >>>> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>> >>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>>> drive letters on Windows. >>> >>> Oops, sent too soon. >>> >>> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >>> to re-root paths like `/usr` into some prefix on the host. >>> >>> -Brad >> >> Ok but even if I remove that, find_package() still isn't working...... >> -- >> >> 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 From rcdailey.lists at gmail.com Tue Aug 29 11:25:15 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 10:25:15 -0500 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: I think the discrepancy here might be config vs module find mode. The documentation I linked seems to be for config mode only, however I'm utilizing the CMake-shipped FindZLIB.cmake module to find this particular library. Does this offer no guarantees on how CMAKE_PREFIX_PATH is used? On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey wrote: > What I'm hoping for is that find_package() follows the rules it > documents here: > https://cmake.org/cmake/help/v3.6/command/find_package.html > > Specifically, it states it searches these paths (and that is > treated case-insensitive): > > / (W) > /(cmake|CMake)/ (W) > /*/ (W) > /*/(cmake|CMake)/ (W) > /(lib/|lib|share)/cmake/*/ (U) > /(lib/|lib|share)/*/ (U) > /(lib/|lib|share)/*/(cmake|CMake)/ (U) > > If this is true, then the 3rd one from the top should be a match, > because is set to: > > E:/code/frontend/msvc_2015/third_party/installed > > And is set to ZLIB in find_package() first argument, so it > should be adding that to the end. > > I need to keep CMAKE_PREFIX_PATH pointing to the parent directory > ("installed") because I have other libraries that get installed in > that directory, each with their own directory to contain their > installation files. If find_package() is appending to > like it says it should, it should find each one of them without > switching the value of CMAKE_PREFIX_PATH. > > Am I misunderstanding something? > > > On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: >> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? >> >> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey >> wrote: >>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >>>> On 08/29/2017 10:55 AM, Brad King wrote: >>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>> >>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>>>> drive letters on Windows. >>>> >>>> Oops, sent too soon. >>>> >>>> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >>>> to re-root paths like `/usr` into some prefix on the host. >>>> >>>> -Brad >>> >>> Ok but even if I remove that, find_package() still isn't working...... >>> -- >>> >>> 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 From DLRdave at aol.com Tue Aug 29 11:31:57 2017 From: DLRdave at aol.com (David Cole) Date: Tue, 29 Aug 2017 11:31:57 -0400 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: Is there a ZLIBConfig.cmake file which find_package is searching for? (i.e. -- somewhere under that directory does that file exist?) On Windows the case won't matter, but on Linux, a find_package(ZLIB will expect a case-sensitive match on a ZLIBConfig.cmake file. If ZLIBConfig.cmake exists, it needs to exist in one of the locations on that find_package documentation snippet you sent. If it's not directly in the "zlib" folder, or one of the other folders listed, then it won't be found. The directory it is in, or something matching one of those in the list needs to be included in your CMAKE_PREFIX_PATH. If that file does not exist, then the CMake FindZLIB.cmake module will be used in an attempt to find your zlib... And the help for that speaks of setting a ZLIB_ROOT var if you want to direct it to find a given zlib. See the "HINTS" section here: https://cmake.org/cmake/help/v3.6/module/FindZLIB.html#hints One more hint regarding CMAKE_PREFIX_PATH : despite its name, it is a **list** of paths, and you can use multiple semi-colon separated values if necessary. So, if appending "/zlib" works, then you could always find zlib and all your other stuff too by using two directories as your CMAKE_PREFIX_PATH value. HTH, David C. On Tue, Aug 29, 2017 at 11:11 AM, Robert Dailey wrote: > What I'm hoping for is that find_package() follows the rules it > documents here: > https://cmake.org/cmake/help/v3.6/command/find_package.html > > Specifically, it states it searches these paths (and that is > treated case-insensitive): > > / (W) > /(cmake|CMake)/ (W) > /*/ (W) > /*/(cmake|CMake)/ (W) > /(lib/|lib|share)/cmake/*/ (U) > /(lib/|lib|share)/*/ (U) > /(lib/|lib|share)/*/(cmake|CMake)/ (U) > > If this is true, then the 3rd one from the top should be a match, > because is set to: > > E:/code/frontend/msvc_2015/third_party/installed > > And is set to ZLIB in find_package() first argument, so it > should be adding that to the end. > > I need to keep CMAKE_PREFIX_PATH pointing to the parent directory > ("installed") because I have other libraries that get installed in > that directory, each with their own directory to contain their > installation files. If find_package() is appending to > like it says it should, it should find each one of them without > switching the value of CMAKE_PREFIX_PATH. > > Am I misunderstanding something? > > > On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: >> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? >> >> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey >> wrote: >>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >>>> On 08/29/2017 10:55 AM, Brad King wrote: >>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>> >>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>>>> drive letters on Windows. >>>> >>>> Oops, sent too soon. >>>> >>>> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >>>> to re-root paths like `/usr` into some prefix on the host. >>>> >>>> -Brad >>> >>> Ok but even if I remove that, find_package() still isn't working...... >>> -- >>> >>> 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 From DLRdave at aol.com Tue Aug 29 11:33:15 2017 From: DLRdave at aol.com (David Cole) Date: Tue, 29 Aug 2017 11:33:15 -0400 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: That's correct: find modules do what they want, and most do not pay attention to CMAKE_PREFIX_PATH. It's better to use a config file, but when you have to use a find module, you have to dig in and figure out the right way to use each one. On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey wrote: > I think the discrepancy here might be config vs module find mode. The > documentation I linked seems to be for config mode only, however I'm > utilizing the CMake-shipped FindZLIB.cmake module to find this > particular library. Does this offer no guarantees on how > CMAKE_PREFIX_PATH is used? > > On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey > wrote: >> What I'm hoping for is that find_package() follows the rules it >> documents here: >> https://cmake.org/cmake/help/v3.6/command/find_package.html >> >> Specifically, it states it searches these paths (and that is >> treated case-insensitive): >> >> / (W) >> /(cmake|CMake)/ (W) >> /*/ (W) >> /*/(cmake|CMake)/ (W) >> /(lib/|lib|share)/cmake/*/ (U) >> /(lib/|lib|share)/*/ (U) >> /(lib/|lib|share)/*/(cmake|CMake)/ (U) >> >> If this is true, then the 3rd one from the top should be a match, >> because is set to: >> >> E:/code/frontend/msvc_2015/third_party/installed >> >> And is set to ZLIB in find_package() first argument, so it >> should be adding that to the end. >> >> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory >> ("installed") because I have other libraries that get installed in >> that directory, each with their own directory to contain their >> installation files. If find_package() is appending to >> like it says it should, it should find each one of them without >> switching the value of CMAKE_PREFIX_PATH. >> >> Am I misunderstanding something? >> >> >> On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: >>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? >>> >>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey >>> wrote: >>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >>>>> On 08/29/2017 10:55 AM, Brad King wrote: >>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>> >>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>>>>> drive letters on Windows. >>>>> >>>>> Oops, sent too soon. >>>>> >>>>> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >>>>> to re-root paths like `/usr` into some prefix on the host. >>>>> >>>>> -Brad >>>> >>>> Ok but even if I remove that, find_package() still isn't working...... >>>> -- >>>> >>>> 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 From rcdailey.lists at gmail.com Tue Aug 29 11:43:03 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 10:43:03 -0500 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: Thanks for your help, the problem is that I was expecting too much consistency between find module behavior. I'll treat them as if I have no guarantees. Last question: Are there guarantees with find modules and CMAKE_FIND_ROOT_PATH? I'm asking because on Android, when I use find_package(), behavior is different because the NDK's toolchain file sets: set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) list(APPEND CMAKE_FIND_ROOT_PATH "${ANDROID_NDK}") To try to "intercept" the search of NDK for libraries using find_package(), I try this: set( CMAKE_FIND_ROOT_PATH ${ZIOSK_THIRD_PARTY_INSTALL} ${CMAKE_FIND_ROOT_PATH} ) However, after running, it's always finding results in the NDK directory set by the toolchain file, even though I put mine first in the list. Furthermore, my install of zlib has the correct version, the NDK one does not, but it still says it founds the NDK version. On Tue, Aug 29, 2017 at 10:33 AM, David Cole wrote: > That's correct: > > find modules do what they want, and most do not pay attention to > CMAKE_PREFIX_PATH. > > It's better to use a config file, but when you have to use a find > module, you have to dig in and figure out the right way to use each > one. > > > > On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey > wrote: >> I think the discrepancy here might be config vs module find mode. The >> documentation I linked seems to be for config mode only, however I'm >> utilizing the CMake-shipped FindZLIB.cmake module to find this >> particular library. Does this offer no guarantees on how >> CMAKE_PREFIX_PATH is used? >> >> On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey >> wrote: >>> What I'm hoping for is that find_package() follows the rules it >>> documents here: >>> https://cmake.org/cmake/help/v3.6/command/find_package.html >>> >>> Specifically, it states it searches these paths (and that is >>> treated case-insensitive): >>> >>> / (W) >>> /(cmake|CMake)/ (W) >>> /*/ (W) >>> /*/(cmake|CMake)/ (W) >>> /(lib/|lib|share)/cmake/*/ (U) >>> /(lib/|lib|share)/*/ (U) >>> /(lib/|lib|share)/*/(cmake|CMake)/ (U) >>> >>> If this is true, then the 3rd one from the top should be a match, >>> because is set to: >>> >>> E:/code/frontend/msvc_2015/third_party/installed >>> >>> And is set to ZLIB in find_package() first argument, so it >>> should be adding that to the end. >>> >>> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory >>> ("installed") because I have other libraries that get installed in >>> that directory, each with their own directory to contain their >>> installation files. If find_package() is appending to >>> like it says it should, it should find each one of them without >>> switching the value of CMAKE_PREFIX_PATH. >>> >>> Am I misunderstanding something? >>> >>> >>> On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: >>>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? >>>> >>>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey >>>> wrote: >>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >>>>>> On 08/29/2017 10:55 AM, Brad King wrote: >>>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>>> >>>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>>>>>> drive letters on Windows. >>>>>> >>>>>> Oops, sent too soon. >>>>>> >>>>>> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >>>>>> to re-root paths like `/usr` into some prefix on the host. >>>>>> >>>>>> -Brad >>>>> >>>>> Ok but even if I remove that, find_package() still isn't working...... >>>>> -- >>>>> >>>>> 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 From brad.king at kitware.com Tue Aug 29 11:49:17 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Aug 2017 11:49:17 -0400 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: <6b08c4ed-17ec-0b07-2b9d-6b0ed170225b@kitware.com> On 08/29/2017 11:33 AM, David Cole wrote: > That's correct: > > find modules do what they want, and most do not pay attention to > CMAKE_PREFIX_PATH. CMAKE_PREFIX_PATH *is* used by find modules. The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. See the documentation of find_library, find_path, etc. for details. Each command searches an appropriate `/` where `` is based on the kind of command doing the searching. -Brad From rcdailey.lists at gmail.com Tue Aug 29 11:50:37 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 10:50:37 -0500 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: Wow even if I set ZLIB_ROOT, FindZLIB.cmake *still* won't find my zlib over the one provided by the Android NDK... Although I was able to get this working fine on Windows, it does not work with the NDK's toolchain file. On Tue, Aug 29, 2017 at 10:43 AM, Robert Dailey wrote: > Thanks for your help, the problem is that I was expecting too much > consistency between find module behavior. I'll treat them as if I have > no guarantees. > > Last question: Are there guarantees with find modules and > CMAKE_FIND_ROOT_PATH? I'm asking because on Android, when I use > find_package(), behavior is different because the NDK's toolchain file > sets: > > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) > list(APPEND CMAKE_FIND_ROOT_PATH "${ANDROID_NDK}") > > To try to "intercept" the search of NDK for libraries using > find_package(), I try this: > > set( CMAKE_FIND_ROOT_PATH ${ZIOSK_THIRD_PARTY_INSTALL} ${CMAKE_FIND_ROOT_PATH} ) > > However, after running, it's always finding results in the NDK > directory set by the toolchain file, even though I put mine first in > the list. Furthermore, my install of zlib has the correct version, the > NDK one does not, but it still says it founds the NDK version. > > On Tue, Aug 29, 2017 at 10:33 AM, David Cole wrote: >> That's correct: >> >> find modules do what they want, and most do not pay attention to >> CMAKE_PREFIX_PATH. >> >> It's better to use a config file, but when you have to use a find >> module, you have to dig in and figure out the right way to use each >> one. >> >> >> >> On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey >> wrote: >>> I think the discrepancy here might be config vs module find mode. The >>> documentation I linked seems to be for config mode only, however I'm >>> utilizing the CMake-shipped FindZLIB.cmake module to find this >>> particular library. Does this offer no guarantees on how >>> CMAKE_PREFIX_PATH is used? >>> >>> On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey >>> wrote: >>>> What I'm hoping for is that find_package() follows the rules it >>>> documents here: >>>> https://cmake.org/cmake/help/v3.6/command/find_package.html >>>> >>>> Specifically, it states it searches these paths (and that is >>>> treated case-insensitive): >>>> >>>> / (W) >>>> /(cmake|CMake)/ (W) >>>> /*/ (W) >>>> /*/(cmake|CMake)/ (W) >>>> /(lib/|lib|share)/cmake/*/ (U) >>>> /(lib/|lib|share)/*/ (U) >>>> /(lib/|lib|share)/*/(cmake|CMake)/ (U) >>>> >>>> If this is true, then the 3rd one from the top should be a match, >>>> because is set to: >>>> >>>> E:/code/frontend/msvc_2015/third_party/installed >>>> >>>> And is set to ZLIB in find_package() first argument, so it >>>> should be adding that to the end. >>>> >>>> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory >>>> ("installed") because I have other libraries that get installed in >>>> that directory, each with their own directory to contain their >>>> installation files. If find_package() is appending to >>>> like it says it should, it should find each one of them without >>>> switching the value of CMAKE_PREFIX_PATH. >>>> >>>> Am I misunderstanding something? >>>> >>>> >>>> On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: >>>>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? >>>>> >>>>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey >>>>> wrote: >>>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >>>>>>> On 08/29/2017 10:55 AM, Brad King wrote: >>>>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>>>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>>>> >>>>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>>>>>>> drive letters on Windows. >>>>>>> >>>>>>> Oops, sent too soon. >>>>>>> >>>>>>> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >>>>>>> to re-root paths like `/usr` into some prefix on the host. >>>>>>> >>>>>>> -Brad >>>>>> >>>>>> Ok but even if I remove that, find_package() still isn't working...... >>>>>> -- >>>>>> >>>>>> 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 From brad.king at kitware.com Tue Aug 29 11:54:53 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Aug 2017 11:54:53 -0400 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: On 08/29/2017 11:50 AM, Robert Dailey wrote: > Wow even if I set ZLIB_ROOT, FindZLIB.cmake *still* won't find my zlib > over the one provided by the Android NDK... > > Although I was able to get this working fine on Windows, it does not > work with the NDK's toolchain file. That's because the CMAKE_FIND_ROOT_PATH settings re-root all search paths to look only inside the NDK. This is one reason toolchain files should not be monolithic and should only be authored locally for the current machine. -Brad From rcdailey.lists at gmail.com Tue Aug 29 11:58:49 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 10:58:49 -0500 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: On Tue, Aug 29, 2017 at 10:54 AM, Brad King wrote: > On 08/29/2017 11:50 AM, Robert Dailey wrote: >> Wow even if I set ZLIB_ROOT, FindZLIB.cmake *still* won't find my zlib >> over the one provided by the Android NDK... >> >> Although I was able to get this working fine on Windows, it does not >> work with the NDK's toolchain file. > > That's because the CMAKE_FIND_ROOT_PATH settings re-root all search > paths to look only inside the NDK. This is one reason toolchain files > should not be monolithic and should only be authored locally for the > current machine. But the documentation[1] says it's a list, so if I add my own directory to that list, it should search there right? [1]: https://cmake.org/cmake/help/v3.6/variable/CMAKE_FIND_ROOT_PATH.html From DLRdave at aol.com Tue Aug 29 12:02:48 2017 From: DLRdave at aol.com (David Cole) Date: Tue, 29 Aug 2017 12:02:48 -0400 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: <6b08c4ed-17ec-0b07-2b9d-6b0ed170225b@kitware.com> References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> <6b08c4ed-17ec-0b07-2b9d-6b0ed170225b@kitware.com> Message-ID: Sorry for the mis-statement. I stand corrected. However, it is true that there are many find modules with some differences in approach, and if you are using one, you need to read up on the individual documentation of that particular find module. Especially if you need to know how to tell it how to find the exact one you already know you have... On Tue, Aug 29, 2017 at 11:49 AM, Brad King wrote: > On 08/29/2017 11:33 AM, David Cole wrote: >> That's correct: >> >> find modules do what they want, and most do not pay attention to >> CMAKE_PREFIX_PATH. > > CMAKE_PREFIX_PATH *is* used by find modules. > > The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. > See the documentation of find_library, find_path, etc. for details. > Each command searches an appropriate `/` where `` > is based on the kind of command doing the searching. > > -Brad From rcdailey.lists at gmail.com Tue Aug 29 12:21:42 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 11:21:42 -0500 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> <6b08c4ed-17ec-0b07-2b9d-6b0ed170225b@kitware.com> Message-ID: Ok I debugged find_path() code in CMake and I determined the problem. First, let me explain what I'm doing a little more... I build third party libraries on demand during configure step in CMake. I do so via execute_process() to invoke another CMake instance, that builds and installs a library. This is similar to how ExternalProject_Add() works, but forces it to happen at configure time so I can use find_package() afterwards to find the library I just built. Each library first tries to be found, and if not found, I build it then try to find it again. Like so: ``` set( library_version 1.2.11 ) set( ZLIB_ROOT ${ZIOSK_THIRD_PARTY_INSTALL} ) find_package( ZLIB ${library_version} EXACT ) if( NOT ZLIB_FOUND OR NOT library_version VERSION_EQUAL ZLIB_VERSION_STRING ) build_third_party_library( CLEAN_BUILD ) find_package( ZLIB ${library_version} EXACT REQUIRED ) endif() ``` When Android's Toolchain is in use, this is what happens: 1. find_package() happens, it finds zlib under android NDK's root, but doesn't accept it because of a version mismatch (since I use the EXACT option) 2. I build the third party library with execute_process() 3. Second find_package() happens, but "AlreadyInCache" is true (line 28 in cmFindPathCommand.cxx) this time, so it doesn't search for it again. Hard to tell where the bug is here. I'd argue that AlreadyInCache shouldn't be set to true since an exact version was not found, and the next find_package() command should do a full path search. Is this a bug in the C++ code or the find module script? What determines the AlreadyInCache variable? On Tue, Aug 29, 2017 at 11:02 AM, David Cole wrote: > Sorry for the mis-statement. I stand corrected. > > However, it is true that there are many find modules with some > differences in approach, and if you are using one, you need to read up > on the individual documentation of that particular find module. > Especially if you need to know how to tell it how to find the exact > one you already know you have... > > > > > On Tue, Aug 29, 2017 at 11:49 AM, Brad King wrote: >> On 08/29/2017 11:33 AM, David Cole wrote: >>> That's correct: >>> >>> find modules do what they want, and most do not pay attention to >>> CMAKE_PREFIX_PATH. >> >> CMAKE_PREFIX_PATH *is* used by find modules. >> >> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. >> See the documentation of find_library, find_path, etc. for details. >> Each command searches an appropriate `/` where `` >> is based on the kind of command doing the searching. >> >> -Brad From brad.king at kitware.com Tue Aug 29 12:37:49 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Aug 2017 12:37:49 -0400 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> <6b08c4ed-17ec-0b07-2b9d-6b0ed170225b@kitware.com> Message-ID: On 08/29/2017 12:21 PM, Robert Dailey wrote: > 3. Second find_package() happens, but "AlreadyInCache" is true (line > 28 in cmFindPathCommand.cxx) this time, so it doesn't search for it > again. > > Hard to tell where the bug is here. I'd argue that AlreadyInCache > shouldn't be set to true since an exact version was not found>, and the > next find_package() command should do a full path search. Is this a > bug in the C++ code or the find module script? What determines the > AlreadyInCache variable? This is one of the problems with find modules. The individual find_* call result *was* found and is already cached. There is no way to tell that apart from the user setting it explicitly in the cache. That it proved insufficient for FPHSA's version check is not the concern of the find_ command. The find_package "config" mode uses only a single result variable and performs a version check before setting it, so it can do multiple searches like that. Find modules can't do that because they need to search for things piecemeal. At most they can report at the end that whatever was found is not suitable. In typical use cases with only a single find_package call it is then up to the user to correct the cached settings. -Brad From jeanmichael.celerier at gmail.com Tue Aug 29 12:46:21 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Tue, 29 Aug 2017 18:46:21 +0200 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: <6b08c4ed-17ec-0b07-2b9d-6b0ed170225b@kitware.com> References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> <6b08c4ed-17ec-0b07-2b9d-6b0ed170225b@kitware.com> Message-ID: > The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. Not always, some people sometimes feel like doing it by hand from scratch with if(EXISTS ...). Sadly. On Tue, Aug 29, 2017 at 5:49 PM, Brad King wrote: > On 08/29/2017 11:33 AM, David Cole wrote: > > That's correct: > > > > find modules do what they want, and most do not pay attention to > > CMAKE_PREFIX_PATH. > > CMAKE_PREFIX_PATH *is* used by find modules. > > The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. > See the documentation of find_library, find_path, etc. for details. > Each command searches an appropriate `/` where `` > is based on the kind of command doing the searching. > > -Brad > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Tue Aug 29 13:12:02 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 29 Aug 2017 19:12:02 +0200 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: References: Message-ID: <1980472.HVN3uRrsPO@daneel.sf-tec.de> Am Dienstag, 29. August 2017, 11:21:42 schrieb Robert Dailey: > Ok I debugged find_path() code in CMake and I determined the problem. > First, let me explain what I'm doing a little more... > > I build third party libraries on demand during configure step in > CMake. I do so via execute_process() to invoke another CMake instance, > that builds and installs a library. This is similar to how > ExternalProject_Add() works, but forces it to happen at configure time > so I can use find_package() afterwards to find the library I just > built. The trick with ExternalProject_Add is to also build your project with it, and not with add_subdirectory, i.e. the CMakeLists.txt that drives the build needs to be one level above your actual project. This way all things are done in order, so the dependencies are build before your main project. Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From rcdailey.lists at gmail.com Tue Aug 29 13:51:05 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 12:51:05 -0500 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: <1980472.HVN3uRrsPO@daneel.sf-tec.de> References: <1980472.HVN3uRrsPO@daneel.sf-tec.de> Message-ID: On Tue, Aug 29, 2017 at 12:12 PM, Rolf Eike Beer wrote: > Am Dienstag, 29. August 2017, 11:21:42 schrieb Robert Dailey: >> Ok I debugged find_path() code in CMake and I determined the problem. >> First, let me explain what I'm doing a little more... >> >> I build third party libraries on demand during configure step in >> CMake. I do so via execute_process() to invoke another CMake instance, >> that builds and installs a library. This is similar to how >> ExternalProject_Add() works, but forces it to happen at configure time >> so I can use find_package() afterwards to find the library I just >> built. > > The trick with ExternalProject_Add is to also build your project with it, and > not with add_subdirectory, i.e. the CMakeLists.txt that drives the build needs > to be one level above your actual project. This way all things are done in > order, so the dependencies are build before your main project. That's not going to work since for multi-configuration generators you want to be able to edit and build your code through the IDE, not via command line. Regarding find modules: it seems simpler at this point to just redo the install logic of upstream libraries using configuration packages instead, that way I can have finer control over how packages are found. Plus it's good for upstream repositories to be able to contribute this back. Thanks to everyone for their feedback. I have a much better understanding of this now, although I still strongly feel this is crazy complex. But nothing we can do about that I guess... it's just the nature of things. From rcdailey.lists at gmail.com Tue Aug 29 17:28:09 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 16:28:09 -0500 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: References: <1980472.HVN3uRrsPO@daneel.sf-tec.de> Message-ID: One other thing: Is there a way to make find_package() default to CONFIG mode? Right now it seems to search MODULE first, then CONFIG. But right now the only way to enable config is to explicitly use the CONFIG option or make sure CMake can't find a find module by manipulating CMAKE_MODULE_PATH. On Tue, Aug 29, 2017 at 12:51 PM, Robert Dailey wrote: > On Tue, Aug 29, 2017 at 12:12 PM, Rolf Eike Beer wrote: >> Am Dienstag, 29. August 2017, 11:21:42 schrieb Robert Dailey: >>> Ok I debugged find_path() code in CMake and I determined the problem. >>> First, let me explain what I'm doing a little more... >>> >>> I build third party libraries on demand during configure step in >>> CMake. I do so via execute_process() to invoke another CMake instance, >>> that builds and installs a library. This is similar to how >>> ExternalProject_Add() works, but forces it to happen at configure time >>> so I can use find_package() afterwards to find the library I just >>> built. >> >> The trick with ExternalProject_Add is to also build your project with it, and >> not with add_subdirectory, i.e. the CMakeLists.txt that drives the build needs >> to be one level above your actual project. This way all things are done in >> order, so the dependencies are build before your main project. > > That's not going to work since for multi-configuration generators you > want to be able to edit and build your code through the IDE, not via > command line. > > Regarding find modules: it seems simpler at this point to just redo > the install logic of upstream libraries using configuration packages > instead, that way I can have finer control over how packages are > found. Plus it's good for upstream repositories to be able to > contribute this back. > > Thanks to everyone for their feedback. I have a much better > understanding of this now, although I still strongly feel this is > crazy complex. But nothing we can do about that I guess... it's just > the nature of things. From brad.king at kitware.com Wed Aug 30 09:15:04 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Aug 2017 09:15:04 -0400 Subject: [cmake-developers] [CMake] Debugging find_package() search behavior? In-Reply-To: References: <1980472.HVN3uRrsPO@daneel.sf-tec.de> Message-ID: <568858d7-f313-9256-a4e5-37c0361574cb@kitware.com> On 08/29/2017 05:28 PM, Robert Dailey wrote: > One other thing: Is there a way to make find_package() default to > CONFIG mode? Right now it seems to search MODULE first, then CONFIG. > But right now the only way to enable config is to explicitly use the > CONFIG option or make sure CMake can't find a find module by > manipulating CMAKE_MODULE_PATH. It only searches in one mode. The presence or non-presence of a find module in CMAKE_MODULE_PATH is the way the mode is selected if an explicit CONFIG option is not given. There is an issue about this here: https://gitlab.kitware.com/cmake/cmake/issues/16805 with an unfinished/expired MR: https://gitlab.kitware.com/cmake/cmake/merge_requests/768 Some find modules call `find_package(MyPackage CONFIG ...)` as their first step if the external package may be found by either method. -Brad