From florent.castelli at gmail.com Wed Oct 1 02:47:37 2014 From: florent.castelli at gmail.com (Florent Castelli) Date: Wed, 1 Oct 2014 08:47:37 +0200 Subject: [cmake-developers] iOS support In-Reply-To: References: Message-ID: Thanks for the detailed information. My "hackweek" starts on Monday and I'll start working on these issues then. I'll work on finding a way to unify toolchain files for simulator and devices first. I don't think I'll try to work on iOS8 features since my company is shipping for iOS6 and there are so many things to do :) Though, I'm not really an iOS developer, there's probably a ton of things I'll miss. But I have great devs in my company and I'm sure it'll be okay! I'll keep you updated of my progress during the week and hopefully, I won't have to call for help here too often :) /Orphis On 1 Oct 2014 01:42, "Eric Wing" wrote: > Thought of one more. > I hate how the top, default target is ALL_BUILD. This is problematic > for both Xcode and Visual Studio because when you use the big giant > "run" button in the UI, the IDE is confused because ALL_BUILD is an > aggregate target and not a real thing that can be run. At least for > Xcode, a bunch of options change dynamically based on the type of > target selected and building/launching to the device/simulator is not > an option when on an aggregate target. > > It's an annoyance because it interferes with the normal workflow for > those familiar with the IDEs. And it's an annoyance for those who are > not familiar with the IDEs because the big giant buttons do nothing > and they don't understand the IDEs well enough on how to correct the > issue. > > (It's also more work invoking xcodebuild and msbuild because you can't > rely on the default targets.) > > Thanks, > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Wed Oct 1 09:09:08 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 1 Oct 2014 09:09:08 -0400 Subject: [cmake-developers] [CMake 0015183]: CMAKE_XCODE_ATTRIBUTE_INSTALL_PATH setting makes archiving impossible Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15183 ====================================================================== Reported By: Jan R?egg Assigned To: ====================================================================== Project: CMake Issue ID: 15183 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-01 09:09 EDT Last Modified: 2014-10-01 09:09 EDT ====================================================================== Summary: CMAKE_XCODE_ATTRIBUTE_INSTALL_PATH setting makes archiving impossible Description: CMake sets CMAKE_XCODE_ATTRIBUTE_INSTALL_PATH to an empty string ("") when generating xcode projects. For whatever reason archiving projects only works when - INSTALL_PATH is NOT set - INSTALL_PATH is set to some value other than the empty string ("") It does NOT work when - INSTALL_PATH is set to the empty string So I propose for CMake to not set this value at all, then XCode takes some default which works for archiving files. See also here: http://web.archiveorange.com/archive/v/5y7PklO3CkRUMmyHhIlr and here: http://public.kitware.com/pipermail/cmake/2011-June/045159.html and here: http://stackoverflow.com/a/8102602/369009 Steps to Reproduce: - Create XCode project with CMake (for example for ios). - Try to archive it "Product->Archive" - Nothing happens ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-01 09:09 Jan R?egg New Issue ====================================================================== From mantis at public.kitware.com Wed Oct 1 11:09:31 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 1 Oct 2014 11:09:31 -0400 Subject: [cmake-developers] [CMake 0015185]: Allow for partial customization of WiX.template.in Message-ID: <18d07f8d8c4f2f83117c52ceb25bc74a@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15185 ====================================================================== Reported By: Richard Ulrich Assigned To: ====================================================================== Project: CMake Issue ID: 15185 Category: CPack Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-01 11:09 EDT Last Modified: 2014-10-01 11:09 EDT ====================================================================== Summary: Allow for partial customization of WiX.template.in Description: At the moment I have my own copy of WiX.template.in in my project specific Modules directory. In the discussion of http://public.kitware.com/Bug/view.php?id=15165 I realized that it would be beneficial, if there was a way to only extend WiX.template.in without having to completely maintain it myself. * One approach would be to include a custom.wxi file in WiX.template.in and ship an empty custom.wxi file that could be overridden. * Another approach would be to extend the patching mechanism to the tag. As at the moment it only work on tags that are generated by the cpack c++ code, it's not just a matter of adding an ApplyPatch() line in the correct place. Things I customized in my WiX.template.in: * Product.Language="!(loc.LANG)" -> this could be tricky. It's not covered by both of the above approaches. -> shipping also a default lang.wxl file could make it work. * Adding Components or ComponentRefs that need to be in the Product tag. -> this is the easy part, solved by both approaches. * Adding a second UiRef (WixUI_ErrorProgressText) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-01 11:09 Richard Ulrich New Issue ====================================================================== From aleixpol at kde.org Wed Oct 1 19:46:09 2014 From: aleixpol at kde.org (Aleix Pol) Date: Thu, 2 Oct 2014 01:46:09 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> <22742143.8V0LQmVuST@tuxedo.neundorf.net> <540DA65F.4030501@kitware.com> <541C6B8D.2020404@kitware.com> <5422CD5E.7020008@kitware.com> Message-ID: On Wed, Sep 24, 2014 at 6:51 PM, Aleix Pol wrote: > On Wed, Sep 24, 2014 at 3:55 PM, Brad King wrote: > >> On 09/22/2014 07:15 PM, Aleix Pol wrote: >> > { >> > version: "1.0", >> > targets: [...] >> > } >> >> Yes. The version number could either be maintained as its own >> thing, or just the CMake version number could be used. Either way >> the Help/variable/CMAKE_OUTPUT_PROJECT_TARGETS.rst documentation >> should specify the format of each version. >> >> BTW, the phrase "output project targets" is not particularly >> clear without knowing the feature already. Perhaps some other >> name like "CMAKE_EXPORT_IDE_METADATA" would be better? >> >> > I've never worked with those, but it sounds like it would make sense. >> What about: >> > >> > { >> > version: .. >> > configurations: { >> > { name: "Debug", targets: [...] }, >> > { name: "Release", targets: [...] } >> > } >> > } >> >> Yes, something like that. I think you meant to use [] rather than >> {} around the list of configurations. In the case that there is >> only one configuration for the generator we should still use a >> list but have only one entry. >> > Sure :) > > >> >> -Brad >> >> > Hi, > Here's another iteration of the patch [1]. > > Basically adopts the possibility to move some information to depend on the > configuration. Currently it's only showing the I source files, I guess > location, directory and installed should be moved as well. Correct? > > Aleix > > [1] > New patch: > http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch > New output: http://proli.net/meu/kdevelop/ProjectTargets.json > Bump. I'm very interested in getting this in and iterating forward. Any comments? How do changes get integrated? Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Oct 2 08:43:37 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 02 Oct 2014 08:43:37 -0400 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> <22742143.8V0LQmVuST@tuxedo.neundorf.net> <540DA65F.4030501@kitware.com> <541C6B8D.2020404@kitware.com> <5422CD5E.7020008@kitware.com> Message-ID: <542D4879.20204@kitware.com> On 10/01/2014 07:46 PM, Aleix Pol wrote: > I'm very interested in getting this in and iterating forward. > > Any comments? How do changes get integrated? My main concern is that the format has not been proven with a corresponding implementation of an actual IDE/plugin to use it. Once we start producing a format changing it later will be problematic for compatibility. Even though we added a version number to the file, an IDE might not be updated along with a CMake that produces a newer version. Perhaps rather than a boolean "CMAKE_EXPORT_IDE_METADATA" setting to enable this, the value should be a version number. That way enabling it requires explicit specification of which format version is desired. In this case we would need to use a format version number that is independent of th CMake version number. It would simply be incremented every time changes are made. If the version number has the form . then we could increment the minor number whenever fields are added and the major number whenever fields are removed or changed. -Brad From samho5888 at gmail.com Thu Oct 2 08:52:08 2014 From: samho5888 at gmail.com (Sam H.) Date: Thu, 2 Oct 2014 20:52:08 +0800 Subject: [cmake-developers] Integrate fixdep for kconfig In-Reply-To: <542ACBD0.3030209@kitware.com> References: <542ACBD0.3030209@kitware.com> Message-ID: Hi Brad, I try my best to describe my understanding. kconfig ( https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kbuild ) is a language for configuration. After user finish configuration, it will generate files, e.g. autoconf.h for C language and auto.conf for makefile, and it will parse configuration to generate proper pseudo file for dependency. For example, CONFIG_A_B_C will be expanded as include/config/a/b/c.h, CONFIG_TST1 will be expanded as include/config/tst1.h So that files use CONFIG_A_B_C will have a dependency to include/config/a/b/c.h. C codes will check CONFIG_A_B_C that will be defined in autoconf.h Since autoconf.h will be re-generated every time when configuration is changed. Files depend to autoconf.h will all be built even CONFIG it used is not modified. So autoconf.h need to be removed from dependency file and pseudo config file refereed need to be added in. Linux kernel build codes with -Wp,-MD,src/path/.file.o.d It will generate dependency list that .h used. Then fixdep will re-parse .file.o.d. It will 1. Remove common file like autoconf.h 2. Add dependency of CONFIG pseudo file. The comments show more information about what fixdep do: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/basic/fixdep.c My prototype patch is try to do what fixdep do in CMake. Attached file is my test sample. (tested on Ubuntu 12.04 with CMake 3.0.1 patched) After extract file. 1. Do configuration by: $ make allyesconfig 2. Generate CONFIG pseudo files: $ make silentoldconfig 3. Do CMake $ mkdir build $ cmake .. $ make 4. Do more configuration: $ cd .. $ make menuconfig $ make silentoldconfig 5. Test CMake again: $ cd build $ make Because the license issue and mmap() issue, codes need to be re-implement. However, I'm not familiar with CMake codes and C++. So what can I do if this feature could be accepted? Thanks, Sam 2014-09-30 23:27 GMT+08:00 Brad King : > On 09/24/2014 07:18 AM, Sam H. wrote: > > I would like to use kconfig from Linux for my project settings. > > So I integrate fixdep tools into CMake for parsing CONFIG_xxx key words > > and set proper dependency of files that are generated by kconfig. > > For those of us unfamiliar with kconfig/fixdep, please provide a > high level explanation of how they work and why CMake dependency > scanning needs to be modified. > > > However, here come some issues. > > 1. The codes from fixdep is declared as GPL. But CMake use BSD. > > 2. fixed use mmap(). But this API is not support well on Windows. > > Both of these need to be addressed before a patch would be accepted. > We cannot link GPLed code, and we need a portable implementation. > > Thanks, > -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: -------------- next part -------------- A non-text attachment was scrubbed... Name: tst_kconfig.tar.bz2 Type: application/x-bzip2 Size: 153547 bytes Desc: not available URL: From brad.king at kitware.com Thu Oct 2 09:02:08 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 02 Oct 2014 09:02:08 -0400 Subject: [cmake-developers] iOS support In-Reply-To: References: <54217E53.2070902@kitware.com> <54218A16.1010008@kitware.com> Message-ID: <542D4CD0.8020304@kitware.com> On 09/23/2014 11:42 AM, Florent Castelli wrote: > On 23 Sep 2014, at 16:56, Bill Hoffman wrote: >> Much of the stuff found in these toolchains: >> https://github.com/Kitware/VTK/blob/master/CMake/ios.toolchain.xcode.cmake >> https://github.com/Kitware/VTK/blob/master/CMake/ios.simulator.toolchain.cmake >> https://github.com/Kitware/VTK/blob/master/CMake/ios.device.toolchain.cmake >> Should be in Platform files. If we created ios platform files we could > remove most of the stuff from those toolchain files. > > The problem is that I want a project that is usable by developers directly > and you can't really force them to target just the simulator. It should work > for targeting both simulator and real device. So having a generic iOS toolchain > that can generate both in one project is a requirement for me. Ideally a toolchain file should have only settings specific to the local machine where it will be used, such as the paths to staging prefixes where dependencies built for the target arch may be installed. All information that is general to the iOS platform should be in a module that comes with CMake, and only the local system info should be the toolchain file (which does not come with CMake). To clarify Bill's suggestion, much of the content in third-party iOS toolchain files is stuff like this: set (CMAKE_SHARED_LIBRARY_PREFIX "lib") set (CMAKE_SHARED_LIBRARY_SUFFIX ".dylib") set (CMAKE_SHARED_MODULE_PREFIX "lib") set (CMAKE_SHARED_MODULE_SUFFIX ".so") set (CMAKE_MODULE_EXISTS 1) set (CMAKE_DL_LIBS "") set (CMAKE_PLATFORM_HAS_INSTALLNAME 1) set (CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS "-dynamiclib -headerpad_max_install_names") set (CMAKE_SHARED_MODULE_CREATE_C_FLAGS "-bundle -headerpad_max_install_names") set (CMAKE_SHARED_MODULE_LOADER_C_FLAG "-Wl,-bundle_loader,") set (CMAKE_SHARED_MODULE_LOADER_CXX_FLAG "-Wl,-bundle_loader,") set (CMAKE_FIND_LIBRARY_SUFFIXES ".dylib" ".so" ".a") These kind of settings belong in a CMake Platform/.cmake file. For example, see the platform file for OS X: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin.cmake;hb=v3.0.2 Furthermore, commonly used third-party iOS toolchain files start with this: set (CMAKE_SYSTEM_NAME Darwin) Instead an iOS toolchain file should start with: set (CMAKE_SYSTEM_NAME iOS) and there should be a Modules/Platform/iOS.cmake file that comes with CMake to contain settings like those above. The code for finding the iOS SDK path should also be in a platform module. It should go either in iOS.cmake itself, or in an iOS-Inititalize.cmake file similar to Darwin-Initialize.cmake: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin-Initialize.cmake;hb=f640b2a4 Once such modules come with CMake, toolchain files can be very short and only need to say they are for iOS and then specify local system information. -Brad From mantis at public.kitware.com Thu Oct 2 09:41:35 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 2 Oct 2014 09:41:35 -0400 Subject: [cmake-developers] [CMake 0015186]: target names restricted to ascii since 3.0 Message-ID: <2892a1db25c9ffdac508917f4885baa5@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15186 ====================================================================== Reported By: Clinton Stimpson Assigned To: ====================================================================== Project: CMake Issue ID: 15186 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-02 09:41 EDT Last Modified: 2014-10-02 09:41 EDT ====================================================================== Summary: target names restricted to ascii since 3.0 Description: Using the project attached here: http://www.cmake.org/Bug/view.php?id=14934 I get a warning: CMake Warning (dev) at CMakeLists.txt:31 (add_executable): Policy CMP0037 is not set: Target names should not be reserved and should match a validity pattern. Run "cmake --help-policy CMP0037" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The target name "????" is reserved or not valid for certain CMake features, such as generator expressions, and may result in undefined behavior. Additional Information: cmGeneratorExpression::IsValidTargetName() has this: static cmsys::RegularExpression targetNameValidator("^[A-Za-z0-9_.:+-]+$"); return targetNameValidator.find(input); Perhaps the regex can be inverted and specific characters which are disallowed should be searched for. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-02 09:41 Clinton StimpsonNew Issue ====================================================================== From joubert.sy at gmail.com Thu Oct 2 17:34:39 2014 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Thu, 02 Oct 2014 23:34:39 +0200 Subject: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible Message-ID: <542DC4EF.2000400@gmail.com> Hi, Since Ninja 1.5, a pre-defined pool 'console' can be used for non buffered output. See http://martine.github.io/ninja/manual.html#_the_literal_console_literal_pool This patch specifies that special pool for the "build.ninja" build block if the Ninja version used is at least 1.5 This is useful for projects that have a long and verbose CMake run step. The idea is to get the output as soon as possible. It also adds the generation of the minimal required version of Ninja in the build.ninja file. The default version is 1.3 since the generator uses features from that version. If the Ninja version is 1.5 or greater, then the generator will use the 'console' pool and the build.ninja file requires at least Ninja 1.5 Regards, Sylvain -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Ninja-Use-console-pool-for-CMake-re-run-if-possible.patch Type: text/x-patch Size: 5378 bytes Desc: not available URL: From mw_triad at users.sourceforge.net Thu Oct 2 18:08:07 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 02 Oct 2014 18:08:07 -0400 Subject: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible In-Reply-To: <542DC4EF.2000400@gmail.com> References: <542DC4EF.2000400@gmail.com> Message-ID: On 2014-10-02 17:34, Sylvain Joubert wrote: > Since Ninja 1.5, a pre-defined pool 'console' can be used for non > buffered output. > See > http://martine.github.io/ninja/manual.html#_the_literal_console_literal_pool > > This patch specifies that special pool for the "build.ninja" build block > if the Ninja version used is at least 1.5 I haven't tried it yet, but I've been wanting this feature; thanks for the patch! Please see also http://public.kitware.com/Bug/view.php?id=14915 which it sounds like this (partly) fixes; you may want to reference that in your patch or vice versa. (The "partly" is that the request is also for the 'install' target to use the console pool; not sure if you did that, want to tackle that, etc., but in any case this is a step in the right direction.) -- Matthew From ewmailing at gmail.com Thu Oct 2 21:10:59 2014 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 2 Oct 2014 18:10:59 -0700 Subject: [cmake-developers] iOS support In-Reply-To: <542D4CD0.8020304@kitware.com> References: <54217E53.2070902@kitware.com> <54218A16.1010008@kitware.com> <542D4CD0.8020304@kitware.com> Message-ID: > Ideally a toolchain file should have only settings specific to > the local machine where it will be used, such as the paths to > staging prefixes where dependencies built for the target arch > may be installed. All information that is general to the iOS > platform should be in a module that comes with CMake, and only > the local system info should be the toolchain file (which does > not come with CMake). Agreed. > The code for > finding the iOS SDK path should also be in a platform module. I think we should nuance and improve this if possible. One thing I really would like fixed is the CMake asserting itself by specifying an explicit path to the iOS SDK. A few years ago, Apple added a generic option for "Latest SDK". This was to address the problem that we always have a new Xcode beta version in flight and new SDKs every year (both iOS and Mac). Additionally, because Apple re-routes the SDK path dynamically based on whether you selected Device or Simulator. Whatever mechanism CMake is using to assert itself seems to be somewhat incompatible with this feature because CMake forces it to just one or the other. I relaxed a few settings in my toolchain and it seems to work better, though I still have problems from time to time. I originally was going to say the path to Xcode is the most important thing, but I'm wondering if that is really important at all. Apple also knows how to automatically root the SDKs relative to the Xcode project that you opened in. This is really valuable to us developers too because it is common that we need to switch back and forth between the current stable and current beta of Xcode (and sometimes multiple betas.) So it would be nice if CMake didn't have to write any information to paths to Xcode and just leverage Apple's generic placeholder values. I'm using a minor fork of one of the open source iOS toolchains. To advance the cause, I would be happy to share it and also give access to my upcoming (commercial) SDK for context (which includes the entire CMake build system I use with all the things I'm trying to accomplish). Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ From mantis at public.kitware.com Fri Oct 3 01:06:09 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 3 Oct 2014 01:06:09 -0400 Subject: [cmake-developers] [CMake 0015191]: find_program should search commands in PATHEXT env. Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15191 ====================================================================== Reported By: Yoshisato Yanagisawa Assigned To: ====================================================================== Project: CMake Issue ID: 15191 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-03 01:06 EDT Last Modified: 2014-10-03 01:06 EDT ====================================================================== Summary: find_program should search commands in PATHEXT env. Description: find_program (http://www.cmake.org/cmake/help/v3.0/command/find_program.html) expected to find an executable that has an extension listed in PATHEXT on Windows. However, it only tries .com and .exe. http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/kwsys/SystemTools.cxx;h=b1221e3a8f7fee97bca54a002590198e5fb0183f;hb=HEAD#l2785 Steps to Reproduce: 1. put foo.bat in the PATH. 2. put CMakeLists.txt like: cmake_minimum_required (VERSION 2.8.11) project (HELLO) find_program(Foo foo PATHS) if (NOT Foo) message (FATAL_ERROR "Foo not found") endif() message("Foo ${Foo}") 3. cmake ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-03 01:06 Yoshisato YanagisawaNew Issue ====================================================================== From eike at sf-mail.de Fri Oct 3 03:35:05 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 03 Oct 2014 09:35:05 +0200 Subject: [cmake-developers] Improving the version selection behavior of EXACT Message-ID: <2265519.UlzGx0ETMW@caliban.sf-tec.de> find_package(foo 2.0 EXACT) means EXACT, i.e. only "2.0" is allowed. In most cases this behavior is not the one that one would expect or need. Most people would instead allow any 2.0.x version to match. This sort of selection is currently impossible without additional effort in every Find*.cmake that is used. I came over this when I tried converting FindLua5[01].cmake to use FindLua.cmake, but I can't do "find_package(Lua 5.0 EXACT)" in there because e.g. 5.0.1 would not be accepted then, and I neither can do "find_package(Lua 5.0)" because that may return e.g. 5.2 instead. Since we can't change this because of the usual backward compatibility concerns I think we should introduce a new version mode, e.g. EXACT_OR_MINOR (or any other naming you find more appropiate). In case this is aggreed on I would try to create a patch ASAP to be able to still land it in 3.1. Opinions? Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From DLRdave at aol.com Fri Oct 3 06:06:01 2014 From: DLRdave at aol.com (David Cole) Date: Fri, 3 Oct 2014 06:06:01 -0400 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <2265519.UlzGx0ETMW@caliban.sf-tec.de> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> Message-ID: How about IN_RANGE and/or IN_SET options? Where IN_RANGE takes two version numbers (low and high) and does the equivalent of: if ( (NOT ver VERSION_LESS low) AND (ver VERSION_LESS high) ) Or possibly even IN_RANGES with multiple ranges... And IN_SET takes a list of explicit version numbers and looks for exact matches among multiple choices...? It's all pie in the sky until you reach up and pull one down. ;-) D On Fri, Oct 3, 2014 at 3:35 AM, Rolf Eike Beer wrote: > find_package(foo 2.0 EXACT) means EXACT, i.e. only "2.0" is allowed. In most > cases this behavior is not the one that one would expect or need. Most people > would instead allow any 2.0.x version to match. This sort of selection is > currently impossible without additional effort in every Find*.cmake that is > used. > > I came over this when I tried converting FindLua5[01].cmake to use > FindLua.cmake, but I can't do "find_package(Lua 5.0 EXACT)" in there because > e.g. 5.0.1 would not be accepted then, and I neither can do "find_package(Lua > 5.0)" because that may return e.g. 5.2 instead. > > Since we can't change this because of the usual backward compatibility > concerns I think we should introduce a new version mode, e.g. EXACT_OR_MINOR > (or any other naming you find more appropiate). > > In case this is aggreed on I would try to create a patch ASAP to be able to > still land it in 3.1. > > Opinions? > > Eike > -- > > 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 brad.king at kitware.com Fri Oct 3 08:27:56 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 08:27:56 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 Message-ID: <542E964C.1050104@kitware.com> Hi Folks, In preparation for the first 3.1 release candidate I will feature- freeze master as of 2014-10-09. As of now there are several open topics in 'next' that we should try to land in master by then, but please refrain from adding non-trivial changes in the meantime. Thanks, -Brad From brad.king at kitware.com Fri Oct 3 08:41:47 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 08:41:47 -0400 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <2265519.UlzGx0ETMW@caliban.sf-tec.de> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> Message-ID: <542E998B.9010202@kitware.com> On 10/03/2014 03:35 AM, Rolf Eike Beer wrote: > find_package(foo 2.0 EXACT) means EXACT, i.e. only "2.0" is allowed. In most > cases this behavior is not the one that one would expect or need. Most people > would instead allow any 2.0.x version to match. Yes. The "EXACT" should refer to exactly matching whatever components are given by the caller. Following components should still be free to vary. If the caller wants them to be exact too then they should be specified. > This sort of selection is currently impossible without additional effort > in every Find*.cmake that is used. Is that because of FPHSA's implementation? > Since we can't change this because of the usual backward compatibility > concerns I think we should introduce a new version mode, e.g. EXACT_OR_MINOR > (or any other naming you find more appropiate). > > In case this is aggreed on I would try to create a patch ASAP to be able to > still land it in 3.1. I'd rather not introduce a new API in an important command like find_package immediately before a release. However, the documentation of find_package has always said that it is up to the Find module (or package version file in Config mode) for each package to decide whether a version matches. I think FPHSA could be changed to implement the expected behavior for EXACT discussed above. The current implementation effectively adds unlimited implicit ".0.0.0" to the caller's components as part of if(VERSION_EQUAL). Instead FPHSA could truncate the available version to match the number of components provided by the caller's version request before using if(VERSION_EQUAL). -Brad From eike at sf-mail.de Fri Oct 3 08:43:57 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 03 Oct 2014 14:43:57 +0200 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <542E998B.9010202@kitware.com> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <542E998B.9010202@kitware.com> Message-ID: <3958318.nxOjhsD5xf@caliban.sf-tec.de> Am Freitag, 3. Oktober 2014, 08:41:47 schrieb Brad King: > On 10/03/2014 03:35 AM, Rolf Eike Beer wrote: > > find_package(foo 2.0 EXACT) means EXACT, i.e. only "2.0" is allowed. In > > most cases this behavior is not the one that one would expect or need. > > Most people would instead allow any 2.0.x version to match. > > Yes. The "EXACT" should refer to exactly matching whatever components are > given by the caller. Following components should still be free to vary. > If the caller wants them to be exact too then they should be specified. > > > This sort of selection is currently impossible without additional effort > > in every Find*.cmake that is used. > > Is that because of FPHSA's implementation? I think that is the main reason. > > Since we can't change this because of the usual backward compatibility > > concerns I think we should introduce a new version mode, e.g. > > EXACT_OR_MINOR (or any other naming you find more appropiate). > > > > In case this is aggreed on I would try to create a patch ASAP to be able > > to > > still land it in 3.1. > > I'd rather not introduce a new API in an important command like find_package > immediately before a release. However, the documentation of find_package > has always said that it is up to the Find module (or package version file > in Config mode) for each package to decide whether a version matches. > > I think FPHSA could be changed to implement the expected behavior for > EXACT discussed above. The current implementation effectively adds > unlimited implicit ".0.0.0" to the caller's components as part of > if(VERSION_EQUAL). Instead FPHSA could truncate the available version > to match the number of components provided by the caller's version > request before using if(VERSION_EQUAL). If it is acceptable to change FPHSA in that way I can just go for it. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Fri Oct 3 08:47:04 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 08:47:04 -0400 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <3958318.nxOjhsD5xf@caliban.sf-tec.de> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <542E998B.9010202@kitware.com> <3958318.nxOjhsD5xf@caliban.sf-tec.de> Message-ID: <542E9AC8.9030907@kitware.com> On 10/03/2014 08:43 AM, Rolf Eike Beer wrote: >> I think FPHSA could be changed to implement the expected behavior for >> EXACT > > If it is acceptable to change FPHSA in that way I can just go for it. Yes, please try it. Thanks, -Brad From brad.king at kitware.com Fri Oct 3 08:56:43 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 08:56:43 -0400 Subject: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible In-Reply-To: References: <542DC4EF.2000400@gmail.com> Message-ID: <542E9D0B.1080806@kitware.com> On 10/02/2014 06:08 PM, Matthew Woehlke wrote: > I haven't tried it yet, but I've been wanting this feature; thanks for > the patch! I tried the patch and it works well. When ninja reruns CMake one can now see the output immediately. > Please see also > http://public.kitware.com/Bug/view.php?id=14915 which it sounds like > this (partly) fixes; you may want to reference that in your patch or > vice versa. I've applied the patch here and added the issue reference: Ninja: Use 'console' pool for CMake re-run if possible (#14915) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f32a241 > (The "partly" is that the request is also for the 'install' target to > use the console pool; not sure if you did that, want to tackle that, > etc., but in any case this is a step in the right direction.) I'll leave that to a follow-up patch if anyone wants to do it. Thanks, -Brad From mantis at public.kitware.com Fri Oct 3 09:01:58 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 3 Oct 2014 09:01:58 -0400 Subject: [cmake-developers] [CMake 0015193]: Error when one of the parent directory is a symlink to it's parent directory Message-ID: <5948bd215798319654adc894f9bb5c82@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15193 ====================================================================== Reported By: Yichao Yu Assigned To: ====================================================================== Project: CMake Issue ID: 15193 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-03 09:01 EDT Last Modified: 2014-10-03 09:01 EDT ====================================================================== Summary: Error when one of the parent directory is a symlink to it's parent directory Description: If one of the parent directory of the source directory is a symlink to one of its parent directory, cmake fails at configure time on add_subdirectory. Directory structure to reproduce this: ``` % tree . ??? 1 ??? ??? 2 ??? ??? ??? cmake ??? ??? ??? a ??? ??? ??? ??? CMakeLists.txt ??? ??? ??? CMakeLists.txt ??? ??? 4 -> . ??? 3 -> 1 6 directories, 2 files ``` The higher level `CMakeLists.txt` is ``` % cat 1/2/cmake/CMakeLists.txt project(cmake-test) cmake_minimum_required(VERSION 2.8) add_subdirectory(a) ``` and the lower level `CMakeLists.txt` is empty. When trying to build in `1/4/2/cmake/build` ``` % cmake .. -- The C compiler identification is GNU 4.9.1 -- The CXX compiler identification is GNU 4.9.1 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Error at CMakeLists.txt:3 (add_subdirectory): add_subdirectory not given a binary directory but the given source directory "/home/yuyichao/tmp/cmake-test/1/4/4/4/2/cmake/a" is not a subdirectory of "/home/yuyichao/tmp/cmake-test/1/4/4/2/cmake". When specifying an out-of-tree source a binary directory must be explicitly specified. -- Configuring incomplete, errors occurred! See also "/home/yuyichao/tmp/cmake-test/1/4/2/cmake/build/CMakeFiles/CMakeOutput.log". ``` Another real life example can be found in the comment here[1] and the qtcurve issue here[2]. [1] http://kde-look.org/content/show.php?content=40492 [2] https://github.com/QtCurve/qtcurve/issues/77 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-03 09:01 Yichao Yu New Issue ====================================================================== From brad.king at kitware.com Fri Oct 3 09:14:06 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 09:14:06 -0400 Subject: [cmake-developers] Integrate fixdep for kconfig In-Reply-To: References: <542ACBD0.3030209@kitware.com> Message-ID: <542EA11E.3090805@kitware.com> On 10/02/2014 08:52 AM, Sam H. wrote: > I try my best to describe my understanding. Thanks for the explanation. > My prototype patch is try to do what fixdep do in CMake. It is do-able in the CMake "Makefile" generator but AFAICT cannot possibly work for the Ninja generator or the VS/Xcode generators. Those all let the build tool do their own dependencies. > 4. Do more configuration: > $ cd .. > $ make menuconfig > $ make silentoldconfig In plain CMake, configuration like this is normally kept in CMake cache variables and edited with ccmake or cmake-gui. It's not the same interface as menuconfig but it has the same capabilities and works on all platforms CMake supports. > Because the license issue and mmap() issue, codes need to be re-implement. Yes. The implementor also shouldn't look at the original source. > However, I'm not familiar with CMake codes and C++. > So what can I do if this feature could be accepted? Personally I see little value in supporting an auxiliary configuration system in a way that works only with one of our generators. However, if it can be implemented in a way that is not intrusive and can be enabled optionally then it would be an acceptable patch. There must still be a way to follow autoconf.h with normal scanning if the kconfig part is not enabled. -Brad From aleixpol at kde.org Fri Oct 3 09:44:43 2014 From: aleixpol at kde.org (Aleix Pol) Date: Fri, 3 Oct 2014 15:44:43 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <542D4879.20204@kitware.com> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> <22742143.8V0LQmVuST@tuxedo.neundorf.net> <540DA65F.4030501@kitware.com> <541C6B8D.2020404@kitware.com> <5422CD5E.7020008@kitware.com> <542D4879.20204@kitware.com> Message-ID: On Thu, Oct 2, 2014 at 2:43 PM, Brad King wrote: > On 10/01/2014 07:46 PM, Aleix Pol wrote: > > I'm very interested in getting this in and iterating forward. > > > > Any comments? How do changes get integrated? > > My main concern is that the format has not been proven with a > corresponding implementation of an actual IDE/plugin to use it. > Once we start producing a format changing it later will be > problematic for compatibility. Even though we added a version > number to the file, an IDE might not be updated along with a > CMake that produces a newer version. > > Perhaps rather than a boolean "CMAKE_EXPORT_IDE_METADATA" > setting to enable this, the value should be a version number. > That way enabling it requires explicit specification of which > format version is desired. In this case we would need to use > a format version number that is independent of th CMake version > number. It would simply be incremented every time changes are > made. If the version number has the form . then > we could increment the minor number whenever fields are added > and the major number whenever fields are removed or changed. > > -Brad > > Ok, I can start working on it in a KDevelop branch and see what needs to be changed. Regarding passing the version rather than "ON" probably makes sense. I'll work on a patch to make it work this way. Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Fri Oct 3 09:52:01 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 03 Oct 2014 15:52:01 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <542D4879.20204@kitware.com> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <542D4879.20204@kitware.com> Message-ID: <6761034.LHuUtODnIM@eto> Brad King wrote: > On 10/01/2014 07:46 PM, Aleix Pol wrote: > > I'm very interested in getting this in and iterating forward. > > > > Any comments? How do changes get integrated? > > My main concern is that the format has not been proven with a > corresponding implementation of an actual IDE/plugin to use it. > Once we start producing a format changing it later will be > problematic for compatibility. Even though we added a version > number to the file, an IDE might not be updated along with a > CMake that produces a newer version. This probably needs a way to query for the IDE which versions the given CMake version supports, no? Otherwise a newer IDE may request version 3 and just get nothing because the CMake binary only supports 1 and 2. Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mw_triad at users.sourceforge.net Fri Oct 3 11:36:44 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 03 Oct 2014 11:36:44 -0400 Subject: [cmake-developers] CMake, Ninja generator, and ExternalProjects In-Reply-To: References: Message-ID: On 2014-07-25 17:05, Williams, Norman K wrote: > There?s also the ?console pool? facility that would allow > ExternalProject builds to display output, though that would get back > to the Gmake issue of different processes interleaving output. It wouldn't; the 'console' pool only permits one job at a time. So your outer build would run serially, directly showing the output of whatever (*one*) inner build is running at the time. -- Matthew From mw_triad at users.sourceforge.net Fri Oct 3 11:41:23 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 03 Oct 2014 11:41:23 -0400 Subject: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible In-Reply-To: <542E9D0B.1080806@kitware.com> References: <542DC4EF.2000400@gmail.com> <542E9D0B.1080806@kitware.com> Message-ID: On 2014-10-03 08:56, Brad King wrote: > On 10/02/2014 06:08 PM, Matthew Woehlke wrote: >> Please see also >> http://public.kitware.com/Bug/view.php?id=14915 which it sounds like >> this (partly) fixes; you may want to reference that in your patch or >> vice versa. > > I've applied the patch here and added the issue reference: > > Ninja: Use 'console' pool for CMake re-run if possible (#14915) > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f32a241 > >> (The "partly" is that the request is also for the 'install' target to >> use the console pool; not sure if you did that, want to tackle that, >> etc., but in any case this is a step in the right direction.) > > I'll leave that to a follow-up patch if anyone wants to do it. I was sort-of hoping / encouraging that Sylvain might be interested :-). Anyway, thanks! (Re-running CMake is the more important task, I think, as that's known to take minutes in some cases... install, while also an obvious candidate for such treatment, I believe tends to be quicker, so it less "important".) -- Matthew From eike at sf-mail.de Fri Oct 3 11:53:29 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 03 Oct 2014 17:53:29 +0200 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <542E9AC8.9030907@kitware.com> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <3958318.nxOjhsD5xf@caliban.sf-tec.de> <542E9AC8.9030907@kitware.com> Message-ID: <1613841.KYJJi9OZnb@eto> Brad King wrote: > On 10/03/2014 08:43 AM, Rolf Eike Beer wrote: > >> I think FPHSA could be changed to implement the expected behavior for > >> EXACT > > > > If it is acceptable to change FPHSA in that way I can just go for it. > > Yes, please try it. It looks like this line is the culprit: if (NOT "${${_NAME}_FIND_VERSION}" VERSION_EQUAL "${VERSION}") I can solve this in CMake language, but the question is again if it may be worth solving in the command itself? Meanwhile I'll prepare an implementation in CMake code, we can replace that with anything better anytime later. Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Fri Oct 3 12:14:38 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 12:14:38 -0400 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <1613841.KYJJi9OZnb@eto> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <3958318.nxOjhsD5xf@caliban.sf-tec.de> <542E9AC8.9030907@kitware.com> <1613841.KYJJi9OZnb@eto> Message-ID: <542ECB6E.8000307@kitware.com> On 10/03/2014 11:53 AM, Rolf Eike Beer wrote: > It looks like this line is the culprit: > > if (NOT "${${_NAME}_FIND_VERSION}" VERSION_EQUAL "${VERSION}") > > I can solve this in CMake language, but the question is again if it may be > worth solving in the command itself? Meanwhile I'll prepare an implementation > in CMake code, we can replace that with anything better anytime later. Yes, I think the command should be fixed to compare only as many components as are given on both sides, ignoring extra on one side. However, that will require a policy. Please fix it in the module by hand for now and look at adding a policy for this after the 3.1 release. Thanks, -Brad From eike at sf-mail.de Fri Oct 3 12:47:31 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 03 Oct 2014 18:47:31 +0200 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <542ECB6E.8000307@kitware.com> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <1613841.KYJJi9OZnb@eto> <542ECB6E.8000307@kitware.com> Message-ID: <7359420.jzfpyDp4lL@eto> Brad King wrote: > On 10/03/2014 11:53 AM, Rolf Eike Beer wrote: > > It looks like this line is the culprit: > > if (NOT "${${_NAME}_FIND_VERSION}" VERSION_EQUAL "${VERSION}") > > > > I can solve this in CMake language, but the question is again if it may be > > worth solving in the command itself? Meanwhile I'll prepare an > > implementation in CMake code, we can replace that with anything better > > anytime later. > Yes, I think the command should be fixed to compare only as many > components as are given on both sides, ignoring extra on one side. > However, that will require a policy. > > Please fix it in the module by hand for now and look at adding a > policy for this after the 3.1 release. Yes, that was my plan. This is what I have now (diff -b for easier review): diff --git a/Modules/FindPackageHandleStandardArgs.cmake b/Modules/FindPackageHandleStandardArgs.cmake index e8d1dfb..f8c990e 100644 --- a/Modules/FindPackageHandleStandardArgs.cmake +++ b/Modules/FindPackageHandleStandardArgs.cmake @@ -290,12 +290,38 @@ function(FIND_PACKAGE_HANDLE_STANDARD_ARGS _NAME _FIRST_ARG) if(VERSION) if(${_NAME}_FIND_VERSION_EXACT) # exact version required + # count the dots in the version string + string(REGEX REPLACE "[^.]" "" _VERSION_DOTS "${VERSION}") + # add one dot because there is one dot more than there are components + string(LENGTH "${_VERSION_DOTS}." _VERSION_DOTS) + if (_VERSION_DOTS GREATER ${_NAME}_FIND_VERSION_COUNT) + # give an exact match if the first ${NAME}_FIND_VERSION_COUNT components of the version string match + # this constructs the equivalent of "(([^.]\\.){${${_NAME}_FIND_VERSION_COUNT}})" + unset(_VERSION_REGEX) + # foreach(RANGE) doesn't like it if stop is greater start + if (${${_NAME}_FIND_VERSION_COUNT} GREATER 1) + foreach (_NUM RANGE 2 ${${_NAME}_FIND_VERSION_COUNT}) + set(_VERSION_REGEX "${_VERSION_REGEX}[^.]*\\.") + endforeach () + endif () + string(REGEX REPLACE "^(${_VERSION_REGEX}[^.]*)\\..*" "\\1" _VERSION_HEAD "${VERSION}") + unset(_VERSION_REGEX) + if (NOT ${_NAME}_FIND_VERSION VERSION_EQUAL _VERSION_HEAD) + set(VERSION_MSG "Found unsuitable version \"${VERSION}\", but required is exact version \"${${_NAME}_FIND_VERSION}\"") + set(VERSION_OK FALSE) + else () + set(VERSION_MSG "(found suitable exact version \"${VERSION}\")") + endif () + unset(_VERSION_HEAD) + else () if (NOT "${${_NAME}_FIND_VERSION}" VERSION_EQUAL "${VERSION}") set(VERSION_MSG "Found unsuitable version \"${VERSION}\", but required is exact version \"${${_NAME}_FIND_VERSION}\"") set(VERSION_OK FALSE) else () set(VERSION_MSG "(found suitable exact version \"${VERSION}\")") endif () + endif () + unset(_VERSION_DOTS) else() # minimum version specified: if ("${${_NAME}_FIND_VERSION}" VERSION_GREATER "${VERSION}") Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mantis at public.kitware.com Fri Oct 3 13:34:38 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 3 Oct 2014 13:34:38 -0400 Subject: [cmake-developers] [CMake 0015194]: Bug in CMake Xcode generator Message-ID: <5ca9a7d906c53a206bf3d2c71b453ef5@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15194 ====================================================================== Reported By: stopiccot Assigned To: ====================================================================== Project: CMake Issue ID: 15194 Category: CMake Reproducibility: always Severity: minor Priority: high Status: new ====================================================================== Date Submitted: 2014-10-03 13:34 EDT Last Modified: 2014-10-03 13:34 EDT ====================================================================== Summary: Bug in CMake Xcode generator Description: Generated project Xcode fails to build libraries with only object input files. Test repo: https://github.com/stopiccot/cmake_xcode_bug Xcode fails to create output file for "output_library_bugged" target nevertheless reporting that build succeeded. Everything is fine for "output_library_fixed" target. This actually maybe an Xcode not a CMake bug but we should consider adding this workaround into CMake. Example of real world project that suffers from this issue - https://github.com/PixarAnimationStudios/OpenSubdiv. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-03 13:34 stopiccot New Issue ====================================================================== From ben.boeckel at kitware.com Fri Oct 3 13:51:54 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 3 Oct 2014 13:51:54 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <542E964C.1050104@kitware.com> References: <542E964C.1050104@kitware.com> Message-ID: <20141003175154.GA2844@megas.kitwarein.com> On Fri, Oct 03, 2014 at 08:27:56 -0400, Brad King wrote: > In preparation for the first 3.1 release candidate I will feature- > freeze master as of 2014-10-09. As of now there are several open > topics in 'next' that we should try to land in master by then, but > please refrain from adding non-trivial changes in the meantime. I've just added the ubsan-support branch to stage (not merged yet; no new tests). It contains some documentation updates for AddressSanitizer and MEMORYCHECK_TYPE which were missed as well as support for MemoryCheckSanitizerOptions which adds key/value values to the environment variables for the sanitizers (ASAN_OPTIONS, TSAN_OPTIONS, and UBSAN_OPTIONS). Feel free to cherry-pick the documentation fixes (or I can spin out a branch) if the other changes are too late (I hope to add tests Monday, but can do it today if that's too late). --Ben From joubert.sy at gmail.com Fri Oct 3 14:00:00 2014 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Fri, 03 Oct 2014 20:00:00 +0200 Subject: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible In-Reply-To: References: <542DC4EF.2000400@gmail.com> <542E9D0B.1080806@kitware.com> Message-ID: <542EE420.7010406@gmail.com> Le 03/10/2014 17:41, Matthew Woehlke a ?crit : > On 2014-10-03 08:56, Brad King wrote: >> I'll leave that to a follow-up patch if anyone wants to do it. > > I was sort-of hoping / encouraging that Sylvain might be interested :-). > I quickly checked if it is possible. Unlike the rerun target which is manually added by the Ninja generator, the install and package targets are handled in a generic way by the utility target generator. Thus, handling these targets is not as straightforward as rerun. I'll keep digging a bit, maybe I can find a way to do it. ;-) From brad.king at kitware.com Fri Oct 3 14:34:38 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 14:34:38 -0400 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <7359420.jzfpyDp4lL@eto> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <1613841.KYJJi9OZnb@eto> <542ECB6E.8000307@kitware.com> <7359420.jzfpyDp4lL@eto> Message-ID: <542EEC3E.7050202@kitware.com> On 10/03/2014 12:47 PM, Rolf Eike Beer wrote: > + # give an exact match if the first ${NAME}_FIND_VERSION_COUNT components of the version string match > + # this constructs the equivalent of "(([^.]\\.){${${_NAME}_FIND_VERSION_COUNT}})" > + unset(_VERSION_REGEX) > + # foreach(RANGE) doesn't like it if stop is greater start > + if (${${_NAME}_FIND_VERSION_COUNT} GREATER 1) > + foreach (_NUM RANGE 2 ${${_NAME}_FIND_VERSION_COUNT}) > + set(_VERSION_REGEX "${_VERSION_REGEX}[^.]*\\.") > + endforeach () > + endif () Since _FIND_VERSION_COUNT is always [0-4], I think a hand-coded lookup table may be simpler and faster. > + string(REGEX REPLACE "^(${_VERSION_REGEX}[^.]*)\\..*" "\\1" _VERSION_HEAD "${VERSION}") Perhaps use something like if(VERSION MATCHES "^(${_VERSION_REGEX}[^.]*)\\..*") set(_VERSION_HEAD "${CMAKE_MATCH_1}") else() message(... bad VERSION in call to fphsa...) endif() in case something fails to match for some reason. Thanks, -Brad From mw_triad at users.sourceforge.net Fri Oct 3 14:43:47 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 03 Oct 2014 14:43:47 -0400 Subject: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible In-Reply-To: <542EE420.7010406@gmail.com> References: <542DC4EF.2000400@gmail.com> <542E9D0B.1080806@kitware.com> <542EE420.7010406@gmail.com> Message-ID: On 2014-10-03 14:00, Sylvain Joubert wrote: > Le 03/10/2014 17:41, Matthew Woehlke a ?crit : >> On 2014-10-03 08:56, Brad King wrote: >>> I'll leave that to a follow-up patch if anyone wants to do it. >> >> I was sort-of hoping / encouraging that Sylvain might be interested :-). > > I quickly checked if it is possible. > > Unlike the rerun target which is manually added by the Ninja generator, > the install and package targets are handled in a generic way by the > utility target generator. > > Thus, handling these targets is not as straightforward as rerun. > I'll keep digging a bit, maybe I can find a way to do it. ;-) Many thanks, Sylvain. Don't worry if it's going to be a pain; I was thinking since you were in there anyway it might be easier for you. It's certainly much appreciated if you want to tackle this, but no worries if you don't. Thanks again for the re-run CMake patch! -- Matthew From eike at sf-mail.de Fri Oct 3 14:48:27 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 03 Oct 2014 20:48:27 +0200 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <542EEC3E.7050202@kitware.com> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <7359420.jzfpyDp4lL@eto> <542EEC3E.7050202@kitware.com> Message-ID: <3092690.HDODxZtjQg@caliban.sf-tec.de> Am Freitag, 3. Oktober 2014, 14:34:38 schrieb Brad King: > On 10/03/2014 12:47 PM, Rolf Eike Beer wrote: > > + # give an exact match if the first ${NAME}_FIND_VERSION_COUNT > > components of the version string match + # this constructs the > > equivalent of "(([^.]\\.){${${_NAME}_FIND_VERSION_COUNT}})" + > > unset(_VERSION_REGEX) > > + # foreach(RANGE) doesn't like it if stop is greater start > > + if (${${_NAME}_FIND_VERSION_COUNT} GREATER 1) > > + foreach (_NUM RANGE 2 ${${_NAME}_FIND_VERSION_COUNT}) > > + set(_VERSION_REGEX "${_VERSION_REGEX}[^.]*\\.") > > + endforeach () > > + endif () > > Since _FIND_VERSION_COUNT is always [0-4], I think a hand-coded lookup > table may be simpler and faster. Yes. > > + string(REGEX REPLACE "^(${_VERSION_REGEX}[^.]*)\\..*" "\\1" > > _VERSION_HEAD "${VERSION}") > Perhaps use something like > > if(VERSION MATCHES "^(${_VERSION_REGEX}[^.]*)\\..*") > set(_VERSION_HEAD "${CMAKE_MATCH_1}") > else() > message(... bad VERSION in call to fphsa...) > endif() > > in case something fails to match for some reason. I counted the number of dots before, so there must be a match. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Fri Oct 3 14:56:46 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 14:56:46 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: References: <542ACE37.1040302@kitware.com> <5370725.77ofmgz3NP@stryke> <542AE1BE.4000608@kitware.com> Message-ID: <542EF16E.7080105@kitware.com> On 09/30/2014 01:44 PM, Adam Strzelecki wrote: >> Please merge the topic to 'next' for testing when you're ready. >> We can at least see if the dashboard stays clean with it. > > Done. Since this was merged the dashboard has reported several failing instances of the BundleUtilities test. They have errors like: /usr/bin/find: invalid mode '+0111' CMake Error at .../Modules/BundleUtilities.cmake:395 (string): string sub-command REPLACE requires at least four arguments. Please extend the topic with a fix. Also use quoting like: - string(REPLACE "\n" ";" file_list ${file_list}) + string(REPLACE "\n" ";" file_list "${file_list}") to make sure the command runs when the file list is empty. After extending the topic please merge to 'next' again and check if it fixes the dashboard. Thanks, -Brad From brad.king at kitware.com Fri Oct 3 15:02:42 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 15:02:42 -0400 Subject: [cmake-developers] FindThreads-macro topic Message-ID: <542EF2D2.6090304@kitware.com> Eike, The topic adds a macro to FindThreads: > +macro(check_threads_lib LIBNAME FUNCNAME VARNAME) Since it is not meant for public use, please name it something like _threads_check_lib. Thanks, -Brad From brad.king at kitware.com Fri Oct 3 15:13:10 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 15:13:10 -0400 Subject: [cmake-developers] kwsys SystemTools::RelativePath() In-Reply-To: <542AB8B7.8020102@gmail.com> References: <542AB8B7.8020102@gmail.com> Message-ID: <542EF546.1050003@kitware.com> On 09/30/2014 10:05 AM, Nils Gladitz wrote: > When both operands are the same absolute path I get the empty string as > a result. > > Should it be "."? Perhaps. One would need to track down existing call sites to see where that might affect behavior. IIRC it is exposed through file(RELATIVE_PATH), so it may need a policy. That is probably overkill because there are legitimate use cases where an empty string looks better than ".". -Brad From nilsgladitz at gmail.com Fri Oct 3 15:30:21 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 03 Oct 2014 21:30:21 +0200 Subject: [cmake-developers] kwsys SystemTools::RelativePath() In-Reply-To: <542EF546.1050003@kitware.com> References: <542AB8B7.8020102@gmail.com> <542EF546.1050003@kitware.com> Message-ID: <542EF94D.7040103@gmail.com> On 03.10.2014 21:13, Brad King wrote: > On 09/30/2014 10:05 AM, Nils Gladitz wrote: >> When both operands are the same absolute path I get the empty string as >> a result. >> >> Should it be "."? > Perhaps. One would need to track down existing call sites > to see where that might affect behavior. IIRC it is exposed > through file(RELATIVE_PATH), so it may need a policy. That > is probably overkill because there are legitimate use cases > where an empty string looks better than ".". I guess that might be a matter of definition. I wouldn't consider the empty string a valid path though I understand that this may be what people expect now given that this behavior has already been established. I've worked around the issue I had with the "wix-fix-root-dir-prop" topic for now so there is no immediate need to change behavior before the 3.1 release. Thanks for the feedback. Nils From eike at sf-mail.de Fri Oct 3 16:20:05 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 03 Oct 2014 22:20:05 +0200 Subject: [cmake-developers] FindThreads-macro topic In-Reply-To: <542EF2D2.6090304@kitware.com> References: <542EF2D2.6090304@kitware.com> Message-ID: <2672065.WbbgQxofbn@caliban.sf-tec.de> Am Freitag, 3. Oktober 2014, 15:02:42 schrieb Brad King: > Eike, > > The topic adds a macro to FindThreads: > > +macro(check_threads_lib LIBNAME FUNCNAME VARNAME) > > Since it is not meant for public use, please name it something > like _threads_check_lib. Will do. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From DLRdave at aol.com Fri Oct 3 20:25:59 2014 From: DLRdave at aol.com (David Cole) Date: Fri, 3 Oct 2014 20:25:59 -0400 Subject: [cmake-developers] kwsys SystemTools::RelativePath() In-Reply-To: <542EF94D.7040103@gmail.com> References: <542AB8B7.8020102@gmail.com> <542EF546.1050003@kitware.com> <542EF94D.7040103@gmail.com> Message-ID: Is the result of RelativePath guaranteed to be a directory name, or is it possibly a file name....? If a directory, then perhaps "." makes sense and wouldn't negatively impact anything (other than cosmetically) if changed. But if a file, then "." doesn't make as much sense. "." to me implies it is the "current directory" or the "directory containing this thing" depending on the context. D On Fri, Oct 3, 2014 at 3:30 PM, Nils Gladitz wrote: > On 03.10.2014 21:13, Brad King wrote: >> >> On 09/30/2014 10:05 AM, Nils Gladitz wrote: >>> >>> When both operands are the same absolute path I get the empty string as >>> a result. >>> >>> Should it be "."? >> >> Perhaps. One would need to track down existing call sites >> to see where that might affect behavior. IIRC it is exposed >> through file(RELATIVE_PATH), so it may need a policy. That >> is probably overkill because there are legitimate use cases >> where an empty string looks better than ".". > > > I guess that might be a matter of definition. > I wouldn't consider the empty string a valid path though I understand that > this may be what people expect now given that this behavior has already been > established. > > I've worked around the issue I had with the "wix-fix-root-dir-prop" topic > for now so there is no immediate need to change behavior before the 3.1 > release. > > Thanks for the feedback. > > Nils > -- > > 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 nilsgladitz at gmail.com Sat Oct 4 02:32:48 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sat, 04 Oct 2014 08:32:48 +0200 Subject: [cmake-developers] kwsys SystemTools::RelativePath() In-Reply-To: References: <542AB8B7.8020102@gmail.com> <542EF546.1050003@kitware.com> <542EF94D.7040103@gmail.com> Message-ID: <542F9490.2020301@gmail.com> On 04.10.2014 02:25, David Cole wrote: > Is the result of RelativePath guaranteed to be a directory name, or is > it possibly a file name....? If the second operand is a path to a file the result is a path to a file. If the second operand is a path to a directory the result is a path to a directory. The first operand can only be a path to a directory. A path can not at the same time refer to a file and a directory. So when both operands are the same path this gives that they, as well as the result, can only be directory paths. Nils From ono at java.pl Sat Oct 4 11:37:18 2014 From: ono at java.pl (Adam Strzelecki) Date: Sat, 4 Oct 2014 17:37:18 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <542EF16E.7080105@kitware.com> References: <542ACE37.1040302@kitware.com> <5370725.77ofmgz3NP@stryke> <542AE1BE.4000608@kitware.com> <542EF16E.7080105@kitware.com> Message-ID: Brad, I've applied your suggestions about quoting and used portable (POSIX compliant) find call that should work now on any system. Fixup pushed to next. Thank you for your support! --Adam From konstantin at podsvirov.pro Sun Oct 5 05:18:33 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Sun, 05 Oct 2014 13:18:33 +0400 Subject: [cmake-developers] [update]: CPack IFW generator In-Reply-To: <53EA6A47.2060607@kitware.com> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> <53D66577.2050506@kitware.com> <599601406656034@web5j.yandex.ru> <53D8F040.1000505@kitware.com> <20851406730617@web26j.yandex.ru> <367461407337889@web14m.yandex.ru> <53E266EE.1070700@kitware.com> <53E8D59E.10000@kitware.com> <620911407869868@web19j.yandex.ru> <53EA6A47.2060607@kitware.com> Message-ID: <2764301412500713@web9g.yandex.ru> Hello dear developers! Hello Brad! Hello Nils! Straight to the point: Brad please apply my changes! There are only two commits. CPackIFW: Search algorithm update http://git.podsvirov.pro/?p=kitware/cmake.git;a=commit;h=f9f748745c6f4ef5b2dbf6d0732bc67a23d1cc63 And CPackIFW: Added support for multiple repositories http://git.podsvirov.pro/?p=kitware/cmake.git;a=commit;h=ed9684a22cf4babeaa1f9083f4061d789e513ba9 And now for more details. First: I got rid of CPACKE_IFW_*_EXECUTABLE_FOUND variables (this has already been asked Nils). Secondly: I've added support for multiple repositories (this is a very nice and useful for related and large projects function). Also you can now configure protected repository. Brad, I was very careful and did not make critical changes. I spent testing locally on their projects and I all works well. I hope that my changes will be applied and will have to be tested and will be included in CMake version 3.1.0-RC1. Regards, Konstantin Podsvirov From ono at java.pl Sun Oct 5 15:35:05 2014 From: ono at java.pl (Adam Strzelecki) Date: Sun, 5 Oct 2014 21:35:05 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: References: <542ACE37.1040302@kitware.com> <5370725.77ofmgz3NP@stryke> <542AE1BE.4000608@kitware.com> <542EF16E.7080105@kitware.com> Message-ID: <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> Correct me if I am wrong but it seems CDash reports no further problems with my changes. Cheers, --Adam From ruslan_baratov at yahoo.com Sun Oct 5 16:59:08 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Mon, 06 Oct 2014 00:59:08 +0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' Message-ID: <5431B11C.3010209@yahoo.com> Hi, I have CMake modules that can share resources between different instances. For now I manage it by invoking `mkdir /lock-directory` and checking the result, then removing this directory so the next instance can do the modification. The problem occurs when somebody terminate CMake. Since I can't set handler (e.g. SIGINT) to CMake, directory will not be removed and will be "locked" forever. So it can't be resolved without some low-level management. I'm thinking about `file` command sub-option like LOCK_DIRECTORY: `file(LOCK_DIRECTORY "/path/to/shared-dir")`. Does it sounds doable? Thanks, Ruslo From nilsgladitz at gmail.com Mon Oct 6 06:39:46 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 06 Oct 2014 12:39:46 +0200 Subject: [cmake-developers] CMP0053 - "Simplify variable reference and escape sequence evaluation" - regression Message-ID: <54327172.6030408@gmail.com> CMP0053 warns/fails on "$ENV{ProgramFiles(x86)}". Could "()" be added to the legal set of characters when within an $ENV{} expansion? Nils From brad.king at kitware.com Mon Oct 6 08:48:33 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Oct 2014 08:48:33 -0400 Subject: [cmake-developers] CMP0053 - "Simplify variable reference and escape sequence evaluation" - regression In-Reply-To: <54327172.6030408@gmail.com> References: <54327172.6030408@gmail.com> Message-ID: <54328FA1.1000306@kitware.com> On 10/06/2014 06:39 AM, Nils Gladitz wrote: > CMP0053 warns/fails on "$ENV{ProgramFiles(x86)}". > > Could "()" be added to the legal set of characters when within an $ENV{} > expansion? We considered that case and decided to ask users to use a nested variable reference for that case. There is a similar workaround in "Modules/Platform/WindowsPaths.cmake". One reason is that adding more characters to the allowed set, especially as a special case for $ENV{}, triggers extra tests and branches inside a tight loop that is used everywhere. -Brad From nilsgladitz at gmail.com Mon Oct 6 08:52:31 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 06 Oct 2014 14:52:31 +0200 Subject: [cmake-developers] CMP0053 - "Simplify variable reference and escape sequence evaluation" - regression In-Reply-To: <54328FA1.1000306@kitware.com> References: <54327172.6030408@gmail.com> <54328FA1.1000306@kitware.com> Message-ID: <5432908F.80909@gmail.com> On 10/06/2014 02:48 PM, Brad King wrote: > On 10/06/2014 06:39 AM, Nils Gladitz wrote: >> CMP0053 warns/fails on "$ENV{ProgramFiles(x86)}". >> >> Could "()" be added to the legal set of characters when within an $ENV{} >> expansion? > > We considered that case and decided to ask users to use a > nested variable reference for that case. There is a similar > workaround in "Modules/Platform/WindowsPaths.cmake". > > One reason is that adding more characters to the allowed set, > especially as a special case for $ENV{}, triggers extra tests > and branches inside a tight loop that is used everywhere. All right, no problem; I'll work around it. Thanks! Nils From brad.king at kitware.com Mon Oct 6 08:54:24 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Oct 2014 08:54:24 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5431B11C.3010209@yahoo.com> References: <5431B11C.3010209@yahoo.com> Message-ID: <54329100.8020502@kitware.com> On 10/05/2014 04:59 PM, Ruslan Baratov via cmake-developers wrote: > So it can't be resolved without some low-level management. I'm thinking > about `file` command sub-option like LOCK_DIRECTORY: > `file(LOCK_DIRECTORY "/path/to/shared-dir")`. Does it sounds doable? I think it is a reasonable proposal. However, more design is needed here, including at least the following items: * There needs to be a way to define the scope of the lock other than "until cmake exits". For example, "until current function exits". * There needs to be a way to explicitly unlock early, or to explicitly release management of the lock (e.g. to pass to some other process). * The implementation on Windows needs to be handled carefully. The "safe" way to delete a file there is to open it with a handle that is marked as delete-on-close, and then close the handle. That way the file is eventually deleted even if other processes currently have it open/locked. I don't know if there is an equivalent for a directory. Thanks, -Brad From brad.king at kitware.com Mon Oct 6 09:01:51 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Oct 2014 09:01:51 -0400 Subject: [cmake-developers] [update]: CPack IFW generator In-Reply-To: <2764301412500713@web9g.yandex.ru> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> <53D66577.2050506@kitware.com> <599601406656034@web5j.yandex.ru> <53D8F040.1000505@kitware.com> <20851406730617@web26j.yandex.ru> <367461407337889@web14m.yandex.ru> <53E266EE.1070700@kitware.com> <53E8D59E.10000@kitware.com> <620911407869868@web19j.yandex.ru> <53EA6A47.2060607@kitware.com> <2764301412500713@web9g.yandex.ru> Message-ID: <543292BF.1040704@kitware.com> On 10/05/2014 05:18 AM, Konstantin Podsvirov wrote: > Straight to the point: Brad please apply my changes! I've merged the topic to 'next' for testing: CPackIFW: Search algorithm update http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f9f74874 CPackIFW: Added support for multiple repositories http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed9684a2 Thanks, -Brad From brad.king at kitware.com Mon Oct 6 09:15:37 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Oct 2014 09:15:37 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> References: <542ACE37.1040302@kitware.com> <5370725.77ofmgz3NP@stryke> <542AE1BE.4000608@kitware.com> <542EF16E.7080105@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> Message-ID: <543295F9.1020705@kitware.com> On 10/04/2014 11:37 AM, Adam Strzelecki wrote: > I've applied your suggestions about quoting and used portable > (POSIX compliant) find call that should work now on any system. Thanks. On 10/05/2014 03:35 PM, Adam Strzelecki wrote: > Correct me if I am wrong but it seems CDash reports no > further problems with my changes. It's better, but the BundleUtilities test fails on OS X 10.5: http://open.cdash.org/testDetails.php?test=285651145&build=3517533 -- 6/10: fixing up '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1' install_name_tool: more than one input file specified (.../Tests/BundleUtilities/testdir1 and -delete_rpath) Usage: install_name_tool [-change old new] ... [-id name] input -- 7/10: fixing up '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/module1.so' install_name_tool: more than one input file specified (.../Tests/BundleUtilities/testdir1 and -delete_rpath) Usage: install_name_tool [-change old new] ... [-id name] input >From this message it looks like the install_name_tool does not support -delete_rpath. IIRC @rpath was first added in OS X 10.5 so it looks like that part had not yet matured. Use of -delete_rpath was previously added at install-time here: OS X: Add RPATH support for Mac. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=94e7fef2 so I think this problem existed before but was not exposed by tests. Clinton, what do you think of changing the Darwin.cmake test for enabling @rpath support to require OS X 10.6 instead of 10.5? Otherwise we may be leaking build tree RPATH entries into installed files on 10.5. Thanks, -Brad From brad.king at kitware.com Mon Oct 6 09:17:43 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Oct 2014 09:17:43 -0400 Subject: [cmake-developers] [update]: CPack IFW generator In-Reply-To: <762721412601328@web18m.yandex.ru> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> <53D66577.2050506@kitware.com> <599601406656034@web5j.yandex.ru> <53D8F040.1000505@kitware.com> <20851406730617@web26j.yandex.ru> <367461407337889@web14m.yandex.ru> <53E266EE.1070700@kitware.com> <53E8D59E.10000@kitware.com> <620911407869868@web19j.yandex.ru> <53EA6A47.2060607@kitware.com> <2764301412500713@web9g.yandex.ru> <543292BF.1040704@kitware.com> <762721412601328@web18m.yandex.ru> Message-ID: <54329677.9040305@kitware.com> On 10/06/2014 09:15 AM, Konstantin Podsvirov wrote: > Can I expect that CPack IFW generator will be in the tag v3.1.0-rc1? Anything that is in 'master' now will be in 3.1. This update should be merged in time barring catastrophic problems with it. Thanks, -Brad From konstantin at podsvirov.pro Mon Oct 6 09:15:28 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Mon, 06 Oct 2014 17:15:28 +0400 Subject: [cmake-developers] [update]: CPack IFW generator In-Reply-To: <543292BF.1040704@kitware.com> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> <53D66577.2050506@kitware.com> <599601406656034@web5j.yandex.ru> <53D8F040.1000505@kitware.com> <20851406730617@web26j.yandex.ru> <367461407337889@web14m.yandex.ru> <53E266EE.1070700@kitware.com> <53E8D59E.10000@kitware.com> <620911407869868@web19j.yandex.ru> <53EA6A47.2060607@kitware.com> <2764301412500713@web9g.yandex.ru> <543292BF.1040704@kitware.com> Message-ID: <762721412601328@web18m.yandex.ru> 06.10.2014, 17:01, "Brad King" : > On 10/05/2014 05:18 AM, Konstantin Podsvirov wrote: >> Straight to the point: Brad please apply my changes! > > I've merged the topic to 'next' for testing... Thank you :-) Can I expect that CPack IFW generator will be in the tag v3.1.0-rc1? This is my first contribution to CMake and I can't wait to see the results of its application. Regards, Konstantin Podsvirov From clinton at elemtech.com Mon Oct 6 10:14:33 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Mon, 6 Oct 2014 08:14:33 -0600 (MDT) Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <543295F9.1020705@kitware.com> References: <542ACE37.1040302@kitware.com> <542AE1BE.4000608@kitware.com> <542EF16E.7080105@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> <543295F9.1020705@kitware.com> Message-ID: <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> ----- Original Message ----- > On 10/04/2014 11:37 AM, Adam Strzelecki wrote: > > I've applied your suggestions about quoting and used portable > > (POSIX compliant) find call that should work now on any system. > > Thanks. > > On 10/05/2014 03:35 PM, Adam Strzelecki wrote: > > Correct me if I am wrong but it seems CDash reports no > > further problems with my changes. > > It's better, but the BundleUtilities test fails on OS X 10.5: > > http://open.cdash.org/testDetails.php?test=285651145&build=3517533 > > -- 6/10: fixing up > '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1' > install_name_tool: more than one input file specified > (.../Tests/BundleUtilities/testdir1 and -delete_rpath) > Usage: install_name_tool [-change old new] ... [-id name] input > -- 7/10: fixing up > '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/module1.so' > install_name_tool: more than one input file specified > (.../Tests/BundleUtilities/testdir1 and -delete_rpath) > Usage: install_name_tool [-change old new] ... [-id name] input > > From this message it looks like the install_name_tool does not > support -delete_rpath. IIRC @rpath was first added in OS X 10.5 > so it looks like that part had not yet matured. > > Use of -delete_rpath was previously added at install-time here: > > OS X: Add RPATH support for Mac. > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=94e7fef2 > > so I think this problem existed before but was not exposed by tests. > > Clinton, what do you think of changing the Darwin.cmake test for > enabling @rpath support to require OS X 10.6 instead of 10.5? > Otherwise we may be leaking build tree RPATH entries into installed > files on 10.5. Sure, I think it would be good to require 10.6. We also have uses of the -delete_rpath/-add_rpath parameters in cmInstallTargetGenerator.cxx, and the test of that already requires 10.6 or greater. Clint From ono at java.pl Mon Oct 6 10:36:43 2014 From: ono at java.pl (Adam Strzelecki) Date: Mon, 6 Oct 2014 16:36:43 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> References: <542ACE37.1040302@kitware.com> <542AE1BE.4000608@kitware.com> <542EF16E.7080105@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> Message-ID: <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> > Sure, I think it would be good to require 10.6. > We also have uses of the -delete_rpath/-add_rpath parameters in cmInstallTargetGenerator.cxx, and the test of that already requires 10.6 or greater. Moreover I believe nobody nowadays builds for 10.5 on 10.5. Since 10.6 with Xcode 3 supports 10.5 PPC and Apple allows virtualization of 10.6 Server, so if anyone still targets PPC on 10.5 or earlier then 10.6 is natural choice. --Adam From brad.king at kitware.com Mon Oct 6 11:00:33 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Oct 2014 11:00:33 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> References: <542ACE37.1040302@kitware.com> <542AE1BE.4000608@kitware.com> <542EF16E.7080105@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> Message-ID: <5432AE91.1010708@kitware.com> On 10/06/2014 10:36 AM, Adam Strzelecki wrote: >> Sure, I think it would be good to require 10.6. > > Moreover I believe nobody nowadays builds for 10.5 on 10.5. Perhaps no one has to build that way for deployment but there could still be people just building for their own host as the only computer they have. The fact that our dashboard reported this problem means we are testing that case. Clinton, I don't have a 10.5 machine anymore and the test is failing on yours. Please take whatever action you feel is appropriate to resolve the test failure on that machine. This could mean either disabling rpath altogether on 10.5 or changing the new hunk: > + foreach(rpath ${${ikey}_RPATHS}) > + set(changes ${changes} -delete_rpath "${rpath}") > + endforeach() to warn and skip removal when hosted on 10.5. Or another option you find. This needs to be resolved in the next day or two or the topic won't be in CMake 3.1. Thanks, -Brad From ben.boeckel at kitware.com Mon Oct 6 14:24:47 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 6 Oct 2014 14:24:47 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <20141003175154.GA2844@megas.kitwarein.com> References: <542E964C.1050104@kitware.com> <20141003175154.GA2844@megas.kitwarein.com> Message-ID: <20141006182447.GA7342@megas.kitwarein.com> On Fri, Oct 03, 2014 at 13:51:54 -0400, Ben Boeckel wrote: > Feel free to cherry-pick the documentation fixes (or I can spin out a > branch) if the other changes are too late (I hope to add tests Monday, > but can do it today if that's too late). A test has been added. Brad, there are some bugfixes for tsan and asan in there. Is it too late to merge the whole branch or do you want me to cherry-pick them out? --Ben From brad.king at kitware.com Mon Oct 6 14:31:58 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Oct 2014 14:31:58 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <20141006182447.GA7342@megas.kitwarein.com> References: <542E964C.1050104@kitware.com> <20141003175154.GA2844@megas.kitwarein.com> <20141006182447.GA7342@megas.kitwarein.com> Message-ID: <5432E01E.7020105@kitware.com> On 10/06/2014 02:24 PM, Ben Boeckel wrote: > On Fri, Oct 03, 2014 at 13:51:54 -0400, Ben Boeckel wrote: >> Feel free to cherry-pick the documentation fixes (or I can spin out a >> branch) if the other changes are too late (I hope to add tests Monday, >> but can do it today if that's too late). > > A test has been added. Brad, there are some bugfixes for tsan and asan > in there. Is it too late to merge the whole branch or do you want me to > cherry-pick them out? Please re-order the topic to have all the fixes first, and then the changes to add ubsan support. That way I can revert the latter if it is problematic. Then merge the whole topic for testing. Thanks, -Brad From ben.boeckel at kitware.com Mon Oct 6 15:29:53 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 6 Oct 2014 15:29:53 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <5432E01E.7020105@kitware.com> References: <542E964C.1050104@kitware.com> <20141003175154.GA2844@megas.kitwarein.com> <20141006182447.GA7342@megas.kitwarein.com> <5432E01E.7020105@kitware.com> Message-ID: <20141006192953.GB30737@megas.kitwarein.com> On Mon, Oct 06, 2014 at 14:31:58 -0400, Brad King wrote: > Please re-order the topic to have all the fixes first, and then the > changes to add ubsan support. That way I can revert the latter if > it is problematic. Then merge the whole topic for testing. Done. --Ben From eike at sf-mail.de Mon Oct 6 16:04:09 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 06 Oct 2014 22:04:09 +0200 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <542EEC3E.7050202@kitware.com> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <7359420.jzfpyDp4lL@eto> <542EEC3E.7050202@kitware.com> Message-ID: <1936223.oZsl9n5N2H@eto> Brad King wrote: > On 10/03/2014 12:47 PM, Rolf Eike Beer wrote: > > + # give an exact match if the first ${NAME}_FIND_VERSION_COUNT > > components of the version string match + # this constructs the > > equivalent of "(([^.]\\.){${${_NAME}_FIND_VERSION_COUNT}})" + > > unset(_VERSION_REGEX) > > + # foreach(RANGE) doesn't like it if stop is greater start > > + if (${${_NAME}_FIND_VERSION_COUNT} GREATER 1) > > + foreach (_NUM RANGE 2 ${${_NAME}_FIND_VERSION_COUNT}) > > + set(_VERSION_REGEX "${_VERSION_REGEX}[^.]*\\.") > > + endforeach () > > + endif () > > Since _FIND_VERSION_COUNT is always [0-4], I think a hand-coded lookup > table may be simpler and faster. Topic FPHSA_exact_version pushed to next. Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From clinton at elemtech.com Tue Oct 7 00:34:51 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Mon, 6 Oct 2014 22:34:51 -0600 (MDT) Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <5432AE91.1010708@kitware.com> References: <542ACE37.1040302@kitware.com> <542EF16E.7080105@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> <5432AE91.1010708@kitware.com> Message-ID: <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> ----- Original Message ----- > On 10/06/2014 10:36 AM, Adam Strzelecki wrote: > >> Sure, I think it would be good to require 10.6. > > > > Moreover I believe nobody nowadays builds for 10.5 on 10.5. > > Perhaps no one has to build that way for deployment but there could > still be people just building for their own host as the only computer > they have. The fact that our dashboard reported this problem means > we are testing that case. > > Clinton, I don't have a 10.5 machine anymore and the test is failing > on yours. Please take whatever action you feel is appropriate to > resolve the test failure on that machine. This could mean either > disabling rpath altogether on 10.5 or changing the new hunk: > > > + foreach(rpath ${${ikey}_RPATHS}) > > + set(changes ${changes} -delete_rpath "${rpath}") > > + endforeach() > > to warn and skip removal when hosted on 10.5. Or another option you > find. > > This needs to be resolved in the next day or two or the topic won't > be in CMake 3.1. > > Thanks, > -Brad > > I don't have a 10.5 machine, but I've put in a commit which I hope solves the problem. 36c509b9 OSX: Only enable @rpath support on OS X 10.6 or greater. Clint From ruslan_baratov at yahoo.com Tue Oct 7 02:49:21 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Tue, 07 Oct 2014 10:49:21 +0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <54329100.8020502@kitware.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> Message-ID: <54338CF1.3070304@yahoo.com> On 06-Oct-14 16:54, Brad King wrote: > On 10/05/2014 04:59 PM, Ruslan Baratov via cmake-developers wrote: >> So it can't be resolved without some low-level management. I'm thinking >> about `file` command sub-option like LOCK_DIRECTORY: >> `file(LOCK_DIRECTORY "/path/to/shared-dir")`. Does it sounds doable? > I think it is a reasonable proposal. However, more design is needed > here, including at least the following items: > > * There needs to be a way to define the scope of the lock other than > "until cmake exits". For example, "until current function exits". > > * There needs to be a way to explicitly unlock early, or > to explicitly release management of the lock (e.g. to pass to some other process). How it will looks like in terms of CMake code? > > * The implementation on Windows needs to be handled carefully. > The "safe" way to delete a file there is to open it with a handle > that is marked as delete-on-close, and then close the handle. > That way the file is eventually deleted even if other processes > currently have it open/locked. I don't know if there is an > equivalent for a directory. > > Thanks, > -Brad > From amine.khaldi at reactos.org Tue Oct 7 03:22:02 2014 From: amine.khaldi at reactos.org (Amine Khaldi) Date: Tue, 07 Oct 2014 08:22:02 +0100 Subject: [cmake-developers] Severe regression caused by #14972 fixes Message-ID: <5433949A.6060707@reactos.org> Hi, Please note that from the http://www.cmake.org/Bug/view.php?id=14972 fixes on, we can no longer compile ReactOS. We have many DEPENDS on files that exist in the source (they are simply input files, they're not generated or so) like spec files, inf files, idl files...etc and they end up in the "Unknown Build Time Dependencies" which should not happen, and did not happen with CMake 2.8.x As a result of this, it's no longer possible to use the new CMake to compile ReactOS, which makes us see this as a severe regression, considering that CMake is the build system we use to compile the project. Adam, Brad and co, can you please help ? Regards, Amine. From konstantin at podsvirov.pro Tue Oct 7 04:27:37 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 07 Oct 2014 12:27:37 +0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <542E964C.1050104@kitware.com> References: <542E964C.1050104@kitware.com> Message-ID: <2161691412670457@web14h.yandex.ru> Hello dear developers! 03.10.2014, 16:28, "Brad King" : > Hi Folks, > > In preparation for the first 3.1 release candidate I will feature- > freeze master as of 2014-10-09. As of now there are several open > topics in 'next' that we should try to land in master by then, but > please refrain from adding non-trivial changes in the meantime. > > Thanks, > -Brad CMake is a large set of tools which touches upon many topics. I think everyone is doing their questions and know little about the problems and successes of others. I noticed that the version for developers (from cmake.org/file/dev does not contain the html documentation (I checked for Windows). Fresh build documentation from 7 October: Sphinx http://ifw.podsvirov.pro/cmake/doc/sphinx Doxygen http://ifw.podsvirov.pro/cmake/doc/doxygen In the first place when the distribution CMake version is created Sphinx and it's a good documentation. But I urge you not to forget about documenting code - it will help new developers to understand and to make a contribution. The version of Doxygen documentation is not in the best form, but I have plans to work over this. And advertising: CMake 3.1 will contain the new CPack generator called "IFW", which will help to create a nice installer with a graphical user interface on the desktop. Fresh morning building (with html documentation from Sphinx) online installer with update support. Linux: http://ifw.podsvirov.pro/cmake/cmake-dev-linux-x86_64-online.run Windows: http://ifw.podsvirov.pro/cmake/cmake-dev-windows-x86-online.exe Set one is updated constantly :-) All for a good day! Regards, Konstantin Podsvirov From mantis at public.kitware.com Tue Oct 7 08:09:18 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 7 Oct 2014 08:09:18 -0400 Subject: [cmake-developers] [CMake 0015198]: ps2pdf not detected when cross-compiling Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15198 ====================================================================== Reported By: Helfer Thomas Assigned To: ====================================================================== Project: CMake Issue ID: 15198 Category: CMake Reproducibility: always Severity: minor Priority: low Status: new ====================================================================== Date Submitted: 2014-10-07 08:09 EDT Last Modified: 2014-10-07 08:09 EDT ====================================================================== Summary: ps2pdf not detected when cross-compiling Description: Hi, ps2pdf not detected when cross-compiling (and only when cross-compiling), but latex is. The main difference seems that latex is an executable and ps2pdf14 a script (I am using the standard texlive distribution). Steps to Reproduce: 1) decompress the attached archive and launch cmake in the created directory: cmake . -DCMAKE_TOOLCHAIN_FILE=../ToolChain-i686-w64-mingw32.cmake 2) check the PS2PDF_CONVERTER value in CMakeCache.txt: //Path to a program. PS2PDF_CONVERTER:FILEPATH=PS2PDF_CONVERTER-NOTFOUND Additional Information: ps2pdf is detected when no toolchain file is declared ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-07 08:09 Helfer Thomas New Issue 2014-10-07 08:09 Helfer Thomas File Added: test-cmake.tar.bz2 ====================================================================== From brad.king at kitware.com Tue Oct 7 08:25:37 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Oct 2014 08:25:37 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <54338CF1.3070304@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> Message-ID: <5433DBC1.5080800@kitware.com> On 10/07/2014 02:49 AM, Ruslan Baratov wrote: > How it will looks like in terms of CMake code? That's what I'm asking you to think through and propose ;) Thanks, -Brad From brad.king at kitware.com Tue Oct 7 08:28:37 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Oct 2014 08:28:37 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> References: <542ACE37.1040302@kitware.com> <542EF16E.7080105@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> <5432AE91.1010708@kitware.com> <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> Message-ID: <5433DC75.9010705@kitware.com> On 10/07/2014 12:34 AM, clinton at elemtech.com wrote: > I don't have a 10.5 machine Oops, I must have mixed up my browser tabs on that one. > but I've put in a commit which I hope solves the problem. > 36c509b9 OSX: Only enable @rpath support on OS X 10.6 or greater. Thanks! -Brad From brad.king at kitware.com Tue Oct 7 08:47:50 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Oct 2014 08:47:50 -0400 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <5433949A.6060707@reactos.org> References: <5433949A.6060707@reactos.org> Message-ID: <5433E0F6.2090802@kitware.com> On 10/07/2014 03:22 AM, Amine Khaldi wrote: > Please note that from the http://www.cmake.org/Bug/view.php?id=14972 > fixes on, we can no longer compile ReactOS. Thanks for trying the development version and reporting this regression before it was released. > We have many DEPENDS on files that exist in the source (they are simply > input files, they're not generated or so) like spec files, inf files, > idl files...etc and they end up in the "Unknown Build Time Dependencies" > which should not happen, and did not happen with CMake 2.8.x Would you please construct a CMake code example demonstrating this in a small test case? We'd rather not have to try building all of ReactOS to reproduce this. Also, what build-time failure do you actually get? Thanks, -Brad From bill.hoffman at kitware.com Tue Oct 7 10:09:01 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 07 Oct 2014 10:09:01 -0400 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <5433E0F6.2090802@kitware.com> References: <5433949A.6060707@reactos.org> <5433E0F6.2090802@kitware.com> Message-ID: <5433F3FD.8070602@kitware.com> On 10/7/2014 8:47 AM, Brad King wrote: > Please note that from thehttp://www.cmake.org/Bug/view.php?id=14972 >>fixes on, we can no longer compile ReactOS. Also, if you really care about ReactOS, you could run a nightly cmake dashboard. Or it is almost certain that it will get broken again. If we are not testing it, it is broken... http://www.cmake.org/testing/ Thanks. -Bill From nilsgladitz at gmail.com Tue Oct 7 10:15:20 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 07 Oct 2014 16:15:20 +0200 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <5433F3FD.8070602@kitware.com> References: <5433949A.6060707@reactos.org> <5433E0F6.2090802@kitware.com> <5433F3FD.8070602@kitware.com> Message-ID: <5433F578.9000900@gmail.com> On 10/07/2014 04:09 PM, Bill Hoffman wrote: > On 10/7/2014 8:47 AM, Brad King wrote: >> Please note that from thehttp://www.cmake.org/Bug/view.php?id=14972 >>> fixes on, we can no longer compile ReactOS. > Also, if you really care about ReactOS, you could run a nightly cmake > dashboard. Or it is almost certain that it will get broken again. If > we are not testing it, it is broken... > > http://www.cmake.org/testing/ To clarify as far as I understand it this particular issue is with building ReactOS on regular Windows rather than using CMake under ReactOS. Which of course doesn't mean that there shouldn't be a dashboard for it nonetheless :) Nils From brad.king at kitware.com Tue Oct 7 10:35:24 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Oct 2014 10:35:24 -0400 Subject: [cmake-developers] FindThreads_overhaul topic Message-ID: <5433FA2C.9070809@kitware.com> Eike, This fails on a few dashboard machines: http://open.cdash.org/testDetails.php?test=286158250&build=3519076 CMake Error at /.../Modules/FindThreads.cmake:207 (add_library): add_library cannot create imported target "CMake::Threads" because another target with the same name already exists. Instead of using a variable like HAVE_CMAKE_THREADS_TARGET, just test for the target. Look at FindOpenGL for an example: if(OPENGL_FOUND) if(NOT TARGET OpenGL::GL) add_library(OpenGL::GL UNKNOWN IMPORTED) > + add_library(CMake::Threads INTERFACE IMPORTED GLOBAL) The imported target should not be GLOBAL. Thanks, -Brad From ono at java.pl Tue Oct 7 10:42:36 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 7 Oct 2014 16:42:36 +0200 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <5433F578.9000900@gmail.com> References: <5433949A.6060707@reactos.org> <5433E0F6.2090802@kitware.com> <5433F3FD.8070602@kitware.com> <5433F578.9000900@gmail.com> Message-ID: > To clarify as far as I understand it this particular issue is with building ReactOS on regular Windows rather than using CMake under ReactOS. > > Which of course doesn't mean that there shouldn't be a dashboard for it nonetheless :) Yup, this is what I understand. It isn't a problem with compiling CMake on ReactOS, but problem of compiling ReactOS with latest CMake master. I'll follow the discussion with Amine and try to sort it out. --Adam From brad.king at kitware.com Tue Oct 7 10:43:23 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Oct 2014 10:43:23 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <542E964C.1050104@kitware.com> References: <542E964C.1050104@kitware.com> Message-ID: <5433FC0B.4060802@kitware.com> On 10/03/2014 08:27 AM, Brad King wrote: > In preparation for the first 3.1 release candidate I will feature- > freeze master as of 2014-10-09. As of now there are several open > topics in 'next' that we should try to land in master by then, but > please refrain from adding non-trivial changes in the meantime. In order to get the dashboard cleaned up for final merges to 'master' before the release, please refrain from merging any changes other than dashboard fixes and documentation updates to 'next'. Thanks, -Brad From ono at java.pl Tue Oct 7 10:56:40 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 7 Oct 2014 16:56:40 +0200 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <5433949A.6060707@reactos.org> References: <5433949A.6060707@reactos.org> Message-ID: > As a result of this, it's no longer possible to use the new CMake to compile ReactOS, which makes us see this as a severe regression, considering that CMake is the build system we use to compile the project. > Adam, Brad and co, can you please help ? If I understand correctly the change introduced by a33cf6d08853ea4c79324bdd36c04f311a23f20a (Ninja: Consider only custom commands deps as side-effects (#14972)) caused that regression? Can you please point to me any test case I can run in order to see it failing on CMake 3.x and running fine on CMake 2.8. If this is a bug I am willing to fix it ASAP. However please note that if these files are produced by some custom commands that not specify them as an output and then these are inputs (dependencies) to some regular build command, then it is expected behavior. Indeed it working was working previously in 2.8 just by coincidence, because CMake was generating suboptimal build graph simply adding all custom commands regardless of anything as implicit dependencies, even it was not necessary or expressed anywhere, causing severe clutter in Ninja build graph. So, (1) Are these .spec, .inf or .idl generated by some custom commands? (2) If yes, are these files specified as an output of these subcommand commands? If no, why? --Adam From nilsgladitz at gmail.com Tue Oct 7 11:04:14 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 07 Oct 2014 17:04:14 +0200 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: References: <5433949A.6060707@reactos.org> Message-ID: <543400EE.5090803@gmail.com> On 10/07/2014 04:56 PM, Adam Strzelecki wrote: > (1) Are these .spec, .inf or .idl generated by some custom commands? > (2) If yes, are these files specified as an output of these subcommand commands? If no, why? From what I remember from the IRC discussion ... They are regular (not generated) source files that are listed as dependencies (but not outputs) of custom commands. Nils From bill.hoffman at kitware.com Tue Oct 7 11:34:21 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 07 Oct 2014 11:34:21 -0400 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: References: <5433949A.6060707@reactos.org> <5433E0F6.2090802@kitware.com> <5433F3FD.8070602@kitware.com> <5433F578.9000900@gmail.com> Message-ID: <543407FD.8030602@kitware.com> On 10/7/2014 10:42 AM, Adam Strzelecki wrote: >> >Which of course doesn't mean that there shouldn't be a dashboard for it nonetheless:) > Yup, this is what I understand. It isn't a problem with compiling CMake on ReactOS, but problem of compiling ReactOS with latest CMake master. > > I'll follow the discussion with Amine and try to sort it out. I see. In that case a contract test might be a good thing... https://github.com/Kitware/CMake/tree/master/Tests/Contracts The idea is to add a build of a project as a test to CMake. See CMAKE_CONTRACT_PROJECTS in Tests/CMakeLists.txt for an idea of how this works. -Bill From eike at sf-mail.de Tue Oct 7 12:18:56 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 07 Oct 2014 18:18:56 +0200 Subject: [cmake-developers] FindThreads_overhaul topic In-Reply-To: <5433FA2C.9070809@kitware.com> References: <5433FA2C.9070809@kitware.com> Message-ID: <1560898.ZRjqAlt5LQ@caliban.sf-tec.de> Am Dienstag, 7. Oktober 2014, 10:35:24 schrieb Brad King: > Eike, > > This fails on a few dashboard machines: > > http://open.cdash.org/testDetails.php?test=286158250&build=3519076 > CMake Error at /.../Modules/FindThreads.cmake:207 (add_library): > add_library cannot create imported target "CMake::Threads" because > another target with the same name already exists. > > Instead of using a variable like HAVE_CMAKE_THREADS_TARGET, > just test for the target. Look at FindOpenGL for an example: > > if(OPENGL_FOUND) > if(NOT TARGET OpenGL::GL) > add_library(OpenGL::GL UNKNOWN IMPORTED) > > > + add_library(CMake::Threads INTERFACE IMPORTED GLOBAL) > > The imported target should not be GLOBAL. Both issues should be fixed now. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Tue Oct 7 14:03:57 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Oct 2014 14:03:57 -0400 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <1936223.oZsl9n5N2H@eto> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <7359420.jzfpyDp4lL@eto> <542EEC3E.7050202@kitware.com> <1936223.oZsl9n5N2H@eto> Message-ID: <54342B0D.6030809@kitware.com> On 10/06/2014 04:04 PM, Rolf Eike Beer wrote: > Topic FPHSA_exact_version pushed to next. Thanks. The impl looks okay to me. Please look at extending the FindPackageTest with a case to cover this. It already has at least one case for FPHSA. Alternatively you could add cases to RunCMake.find_package if that proves easier. Thanks, -Brad From ono at java.pl Tue Oct 7 14:21:58 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 7 Oct 2014 20:21:58 +0200 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <543400EE.5090803@gmail.com> References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> Message-ID: > From what I remember from the IRC discussion ... > They are regular (not generated) source files that are listed as dependencies (but not outputs) of custom commands. Okay now I get it. So actually 7243c951 (Ninja: Don't limit custom cmd side-effects to build folder (#14972)) is to blame not a33cf6d0 (Ninja: Consider only custom commands deps as side-effects (#14972)). Previously in 2.8 only files in build folder might have been be side-effects, but as we have discussed with Brad this is pretty inaccurate assumption. So we have decided that ANY file that is dependency of custom command may be a side effect, therefore ReactOS files landing in "Unknown Build Time Dependencies." that serve only one purpose, to not bail out Ninja on very beginning if file does not exist as file may appear later on during build. But it does NOT stop Ninja to properly relaunch custom command if the file gets modified. So I guess we may point to the wrong direction. Simple example: -- test.txt 1 2 3 test -- CMakeLists.txt cmake_minimum_required(VERSION 2.6) project(DependTest C) add_custom_command( OUTPUT test-out.txt COMMAND cp test.txt test-out.txt DEPENDS test.txt) add_custom_target(depend-test ALL cat test-out.txt DEPENDS test-out.txt) (1) first run $ ninja -v [1/2] cd /tmp/depend && cp test.txt test-out.txt [2/2] cd /tmp/depend && cat test-out.txt 1 2 3 test (2) 2nd run $ ninja -v [1/1] cd /tmp/depend && cat test-out.txt 1 2 3 test (3) touching test.txt $ touch test.txt $ ninja -v [1/2] cd /tmp/depend && cp test.txt test-out.txt [2/2] cd /tmp/depend && cat test-out.txt 1 2 3 test So with proper test case and detailed reports, something more than vague "latest CMake makes our project not to compile anymore" I am unable to help, but I am willing to help. So please either provide test case, or some info how to run this problematic build (I have access to OSX, Linux or Windows system), or find me on #cmake IRC channel under "OnO". --Adam From brad.king at kitware.com Tue Oct 7 15:58:16 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Oct 2014 15:58:16 -0400 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> Message-ID: <543445D8.1000806@kitware.com> On 10/07/2014 02:21 PM, Adam Strzelecki wrote: > So please either provide test case, or some info [snip] On 10/07/2014 03:20 PM, Adam Strzelecki wrote: > I had a talk with Amine, and the problem was that due 7243c951 > their build.ninja was getting numerous extra phony entries that > were leading Ninja to crash! So yes we could point our fingers > on Ninja and close the case, but I propose we do something > better: For reference, that commit was: Ninja: Don't limit custom cmd side-effects to build folder (#14972) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7243c951 So now a large number of phony rules for files in the source tree appear that did not before. The case in question uses custom command dependencies so is not helped by the parent change: Ninja: Consider only custom commands deps as side-effects (#14972) http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a33cf6d0 > I kindly ask to make possible side-effects phony rules as > deprecated by some new policy. Basically long story short all > these "side-effects" tricks were to make some old projects > don't explicitly specifying custom command outputs work with > Ninja that stat files once at start, so if there is a > side-effect file that isn't explicitly specified as command > output it will be NOT restat, that will lead to some other > command having that file as dependency to fail. That situation is discussed thoroughly here: Add explicit specification of custom command side effect outputs http://www.cmake.org/Bug/view.php?id=14963 and here: https://github.com/martine/ninja/issues/760#issuecomment-46540858 Ideally both CMake and Ninja will fix their pieces of the problem. Fixing the Ninja side as I propose in the above-linked comment would solve the problem outright with no further changes. The fix on the CMake side will also require projects to be updated to use the new feature, but will help generate more efficient Ninja build rules. > Since Make does restat dependencies on each rule this won't > happen with Make. So we put "side-effects" in phony ensuring > Ninja to pickup the rules even the file didn't exist when Ninja > was started. No. For build systems besides Ninja the side effects cannot be listed as outputs of custom commands. Their timestamps are not always updated when the custom command runs, so the rules may be left in an always-rerun state because the side-effect "outputs" will never be newer than inputs. Since CMake was designed for such build systems before Ninja existed, there is no interface to specify the side-effects explicitly. > My original intention was actually to limit these phony rules > and it was done by: > > (1) a33cf6d0 (Ninja: Consider only custom commands deps as > side-effects (#14972)) > > However somewhere during discussion with Brad I raised question > why such side-effect are to be in build folder in fact they can > be anywhere and it we want to ensure Ninja build won't fail > when Make build goes well we need introduced: > > (2) 7243c951 (Ninja: Don't limit custom cmd side-effects to > build folder (#14972)) > > This unfortunately lead Ninja to crash with many extra > side-effect phony rules in ReactOS case. > > So again I propose we make side-effect as policy enabled only > for projects <3.1. That is not possible because CMake currently does not have enough information to produce valid Ninja files without the phony rules. The proper fix to address issue 14963 and provide projects with an interface to specify custom command side-effects explicitly. Then dependencies can be hooked up correctly for Ninja. I invite you to propose an interface to achieve this. This will not be done before the freeze for 3.1 on Thursday. Reverting 7243c951 will resolve the problem for ReactOS in out-of-source builds. So, we either revert that or hope Ninja can be fixed to deal with the large dependency lists w/out crashing. -Brad From ono at java.pl Tue Oct 7 16:53:26 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 7 Oct 2014 22:53:26 +0200 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <543445D8.1000806@kitware.com> References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> <543445D8.1000806@kitware.com> Message-ID: <067CB9F0-D22A-4595-BD45-23A70F162C20@java.pl> > This will not be done before the freeze for 3.1 on Thursday. > Reverting 7243c951 will resolve the problem for ReactOS in > out-of-source builds. So, we either revert that or hope Ninja can > be fixed to deal with the large dependency lists w/out crashing. In meantime I've pushed stage/cmp0055-disable-ninja-side-effects that make CMake warn about this compatibility layer when such phony rules are about to be emitted. Setting policy to NEW or making all deps to be explicit outputs disables warning, setting to OLD removed warning keeping phony rules. IHMO this is win-win for everybody, since it will emit warnings once someone installs 3.1 and possibly relies on side-effect. One thing I am not sure about is if the CMP0055.rst provided is clear enough for the reader. --Adam From irwin at beluga.phys.uvic.ca Tue Oct 7 16:59:00 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 7 Oct 2014 13:59:00 -0700 (PDT) Subject: [cmake-developers] "Contract" testing of CMake Message-ID: Hi Bill: In a recent thread on list you brought up the topic of "contract" testing where apparently the idea is CMake is tested by building some git version of CMake than building some fixed version of another project against that version to make sure no regression in CMake behaviour has crept in. I would like to help CMake (and protect PLplot against potential future CMake regressions) by doing informal "contract" PLplot build tests by hand for some fixed version of PLplot to to start with. Which CMake branch would you recommend for this general purpose? Should I be following the tip of maint, master, next, or release with such tests? Of course, once I got such a contract test to work by hand, I would probably want to move to a formal automated procedure so your advice on that would be appreciated as well. 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 eike at sf-mail.de Tue Oct 7 17:18:14 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 07 Oct 2014 23:18:14 +0200 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <54342B0D.6030809@kitware.com> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <1936223.oZsl9n5N2H@eto> <54342B0D.6030809@kitware.com> Message-ID: <4891641.1y26fJf6Lr@caliban.sf-tec.de> Am Dienstag, 7. Oktober 2014, 14:03:57 schrieb Brad King: > On 10/06/2014 04:04 PM, Rolf Eike Beer wrote: > > Topic FPHSA_exact_version pushed to next. > > Thanks. The impl looks okay to me. Please look at extending > the FindPackageTest with a case to cover this. It already has > at least one case for FPHSA. Alternatively you could add cases > to RunCMake.find_package if that proves easier. I extended RunCMake.FPHSA ;) And found an unrelated bug along the way. Once this is settled I would like to change the run_cmake implementation to allow for an explicitely named include. It hurts me to drop many identical test files in the directories for no good reason. But for that I wait until the dust has settled. FPHSA also has some needless variable expansion that I would like to get rid of, too. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From irwin at beluga.phys.uvic.ca Tue Oct 7 18:46:51 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 7 Oct 2014 15:46:51 -0700 (PDT) Subject: [cmake-developers] Any ideas for accessing the Dart source code? Message-ID: I thought it would be interesting to install my own local dart server to learn how to use CTest as a dart client. However, the dart server software development effort seems to have a largely broken web presence. For example, http://www.cmake.org/dart/HTML/Install.shtml points to a Dart.pdf documentation file that is a broken link. The Dart Wiki at which is recommended by the above cmake.org site is still up and running, but it also refers to that same broken link for Dart.pdf. From the Wiki the latest Dart release seems to be 1.0.9 (from 7 (!) years ago). I discovered that release does include the Dart.pdf file which is good, but only includes jar files and not source code which is bad. For example, I am concerned those 7-year old *.class files in the jar files might not run properly with modern java. Therefore, I would like to build those jar files from source. According to the above wiki you can get access to the source code using svn co http://svn.na-mic.org/svn/Dart/trunk but that command immediately returns svn: OPTIONS of 'http://svn.na-mic.org/svn/Dart/trunk': 200 OK In contrast, Dart.pdf states that source code is available using svn checkout http://svn.na-mic.org:8000/svn/Dart However, that command times out with "cannot connect to server". Does anyone here know how to access the Dart source or is that gone forever? 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 DLRdave at aol.com Tue Oct 7 19:06:32 2014 From: DLRdave at aol.com (David Cole) Date: Tue, 7 Oct 2014 19:06:32 -0400 Subject: [cmake-developers] Any ideas for accessing the Dart source code? In-Reply-To: References: Message-ID: Consider using CDash instead. It was Dart's "drop-in" replacement... and is actively maintained today. www.cdash.org On Tue, Oct 7, 2014 at 6:46 PM, Alan W. Irwin wrote: > I thought it would be interesting to install my own local dart server > to learn how to use CTest as a dart client. However, the dart server > software development effort seems to have a largely broken web > presence. For example, http://www.cmake.org/dart/HTML/Install.shtml > points to a Dart.pdf documentation file that is a broken link. The > Dart Wiki at which is > recommended by the above cmake.org site is still up and running, but > it also refers to that same broken link for Dart.pdf. From the Wiki > the latest Dart release seems to be 1.0.9 (from 7 (!) years ago). I > discovered that release does include the Dart.pdf file which is good, > but only includes jar files and not source code which is bad. For > example, I am concerned those 7-year old *.class files in the jar > files might not run properly with modern java. > > Therefore, I would like to build those jar files from source. According > to the above wiki you can get access to the source code using > > svn co http://svn.na-mic.org/svn/Dart/trunk > > but that command immediately returns > svn: OPTIONS of 'http://svn.na-mic.org/svn/Dart/trunk': 200 OK > > In contrast, Dart.pdf states that source code is available using > > svn checkout http://svn.na-mic.org:8000/svn/Dart > > However, that command times out with "cannot connect to server". > > Does anyone here know how to access the Dart source or is that gone > forever? > > 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 > __________________________ > -- > > 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 irwin at beluga.phys.uvic.ca Tue Oct 7 21:23:06 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 7 Oct 2014 18:23:06 -0700 (PDT) Subject: [cmake-developers] Any ideas for accessing the Dart source code? In-Reply-To: References: Message-ID: On 2014-10-07 19:06-0400 David Cole wrote: > Consider using CDash instead. It was Dart's "drop-in" replacement... > and is actively maintained today. > > www.cdash.org Thanks, Dave, for that information. In reviewing why I wasted my time looking at the moribund dart rather than cdash, dart clients are mentioned several times in the ctest-2.8.12.2 documentation (and I missed the one reference to cdash that also occurs there) so I did a google search, found and went galloping off in the wrong direction. :-( I have now looked at the documentation for ctest-3.0.2, and cdash is mentioned a lot more but then so is dart. I think that documentation should be updated to point users exclusively at cdash (possibly with a reference to the dart protocol or dart standard but definitely not the dart software which really is moribund or dart servers unless you are referring to the protocol and not the software). Furthermore, to prevent others being misled like I was by , could someone with write access to that web server either drop that page or modify that page so that it at least mentions that dart is no longer maintained and cdash is the suggested alternative? Currently http://www.cdash.org/overview/ does not mention dart at all which is probably the best approach and what the ctest documentation should do as well. 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 jackyalcine at gmail.com Tue Oct 7 21:24:32 2014 From: jackyalcine at gmail.com (=?UTF-8?Q?Jacky_Alcin=C3=A9?=) Date: Tue, 7 Oct 2014 21:24:32 -0400 Subject: [cmake-developers] Any ideas for accessing the Dart source code? In-Reply-To: References: Message-ID: On Tue, Oct 7, 2014 at 9:23 PM, Alan W. Irwin wrote: > On 2014-10-07 19:06-0400 David Cole wrote: > >> Consider using CDash instead. It was Dart's "drop-in" replacement... >> and is actively maintained today. >> >> www.cdash.org > > > Thanks, Dave, for that information. > > In reviewing why I wasted my time looking at the moribund dart rather > than cdash, dart clients are mentioned several times in the > ctest-2.8.12.2 documentation (and I missed the one reference to cdash > that also occurs there) so I did a google search, found > and went galloping off > in the wrong direction. :-( > > I have now looked at the documentation for ctest-3.0.2, and cdash is > mentioned a lot more but then so is dart. I think that documentation > should be updated to point users exclusively at cdash (possibly with a > reference to the dart protocol or dart standard but definitely not the > dart software which really is moribund or dart servers unless you are > referring to the protocol and not the software). > > Furthermore, to prevent others being misled like I was by > , could someone with > write access to that web server either drop that page or modify that > page so that it at least mentions that dart is no longer maintained > and cdash is the suggested alternative? > > Currently http://www.cdash.org/overview/ does not mention dart at all > which is probably the best approach and what the ctest documentation > should do as well. > > > 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 > __________________________ > -- > > 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 We should probably wipe those references or just update that for 3.0 -- Jacky Alcin? - http://jalcine.me From bill.hoffman at kitware.com Tue Oct 7 21:49:32 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 07 Oct 2014 21:49:32 -0400 Subject: [cmake-developers] "Contract" testing of CMake In-Reply-To: References: Message-ID: <5434982C.3000307@kitware.com> On 10/7/2014 4:59 PM, Alan W. Irwin wrote: > Of course, once I got such a contract test to work by hand, I would > probably want to move to a formal automated procedure so your advice > on that would be appreciated as well. The idea is to test next CMake against a version of the "contract" project that is known to work with the current release of CMake. We don't want development of the "contract" project to cause the test to fail. So, use a fixed version of PLplot and build it with next CMake. By using next CMake bugs will be noticed as soon as they are introduced. -Bill From nilsgladitz at gmail.com Wed Oct 8 01:00:47 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 08 Oct 2014 07:00:47 +0200 Subject: [cmake-developers] Any ideas for accessing the Dart source code? In-Reply-To: References: Message-ID: <5434C4FF.1000106@gmail.com> On 10/08/2014 12:46 AM, Alan W. Irwin wrote: > I thought it would be interesting to install my own local dart server > to learn how to use CTest as a dart client. You probably want the newer Kitware maintained replacement "CDash": http://www.cdash.org/ Additional instructions for a local installation can be found here: http://public.kitware.com/Wiki/CDash:Installation CMake's own CDash Dashboard can be seen in action here: http://open.cdash.org/index.php?project=CMake Nils From amine.khaldi at reactos.org Wed Oct 8 03:45:16 2014 From: amine.khaldi at reactos.org (Amine Khaldi) Date: Wed, 08 Oct 2014 08:45:16 +0100 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <543445D8.1000806@kitware.com> References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> <543445D8.1000806@kitware.com> Message-ID: <5434EB8C.109@reactos.org> > This will not be done before the freeze for 3.1 on Thursday. > Reverting 7243c951 will resolve the problem for ReactOS in > out-of-source builds. So, we either revert that or hope Ninja can > be fixed to deal with the large dependency lists w/out crashing. In the discussion with Adam, he mentioned (about input files) that CMake can not know that some file will always exist or not, and that it doesn't know files is generated unless someone tells that, *unfortunately some projects don't* Reverting this change makes more sense, because CMake has always been advertised as being designed for out-of-source builds, and we cannot penalize every single sane CMake user out there simply because some projects do not properly mark their generated input files (in custom commands) as GENERATED. I don't understand why is it okay for the CMake project (at least in ReactOS case) to introduce now a (very) huge list of our codebase *source files* (files that exist in our *repo* and not *generated* nor we can even *assume* they may not exist at some point, because they will *always* exist) simply to solve a problem that is, if some projects do *not* properly use CMake (GENERATED property, adding dependencies properly on commands/target that generate the said input files...etc) we need to do this to keep them working. The extra bloat of generating a very large list of phony rules on *source* files to solve a CMake misuse problem suggests that we're Doing It Wrong. If ninja didn't crash on us, we would probably never find out about this bloat, unless some of us randomly had the idea of diffing the old build log (from CMake 2.8.x) with this new one. From ruslan_baratov at yahoo.com Wed Oct 8 07:52:27 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 08 Oct 2014 15:52:27 +0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5433DBC1.5080800@kitware.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> Message-ID: <5435257B.80201@yahoo.com> On 07-Oct-14 16:25, Brad King wrote: > On 10/07/2014 02:49 AM, Ruslan Baratov wrote: >> How it will looks like in terms of CMake code? > That's what I'm asking you to think through and propose ;) > > Thanks, > -Brad > Okay :) I just not sure that I understand "to pass to some other process" goal correctly. * we just need to `unlock` file so the other instance will use it: file(UNLOCK_FILE "/path/to/shared/file") # now anybody can do the lock * we need other process to "inherit" the lock (what for?), i.e. move ownership (?): file(LOCK_FILE "/path/to/shared/file") execute_process(${CMAKE_COMMAND} --take-ownership "/path/to/shared/file" ...) # unlocked by execute_process Ruslo From brad.king at kitware.com Wed Oct 8 08:45:00 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 08:45:00 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5435257B.80201@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> Message-ID: <543531CC.7090103@kitware.com> On 10/08/2014 07:52 AM, Ruslan Baratov wrote: > Okay :) I just not sure that I understand "to pass to some other > process" goal correctly. That was just an example of why one might want to drop management of the lock by CMake without actually unlocking it. Perhaps the code is starting a daemon and passes off responsibility for the unlock side to the daemon process. > * we just need to `unlock` file so the other instance will use it: > file(UNLOCK_FILE "/path/to/shared/file") > # now anybody can do the lock Yes. We also need the locking API to return information about whether we really acquired the lock. > * we need other process to "inherit" the lock (what for?), i.e. move > ownership (?): > file(LOCK_FILE "/path/to/shared/file") > execute_process(${CMAKE_COMMAND} --take-ownership "/path/to/shared/file" > ...) > # unlocked by execute_process I think all we need there is a way to ask CMake to take over responsibility for a lock that it did not originally create. It can also be in the file() command. Thanks, -Brad From brad.king at kitware.com Wed Oct 8 09:16:03 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 09:16:03 -0400 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <067CB9F0-D22A-4595-BD45-23A70F162C20@java.pl> References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> <543445D8.1000806@kitware.com> <067CB9F0-D22A-4595-BD45-23A70F162C20@java.pl> Message-ID: <54353913.6010606@kitware.com> On 10/07/2014 04:53 PM, Adam Strzelecki wrote: > In meantime I've pushed stage/cmp0055-disable-ninja-side-effects > that make CMake warn about this compatibility layer when such > phony rules are about to be emitted. What I've been trying to say is that this is NOT about compatibility with broken projects. It is a *fundamental limitation* of the current CMake custom command specification interface (add_custom_command). If you start requiring explicit specification of side-effects as custom command outputs, you will make it *impossible* for project code to specify their build rules for cases involving side-effect outputs whose timestamps do not need to be newer than their inputs. Non-Ninja build systems do *not* support this. This issue: Add explicit specification of custom command side effect outputs http://www.cmake.org/Bug/view.php?id=14963 documents a few such cases. It explains that we need a new interface, perhaps as an option to add_custom_command, to specify side-effect outputs of rules. Another possible middle-ground workaround is to generate phony rules only for custom command dependencies that are marked with the GENERATED property. That would avoid the phony rule bloat and simply require projects to explicitly mark their generated side effects. We still won't be able to tell Ninja which rule generates them, but at least we could reduce the number of phony rules. However, there is no way this will be done for 3.1 by tomorrow, so it would be best to think about a full solution to #14963 to start development now and target the 3.2 release. -Brad From brad.king at kitware.com Wed Oct 8 09:16:05 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 09:16:05 -0400 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <5434EB8C.109@reactos.org> References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> <543445D8.1000806@kitware.com> <5434EB8C.109@reactos.org> Message-ID: <54353915.3010200@kitware.com> On 10/08/2014 03:45 AM, Amine Khaldi wrote: > Reverting this change makes more sense This is the simplest solution for the upcoming 3.1 release because it just restores behavior to what 3.0 does. I've done it here: Ninja: Limit custom command side-effects to build folder http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=de8e534b > simply to solve a problem that is, if some projects do *not* > properly use CMake (GENERATED property, adding dependencies > properly on commands/target that generate the said input > files...etc) we need to do this to keep them working. This is not about supporting projects that do it wrong. Ninja wants to know not just that a file is generated, but also *which* custom command generates it. We have no interface for specifying side-effect outputs whose timestamps do not need to be newer than the inputs. That is what this issue is about: Add explicit specification of custom command side effect outputs http://www.cmake.org/Bug/view.php?id=14963 The reason is that CMake was designed long before Ninja existed, and all the other build systems not only do not need this information, but have no place to put it even if we did have it. See also my reply to Adam's sibling message to yours. -Brad From ono at java.pl Wed Oct 8 09:55:16 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 8 Oct 2014 15:55:16 +0200 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <54353915.3010200@kitware.com> References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> <543445D8.1000806@kitware.com> <5434EB8C.109@reactos.org> <54353915.3010200@kitware.com> Message-ID: <1032790C-7E57-471E-B81C-64C14AEBD69B@java.pl> > This is the simplest solution for the upcoming 3.1 release because > it just restores behavior to what 3.0 does. I've done it here: Okay. But still I feel like this is just workaround rather than solution for the problem. > This is not about supporting projects that do it wrong. Ninja > wants to know not just that a file is generated, but also *which* > custom command generates it. We have no interface for specifying > side-effect outputs whose timestamps do not need to be newer than > the inputs. Yes, it isn't about doing anything wrong, but to make projects building fine with Make build fine with Ninja too. And you are right here, we have no means for provide proper transition to remove this implicit compatibility layer. We lack OUTPUT for add_custom_target. I can work on OUTPUT support for add_custom_target if you want? Together with new POLICY it will make sense, unless you have other opinion on that. But I guess it won't make it to 3.1? > That is what this issue is about: > Add explicit specification of custom command side effect outputs > http://www.cmake.org/Bug/view.php?id=14963 Shouldn't it be called "Add explicit specification of custom TARGET side effect outputs"? --Adam From brad.king at kitware.com Wed Oct 8 10:05:04 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 10:05:04 -0400 Subject: [cmake-developers] Any ideas for accessing the Dart source code? In-Reply-To: References: Message-ID: <54354490.9080805@kitware.com> On 10/07/2014 09:23 PM, Alan W. Irwin wrote: > I have now looked at the documentation for ctest-3.0.2, and cdash is > mentioned a lot more but then so is dart. I think that documentation > should be updated to point users exclusively at cdash Help: Replace 'Dart' with 'CDash' in ctest.1 manual http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b8aa0cdf > Furthermore, to prevent others being misled like I was by > , could someone with > write access to that web server either drop that page or modify that > page so that it at least mentions that dart is no longer maintained > and cdash is the suggested alternative? I will look at that, thanks. -Brad From brad.king at kitware.com Wed Oct 8 10:26:44 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 10:26:44 -0400 Subject: [cmake-developers] explicit custom command side-effects (was: Severe regression caused by #14972 fixes) In-Reply-To: <1032790C-7E57-471E-B81C-64C14AEBD69B@java.pl> References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> <543445D8.1000806@kitware.com> <5434EB8C.109@reactos.org> <54353915.3010200@kitware.com> <1032790C-7E57-471E-B81C-64C14AEBD69B@java.pl> Message-ID: <543549A4.8070508@kitware.com> On 10/08/2014 09:55 AM, Adam Strzelecki wrote: > We lack OUTPUT for add_custom_target. > > I can work on OUTPUT support for add_custom_target if you want? This is not just about add_custom_target, and it is not about OUTPUT. Custom targets have no explicit output by design, but they can have DEPENDS on custom commands that have outputs. Both add_custom_target and add_custom_command can run operations that produce side-effects. Both commands need a way to specify any side effects they produce. Perhaps a new option like "GENERATES" can be added for this. For example: add_custom_target(Provider COMMAND some-generator -o side-effect GENERATES side-effect ) or: add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/generator-stamp.txt COMMAND some-generator -o side-effect COMMAND ${CMAKE_COMMAND} -E touch generator-stamp.txt DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/generator-input.txt GENERATES side-effect ) The GENERATES value(s) would be marked with the GENERATED property. For Ninja we would add extra outputs to the generated rule and ask Ninja to restat them to avoid the always-rebuild case. For other generators no additional build system content is needed. > Together with new POLICY it will make sense, unless you have other > opinion on that. We need some kind of transition plan that may or may not be a policy. Let's get the design of the new interface done first. > But I guess it won't make it to 3.1? Absolutely not for 3.1. The feature freeze for it is upon us NOW and we haven't even started the design for the new behavior yet. We have plenty of time before 3.2 though to get it right. -Brad From brad.king at kitware.com Wed Oct 8 10:54:12 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 10:54:12 -0400 Subject: [cmake-developers] FindThreads_overhaul topic In-Reply-To: <1560898.ZRjqAlt5LQ@caliban.sf-tec.de> References: <5433FA2C.9070809@kitware.com> <1560898.ZRjqAlt5LQ@caliban.sf-tec.de> Message-ID: <54355014.3000501@kitware.com> On 10/07/2014 12:18 PM, Rolf Eike Beer wrote: >>> + add_library(CMake::Threads INTERFACE IMPORTED GLOBAL) >> > Both issues should be fixed now. Thanks. Your use of an interface target for this is a clever way of abstracting the differences between libraries and flags. Nice. I'd rather reserve the CMake:: imported target namespace for future use. The convention in other Find modules is to prefix the imported targets with the name of the package. In this case we have no good name for the library within the namespace. Here is a brainstorming list of possible names: Threads::Threads Threads::Interface # my favorite Threads::Native Threads::System Please pick one of these or propose your own and update the topic. Thanks, -Brad From clinton at elemtech.com Wed Oct 8 11:05:03 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Wed, 8 Oct 2014 09:05:03 -0600 (MDT) Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> References: <542ACE37.1040302@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> <5432AE91.1010708@kitware.com> <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> Message-ID: <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> ----- Original Message ----- > > ----- Original Message ----- > > On 10/06/2014 10:36 AM, Adam Strzelecki wrote: > > >> Sure, I think it would be good to require 10.6. > > > > > > Moreover I believe nobody nowadays builds for 10.5 on 10.5. > > > > Perhaps no one has to build that way for deployment but there could > > still be people just building for their own host as the only computer > > they have. The fact that our dashboard reported this problem means > > we are testing that case. > > > > Clinton, I don't have a 10.5 machine anymore and the test is failing > > on yours. Please take whatever action you feel is appropriate to > > resolve the test failure on that machine. This could mean either > > disabling rpath altogether on 10.5 or changing the new hunk: > > > > > + foreach(rpath ${${ikey}_RPATHS}) > > > + set(changes ${changes} -delete_rpath "${rpath}") > > > + endforeach() > > > > to warn and skip removal when hosted on 10.5. Or another option you > > find. > > > > This needs to be resolved in the next day or two or the topic won't > > be in CMake 3.1. > > > > Thanks, > > -Brad > > > > > > I don't have a 10.5 machine, but I've put in a commit which I hope solves the > problem. > 36c509b9 OSX: Only enable @rpath support on OS X 10.6 or greater. > I pushed more fixes for this. Instead of requiring 10.6, I took the other path of warning when rpaths need changed at install time and skip it. This should also fix the CMP0042 test which started failing. By the way, Brad, your change to require 10.6 for the BundleUtilities test is no longer required on the rpath-osx-10_6 topic. However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5 topic. Clint From brad.king at kitware.com Wed Oct 8 11:17:03 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 11:17:03 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> References: <542ACE37.1040302@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> <5432AE91.1010708@kitware.com> <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> Message-ID: <5435556F.9070303@kitware.com> On 10/08/2014 11:05 AM, clinton at elemtech.com wrote: > I pushed more fixes for this. Instead of requiring 10.6, > I took the other path of warning when rpaths need changed > at install time and skip it. > This should also fix the CMP0042 test which started failing. Thanks. The message is currently: > + msg << "WARNING: Target \"" << this->Target->GetName() > + << "\" has runtime paths which cannot be changed during install. " > + << "To change runtime paths, OS X version 10.6 or newer is required. " > + << "Therefore, runtime paths will not be changed when installing."; > + cmSystemTools::Message(msg.str().c_str(), "Warning"); Can that be changed to an IssueMessage, possibly on a cmMakefile for at least a little context? Also it should suggest using CMAKE_BUILD_WITH_INSTALL_RPATH. > By the way, Brad, your change to require 10.6 for the > BundleUtilities test is no longer required on the rpath-osx-10_6 topic. > I thought it was a missing piece of your original change. Since you've reverted that I've now reverted mine so we'll see how testing goes. > However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5 topic. I rebased rpath-osx-10_6 on fix-OSX-bundle-rpaths-and-Qt5 to make local testing of both together easier. Please base the above-requested fixes on: OSX: Warn when attempting to change runtime paths on OS X 10.5 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6e58f55 Thanks, -Brad From eike at sf-mail.de Wed Oct 8 11:37:40 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 08 Oct 2014 17:37:40 +0200 Subject: [cmake-developers] FindThreads_overhaul topic In-Reply-To: <54355014.3000501@kitware.com> References: <5433FA2C.9070809@kitware.com> <1560898.ZRjqAlt5LQ@caliban.sf-tec.de> <54355014.3000501@kitware.com> Message-ID: <3327542.MMlHKRjttH@caliban.sf-tec.de> Am Mittwoch, 8. Oktober 2014, 10:54:12 schrieb Brad King: > On 10/07/2014 12:18 PM, Rolf Eike Beer wrote: > >>> + add_library(CMake::Threads INTERFACE IMPORTED GLOBAL) > > > > Both issues should be fixed now. > > Thanks. Your use of an interface target for this is a clever way > of abstracting the differences between libraries and flags. Nice. All credits go to Timo Rothenpieler, I just refactored his changes and pushed this upstream. > I'd rather reserve the CMake:: imported target namespace for future > use. The convention in other Find modules is to prefix the imported > targets with the name of the package. In this case we have no good > name for the library within the namespace. Here is a brainstorming > list of possible names: > > Threads::Threads > Threads::Interface # my favorite > Threads::Native > Threads::System > > Please pick one of these or propose your own and update the topic. I'm not sure about Threads::Interface, it sounds so "generic" or "abstract" to me, but this target offers no abstraction of the thread API. All others have different up- and downsides, so I think I'll stay with Threads::Threads, that is the one that probably results in the least blame for a badly chosen name. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Wed Oct 8 11:44:28 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 11:44:28 -0400 Subject: [cmake-developers] FindThreads_overhaul topic In-Reply-To: <3327542.MMlHKRjttH@caliban.sf-tec.de> References: <5433FA2C.9070809@kitware.com> <1560898.ZRjqAlt5LQ@caliban.sf-tec.de> <54355014.3000501@kitware.com> <3327542.MMlHKRjttH@caliban.sf-tec.de> Message-ID: <54355BDC.3050705@kitware.com> On 10/08/2014 11:37 AM, Rolf Eike Beer wrote: > All credits go to Timo Rothenpieler Okay. Please add a "Co-Author: " or "Inspired-by: " footer line to give this credit. > I'm not sure about Threads::Interface, it sounds so "generic" or "abstract" to > me, but this target offers no abstraction of the thread API. All others have > different up- and downsides, so I think I'll stay with Threads::Threads, that > is the one that probably results in the least blame for a badly chosen name. On second thought I agree Threads::Interface is too generic. It exposes an implementation detail in the name. I agree Threads::Threads is the best or now. I suspect other packages will encounter a similar double-name later. Thanks, -Brad From eike at sf-mail.de Wed Oct 8 11:48:13 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 08 Oct 2014 17:48:13 +0200 Subject: [cmake-developers] FindThreads_overhaul topic In-Reply-To: <54355BDC.3050705@kitware.com> References: <5433FA2C.9070809@kitware.com> <3327542.MMlHKRjttH@caliban.sf-tec.de> <54355BDC.3050705@kitware.com> Message-ID: <1443494.yLndqPJEr5@caliban.sf-tec.de> Am Mittwoch, 8. Oktober 2014, 11:44:28 schrieb Brad King: > On 10/08/2014 11:37 AM, Rolf Eike Beer wrote: > > All credits go to Timo Rothenpieler > > Okay. Please add a "Co-Author: " or "Inspired-by: " footer line to give > this credit. He is recorded as author of that change. Only the first and last of the 3 commits in that branch are authored by me, and recorded that way. > > I'm not sure about Threads::Interface, it sounds so "generic" or > > "abstract" to me, but this target offers no abstraction of the thread > > API. All others have different up- and downsides, so I think I'll stay > > with Threads::Threads, that is the one that probably results in the least > > blame for a badly chosen name. > On second thought I agree Threads::Interface is too generic. It exposes > an implementation detail in the name. I agree Threads::Threads is the > best or now. I suspect other packages will encounter a similar double-name > later. Will push an update soonish. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From clinton at elemtech.com Wed Oct 8 12:17:57 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Wed, 08 Oct 2014 10:17:57 -0600 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <5435556F.9070303@kitware.com> References: <542ACE37.1040302@kitware.com> <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> <5435556F.9070303@kitware.com> Message-ID: <6523826.ocfdZJFGtQ@stryke> On Wednesday, October 08, 2014 11:17:03 AM Brad King wrote: > On 10/08/2014 11:05 AM, clinton at elemtech.com wrote: > > I pushed more fixes for this. Instead of requiring 10.6, > > I took the other path of warning when rpaths need changed > > at install time and skip it. > > This should also fix the CMP0042 test which started failing. > > Thanks. The message is currently: > > + msg << "WARNING: Target \"" << this->Target->GetName() > > + << "\" has runtime paths which cannot be changed during install. > > " + << "To change runtime paths, OS X version 10.6 or newer is > > required. " + << "Therefore, runtime paths will not be changed > > when installing."; + cmSystemTools::Message(msg.str().c_str(), > > "Warning"); > > Can that be changed to an IssueMessage, possibly on a cmMakefile > for at least a little context? Also it should suggest using > CMAKE_BUILD_WITH_INSTALL_RPATH. Fixed. > > > By the way, Brad, your change to require 10.6 for the > > BundleUtilities test is no longer required on the rpath-osx-10_6 topic. > > I thought it was a missing piece of your original change. > Since you've reverted that I've now reverted mine so we'll > see how testing goes. Yeah. I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle- rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with @rpath on OS X 10.5. Perhaps it'll recognize there is no need to change rpaths. Clint From irwin at beluga.phys.uvic.ca Wed Oct 8 13:34:17 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 8 Oct 2014 10:34:17 -0700 (PDT) Subject: [cmake-developers] Any ideas for accessing the Dart source code? In-Reply-To: <54354490.9080805@kitware.com> References: <54354490.9080805@kitware.com> Message-ID: On 2014-10-08 10:05-0400 Brad King wrote: > On 10/07/2014 09:23 PM, Alan W. Irwin wrote: >> I have now looked at the documentation for ctest-3.0.2, and cdash is >> mentioned a lot more but then so is dart. I think that documentation >> should be updated to point users exclusively at cdash > > Help: Replace 'Dart' with 'CDash' in ctest.1 manual > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b8aa0cdf Thanks. That is a step in the right direction, but there are more mentions of dart then you have dealt with so far. See the results from ctest --help-full (at least for version 3.0.2). > >> Furthermore, to prevent others being misled like I was by >> , could someone with >> write access to that web server either drop that page or modify that >> page so that it at least mentions that dart is no longer maintained >> and cdash is the suggested alternative? > > I will look at that, thanks. > > -Brad > __________________________ 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 Oct 8 13:43:53 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 13:43:53 -0400 Subject: [cmake-developers] Any ideas for accessing the Dart source code? In-Reply-To: References: <54354490.9080805@kitware.com> Message-ID: <543577D9.6020300@kitware.com> On 10/08/2014 01:34 PM, Alan W. Irwin wrote: > Thanks. That is a step in the right direction, but there are more mentions of > dart then you have dealt with so far. See the results from > > ctest --help-full > > (at least for version 3.0.2). According to: $ git grep -i dart -- Help Modules the remaining mentions of "Dart" are in: * The FindDart module which we have to keep for compatibility. It is only linked from the list of available modules. * The Dart module which we have to keep for compatibility, and whose documentation says so and refers to the CTest module. * Discussion of the DartConfiguration.tcl configuration file, which is actually for configuring CTest (it's historical). There is no text left that suggests using "Dart" for anything in the ctest(1) manual. -Brad From ydginster at gmail.com Wed Oct 8 13:48:29 2014 From: ydginster at gmail.com (Evgeny Kalishenko) Date: Wed, 8 Oct 2014 21:48:29 +0400 Subject: [cmake-developers] [PATCH] Preinstall requirements support for CPack RPM generator Message-ID: I was interested in feature request http://public.kitware.com/Bug/view.php?id=14769 and made a simple patch for CPack RPM generator (attached). -- Regards, Evgeny Kalishenko -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pre_post_rpm_install.patch Type: text/x-patch Size: 3047 bytes Desc: not available URL: From paul at mad-scientist.net Wed Oct 8 14:36:01 2014 From: paul at mad-scientist.net (Paul Smith) Date: Wed, 08 Oct 2014 14:36:01 -0400 Subject: [cmake-developers] [CMake] Forcing colorization of output from cmake In-Reply-To: <54356C78.7060501@kitware.com> References: <1367417913.4101.127.camel@pdsdesk> <1412784946.29340.123.camel@mad-scientist.net> <54356C78.7060501@kitware.com> Message-ID: <1412793361.29340.127.camel@mad-scientist.net> On Wed, 2014-10-08 at 12:55 -0400, Brad King wrote: > On 10/08/2014 12:15 PM, Paul Smith wrote: > > Maybe we could add another valid value to --switch, like --switch=FORCE > > which would always colorize. > [snip] > > The best option seems to be to add another flag to the "color" bitflag > > variable that forces colorization always. > > Yes, I think both of the above make sense. If you want to work on > it please read CONTRIBUTING.rst from the top of our source tree > in Git ( http://cmake.org/cmake.git ) and come to the developers > list with a proposal: Hi all. Attached please find a proposed patch for the above. I still think there's some slightly awkward redundancy between AssumeTTY and the new ForceTTY, but I'm not sure these can actually be combined into one flag... certainly not without reworking more of how AssumeTTY is interpreted and used than I felt confident with. I didn't try to allow "FORCE" to be case-insensitive. It wouldn't be hard, but I wasn't sure if it was worth it. You must capitalize it as the code is written today. I found precedent for both options. Also, the check for MAKE_TERMOUT might not be something you want to keep... there's not a lot of precedent in the code, that I found, for looking at other utilities' environment variables. On the other hand it's darn handy to have this "just work" without having to export COLOR='$(if $(MAKE_TERMOUT),FORCE)' in your ~/.bashrc or whatever. There's no "GNU Makefiles" generator, and I couldn't come up with a good way to implement this in the generic Unix Makefiles generator. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-cmake-Allow-forced-color-output.patch Type: text/x-patch Size: 7424 bytes Desc: not available URL: From robert.maynard at kitware.com Wed Oct 8 14:50:03 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 8 Oct 2014 14:50:03 -0400 Subject: [cmake-developers] FindThreads_overhaul topic In-Reply-To: <1443494.yLndqPJEr5@caliban.sf-tec.de> References: <5433FA2C.9070809@kitware.com> <3327542.MMlHKRjttH@caliban.sf-tec.de> <54355BDC.3050705@kitware.com> <1443494.yLndqPJEr5@caliban.sf-tec.de> Message-ID: As an aside have we formally documented that we are reserving the CMake namespace on imported targets anywhere? On Wed, Oct 8, 2014 at 11:48 AM, Rolf Eike Beer wrote: > Am Mittwoch, 8. Oktober 2014, 11:44:28 schrieb Brad King: >> On 10/08/2014 11:37 AM, Rolf Eike Beer wrote: >> > All credits go to Timo Rothenpieler >> >> Okay. Please add a "Co-Author: " or "Inspired-by: " footer line to give >> this credit. > > He is recorded as author of that change. Only the first and last of the 3 > commits in that branch are authored by me, and recorded that way. > >> > I'm not sure about Threads::Interface, it sounds so "generic" or >> > "abstract" to me, but this target offers no abstraction of the thread >> > API. All others have different up- and downsides, so I think I'll stay >> > with Threads::Threads, that is the one that probably results in the least >> > blame for a badly chosen name. >> On second thought I agree Threads::Interface is too generic. It exposes >> an implementation detail in the name. I agree Threads::Threads is the >> best or now. I suspect other packages will encounter a similar double-name >> later. > > Will push an update soonish. > -- > > 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 konstantin at podsvirov.pro Thu Oct 9 01:55:14 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 09 Oct 2014 09:55:14 +0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <5433FC0B.4060802@kitware.com> References: <542E964C.1050104@kitware.com> <5433FC0B.4060802@kitware.com> Message-ID: <1545841412834114@web8j.yandex.ru> Hello people! 07.10.2014, 18:43, "Brad King" : > In order to get the dashboard cleaned up for final merges to > 'master' before the release, please refrain from merging any > changes other than dashboard fixes and documentation updates > to 'next'. > > Thanks, > -Brad CMake 3.0.20141008-ge5734 Documentation with the latest updates: Sphinx http://ifw.podsvirov.pro/cmake/doc/sphinx Doxygen http://ifw.podsvirov.pro/cmake/doc/doxygen Can also upgrade the components in your online installers :-) All a good day! Regards, Konstantin Podsvirov From mantis at public.kitware.com Thu Oct 9 05:11:10 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 9 Oct 2014 05:11:10 -0400 Subject: [cmake-developers] [CMake 0015199]: Better error message for export conflicts Message-ID: <705497265c31cce384ae0b2e8cfc60e0@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15199 ====================================================================== Reported By: Nico Schl?mer Assigned To: ====================================================================== Project: CMake Issue ID: 15199 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-09 05:11 EDT Last Modified: 2014-10-09 05:11 EDT ====================================================================== Summary: Better error message for export conflicts Description: If an export target depends on another target, that other target must either be * in the same export set, or * in exactly one other export set. If it is not in the same export set and in more than one other export set, CMake reports ``` CMake Error: install(EXPORT "A" ...) includes target "b" which requires target "c" that is not in this export set, but 5 times in others. ``` This error message is somewhat misleading; one could think that "c" must be in the same export set as "b". Perhaps a less ambiguous wording would be: ``` CMake Error: install(EXPORT "A" ...) includes target "b" which requires target "c" that is * not in this export set, and * in more than one other export set (5). ``` I'm sure we can do even better than that. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-09 05:11 Nico Schl?mer New Issue ====================================================================== From mantis at public.kitware.com Thu Oct 9 08:24:58 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 9 Oct 2014 08:24:58 -0400 Subject: [cmake-developers] [CMake 0015200]: Odd quoting issue when mixing single, double and escaped quotes to COMMAND Message-ID: <502dede04c486d1bc548657f61f36be2@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15200 ====================================================================== Reported By: Ray Donnelly Assigned To: ====================================================================== Project: CMake Issue ID: 15200 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-09 08:24 EDT Last Modified: 2014-10-09 08:24 EDT ====================================================================== Summary: Odd quoting issue when mixing single, double and escaped quotes to COMMAND Description: Using the following CMakeList.txt: add_executable (blender blender.c) set(TARGETDIR_VER "C:/Program Files (x86)/Blender/share/blender/2.72") add_custom_command( TARGET blender POST_BUILD MAIN_DEPENDENCY blender COMMAND ${CMAKE_COMMAND} -E echo 'now run: \"make install\" to copy runtime files and scripts to ${TARGETDIR_VER}' ) Using any old blender.c (hello world will do) And either "MSYS Makefiles" or "MinGW Makefiles" generators (actually I suspect any Makefile generator at all), we get badly quoted strings in CMakeFiles/blender.dir/build.make: /C/cmake-3.0.2-win32-x86/bin/cmake.exe -E echo 'now run: "make install" to copy runtime files and scripts to "C:/Program Files (x86)/Blender/share/blender/2.72'" It seems that the final ' and " have been swapped, which causes: /bin/sh: -c: line 0: unexpected EOF while looking for matching `"' Steps to Reproduce: unzip quote-problem.7z, and from the MSYS2 shell enter: /c/cmake-3.0.2-win32-x86/bin/cmake.exe -G'MSYS Makefiles' make and observe the error message above. Additional Information: This happens on the officially release 3.0.2 Windows binary and also on MSYS2's cmake. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-09 08:24 Ray Donnelly New Issue 2014-10-09 08:24 Ray Donnelly File Added: quote-problem.7z ====================================================================== From brad.king at kitware.com Thu Oct 9 09:24:10 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Oct 2014 09:24:10 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <6523826.ocfdZJFGtQ@stryke> References: <542ACE37.1040302@kitware.com> <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> <5435556F.9070303@kitware.com> <6523826.ocfdZJFGtQ@stryke> Message-ID: <54368C7A.8060007@kitware.com> Adam, On 10/08/2014 12:17 PM, Clinton Stimpson wrote: > Yeah. I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle- > rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with > @rpath on OS X 10.5. Perhaps it'll recognize there is no need to change > rpaths. The BundleUtilities test still fails on OS X 10.5: http://open.cdash.org/testDetails.php?test=285651145&build=3522021 -- 6/10: fixing up '/.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1' install_name_tool: more than one input file specified (/.../Tests/BundleUtilities/testdir1 and -delete_rpath) Usage: install_name_tool [-change old new] ... [-id name] input Clinton's changes in his rpath-osx-10_6 extension topic to yours teach other uses of -delete_rpath to warn on OS X 10.5 and skip deletion. I think something similar will be needed here. Please investigate. Meanwhile, on my local OS X 10.9 machine I added this patch: diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index eedab44..80e5d3b 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -755,6 +755,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) # if(changes) execute_process(COMMAND install_name_tool ${changes} "${resolved_embedded_item}") + message(STATUS "CHANGE install_name_tool ${changes} \"${resolved_embedded_item}\"") endif() endfunction() >From the test output I can see that it is trying to delete several rpath entries that do not exist and therefore do not need deletion. How is the list chosen for each binary? -Brad From clinton at elemtech.com Thu Oct 9 09:43:08 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Thu, 9 Oct 2014 07:43:08 -0600 (MDT) Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <5435556F.9070303@kitware.com> References: <542ACE37.1040302@kitware.com> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> <5432AE91.1010708@kitware.com> <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> <5435556F.9070303@kitware.com> Message-ID: <888522664.277920.1412862188537.JavaMail.zimbra@elemtech.com> ----- Original Message ----- > On 10/08/2014 11:05 AM, clinton at elemtech.com wrote: > > I pushed more fixes for this. Instead of requiring 10.6, > > I took the other path of warning when rpaths need changed > > at install time and skip it. > > This should also fix the CMP0042 test which started failing. > > Thanks. The message is currently: > > > + msg << "WARNING: Target \"" << this->Target->GetName() > > + << "\" has runtime paths which cannot be changed during install. > > " > > + << "To change runtime paths, OS X version 10.6 or newer is > > required. " > > + << "Therefore, runtime paths will not be changed when > > installing."; > > + cmSystemTools::Message(msg.str().c_str(), "Warning"); > > Can that be changed to an IssueMessage, possibly on a cmMakefile > for at least a little context? Also it should suggest using > CMAKE_BUILD_WITH_INSTALL_RPATH. > > > By the way, Brad, your change to require 10.6 for the > > BundleUtilities test is no longer required on the rpath-osx-10_6 topic. > > > > I thought it was a missing piece of your original change. > Since you've reverted that I've now reverted mine so we'll > see how testing goes. > > > However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5 > > topic. > > I rebased rpath-osx-10_6 on fix-OSX-bundle-rpaths-and-Qt5 to > make local testing of both together easier. Please base the > above-requested fixes on: > > OSX: Warn when attempting to change runtime paths on OS X 10.5 > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6e58f55 > Adam, I was looking at the BundleUtilities failure after the above fixes, and I noticed it unconditionally removes rpaths. Is there a reason for that? If the user does set_target_properties(testbundleutils1 module1 PROPERTIES INSTALL_RPATH "${CMAKE_CURRENT_BINARY_DIR}/testdir1" BUILD_WITH_INSTALL_RPATH 1) The new BundleUtilities.cmake will strip that rpath. The attempt to strip those rpaths fails on OS X 10.5, because install_name_tool does not recognize the -delete_rpath. The test fails because the -id and -change portion of the install_name_tool command is prevented by the error from the use of -delete_rpath. Perhaps we can separate the -delete_rpath part into its own call to install_name_tool. If it fails, the failure can be ignored (as it previously ignored install_name_tool failures). Or maybe there is another idea. Clint From brad.king at kitware.com Thu Oct 9 09:55:46 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Oct 2014 09:55:46 -0400 Subject: [cmake-developers] [CMake] Forcing colorization of output from cmake In-Reply-To: <1412793361.29340.127.camel@mad-scientist.net> References: <1367417913.4101.127.camel@pdsdesk> <1412784946.29340.123.camel@mad-scientist.net> <54356C78.7060501@kitware.com> <1412793361.29340.127.camel@mad-scientist.net> Message-ID: <543693E2.5090901@kitware.com> On 10/08/2014 02:36 PM, Paul Smith wrote: > Hi all. Attached please find a proposed patch for the above. I still > think there's some slightly awkward redundancy between AssumeTTY and the > new ForceTTY, but I'm not sure these can actually be combined into one > flag... certainly not without reworking more of how AssumeTTY is > interpreted and used than I felt confident with. In this hunk: > @@ -68,14 +68,16 @@ void kwsysTerminal_cfprintf(int color, FILE* stream, const char* format, ...) > #if defined(KWSYS_TERMINAL_SUPPORT_CONSOLE) > CONSOLE_SCREEN_BUFFER_INFO hOutInfo; > HANDLE hOut = kwsysTerminalGetStreamHandle(stream); > - if(GetConsoleScreenBufferInfo(hOut, &hOutInfo)) > + if(color & kwsysTerminal_Color_ForceTTY || > + GetConsoleScreenBufferInfo(hOut, &hOutInfo)) > { > pipeIsConsole = 1; > kwsysTerminalSetConsoleColor(hOut, &hOutInfo, stream, color); > } we cannot enter the if() block unless GetConsoleScreenBufferInfo returns true because otherwise the hOutInfo will not be initialized correctly. In the Windows console code path we really need a handle to the console from the stream or it cannot work. Also, once the pipeIsConsole value is true, the kwsysTerminalSetVT100Color code path should not be used, so we do not want to force the second code path either. Instead ForceTTY should just influence the return value of kwsysTerminalStreamIsVT100. The Source/kwsys part of the change actually belongs in a separate KWSys upstream first. I've added a modified version of your change for upstream review and testing here: http://review.source.kitware.com/17578 Please try out that version with the rest of your changes. > it's darn handy to have this "just work" without having to export > COLOR='$(if $(MAKE_TERMOUT),FORCE)' in your ~/.bashrc or whatever. > There's no "GNU Makefiles" generator, and I couldn't come up with a good > way to implement this in the generic Unix Makefiles generator. We already have a CMAKE_COLOR_MAKEFILE option. Perhaps instead of just ON or OFF values it could have a GNU value that enables this behavior. When initializing it in CMakeGenericSystem.cmake perhaps it is possible to detect if CMAKE_MAKE_PROGRAM is a GNU make tool and provide a good default. Thanks, -Brad From brad.king at kitware.com Thu Oct 9 10:03:31 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Oct 2014 10:03:31 -0400 Subject: [cmake-developers] [PATCH] Preinstall requirements support for CPack RPM generator In-Reply-To: References: Message-ID: <543695B3.5010201@kitware.com> On 10/08/2014 01:48 PM, Evgeny Kalishenko wrote: > I was interested in feature request > http://public.kitware.com/Bug/view.php?id=14769 and made a > simple patch for CPack RPM generator (attached). Thanks. In this hunk: > + # The following keywords require braces around the "pre" or "post" suffix in the final RPM spec file. > + if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE" OR "${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST") > + string(REPLACE "_" "(" _PACKAGE_HEADER_NAME "${_PACKAGE_HEADER_NAME}") > + set(_PACKAGE_HEADER_NAME "${_PACKAGE_HEADER_NAME})") > + endif() The MATCHES conditions can use simply STREQUAL instead. I'm not very familiar with the spec format, so please explain the purpose of the s/_/(/ subsitution in comments here. Thanks, -Brad From clinton at elemtech.com Thu Oct 9 10:16:16 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Thu, 9 Oct 2014 08:16:16 -0600 (MDT) Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <54368C7A.8060007@kitware.com> References: <542ACE37.1040302@kitware.com> <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> <5435556F.9070303@kitware.com> <6523826.ocfdZJFGtQ@stryke> <54368C7A.8060007@kitware.com> Message-ID: <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> ----- Original Message ----- > Adam, > > On 10/08/2014 12:17 PM, Clinton Stimpson wrote: > > Yeah. I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle- > > rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with > > @rpath on OS X 10.5. Perhaps it'll recognize there is no need to change > > rpaths. > > The BundleUtilities test still fails on OS X 10.5: > > http://open.cdash.org/testDetails.php?test=285651145&build=3522021 > -- 6/10: fixing up > '/.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1' > install_name_tool: more than one input file specified > (/.../Tests/BundleUtilities/testdir1 and -delete_rpath) > Usage: install_name_tool [-change old new] ... [-id name] input > > Clinton's changes in his rpath-osx-10_6 extension topic to yours teach > other uses of -delete_rpath to warn on OS X 10.5 and skip deletion. > I think something similar will be needed here. Please investigate. > > Meanwhile, on my local OS X 10.9 machine I added this patch: > > diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake > index eedab44..80e5d3b 100644 > --- a/Modules/BundleUtilities.cmake > +++ b/Modules/BundleUtilities.cmake > @@ -755,6 +755,7 @@ function(fixup_bundle_item resolved_embedded_item exepath > dirs) > # > if(changes) > execute_process(COMMAND install_name_tool ${changes} > "${resolved_embedded_item}") > + message(STATUS "CHANGE install_name_tool ${changes} > \"${resolved_embedded_item}\"") > endif() > endfunction() > > From the test output I can see that it is trying to delete several > rpath entries that do not exist and therefore do not need deletion. > How is the list chosen for each binary? > Brad, When I do the same message(), I don't see deletion of rpaths which do not exist. I see deletions of rpaths which do exist as defined in the CMakeLists.txt file: set_target_properties(testbundleutils1 module1 PROPERTIES INSTALL_RPATH "${CMAKE_CURRENT_BINARY_DIR}/testdir1" BUILD_WITH_INSTALL_RPATH 1) But, I'm wondering if INSTALL_RPATH should only be effective on OS X if MACOSX_RPATH is set. Currently MACOSX_RPATH determines whether a target uses @rpath for its id, which can result in rpaths for a consumer. In other words, whether a target has rpaths is determined by the use of @rpath in its dependencies. What do you think about the case of INSTALL_RPATH? Clint From brad.king at kitware.com Thu Oct 9 10:27:32 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Oct 2014 10:27:32 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> References: <542ACE37.1040302@kitware.com> <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> <5435556F.9070303@kitware.com> <6523826.ocfdZJFGtQ@stryke> <54368C7A.8060007@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> Message-ID: <54369B54.3040501@kitware.com> On 10/09/2014 10:16 AM, clinton at elemtech.com wrote: > When I do the same message(), I don't see deletion of rpaths which do not exist. I see them for libshared and libshared2 which have SKIP_BUILD_RPATH. > But, I'm wondering if INSTALL_RPATH should only be effective on OS X > if MACOSX_RPATH is set. > Currently MACOSX_RPATH determines whether a target uses @rpath for > its id, which can result in rpaths for a consumer. > In other words, whether a target has rpaths is determined by the > use of @rpath in its dependencies. > What do you think about the case of INSTALL_RPATH? If any dependencies have @rpath then the RPATH of a target is meaningful, and INSTALL_RPATH is how the actual search paths listed in the RPATH are to be set. INSTALL_RPATH is orthogonal to MACOSX_RPATH. The affect different fields of their target. -Brad From ono at java.pl Thu Oct 9 10:37:48 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 9 Oct 2014 16:37:48 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <888522664.277920.1412862188537.JavaMail.zimbra@elemtech.com> References: <542ACE37.1040302@kitware.com> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> <5432AE91.1010708@kitware.com> <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> <5435556F.9070303@kitware.com> <888522664.277920.1412862188537.JavaMail.zimbra@elemtech.com> Message-ID: <8EA6525C-DFC9-4162-AD46-C919B95D238F@java.pl> > I was looking at the BundleUtilities failure after the above fixes, and I noticed it unconditionally removes paths. It does that because all bundles frameworks/libraries are referenced by @executable/loader_path and all @rpath references will be replaced, so there no point to have LC_RPATH in executables that will likely point to absolute old library locations. Please note that this is just an extension to existing BundleUtilities behavior. I intentionally didn't want to support or add an option to bundle framework using @path + LC_PATH. --Adam From eric.noulard at gmail.com Thu Oct 9 10:58:55 2014 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 9 Oct 2014 16:58:55 +0200 Subject: [cmake-developers] [CPack] Call for volunteer for CPackRPM, CPackDeb maintenance. Message-ID: Hi everybody, This message is an open request to find volunteer maintainers for CPackRPM and CPackDeb which were my main contributions to CPack (CPackDeb was initially contributed by Mathieu). I have 21 Mantis tickets (http://public.kitware.com/Bug) assigned to me I will soon unassign them or "transfer" them to volunteering people. I did contribute to CMake/CPack for some time (~2007) now but my "CMake free time" is now too small to be able to test and integrate contribution/patches to CPackDeb and CPackRPM. I will be listening to the mailing lists as usual but one shall not count on a timely responsiveness from me. I shall say that this is not a lack of interest but a clear lack of time. I do continue to use CMake/CPack/CTest on a daily basis but cannot find enough time to contribute anymore. I'll try my best to help the volunteer(s) to take over. People interested may answer here and/or send me direct e-mail if they find it necessary. I shall say that the CMake developer community including Kitware people (off course) were (and are) very helpful and always kind to handle my cmake/cpack contribution. -- Erk L'?lection n'est pas la d?mocratie -- http://www.le-message.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton at elemtech.com Thu Oct 9 11:01:10 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Thu, 09 Oct 2014 09:01:10 -0600 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <54369B54.3040501@kitware.com> References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> Message-ID: <4919083.hvPr6C4Ify@stryke> On Thursday, October 09, 2014 10:27:32 AM Brad King wrote: > On 10/09/2014 10:16 AM, clinton at elemtech.com wrote: > > When I do the same message(), I don't see deletion of rpaths which do not > > exist. > I see them for libshared and libshared2 which have SKIP_BUILD_RPATH. > > > But, I'm wondering if INSTALL_RPATH should only be effective on OS X > > if MACOSX_RPATH is set. > > Currently MACOSX_RPATH determines whether a target uses @rpath for > > its id, which can result in rpaths for a consumer. > > In other words, whether a target has rpaths is determined by the > > use of @rpath in its dependencies. > > What do you think about the case of INSTALL_RPATH? > > If any dependencies have @rpath then the RPATH of a target is > meaningful, and INSTALL_RPATH is how the actual search paths > listed in the RPATH are to be set. INSTALL_RPATH is orthogonal > to MACOSX_RPATH. The affect different fields of their target. > Another justification for that is if a target does not link to any libraries with an @rpath id, it is still useful to have an rpath to support dlopen("@rpath/somelib"). Thanks, Clint From mantis at public.kitware.com Thu Oct 9 11:07:33 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 9 Oct 2014 11:07:33 -0400 Subject: [cmake-developers] [CMake 0015201]: Xcode generator is unusably slow on large projects Message-ID: <15f76c320208f2a1b0cb8bbeae291cd8@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15201 ====================================================================== Reported By: Simon Assigned To: ====================================================================== Project: CMake Issue ID: 15201 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-09 11:07 EDT Last Modified: 2014-10-09 11:07 EDT ====================================================================== Summary: Xcode generator is unusably slow on large projects Description: I am building a large project, over a thousand CMakeList.txt files resulting in hundreds of Xcode projects being generated. This takes at least 6 times longer than the same makefile generation. I have profiled cmake 3.0.2 and found a significant bottleneck in cmGlobalXCodeGenerator::FindXCodeTarget() because the objects are stored in a vector and this vector has to be iterated over each time to find a target. This is done thousands of times in the course of generating the Xcode project. As a quick fix I did the following: cmGlobalXCodeGenerator.h, added member var: std::unordered_map mXcodeObjectMap; cmGlobalXCodeGenerator.cpp void cmGlobalXCodeGenerator::ClearXCodeObjects() added to end of method: mXcodeObjectMap.clear(); cmGlobalXCodeGenerator::CreateUtilityTarget(cmTarget& cmtarget) Under call to target->SetTarget(...) added: mXcodeObjectMap[&cmtarget] = target; cmGlobalXCodeGenerator::CreateXCodeTarget(...) Under call to target->SetTarget(...) added: mXcodeObjectMap[&cmtarget] = target; cmXCodeObject* cmGlobalXCodeGenerator::FindXCodeTarget(cmTarget const* t) rewrote to: cmXCodeObject* cmGlobalXCodeGenerator::FindXCodeTarget(cmTarget const* t) { if(!t) { return 0; } std::unordered_map::iterator iter = mXcodeObjectMap.find(t); if (iter == mXcodeObjectMap.end()) { return 0; } return iter->second; } So basically rather than constantly iterating through a vector for the Xcode object with the right target, it now keeps an unordered map where the key is the target pointer, and the object is the Xcode object. This reduces the lookup time enormously. With only this change the generation of the project I'm working on goes down from well over an hour to around 10 mins, which puts it inline with the makefile generator performance. Steps to Reproduce: Build a large set of projects. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-09 11:07 Simon New Issue ====================================================================== From ono at java.pl Thu Oct 9 11:14:46 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 9 Oct 2014 17:14:46 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <4919083.hvPr6C4Ify@stryke> References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> Message-ID: <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> FYI pushed e646a14f61 BundleUtilities: Check install_name_tool has -delete_rpath which is safest way to check if we can use -delete_rpath as it was introduced somewhere in 10.6 SDK, but there's no guarantee what SDK user has even it runs more recent OSX. --Adam From brad.king at kitware.com Thu Oct 9 11:19:17 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Oct 2014 11:19:17 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> Message-ID: <5436A775.7040401@kitware.com> On 10/09/2014 11:14 AM, Adam Strzelecki wrote: > FYI pushed e646a14f61 BundleUtilities: Check install_name_tool > has -delete_rpath which is safest way to check if we can use Thanks. I moved the commit over on top of the rpath-osx-10_6 topic and then removed that topic. For now fix-OSX-bundle-rpaths-and-Qt5 will contain all these related changes. I merged it for testing in 'next'. Thanks, -Brad From ydginster at gmail.com Thu Oct 9 13:30:15 2014 From: ydginster at gmail.com (Evgeny Kalishenko) Date: Thu, 9 Oct 2014 21:30:15 +0400 Subject: [cmake-developers] [PATCH] Preinstall requirements support for CPack RPM generator In-Reply-To: <543695B3.5010201@kitware.com> References: <543695B3.5010201@kitware.com> Message-ID: Ok, thanks for the advise about STREQUAL. Explanation of s/_/(/ (from http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html): "Recent versions of RPM support context marked dependencies. This is a special type of a dependency that applies only in a specified *context*. Using this feature, one can specify dependencies for pre- and post(un)install scriptlets, ie. the context of a dependency is the execution time of the specified scriptlet. The syntax for specifying these dependencies is: Requires(*X*): foo Here, *X* can be one of *pre*, *post*, *preun*, or *postun*, which tells RPM that the package depends on package foo for running the corresponding *%pre*, *%post*, *%preun*, or *%postun* script." Modified patch attached. 2014-10-09 18:03 GMT+04:00 Brad King : > On 10/08/2014 01:48 PM, Evgeny Kalishenko wrote: > > I was interested in feature request > > http://public.kitware.com/Bug/view.php?id=14769 and made a > > simple patch for CPack RPM generator (attached). > > Thanks. > > In this hunk: > > > + # The following keywords require braces around the "pre" or "post" > suffix in the final RPM spec file. > > + if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE" OR > "${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST") > > + string(REPLACE "_" "(" _PACKAGE_HEADER_NAME > "${_PACKAGE_HEADER_NAME}") > > + set(_PACKAGE_HEADER_NAME "${_PACKAGE_HEADER_NAME})") > > + endif() > > The MATCHES conditions can use simply STREQUAL instead. > I'm not very familiar with the spec format, so please > explain the purpose of the s/_/(/ subsitution in comments > here. > > Thanks, > -Brad > > -- ? ?????????, ??????? ????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pre_post_rpm_install.patch Type: text/x-patch Size: 5997 bytes Desc: not available URL: From chuck.atkins at kitware.com Thu Oct 9 14:27:18 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 9 Oct 2014 14:27:18 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <5433FC0B.4060802@kitware.com> References: <542E964C.1050104@kitware.com> <5433FC0B.4060802@kitware.com> Message-ID: Are we still on a "stage freeze" until the release, or is it just a hold on stage/next? I ask because I've got a non-trivial branch to push to the stage for review that re-factors how search paths are constructed for find* commands. - Chuck On Tue, Oct 7, 2014 at 10:43 AM, Brad King wrote: > On 10/03/2014 08:27 AM, Brad King wrote: > > In preparation for the first 3.1 release candidate I will feature- > > freeze master as of 2014-10-09. As of now there are several open > > topics in 'next' that we should try to land in master by then, but > > please refrain from adding non-trivial changes in the meantime. > > In order to get the dashboard cleaned up for final merges to > 'master' before the release, please refrain from merging any > changes other than dashboard fixes and documentation updates > to 'next'. > > Thanks, > -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 brad.king at kitware.com Thu Oct 9 14:32:43 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Oct 2014 14:32:43 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: References: <542E964C.1050104@kitware.com> <5433FC0B.4060802@kitware.com> Message-ID: <5436D4CB.8010702@kitware.com> On 10/09/2014 02:27 PM, Chuck Atkins wrote: > I've got a non-trivial branch to push to the stage for review You can push it for review but please do not merge to 'next' yet. Thanks, -Brad From chuck.atkins at kitware.com Thu Oct 9 14:34:08 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 9 Oct 2014 14:34:08 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <5436D4CB.8010702@kitware.com> References: <542E964C.1050104@kitware.com> <5433FC0B.4060802@kitware.com> <5436D4CB.8010702@kitware.com> Message-ID: Great, thanks! - Chuck On Thu, Oct 9, 2014 at 2:32 PM, Brad King wrote: > On 10/09/2014 02:27 PM, Chuck Atkins wrote: > > I've got a non-trivial branch to push to the stage for review > > You can push it for review but please do not merge to 'next' yet. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Thu Oct 9 14:45:19 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 9 Oct 2014 14:45:19 -0400 Subject: [cmake-developers] Refactoring search path construction Message-ID: I've just pushed a branch to the stage for review: refactor-search-path-construction , not merged to next due to the current release hold. Just a head's up, it's rather invasive. It's a re-factoring of how search paths get constructed for find* commands. Up until now, search paths have been incrementally constructed with the composite search path being the only result. This separates and constructs each "class" of search path separately and combines them together afterwards. This branch is a pre-cursor for new features that can manipulate groups of search paths with leaving others untouched. - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Thu Oct 9 14:55:57 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 9 Oct 2014 14:55:57 -0400 Subject: [cmake-developers] Refactoring search path construction In-Reply-To: References: Message-ID: Just to clarify, this does *NOT* change the search order. - Chuck On Thu, Oct 9, 2014 at 2:45 PM, Chuck Atkins wrote: > I've just pushed a branch to the stage for review: > refactor-search-path-construction , not merged to next due to the current > release hold. > > Just a head's up, it's rather invasive. It's a re-factoring of how search > paths get constructed for find* commands. Up until now, search paths have > been incrementally constructed with the composite search path being the > only result. This separates and constructs each "class" of search path > separately and combines them together afterwards. > > This branch is a pre-cursor for new features that can manipulate groups of > search paths with leaving others untouched. > > - Chuck > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Thu Oct 9 13:38:09 2014 From: paul at mad-scientist.net (Paul Smith) Date: Thu, 09 Oct 2014 13:38:09 -0400 Subject: [cmake-developers] [CMake] Forcing colorization of output from cmake In-Reply-To: <543693E2.5090901@kitware.com> References: <1367417913.4101.127.camel@pdsdesk> <1412784946.29340.123.camel@mad-scientist.net> <54356C78.7060501@kitware.com> <1412793361.29340.127.camel@mad-scientist.net> <543693E2.5090901@kitware.com> Message-ID: <1412876289.29340.133.camel@mad-scientist.net> Thanks Brad. I wrote a bunch more below and left it for posterity. However thinking more about this I wonder if we couldn't make this simpler. What I really want is that if MAKE_TERMOUT is set to a non-empty value, cmake should pretend that it's in a terminal regardless of what isatty() says. We can do this easily enough by adding a simple test to Terminal.c:kwsysTerminalStreamIsVT100() _without_ adding any code anywhere else: /* Check for a valid terminal. */ if(!default_vt100) { ... } + + /* If we're being run from GNU make 4.1+ see if IT thinks we have a TTY. */ + const char* termout = getenv("MAKE_TERMOUT"); + if(termout && termout[0] != '\0') + { + return 1; + } In a way this is gross, certainly, but this function already checks for environment variable such as TERM, EMACS, etc. which are set by calling utilities and handles them specially. So why not MAKE_TERMOUT as well? That one change is enough for my particular use-case, without any other changes (don't need a FORCE setting for color). I think it would be useful to allow FORCE (I think this is a good capability to provide; as I mentioned other tools that support colorization such as GCC etc. to provide an "always"-type flag) but it would be decoupled from this GNU make capability. Thoughts? On Thu, 2014-10-09 at 09:55 -0400, Brad King wrote: > The Source/kwsys part of the change actually belongs in a separate > KWSys upstream first. I've added a modified version of your change > for upstream review and testing here: > > http://review.source.kitware.com/17578 > > Please try out that version with the rest of your changes. OK. I see that in your version FORCE only comes into effect if we have a "known good" terminal (the new code comes after the check for valid terminal). Personally I would expect FORCE to be stronger than that, and return true regardless of TERM settings. Whether or not it should override EMACS env.var. I don't know... I'm on the fence. In my solution I had it really FORCE; that is, kwsysTerminalStreamIsVT100() effectively always was true if --switch=FORCE, regardless of EMACS or TERM. I'm not at all familiar with Windows so I have no strong opinions on whether FORCE should also force color output on a Windows console... although I know a number of people who do use GNU make on Windows and the Windows port of GNU make does set MAKE_TERMOUT properly. > > it's darn handy to have this "just work" without having to export > > COLOR='$(if $(MAKE_TERMOUT),FORCE)' in your ~/.bashrc or whatever. > > There's no "GNU Makefiles" generator, and I couldn't come up with a good > > way to implement this in the generic Unix Makefiles generator. > > We already have a CMAKE_COLOR_MAKEFILE option. Perhaps instead > of just ON or OFF values it could have a GNU value that enables > this behavior. When initializing it in CMakeGenericSystem.cmake > perhaps it is possible to detect if CMAKE_MAKE_PROGRAM is a GNU > make tool and provide a good default. Well, it's easy enough to detect if CMAKE_MAKE_PROGRAM is GNU make, if we can run it to test the output of "${CMAKE_MAKE_PROGRAM} --version". The question is, what do you do in the generated makefile if you see that it's GNU make? Anything you'd generate into the makefile that could choose to set --switch=FORCE would have to be GNU-specific (I can't think of a way to write it using POSIX standard makefile syntax). It would need to be the equivalent of: --switch=$(or $(COLOR),$(if $(MAKE_TERMOUT),FORCE)) to preserve the current behavior, where the COLOR variable setting can be inherited from the environment. What if someone runs cmake and it detects GNU make, but then they run "/my/other/make" which is not GNU make? That would work fine now but fail if we generated GNU-specific content in 'Unix Makefiles' generators. If we had a different generator, like 'GNU Makefiles' for example, then people who chose that would clearly expect the results would only work with GNU make, but we don't have that. From Geoffrey.Viola at asirobots.com Thu Oct 9 19:36:20 2014 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Thu, 9 Oct 2014 23:36:20 +0000 Subject: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support Message-ID: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> Attached is a patch to make CMake generate files for the Green Hills MULTI IDE. These patches are in reference to this feature request: http://public.kitware.com/Bug/view.php?id=14992. There were some limitations. It has been restricted to Windows, because that is the version of the IDE that I have. There is a special grouping called a Monolith that includes several executables, shared libraries, and the kernel. These monoliths have their own set of compile options. I'm not sure how CMake would be able to create these. Also, there are some internal macros that point to the compiler's target BSP and OS that are currently populated via CMake variables: GHS_CUSTOMIZATION, GHS_OS_DIR, and GHS_BSP_NAME. Any feedback would be appreciated. Thanks, [cid:image001.png at 01CE6DA0.CA468FE0] Geoffrey Viola Software Engineer T +1.435.755.2980 ext 1077 M +1.215.896.6521 asirobots.com This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1911 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Updated-supplementary-files-to-include-the-GHS-gener.patch Type: application/octet-stream Size: 15035 bytes Desc: 0002-Updated-supplementary-files-to-include-the-GHS-gener.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-basic-and-partial-support-for-a-Green-Hill-MUL.patch Type: application/octet-stream Size: 36468 bytes Desc: 0001-Added-basic-and-partial-support-for-a-Green-Hill-MUL.patch URL: From nilsgladitz at gmail.com Fri Oct 10 05:09:54 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Oct 2014 11:09:54 +0200 Subject: [cmake-developers] $ genex regression Message-ID: <5437A262.1050305@gmail.com> "cmTarget: Refactor ComputeLinkImplementation" (24637979): http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=24637979 Seems to have broken this reduced testcase: cmake_minimum_required(VERSION 3.0) set(LIBRARIES foobar.lib barfoo.lib ) add_executable(foo foo.cpp) target_link_libraries(foo PUBLIC $) For the Ninja generator in 3.0 this produces a "build.ninja" with: LINK_LIBRARIES = -rdynamic -lfoobar.lib -lbarfoo.lib Since 24637979 this produces: LINK_LIBRARIES = -rdynamic $ I can work around this by wrapping the libraries with $ individually or by quoting the entire genex. Given the title of the commit I'm guessing this wasn't an intentional change of behavior? Nils From nilsgladitz at gmail.com Fri Oct 10 07:10:44 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Oct 2014 13:10:44 +0200 Subject: [cmake-developers] Ninja RC cmcldeps regression Message-ID: <5437BEB4.1000208@gmail.com> Ninja on windows invokes the resource compiler through cmcldeps. When passing ${CMAKE_BINARY_DIR} as an include directory CMake used to (3.0) add the absolute path to the command line; now "-I." is being added instead. The relative path does not seem to work in context of cmcldeps/rc since headers in ${CMAKE_BINARY_DIR} aren't found anymore. Nils From ruslan_baratov at yahoo.com Fri Oct 10 07:45:14 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 10 Oct 2014 15:45:14 +0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <543531CC.7090103@kitware.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> Message-ID: <5437C6CA.3030201@yahoo.com> On 08-Oct-14 16:45, Brad King wrote: > On 10/08/2014 07:52 AM, Ruslan Baratov wrote: >> Okay :) I just not sure that I understand "to pass to some other >> process" goal correctly. > That was just an example of why one might want to drop management > of the lock by CMake without actually unlocking it. Perhaps the > code is starting a daemon and passes off responsibility for the > unlock side to the daemon process. Okay, got it. > >> * we just need to `unlock` file so the other instance will use it: >> file(UNLOCK_FILE "/path/to/shared/file") >> # now anybody can do the lock > Yes. We also need the locking API to return information about > whether we really acquired the lock. So it can be TRY_LOCK and LOCK. But does the TRY_LOCK really needed? With LOCK we can try to lock and spin until acquire, but what to do with TRY_LOCK? Just give up? > >> * we need other process to "inherit" the lock (what for?), i.e. move >> ownership (?): >> file(LOCK_FILE "/path/to/shared/file") >> execute_process(${CMAKE_COMMAND} --take-ownership "/path/to/shared/file" >> ...) >> # unlocked by execute_process > I think all we need there is a way to ask CMake to take over > responsibility for a lock that it did not originally create. > It can also be in the file() command. > > Thanks, > -Brad > Okay, so here is the commands inspired by C++: file(TRY_LOCK "/path/to/file" result) # try to lock and return TRUE on success (needed?) file(LOCK ...) # lock until unlock (unlock by further code (what if exit/crashed?) or by deamon) file(LOCK_GUARD ...) # lock for scope of current function or until exit file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD Locking directory is equivalent to locking file `cmake.lock` in directory "/path/to/shared/directory/": file(DIRECTORY_TRY_LOCK ...) file(DIRECTORY_LOCK "/path/to/shared/directory/") # == file(LOCK "/path/to/shared/directory/cmake.lock") file(DIRECTORY_LOCK_GUARD ...) file(DIRECTORY_UNLOCK ...) If any of this commands failed (e.g. have no permissions) - exit with unsuccessful code (i.e. FATAL_ERROR) ? * http://en.cppreference.com/w/cpp/thread/try_lock * http://en.cppreference.com/w/cpp/thread/lock * http://en.cppreference.com/w/cpp/thread/lock_guard * http://en.cppreference.com/w/cpp/thread/mutex/unlock From nilsgladitz at gmail.com Fri Oct 10 08:43:02 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Oct 2014 14:43:02 +0200 Subject: [cmake-developers] Ninja RC cmcldeps regression In-Reply-To: <5437BEB4.1000208@gmail.com> References: <5437BEB4.1000208@gmail.com> Message-ID: <5437D456.3030801@gmail.com> On 10/10/2014 01:10 PM, Nils Gladitz wrote: > Ninja on windows invokes the resource compiler through cmcldeps. > > When passing ${CMAKE_BINARY_DIR} as an include directory CMake used to > (3.0) add the absolute path to the command line; now "-I." is being > added instead. > > The relative path does not seem to work in context of cmcldeps/rc since > headers in ${CMAKE_BINARY_DIR} aren't found anymore. This seems to have broken with "cmLocalGenerator: Simplify GetIncludeFlags output formatting" (b9aa5041): http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=b9aa5041 I used the following test case to reproduce the issue: cmake_minimum_required(VERSION 3.0) file(WRITE foo.cpp "int main() {}") file(WRITE foo.rc "#include ") file(WRITE ${CMAKE_BINARY_DIR}/bar.rc "") add_executable(foo foo.cpp foo.rc) target_include_directories(foo PRIVATE ${CMAKE_BINARY_DIR}) Nils From brad.king at kitware.com Fri Oct 10 08:48:24 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Oct 2014 08:48:24 -0400 Subject: [cmake-developers] [CPack] Call for volunteer for CPackRPM, CPackDeb maintenance. In-Reply-To: References: Message-ID: <5437D598.30307@kitware.com> On 10/09/2014 10:58 AM, Eric Noulard wrote: > This message is an open request to find volunteer maintainers > for CPackRPM and CPackDeb > > I did contribute to CMake/CPack for some time (~2007) now but > my "CMake free time" is now too small to be able to test and > integrate contribution/patches to CPackDeb and CPackRPM. Thank you for your help over all these years, Eric! -Brad From DLRdave at aol.com Fri Oct 10 08:58:00 2014 From: DLRdave at aol.com (David Cole) Date: Fri, 10 Oct 2014 08:58:00 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5437C6CA.3030201@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> Message-ID: What is the main use case for locking files and directories from the CMake language? I feel slightly uncomfortable, without being able to put my finger on exactly why, with the prospect of adding this to CMake... Behavior when there's a lock that still exists (by bug/mistake) after CMake is done running is going to be strange and possibly hard-to-diagnose / hard-to-understand. Let's make sure the use case is quite strong before we accept the possibility of "stale locks" in CMake. Thanks, David C. On Fri, Oct 10, 2014 at 7:45 AM, Ruslan Baratov via cmake-developers wrote: > On 08-Oct-14 16:45, Brad King wrote: >> >> On 10/08/2014 07:52 AM, Ruslan Baratov wrote: >>> >>> Okay :) I just not sure that I understand "to pass to some other >>> process" goal correctly. >> >> That was just an example of why one might want to drop management >> of the lock by CMake without actually unlocking it. Perhaps the >> code is starting a daemon and passes off responsibility for the >> unlock side to the daemon process. > > Okay, got it. >> >> >>> * we just need to `unlock` file so the other instance will use it: >>> file(UNLOCK_FILE "/path/to/shared/file") >>> # now anybody can do the lock >> >> Yes. We also need the locking API to return information about >> whether we really acquired the lock. > > So it can be TRY_LOCK and LOCK. But does the TRY_LOCK really needed? With > LOCK we can try to lock and spin until acquire, but what to do with > TRY_LOCK? Just give up? >> >> >>> * we need other process to "inherit" the lock (what for?), i.e. move >>> ownership (?): >>> file(LOCK_FILE "/path/to/shared/file") >>> execute_process(${CMAKE_COMMAND} --take-ownership "/path/to/shared/file" >>> ...) >>> # unlocked by execute_process >> >> I think all we need there is a way to ask CMake to take over >> responsibility for a lock that it did not originally create. >> It can also be in the file() command. >> >> Thanks, >> -Brad >> > Okay, so here is the commands inspired by C++: > > file(TRY_LOCK "/path/to/file" result) # try to lock and return TRUE on > success (needed?) > file(LOCK ...) # lock until unlock (unlock by further code (what if > exit/crashed?) or by deamon) > file(LOCK_GUARD ...) # lock for scope of current function or until exit > file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD > > Locking directory is equivalent to locking file `cmake.lock` in directory > "/path/to/shared/directory/": > > file(DIRECTORY_TRY_LOCK ...) > file(DIRECTORY_LOCK "/path/to/shared/directory/") # == file(LOCK > "/path/to/shared/directory/cmake.lock") > file(DIRECTORY_LOCK_GUARD ...) > file(DIRECTORY_UNLOCK ...) > > If any of this commands failed (e.g. have no permissions) - exit with > unsuccessful code (i.e. FATAL_ERROR) ? > > * http://en.cppreference.com/w/cpp/thread/try_lock > * http://en.cppreference.com/w/cpp/thread/lock > * http://en.cppreference.com/w/cpp/thread/lock_guard > * http://en.cppreference.com/w/cpp/thread/mutex/unlock > > -- > > 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 brad.king at kitware.com Fri Oct 10 09:14:57 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Oct 2014 09:14:57 -0400 Subject: [cmake-developers] $ genex regression In-Reply-To: <5437A262.1050305@gmail.com> References: <5437A262.1050305@gmail.com> Message-ID: <5437DBD1.1050401@kitware.com> On 10/10/2014 05:09 AM, Nils Gladitz wrote: > set(LIBRARIES > foobar.lib > barfoo.lib > ) > > add_executable(foo foo.cpp) > target_link_libraries(foo PUBLIC $) This is basically writing: target_link_libraries(foo PUBLIC $) which was never intended to be supported. It worked only as an accident of the 3.0 implementation. In 2.8.12.2 it did not work. > I can work around this by wrapping the libraries with $ > individually or by quoting the entire genex. This was the intended interface. I'm willing to regress this because: - It restores 2.8.12 behavior - The quoting is easy to do - It is very hard to fix this without un-doing all the other improvements enabled by the refactoring that broke this. I will add mention of this in the 3.1 release notes. Thanks, -Brad From nilsgladitz at gmail.com Fri Oct 10 09:17:09 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Oct 2014 15:17:09 +0200 Subject: [cmake-developers] $ genex regression In-Reply-To: <5437DBD1.1050401@kitware.com> References: <5437A262.1050305@gmail.com> <5437DBD1.1050401@kitware.com> Message-ID: <5437DC55.1040002@gmail.com> On 10/10/2014 03:14 PM, Brad King wrote: >> I can work around this by wrapping the libraries with $ >> individually or by quoting the entire genex. > > This was the intended interface. > > I'm willing to regress this because: > > - It restores 2.8.12 behavior > - The quoting is easy to do > - It is very hard to fix this without un-doing all the other > improvements enabled by the refactoring that broke this. > > I will add mention of this in the 3.1 release notes. Good enough for me, thanks! Nils From ruslan_baratov at yahoo.com Fri Oct 10 09:59:07 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 10 Oct 2014 17:59:07 +0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> Message-ID: <5437E62B.4050903@yahoo.com> On 10-Oct-14 16:58, David Cole wrote: > What is the main use case for locking files and directories from the > CMake language? > > I feel slightly uncomfortable, without being able to put my finger on > exactly why, with the prospect of adding this to CMake... I've described the situation in the first message of this thread: sharing resources between different cmake builds. If you want the particular case: I'm developing cmake-based package manager that share the builds of ExternalProject_Add. I'm experienced problems even when working on my local machine (I've started long-build in one console, then accidentally connect to the same shared directory in other console), but the main problem here is the server auto-builds which usually start multiple jobs simultaneously. > > Behavior when there's a lock that still exists (by bug/mistake) after > CMake is done running is going to be strange and possibly > hard-to-diagnose / hard-to-understand. That's *exactly* the problem I have and why I start this discussion. Currently I'm using mkdir command which return 0 only if directory created by current process (just to clarify, not the cmake -E make_directory). This works fine for me (tested on windows (mingw, cygwin), linux and mac). But I can't (or I don't know how) make remove this directory when I Ctrl+C my build (or abort the job on jenkins server). My current implementation just keep spinning with message: "Directory locked by cmake, build started in directory at ". > > Let's make sure the use case is quite strong before we accept the > possibility of "stale locks" in CMake. Command `file(LOCK_GUARD ...)` will cover 100% of my needs. Other commands that I've mentioned used to cover suggestions from Brad K. (may be I've just understand them wrong). Ruslo Thanks, David C. On Fri, Oct 10, 2014 at 7:45 AM, Ruslan Baratov via cmake-developers wrote: >> On 08-Oct-14 16:45, Brad King wrote: >>> On 10/08/2014 07:52 AM, Ruslan Baratov wrote: >>>> Okay :) I just not sure that I understand "to pass to some other >>>> process" goal correctly. >>> That was just an example of why one might want to drop management >>> of the lock by CMake without actually unlocking it. Perhaps the >>> code is starting a daemon and passes off responsibility for the >>> unlock side to the daemon process. >> Okay, got it. >>> >>>> * we just need to `unlock` file so the other instance will use it: >>>> file(UNLOCK_FILE "/path/to/shared/file") >>>> # now anybody can do the lock >>> Yes. We also need the locking API to return information about >>> whether we really acquired the lock. >> So it can be TRY_LOCK and LOCK. But does the TRY_LOCK really needed? With >> LOCK we can try to lock and spin until acquire, but what to do with >> TRY_LOCK? Just give up? >>> >>>> * we need other process to "inherit" the lock (what for?), i.e. move >>>> ownership (?): >>>> file(LOCK_FILE "/path/to/shared/file") >>>> execute_process(${CMAKE_COMMAND} --take-ownership "/path/to/shared/file" >>>> ...) >>>> # unlocked by execute_process >>> I think all we need there is a way to ask CMake to take over >>> responsibility for a lock that it did not originally create. >>> It can also be in the file() command. >>> >>> Thanks, >>> -Brad >>> >> Okay, so here is the commands inspired by C++: >> >> file(TRY_LOCK "/path/to/file" result) # try to lock and return TRUE on >> success (needed?) >> file(LOCK ...) # lock until unlock (unlock by further code (what if >> exit/crashed?) or by deamon) >> file(LOCK_GUARD ...) # lock for scope of current function or until exit >> file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD >> >> Locking directory is equivalent to locking file `cmake.lock` in directory >> "/path/to/shared/directory/": >> >> file(DIRECTORY_TRY_LOCK ...) >> file(DIRECTORY_LOCK "/path/to/shared/directory/") # == file(LOCK >> "/path/to/shared/directory/cmake.lock") >> file(DIRECTORY_LOCK_GUARD ...) >> file(DIRECTORY_UNLOCK ...) >> >> If any of this commands failed (e.g. have no permissions) - exit with >> unsuccessful code (i.e. FATAL_ERROR) ? >> >> * http://en.cppreference.com/w/cpp/thread/try_lock >> * http://en.cppreference.com/w/cpp/thread/lock >> * http://en.cppreference.com/w/cpp/thread/lock_guard >> * http://en.cppreference.com/w/cpp/thread/mutex/unlock >> >> -- >> >> 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 brad.king at kitware.com Fri Oct 10 10:11:35 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Oct 2014 10:11:35 -0400 Subject: [cmake-developers] Ninja RC cmcldeps regression In-Reply-To: <5437D456.3030801@gmail.com> References: <5437BEB4.1000208@gmail.com> <5437D456.3030801@gmail.com> Message-ID: <5437E917.4090002@kitware.com> On 10/10/2014 08:43 AM, Nils Gladitz wrote: > This seems to have broken with "cmLocalGenerator: Simplify > GetIncludeFlags output formatting" (b9aa5041): > http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=b9aa5041 > > I used the following test case to reproduce the issue: Thanks, fixed and test added: Ninja: Fix RC include directories regression http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23c8eeb7 -Brad From nilsgladitz at gmail.com Fri Oct 10 10:18:16 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Oct 2014 16:18:16 +0200 Subject: [cmake-developers] $ genex regression In-Reply-To: <5437DC55.1040002@gmail.com> References: <5437A262.1050305@gmail.com> <5437DBD1.1050401@kitware.com> <5437DC55.1040002@gmail.com> Message-ID: <5437EAA8.2080909@gmail.com> On 10/10/2014 03:17 PM, Nils Gladitz wrote: > On 10/10/2014 03:14 PM, Brad King wrote: >>> I can work around this by wrapping the libraries with $ >>> individually or by quoting the entire genex. >> >> This was the intended interface. >> >> I'm willing to regress this because: >> >> - It restores 2.8.12 behavior >> - The quoting is easy to do >> - It is very hard to fix this without un-doing all the other >> improvements enabled by the refactoring that broke this. >> >> I will add mention of this in the 3.1 release notes. > > Good enough for me, thanks! > > Nils > As a side node for post-3.1 development it might be nice to have the Ninja generator properly escape the $ from e.g. those broken generator expressions that leak through or alternatively have CMake produce an error during generation. As it is the generated build.ninja is invalid and my local Dashboard (with launchers) showed all green for the configuration and build steps since even though ninja itself failed none of the compile/build jobs ran (and hence could not fail). In continuous builds where stale outputs still existed from previous builds there was no failure indication in the "Test" columns either. Nils From nilsgladitz at gmail.com Fri Oct 10 10:18:52 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Oct 2014 16:18:52 +0200 Subject: [cmake-developers] Ninja RC cmcldeps regression In-Reply-To: <5437E917.4090002@kitware.com> References: <5437BEB4.1000208@gmail.com> <5437D456.3030801@gmail.com> <5437E917.4090002@kitware.com> Message-ID: <5437EACC.50209@gmail.com> On 10/10/2014 04:11 PM, Brad King wrote: > Thanks, fixed and test added: > > Ninja: Fix RC include directories regression > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23c8eeb7 Thanks! Nils From brad.king at kitware.com Fri Oct 10 10:27:37 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Oct 2014 10:27:37 -0400 Subject: [cmake-developers] $ genex regression In-Reply-To: <5437EAA8.2080909@gmail.com> References: <5437A262.1050305@gmail.com> <5437DBD1.1050401@kitware.com> <5437DC55.1040002@gmail.com> <5437EAA8.2080909@gmail.com> Message-ID: <5437ECD9.301@kitware.com> On 10/10/2014 10:18 AM, Nils Gladitz wrote: > As a side node for post-3.1 development it might be nice to have the > Ninja generator properly escape the $ from e.g. those broken generator > expressions that leak through or alternatively have CMake produce an > error during generation. I think the most user-friendly approach would be an error during generation, or at least a warning. Perhaps a policy to make the warning an error. The main challenge will be deciding what to actually consider wrong without breaking real use cases. -Brad From brad.king at kitware.com Fri Oct 10 10:49:13 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Oct 2014 10:49:13 -0400 Subject: [cmake-developers] $ genex regression In-Reply-To: <5437DC55.1040002@gmail.com> References: <5437A262.1050305@gmail.com> <5437DBD1.1050401@kitware.com> <5437DC55.1040002@gmail.com> Message-ID: <5437F1E9.5080303@kitware.com> On 10/10/2014 09:17 AM, Nils Gladitz wrote: > On 10/10/2014 03:14 PM, Brad King wrote: >> I will add mention of this in the 3.1 release notes. > > Good enough for me, thanks! Here is a release note entry: Help: Add note about restoring pre-3.0 link libraries genex behavior http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8bd81981 -Brad From brad.king at kitware.com Fri Oct 10 10:59:15 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Oct 2014 10:59:15 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <5436A775.7040401@kitware.com> References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com> Message-ID: <5437F443.3040705@kitware.com> On 10/09/2014 11:19 AM, Brad King wrote: > I merged it for testing in 'next'. Everything tested cleanly! Adam, Clinton, thanks for your help bringing this topic to maturity. It was the last non-regression topic I'm planning to take for 3.1. I squashed the fixes and revised commit messages slightly. Then I merged to 'master': Merge topic 'fix-OSX-bundle-rpaths-and-Qt5' http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26bffa6e -Brad From steveire at gmail.com Fri Oct 10 11:56:38 2014 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 10 Oct 2014 17:56:38 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> Message-ID: Clinton Stimpson wrote: > Another justification for that is if a target does not link to any > libraries with an @rpath id, it is still useful to have an rpath to > support dlopen("@rpath/somelib"). Picking a message randomly, to respond to - Can someone tell me what this comment is referring to? # FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly # Qt5 Mac support is missing there. Thanks, Steve. From mantis at public.kitware.com Fri Oct 10 16:59:05 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 10 Oct 2014 16:59:05 -0400 Subject: [cmake-developers] [CMake 0015202]: BundleUtilities.cmake - function fixup_bundle_item fails with very long path Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15202 ====================================================================== Reported By: Mark Manthei Assigned To: ====================================================================== Project: CMake Issue ID: 15202 Category: CMake Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-10 16:59 EDT Last Modified: 2014-10-10 16:59 EDT ====================================================================== Summary: BundleUtilities.cmake - function fixup_bundle_item fails with very long path Description: when fixing up a very long exe inside of a bundle, the code attempts to figure out if the item is embedded in the bundle. The current logic fails because the SUBSTRING search starts at offset 0 and can fail to find the embedded item in the given length. >From debug output of BundleUtilities.cmake: -- 22/42: fixing up '/Users/autobuild/hudson/workspace/Product-Mac/build/Installed/Really Long App Name.app/Contents/MacOS/embeddeditem exe_dotapp_dir/='Installed/Really Long App Name.app/' item_substring='/Users/autobuild/hudson/workspace/R' Steps to Reproduce: Use long paths. Additional Information: Patch to fix issue, CMake version 3.0.2 attached ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-10 16:59 Mark Manthei New Issue 2014-10-10 16:59 Mark Manthei File Added: BundleUtilities.patch ====================================================================== From mantis at public.kitware.com Fri Oct 10 17:46:51 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 10 Oct 2014 17:46:51 -0400 Subject: [cmake-developers] [CMake 0015203]: CheckStructHasMember breaks on -Wunused-value Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15203 ====================================================================== Reported By: Lekensteyn Assigned To: ====================================================================== Project: CMake Issue ID: 15203 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-10 17:46 EDT Last Modified: 2014-10-10 17:46 EDT ====================================================================== Summary: CheckStructHasMember breaks on -Wunused-value Description: When CMAKE_C_FLAGS containg -Wall -Werror, CheckStructHasMember will always fail due to the generated code appearing as: int main() { struct FOO* s; s->MEMBER; return 0; } See the attached patch for a fix. Don't know whether some -std flag will also bail out on int main() rather than int main(void), but that's a different issue. This one is about breakage due to very strict warnings on a modern compiler (GCC 4.9.1). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-10 17:46 Lekensteyn New Issue 2014-10-10 17:46 Lekensteyn File Added: 0001-CheckStructHasMember-avoid-breakage-on-Wall.patch ====================================================================== From mantis at public.kitware.com Sun Oct 12 04:21:28 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 12 Oct 2014 01:21:28 -0700 Subject: [cmake-developers] [CMake 0015204]: On windows x64 system, cpack generate file names ending with AMD64, with 32 bit msvc compiler Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15204 ====================================================================== Reported By: Hong Xu Assigned To: ====================================================================== Project: CMake Issue ID: 15204 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-12 01:21 PDT Last Modified: 2014-10-12 01:21 PDT ====================================================================== Summary: On windows x64 system, cpack generate file names ending with AMD64, with 32 bit msvc compiler Description: On windows x64 system, cpack generate file names ending with AMD64, even with 32 bit msvc compiler. Packages (zip and NSIS installer) are generated with AMD64 in file name but not x86. However, the NSIS installer is an x86 executable as I tested. Output of cl command: Microsoft (R) C/C++ Optimizing Compiler Version 18.00.30723 for x86 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] Steps to Reproduce: Under 32bit compiler environment, use cpack to build the package by typing "cpack". ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-12 01:21 Hong Xu New Issue ====================================================================== From ono at java.pl Mon Oct 13 05:54:22 2014 From: ono at java.pl (Adam Strzelecki) Date: Mon, 13 Oct 2014 11:54:22 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> Message-ID: <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl> > Picking a message randomly, to respond to - Can someone tell me what this > comment is referring to? > > # FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly > # Qt5 Mac support is missing there. AFAIR it is about installing correct app bundle PlugIns. Qt provides half-baked CMake support, but some of necessary things still has to be done by user manually, such as installing cocoa platform plugin. --Adam From ben.boeckel at kitware.com Mon Oct 13 10:34:30 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 13 Oct 2014 10:34:30 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5437E62B.4050903@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> <5437E62B.4050903@yahoo.com> Message-ID: <20141013143430.GA15816@megas.kitwarein.com> On Fri, Oct 10, 2014 at 17:59:07 +0400, Ruslan Baratov via cmake-developers wrote: > > Behavior when there's a lock that still exists (by bug/mistake) after > > CMake is done running is going to be strange and possibly > > hard-to-diagnose / hard-to-understand. > That's *exactly* the problem I have and why I start this discussion. > Currently I'm using mkdir command which return 0 only if directory > created by current process (just to clarify, not the cmake -E > make_directory). This works fine for me (tested on windows (mingw, > cygwin), linux and mac). But I can't (or I don't know how) make remove > this directory when I Ctrl+C my build (or abort the job on jenkins > server). My current implementation just keep spinning with message: > "Directory locked by cmake, build started in directory > at ". Maybe we need something like the 'trap' shell builtin which runs code on various triggers rather than something like file/directory locks which are?hairy (especially in the face of things like NFS or Samba)? I can think of at least: - end of configure - end of generate - end of directory scope - end of scope (function or directory) --Ben From brad.king at kitware.com Mon Oct 13 10:39:08 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Oct 2014 10:39:08 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5437C6CA.3030201@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> Message-ID: <543BE40C.4000404@kitware.com> On 10/10/2014 07:45 AM, Ruslan Baratov wrote: > file(TRY_LOCK "/path/to/file" result) # try to lock and return TRUE on success (needed?) > file(LOCK ...) # lock until unlock (unlock by further code (what if exit/crashed?) or by deamon) The LOCK signature should have a timeout after which it returns failure instead of blocking forever. One can just use a timeout of 0 to get TRY_LOCK behavior without a separate signature for it. Or, by leaving out the timeout, one can ask to block forever waiting for the lock. > file(LOCK_GUARD ...) # lock for scope of current function or until exit I think the GUARD part can be an option to file(LOCK). We may need more than one to determine the scope, e.g. file(LOCK GUARD_FUNCTION ...) file(LOCK GUARD_PROCESS ...) > file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD Perhaps file(LOCK RELEASE ...) # unlock now file(LOCK UNGUARD ...) # drop guard > Locking directory is equivalent to locking file `cmake.lock` in > directory "/path/to/shared/directory/": I think this can be activated buy a DIRECTORY option. > If any of this commands failed (e.g. have no permissions) - exit with > unsuccessful code (i.e. FATAL_ERROR) ? The commands should all have an optional result argument so callers can find out what happened. If it is not provided, then failure can result in a FATAL_ERROR. With all the above in mind, please brainstorm and propose a more complete signature set. You can use the keyword/value pairing common in other commands to avoid needing a positional argument for every value. Also, please post a summary of how the implementation will work on each platform. Thanks, -Brad From brad.king at kitware.com Mon Oct 13 10:41:46 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Oct 2014 10:41:46 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <20141013143430.GA15816@megas.kitwarein.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> <5437E62B.4050903@yahoo.com> <20141013143430.GA15816@megas.kitwarein.com> Message-ID: <543BE4AA.5070907@kitware.com> On 10/13/2014 10:34 AM, Ben Boeckel wrote: > Maybe we need something like the 'trap' shell builtin which runs code on > various triggers That would first require an 'eval' equivalent in CMake, e.g. "cmake_eval()". This has been requested a few times. -Brad From chuck.atkins at kitware.com Mon Oct 13 11:40:10 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 13 Oct 2014 11:40:10 -0400 Subject: [cmake-developers] Proposed Feature: Selective search path re-rooting Message-ID: Following the topic branch to separately maintain each type of search path, I'm working on adding a feature for cross-compiling to separately control how each type of search path gets re-rooted. Currently, the options CMAKE_FIND_ROOT_PATH_MODE_{INCLUDE_LIBRARY_PROGRAM} can be set to ONLY, NEVER, or BOTH. This takes effect for all search paths, both CMake determined and user-specifies (through HINTS and PATHS options). Before putting the time and effort into implementing the feature this way, I wanted to get some feedback on the design first: My approach to control the path types independently is to allow the variable to be specified as either a single mode, applying to all paths, or a named list of the form "PATH_TYPE1 MODE1 PATH_TYPE2_MODE2..." much in the way that properties are specified. The following search path groups can be specified: - CMAKE_PATH - CMAKE_ENVIRONMENT_PATH - USER_HINTS_PATH - SYSTEM_ENVIRONMENT_PATH - CMAKE_SYSTEM_PATH - USER_GUESS_PATH In addition to each search path type, there will also be defined path groups: - ALL - All search paths - DEFAULT - CMAKE_PATH - CMAKE_ENVIRONMENT_PATH - SYSTEM_ENVIRONMENT_PATH - CMAKE_SYSTEM_PATH - USER - User hints and user guess paths If one had: set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ALL ONLY HINTS NEVER) Then the following modes would be set: - find_program: All search paths set to never - find_library: user hints would never be re-rooted and all others would operate in ONLY mode. - find_file: All search paths set to BOTH mode since that's the default behavior. - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Mon Oct 13 12:43:02 2014 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 13 Oct 2014 18:43:02 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl> Message-ID: Adam Strzelecki wrote: >> Picking a message randomly, to respond to - Can someone tell me what this >> comment is referring to? >> >> # FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly >> # Qt5 Mac support is missing there. > > AFAIR it is about installing correct app bundle PlugIns. Qt provides > half-baked CMake support, but some of necessary things still has to be > done by user manually, such as installing cocoa platform plugin. If you can be more specific or explain why the Qt5 CMake files should install a plugin for you, or whatever it should should do, feel free to file bug reports or patches. Thanks, Steve. From brad.king at kitware.com Mon Oct 13 13:31:54 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Oct 2014 13:31:54 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl> References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl> Message-ID: <543C0C8A.8010509@kitware.com> On 10/13/2014 05:54 AM, Adam Strzelecki wrote: > Qt provides half-baked CMake support Side note: this is not a fair characterization of Qt's support for CMake. Qt5 is an outstanding example of how an upstream can make it easy to use a project with CMake even when the upstream itself does not use CMake. Qt5 provides package configuration files for find_package(), and once loaded they provide imported targets with usage requirements. Building a CMake-based project against Qt5 couldn't be much easier IMO. Furthermore, all the CMake-related files come with Qt5 and are maintained there rather than in CMake. This is much easier than Qt4, where FindQt4 in CMake has needed maintenance with every new upstream version. -Brad From micha.hergarden at gmail.com Mon Oct 13 13:36:21 2014 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Mon, 13 Oct 2014 19:36:21 +0200 Subject: [cmake-developers] [CPack] Call for volunteer for CPackRPM, CPackDeb maintenance. In-Reply-To: References: Message-ID: <543C0D95.9090109@gmail.com> On 10/09/2014 04:58 PM, Eric Noulard wrote: > Hi everybody, > > This message is an open request to find volunteer maintainers for > CPackRPM and CPackDeb > which were my main contributions to CPack (CPackDeb was initially > contributed by Mathieu). > > I have 21 Mantis tickets (http://public.kitware.com/Bug) assigned to > me I will soon > unassign them or "transfer" them to volunteering people. > > I did contribute to CMake/CPack for some time (~2007) now but my > "CMake free time" > is now too small to be able to test and integrate contribution/patches > to CPackDeb and > CPackRPM. > > I will be listening to the mailing lists as usual but one shall not > count on a timely responsiveness > from me. I shall say that this is not a lack of interest but a clear > lack of time. > I do continue to use CMake/CPack/CTest on a daily basis but cannot > find enough time > to contribute anymore. > > I'll try my best to help the volunteer(s) to take over. People > interested may answer here > and/or send me direct e-mail if they find it necessary. > > I shall say that the CMake developer community including Kitware > people (off course) > were (and are) very helpful and always kind to handle my cmake/cpack > contribution. > > > -- > Erk > L'?lection n'est pas la d?mocratie -- http://www.le-message.org > > Hello list, With this mail I would like to help out maintaining these modules. I have been reading this list for a while, and been a happy CMake user for several years now. It has saved me a lot of time, so I deceided it was time I contributed some of it back. With kind regards, Micha Hergarden -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From brad.king at kitware.com Mon Oct 13 14:00:56 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Oct 2014 14:00:56 -0400 Subject: [cmake-developers] [CPack] Call for volunteer for CPackRPM, CPackDeb maintenance. In-Reply-To: <543C0D95.9090109@gmail.com> References: <543C0D95.9090109@gmail.com> Message-ID: <543C1358.8090502@kitware.com> On 10/13/2014 01:36 PM, Micha Hergarden wrote: > With this mail I would like to help out maintaining these modules. Wonderful, thanks! To others: this does not close the call. We can have more than one maintainer with overlapping responsibilities. Micha, please start by taking a look at the proposal here: [PATCH] Preinstall requirements support for CPack RPM generator http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11235/focus=11253 and the corresponding issue tracker entry: CPackRPM: need CPACK_RPM__PACKAGE_
_REQUIRES
 http://www.cmake.org/Bug/view.php?id=14769

Thanks,
-Brad


From raffi.enficiaud at free.fr  Mon Oct 13 14:23:27 2014
From: raffi.enficiaud at free.fr (Raffi Enficiaud)
Date: Mon, 13 Oct 2014 20:23:27 +0200
Subject: [cmake-developers] Introduction and volunteering for the Matlab
	package
Message-ID: 

Hi Brad,

(Sorry for the late answer (again).)
I addressed your comments in the files attached to this email (please see the remarks below). I have not yet addressed your comment about ?MATLAB_ADDITIONAL_VERSIONS? but I think it is a better proposition, so I will do it next.
I updated the documentation also, I think it looks now understandable.

I had a hard time making some stuff compile again with Matlab under Linux. The fact is that Matlab is shipped with its own version of libC, libhdf5, libboost etc, and sometimes the filenames are the same (eg. hdf5, or libc) but the subminor versions are not. If I understand properly, the fact that the filenames are the same prevents the dynamic loader of Linux to load the files that are referred by the mex file in their respective rpath (there is only one libhdf51.8.2.so in the matlab process). Beside that, the symbols also may clash: I had an implementation with a dynamic loader under linux, but yet the boost symbols of my mex files were not loaded because same symbols were already there in the process. 
I found a technical solution to this on Linux: 
- the use of -Wl,--exclude-libs,ALL for the linker. 
- the symbol hiding (both include and function definition) from within the mex file
- exporting only the mexFunction symbol

I know that this scheme is working for statically linked libraries, that then should be recompiled with -fPIC. I know also that this is working for shared libraries that do not have the same name (eg. boost1.49.so vs. boost1.55.so). But I think there is nothing more I can do for the shared library having the same name (like hdf51.8.2.so), having the same symbols but apparently having a different ABI.

I do not know how to do that properly under OSX neither. There is no -Wl,--exclude-libs,ALL option in Clang.

Also, I am checking against CMAKE_CXX_COMPILER_ID, which is I think a not so good idea. Is there anything for having the -Wl,--exclude-libs,ALL like the variable CXX_VISIBILITY_PRESET in cmake? I started using a .map file on these two platforms, but also I would prefer limiting the number of files. 

I am using this FindMatlab in two projects now, under OSX 10.9, Win7 Visual2013 and Ubuntu12.04. 

Best,
Raffi




??????

> Hi Raffi,
> 
> Thanks for your continuing work on this module.
> 
> I've made some whitespace and quoting tweaks to the files.  See attached
> updated versions.  I also renamed the test helper to not start in "Find"
> since no one should call find_package(Matlab_TestsRedirect).  See further
> comments below.
> 
> On 07/04/2014 08:02 PM, Raffi Enficiaud wrote:
>>> Many of our tests use "cmake -P" to run a cmake script that performs
>>> the test inside.  You can use -Dvar=${val} before the -P option to
>>> pass options to the script, such as $.
>> 
>> Done: this is the add_matlab_unit_test function. In fact, I think I can
>> remove the log files since they are redundant with the tests logs.
> 
> I see no problem with that, but I'm not familiar with the tools.
> 
>> I added a function add_matlab_mex that is like a add_library
> 
> Please make all APIs start in "matlab_?.

Done

> 
> The documentation blocks for each command also need to start in "#.rst:"
> 
> #.rst:
> # .. command:: add_matlab_mex
> 
> or they will not be included in the processed documentation.

Ok. I checked the documentation again, and I think it contains now all the necessary information, plus it is now visually more appealing. 


> 
>> for creating MEX (compiled) extensions. There is an option to this
>> function called REDUCE_VISIBILITY
> 
> I see that implemented here:
> 
>> if(HAS_VISIBILITY_INLINE_HIDDEN)
>>  target_compile_options(${${prefix}_NAME} PRIVATE "-fvisibility-inlines-hidden")
>> endif()
>> if(HAS_VISIBILITY_HIDDEN)
>>  target_compile_options(${${prefix}_NAME} PRIVATE "-fvisibility=hidden")
>> endif()
> 
> An upstream version of the module should use the builtin features
> for visibility settings:
> 
> 
> http://www.cmake.org/cmake/help/v3.0/prop_tgt/LANG_VISIBILITY_PRESET.html
> 
> 
> http://www.cmake.org/cmake/help/v3.0/prop_tgt/VISIBILITY_INLINES_HIDDEN.html

I am not sure how to do that, please have a look at my changes. It looks ok to me (generated compilation command include the visibility element) but maybe there is something better.



> 
> 
>> #    set(MATLAB_ADDITIONAL_VERSIONS
>> #       "release_name1" "corresponding_version1"
>> #       "release_name2" "corresponding_version2"
>> #       ...
>> #       )
> 
> Rather than relying on matched pairs, perhaps use "=" to separate:
> 
> #    set(MATLAB_ADDITIONAL_VERSIONS
> #       "release_name1=corresponding_version1"
> #       "release_name2=corresponding_version2"
> 
> ?

Right, it is better.


> 
>> I am not sure how my implementation is compatible with the previous
>> FindMatlab package. The requirements are to define the same variables,
>> right? Is there anything else?
> 
> It needs to produce the same result variables and also respond to
> the old "input" variables (like find_ command cached results) that
> the old module did.  That way existing build scripts can continue
> to work.

This is something I should now check deeper. Is it an option to call it FindMatlab2 ?



> 
>> +# * ``MATLAB_USER_ROOT`` the root of the Matlab installation. This is given by the user.
> 
> This should be documented in its own section of variables that the
> user can set to control the search.  See FindZLIB for example.
> 
>> +  # list the keys under HKEY_LOCAL_MACHINE\SOFTWARE\mathworks but the call to reg does not work
>> +  # from cmake, curiously, as is. The command provides the desired result under the command line though.
>> +  # Fix: this is because "/reg:64" should appended to the command, otherwise it gets on the 32 bits software
> key (curiously again)
> 
> This is because it gets the registry view of the calling CMake
> unless you tell it what view to use.

Ok

> 
>> +  find_program(MATLAB_REG_EXE_LOCATION "reg")
>> +  file(TO_NATIVE_PATH ${MATLAB_REG_EXE_LOCATION} MATLAB_REG_EXE_LOCATION)
> 
> The second line should not be needed.  The execute_process command
> will take care of the path format.

Done

> 
>> +  if((NOT DEFINED MATLAB_USER_ROOT) OR (NOT MATLAB_USER_ROOT))
> 
> This can be shortened to
> 
> if(NOT MATLAB_USER_ROOT)

Done

> 
>> +    if(NOT ${Matlab_PROGRAM})
> 
> and this to
> 
> if(NOT Matlab_PROGRAM)

Done

> 
>> BTW, is there any variable that tells the current cmake list,
>> even in function in packages?
> 
> In the attached version I added
> 
> set(_FindMatlab_SELF_DIR "${CMAKE_CURRENT_LIST_DIR}")
> 
> to the top of the file to save the location of the file for re-use
> inside function calls later.

Good. 

> 
> Thanks,
> -Brad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FindMatlab.cmake
Type: application/octet-stream
Size: 42524 bytes
Desc: not available
URL: 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MatlabTestsRedirect.cmake
Type: application/octet-stream
Size: 2039 bytes
Desc: not available
URL: 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From domen.vrankar at gmail.com  Mon Oct 13 15:51:08 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Mon, 13 Oct 2014 21:51:08 +0200
Subject: [cmake-developers] [CPack] Call for volunteer for CPackRPM,
 CPackDeb maintenance.
In-Reply-To: <543C1358.8090502@kitware.com>
References: 
 <543C0D95.9090109@gmail.com> <543C1358.8090502@kitware.com>
Message-ID: 

Hello,

I have been talking with Eric for the past few days now and would also like
to help out with maintaining these two modules.
I am a CMake user for about six years now and have also been using CPackRPM
but for now I haven no experience with CPackDeb.

As suggested by Eric I'll start with issue tracker:
http://public.kitware.com/Bug/view.php?id=13176

Regards,
Domen

2014-10-13 20:00 GMT+02:00 Brad King :

> On 10/13/2014 01:36 PM, Micha Hergarden wrote:
> > With this mail I would like to help out maintaining these modules.
>
> Wonderful, thanks!
>
> To others: this does not close the call.  We can have more than
> one maintainer with overlapping responsibilities.
>
> Micha, please start by taking a look at the proposal here:
>
>  [PATCH] Preinstall requirements support for CPack RPM generator
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11235/focus=11253
>
> and the corresponding issue tracker entry:
>
>  CPackRPM: need CPACK_RPM__PACKAGE_
_REQUIRES
>  http://www.cmake.org/Bug/view.php?id=14769
>
> Thanks,
> -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 brad.king at kitware.com  Mon Oct 13 15:57:07 2014
From: brad.king at kitware.com (Brad King)
Date: Mon, 13 Oct 2014 15:57:07 -0400
Subject: [cmake-developers] [CPack] Call for volunteer for CPackRPM,
 CPackDeb maintenance.
In-Reply-To: 
References: 	<543C0D95.9090109@gmail.com>	<543C1358.8090502@kitware.com>
 
Message-ID: <543C2E93.6060205@kitware.com>

On 10/13/2014 03:51 PM, Domen Vrankar wrote:
> would also like to help out with maintaining these two modules.

Thanks for volunteering too!

> As suggested by Eric I'll start with issue tracker:
> http://public.kitware.com/Bug/view.php?id=13176

Sounds good!

Thanks,
-Brad


From ono at java.pl  Mon Oct 13 16:04:41 2014
From: ono at java.pl (Adam Strzelecki)
Date: Mon, 13 Oct 2014 22:04:41 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <543C0C8A.8010509@kitware.com>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
  <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl>
 <543C0C8A.8010509@kitware.com>
Message-ID: 

> Side note: this is not a fair characterization of Qt's support for CMake.
> (?)
> Furthermore, all the CMake-related files come with Qt5 and are maintained
> there rather than in CMake.  This is much easier than Qt4, where FindQt4
> in CMake has needed maintenance with every new upstream version.

Of course it is great that THEY provide official CMake support. Maybe "half-baked" is a bit harsh, but everything goes smooth until you try to run your freshly compiled Qt5 app in on the any other machine that the one it was compiled on.

First you realize you miss some Qt libraries you were linking to. Fine, fixup_bundle should do the job, but it doesn't.

----
$ hello.app/Contents/MacOS/hello 
This application failed to start because it could not find or load the Qt platform plugin "cocoa".

Available platform plugins are: cocoa, minimal, offscreen.

Reinstalling the application may fix this problem.
----

The message isn't really helpful.

Finally after seeking googling for an answer you find out that there are "platform plugins" and there is no function or module that will help you to bundle them and create proper qt.conf. So all apps that are willing to use Qt5 (not Qt4 legacy version) need to have that manually.

This is why I call it half-baked.

But to be fair, Qt team is really welcoming and open for improvements, I am sure complete support will arrive sooner or later.

FYI I was working hard on relocatable Qt SDK for OSX for a while, it is almost complete. We were to release it for 5.4 but due some fancy testing suite problems probably this will be delayed. This was one of the reasons of my rpath support here. Otherwise once Qt SDK uses rpath it will immediately break CMake compatibility.

--Adam

From steveire at gmail.com  Mon Oct 13 17:11:12 2014
From: steveire at gmail.com (Stephen Kelly)
Date: Mon, 13 Oct 2014 23:11:12 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
  <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl>
 <543C0C8A.8010509@kitware.com> 
Message-ID: 

Adam Strzelecki wrote:

> But to be fair, Qt team is really welcoming and open for improvements, I
> am sure complete support will arrive sooner or later.
> 

As the person who wrote what Qt ships, I can say that it won't be 'complete' 
sooner or later unless someone with enough interest communicates/contributes 
what is missing. I don't have the requisite mac experience.

I also think there might be a generic solution (or partial solution) to 
implement in CMake first (an interface for determining the package 
dependencies perhaps, etc).

What makes this a Qt issue instead of a generic issue?

Thanks,

Steve.



From domen.vrankar at gmail.com  Mon Oct 13 18:17:15 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 14 Oct 2014 00:17:15 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176 CPackRPM
 support for per-component summary and description
Message-ID: 

Hi,

I extended the proposed patch for ticket 13176 with:
- documentation section
- CPACK_RPM__PACKAGE_DESCRIPTION fallback to
CPACK_COMPONENT__DESCRIPTION
- handling of cases when one component sets its variable and the other
doesn't


Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From domen.vrankar at gmail.com  Mon Oct 13 18:23:55 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 14 Oct 2014 00:23:55 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 
Message-ID: 

Message was sent to early by accident so I'm resending the rest.

2014-10-14 0:17 GMT+02:00 Domen Vrankar :

> Hi,
>
> I extended the proposed patch for ticket 13176 with:
> - documentation section
> - CPACK_RPM__PACKAGE_DESCRIPTION fallback to
> CPACK_COMPONENT__DESCRIPTION
> - handling of cases when one component sets its variable and the other
> doesn't
>

e.g.
#set(CPACK_RPM_test_PACKAGE_SUMMARY "test_summary")
set(CPACK_RPM_bin_PACKAGE_SUMMARY "bin_summary")

Could somebody please review the patch attached to this mail?


>
> Regards,
> Domen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CPackRPM_component_summary_description.patch
Type: text/x-diff
Size: 5245 bytes
Desc: not available
URL: 

From mantis at public.kitware.com  Tue Oct 14 02:08:27 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 14 Oct 2014 02:08:27 -0400
Subject: [cmake-developers] [CMake 0015205]: support for osx resource
	toolchain
Message-ID: <5753f570c86d52e36f72b4e6128854dc@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15205 
====================================================================== 
Reported By:                tim blechmann
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15205
Category:                   CMake
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-14 02:08 EDT
Last Modified:              2014-10-14 02:08 EDT
====================================================================== 
Summary:                    support for osx resource toolchain
Description: 
CMake supports windows resource files (.rc) out of the box. OSX has a similar
concept, .r files which compile resource forks of a file.

the toolchain includes Rez (to compile a resource) and ResMerger (to merge
different resources into one file).

xcode supports this toolchain natively, but when using cmake, one has to set up
the toolchain manually via POST_BUILD custom commands, which does not scale
well. so it would be great if cmake would support this natively.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-14 02:08 tim blechmann  New Issue                                    
======================================================================


From mantis at public.kitware.com  Tue Oct 14 02:28:20 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 14 Oct 2014 02:28:20 -0400
Subject: [cmake-developers] [CMake 0015206]: add_jar() in UseJava.cmake uses
	wrong classpath seperator when cross-compiling under Windows
Message-ID: <117c88e6fc2ed7e5ecf29519449c0715@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15206 
====================================================================== 
Reported By:                Lorenz Witte
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15206
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-14 02:28 EDT
Last Modified:              2014-10-14 02:28 EDT
====================================================================== 
Summary:                    add_jar() in UseJava.cmake uses wrong classpath
seperator when cross-compiling under Windows
Description: 
The condition to use ";" as classpath separator includes a check for the switch
"WIN32" which is a target switch. When cross-compiling for a non-windows target,
this switch is not present and the separator defaults to ":".

I think it should rather check for "CMAKE_HOST_WIN32" instead.

Steps to Reproduce: 
Call add_jar() during a cross-compilation on a Windows host.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-14 02:28 Lorenz Witte   New Issue                                    
2014-10-14 02:28 Lorenz Witte   File Added:
0001-fixed-classpath-separator-on-WIN32-cross-compilation.patch                 
  
======================================================================


From domen.vrankar at gmail.com  Tue Oct 14 03:03:01 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 14 Oct 2014 09:03:01 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 
 
Message-ID: 

Sorry for spamming...

I noticed that the previous patch would break user provided rpm spec files
so I'm attaching a new patch that fixes that problem with a bit more
variable juggling.

I also have a question. Would CPack also need something like
CPACK_COMPONENT__PACKAGE_SUMMARY that could be used by
CPACK_RPM__PACKAGE_SUMMARY as default value?

Thanks,
Domen


2014-10-14 0:23 GMT+02:00 Domen Vrankar :

> Message was sent to early by accident so I'm resending the rest.
>
> 2014-10-14 0:17 GMT+02:00 Domen Vrankar :
>
>> Hi,
>>
>> I extended the proposed patch for ticket 13176 with:
>> - documentation section
>> - CPACK_RPM__PACKAGE_DESCRIPTION fallback to
>> CPACK_COMPONENT__DESCRIPTION
>> - handling of cases when one component sets its variable and the other
>> doesn't
>>
>
> e.g.
> #set(CPACK_RPM_test_PACKAGE_SUMMARY "test_summary")
> set(CPACK_RPM_bin_PACKAGE_SUMMARY "bin_summary")
>
> Could somebody please review the patch attached to this mail?
>
>
>>
>> Regards,
>> Domen
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-CPackRPM-component-based-packaging-description-and-s.patch
Type: text/x-diff
Size: 5040 bytes
Desc: not available
URL: 

From eric.noulard at gmail.com  Tue Oct 14 03:28:18 2014
From: eric.noulard at gmail.com (Eric Noulard)
Date: Tue, 14 Oct 2014 09:28:18 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 
 
 
Message-ID: 

2014-10-14 9:03 GMT+02:00 Domen Vrankar :

> Sorry for spamming...
>
> I noticed that the previous patch would break user provided rpm spec files
> so I'm attaching a new patch that fixes that problem with a bit more
> variable juggling.
>


Hi Domen,

I did re-assign the bug entry to you
http://public.kitware.com/Bug/view.php?id=13176

Then we discussing various patches I suggest you to attach the patch
directly to the tracker
that way it's easy to see the patch history and if ever some patch version
is obsolete you may simply remove it from the tracker.


>
> I also have a question. Would CPack also need something like
> CPACK_COMPONENT__PACKAGE_SUMMARY that could be used by
> CPACK_RPM__PACKAGE_SUMMARY as default value?
>


Not sure of that one.
We already have "CPACK_COMPONENT_GROUP_CMAKE_DESCRIPTION"
which may be a default value for "CPACK_RPM__PACKAGE_
SUMMARY" if packaging is done "by compoent group" (which is the default):

The behavior of the various CPack generator w.r.t. mono- or multi-
file/package generation vary,
see:
http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior

e.g. for NSIS or PackageMaker I don't know what you can do with
"CPACK_COMPONENT__
PACKAGE_SUMMARY" because there is only one package.

Otherwise I only read the patch and it looks good.

However you should at least:
  1) run ctest -R CPack  --> this the "minimal" way to run CPack related
tests in the CMake tree
  2) enhance or provide a specific test for the new behavior.


 Eric

>
> Thanks,
> Domen
>
>
> 2014-10-14 0:23 GMT+02:00 Domen Vrankar :
>
>> Message was sent to early by accident so I'm resending the rest.
>>
>> 2014-10-14 0:17 GMT+02:00 Domen Vrankar :
>>
>>> Hi,
>>>
>>> I extended the proposed patch for ticket 13176 with:
>>> - documentation section
>>> - CPACK_RPM__PACKAGE_DESCRIPTION fallback to
>>> CPACK_COMPONENT__DESCRIPTION
>>> - handling of cases when one component sets its variable and the other
>>> doesn't
>>>
>>
>> e.g.
>> #set(CPACK_RPM_test_PACKAGE_SUMMARY "test_summary")
>> set(CPACK_RPM_bin_PACKAGE_SUMMARY "bin_summary")
>>
>> Could somebody please review the patch attached to this mail?
>>
>>
>>>
>>> Regards,
>>> Domen
>>>
>>
>>
>
> --
>
> 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
>



-- 
Erk
L'?lection n'est pas la d?mocratie -- http://www.le-message.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From domen.vrankar at gmail.com  Tue Oct 14 03:59:11 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 14 Oct 2014 09:59:11 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 
 
 
 
Message-ID: 

2014-10-14 9:28 GMT+02:00 Eric Noulard :

>
>
> 2014-10-14 9:03 GMT+02:00 Domen Vrankar :
>
>> Sorry for spamming...
>>
>> I noticed that the previous patch would break user provided rpm spec
>> files so I'm attaching a new patch that fixes that problem with a bit more
>> variable juggling.
>>
>
>
> Hi Domen,
>
> I did re-assign the bug entry to you
> http://public.kitware.com/Bug/view.php?id=13176
>

Noticed that. Thanks. I did not notice that I can reassign bugs myself.


>
> Then we discussing various patches I suggest you to attach the patch
> directly to the tracker
> that way it's easy to see the patch history and if ever some patch version
> is obsolete you may simply remove it from the tracker.
>
>

Done.


>
>> I also have a question. Would CPack also need something like
>> CPACK_COMPONENT__PACKAGE_SUMMARY that could be used by
>> CPACK_RPM__PACKAGE_SUMMARY as default value?
>>
>
>
> Not sure of that one.
> We already have "CPACK_COMPONENT_GROUP_CMAKE_DESCRIPTION"
> which may be a default value for "CPACK_RPM__PACKAGE_
> SUMMARY" if packaging is done "by compoent group" (which is the default):
>
> The behavior of the various CPack generator w.r.t. mono- or multi-
> file/package generation vary,
> see:
>
> http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior
>
>
I'll read it in the afternoon.


> e.g. for NSIS or PackageMaker I don't know what you can do with
> "CPACK_COMPONENT__
> PACKAGE_SUMMARY" because there is only one package.
>
> Otherwise I only read the patch and it looks good.
>

> However you should at least:
>   1) run ctest -R CPack  --> this the "minimal" way to run CPack related
> tests in the CMake tree
>

Forgot to run the tests the first time but remembered afterwards.


>   2) enhance or provide a specific test for the new behavior.
>
>
Will do this in the afternoon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ono at java.pl  Tue Oct 14 05:32:50 2014
From: ono at java.pl (Adam Strzelecki)
Date: Tue, 14 Oct 2014 11:32:50 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: 
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
  <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl>
 <543C0C8A.8010509@kitware.com> 
 
Message-ID: <29F6DD1A-D501-4CC3-AD77-3032BB454C45@java.pl>

> As the person who wrote what Qt ships, I can say that it won't be 'complete' 
> sooner or later unless someone with enough interest communicates/contributes 
> what is missing. I don't have the requisite mac experience.

Sure, I believe someone will sooner or later submit patches to Qt.

> I also think there might be a generic solution (or partial solution) to 
> implement in CMake first (an interface for determining the package 
> dependencies perhaps, etc).

CMake has everything necessary there install(...) & fixup_bundle(...).

> What makes this a Qt issue instead of a generic issue?

$ git show 9b98fd52

install_qt5_plugin writing qt.conf and launching fixup_bundle should be part of Qt5 CMake support not part of app specific CMakeLists.txt (in this case CMake.app), e.g. single function install_qt5_bundle that does it all, selects default platform plugins and it is clearly documented somewhere.

Also on Qt SDK side there are couple of things to be done: QTBUG-14150 QTBUG-31814

--Adam

From brad.king at kitware.com  Tue Oct 14 09:48:14 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 14 Oct 2014 09:48:14 -0400
Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1
In-Reply-To: <542E964C.1050104@kitware.com>
References: <542E964C.1050104@kitware.com>
Message-ID: <543D299E.6050201@kitware.com>

On 10/03/2014 08:27 AM, Brad King wrote:
> please refrain from adding non-trivial changes in the meantime.

I've branched 'release' for 3.1.  The repository is now open for
post-3.1 development.  Please rebase any open topics on 'master'
before merging to 'next'.

Thanks,
-Brad


From brad.king at kitware.com  Tue Oct 14 09:57:16 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 14 Oct 2014 09:57:16 -0400
Subject: [cmake-developers] Initial Attempt at Green Hill MULTI IDE
 Generator Support
In-Reply-To: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com>
References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com>
Message-ID: <543D2BBC.1010306@kitware.com>

On 10/09/2014 07:36 PM, Geoffrey Viola wrote:
> Attached is a patch to make CMake generate files for the Green
> Hills MULTI IDE. These patches are in reference to this feature
> request: http://public.kitware.com/Bug/view.php?id=14992.

Thanks for working on this.

First I've extracted the comment typo fixes from the second patch:

 Fix some spelling errors in comments
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bef23e81

I've attached a patch rebasing the rest of the changes on 'master'
after integration of the typo fixes.

To aid others for review, please provide a high-level explanation
of the MULTI IDE, its target platforms, and how developers might
use it with CMake.

> There were some limitations. It has been restricted to Windows,
> because that is the version of the IDE that I have. There is a
> special grouping called a Monolith that includes several
> executables, shared libraries, and the kernel. These monoliths
> have their own set of compile options. I?m not sure how CMake
> would be able to create these. Also, there are some internal
> macros that point to the compiler?s target BSP and OS that are
> currently populated via CMake variables: GHS_CUSTOMIZATION,
> GHS_OS_DIR, and GHS_BSP_NAME.

Depending on the semantics, these may belong in
Modules/Platform/.cmake for some  name of the target
platform.  We'll need a better understanding of their role to
say for sure though.  See CMAKE_OSX_SYSROOT in Darwin*.cmake
for example.

Thanks,
-Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Added-basic-and-partial-support-for-a-Green-Hill-MUL.patch
Type: text/x-diff
Size: 37840 bytes
Desc: not available
URL: 

From brad.king at kitware.com  Tue Oct 14 10:04:54 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 14 Oct 2014 10:04:54 -0400
Subject: [cmake-developers] [CMake] Forcing colorization of output from
	cmake
In-Reply-To: <1412876289.29340.133.camel@mad-scientist.net>
References: <1367417913.4101.127.camel@pdsdesk>		
 <1412784946.29340.123.camel@mad-scientist.net>		
 <54356C78.7060501@kitware.com>	
 <1412793361.29340.127.camel@mad-scientist.net>	
 <543693E2.5090901@kitware.com> <1412876289.29340.133.camel@mad-scientist.net>
Message-ID: <543D2D86.3060801@kitware.com>

On 10/09/2014 01:38 PM, Paul Smith wrote:
> What I really want is that if MAKE_TERMOUT is set to a non-empty value,
> cmake should pretend that it's in a terminal regardless of what isatty()
> says.  We can do this easily enough by adding a simple test to
> Terminal.c:kwsysTerminalStreamIsVT100() _without_ adding any code
> anywhere else:

One problem with this is that non-make processes launched by make may
run their own children to capture the output through pipes and not
unset MAKE_TERMOUT.  We need it to be 'make' that evaluates that env
variable.  Your original command-line approach did this.

> In a way this is gross, certainly, but this function already checks for
> environment variable such as TERM, EMACS, etc. which are set by calling
> utilities and handles them specially.  So why not MAKE_TERMOUT as well?

The TERM and EMACS variables are checked to determine whether the
terminal supports color when isatty() returns true.  That is not
the same as forcing tty behavior.

> I would expect FORCE to be stronger than that, and return
> true regardless of TERM settings.

Okay, but the internal API in KWSys Terminal needs to be more granular
than that.  Please revise your patch to use my KWSys part but also
add a ForceVT100 setting that causes TERM and EMACS to be ignored.
Then the --switch=FORCE can set both the ForceTTY and ForceVT100
setting internally.

> I'm not at all familiar with Windows so I have no strong opinions on
> whether FORCE should also force color output on a Windows console...
> although I know a number of people who do use GNU make on Windows and
> the Windows port of GNU make does set MAKE_TERMOUT properly.

Native Windows terminals do not support the color escape sequences
at all.  We need to get a handle to the underlying console buffer and
set parameters on it directly.  If the output pipe is not connected
to a real console then we cannot get the console handle and print
color at all.

>> We already have a CMAKE_COLOR_MAKEFILE option.  Perhaps instead
>> of just ON or OFF values it could have a GNU value that enables
> 
> Well, it's easy enough to detect if CMAKE_MAKE_PROGRAM is GNU make, if
> we can run it to test the output of "${CMAKE_MAKE_PROGRAM} --version".
> 
> The question is, what do you do in the generated makefile if you see
> that it's GNU make?

The CMake generator would recognize CMAKE_COLOR_MAKEFILE==GNU and
enable the GNU-specific content.  CMAKE_COLOR_MAKEFILE is a cache
setting the user could set if they don't like the default.  We can
set the default based on whether the CMAKE_MAKE_PROGRAM is GNU.

> It would need to be the equivalent of:
> 
>    --switch=$(or $(COLOR),$(if $(MAKE_TERMOUT),FORCE))
> 
> to preserve the current behavior, where the COLOR variable setting can
> be inherited from the environment.

Yes.

> What if someone runs cmake and it detects GNU make, but then they run
> "/my/other/make" which is not GNU make?  That would work fine now but
> fail if we generated GNU-specific content in 'Unix Makefiles'
> generators.

The user could always set CMAKE_COLOR_MAKEFILE to ON instead of GNU
to work with other make tools.

> If we had a different generator, like 'GNU Makefiles' for example, then
> people who chose that would clearly expect the results would only work
> with GNU make, but we don't have that.

One day we may create a 'GNU Makefiles' generator to enable use of
GNU-specific features, but that would need to be a more comprehensive
effort than just changing the color option.

Thanks,
-Brad


From mantis at public.kitware.com  Tue Oct 14 10:31:32 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 14 Oct 2014 10:31:32 -0400
Subject: [cmake-developers] [CMake 0015207]: FindJNI does not work when
	compiling 32-bit target on 64-bit host
Message-ID: <752725d05636fb5cc34874da9bddec26@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15207 
====================================================================== 
Reported By:                Stepan Schejbal
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15207
Category:                   Modules
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-14 10:31 EDT
Last Modified:              2014-10-14 10:31 EDT
====================================================================== 
Summary:                    FindJNI does not work when compiling 32-bit target
on 64-bit host
Description: 
When compiling 32-bit linux target using "-m32", FindJNI breaks, because it is
based on CMAKE_SYSTEM_PROCESSOR which does not match the target architecture.
This is related to issue http://public.kitware.com/Bug/view.php?id=9611.

Steps to Reproduce: 
find_package(JNI REQUIRED)

export CC=gcc-4.8
export CXX=g++-4.8
export JAVA_HOME=/opt/jdk1.7.0_55-i586
export CFLAGS=-m32
export CXXFLAGS=-m32
export LDFALGS=-m32
cmake...
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-14 10:31 Stepan SchejbalNew Issue                                    
======================================================================


From steveire at gmail.com  Tue Oct 14 12:19:24 2014
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 14 Oct 2014 18:19:24 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
  <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl>
 <543C0C8A.8010509@kitware.com> 
  <29F6DD1A-D501-4CC3-AD77-3032BB454C45@java.pl>
Message-ID: 

Adam Strzelecki wrote:

>> What makes this a Qt issue instead of a generic issue?
> 
> $ git show 9b98fd52

[Ignoring the qt.conf part]

Again, what is Qt-specific about bundling a plugin with an application? What 
is non-generic about that?

Why can't CMake targets communicate what needs to be bundled with them? Why 
can't some CMake interface consume such information? 

Why would a install_qt5_bundle function bundle only the platform plugin, but 
not other plugins?

Thanks,

Steve.



From Geoffrey.Viola at asirobots.com  Tue Oct 14 12:48:09 2014
From: Geoffrey.Viola at asirobots.com (Geoffrey Viola)
Date: Tue, 14 Oct 2014 16:48:09 +0000
Subject: [cmake-developers] Initial Attempt at Green Hill MULTI IDE
 Generator Support
In-Reply-To: <543D2BBC.1010306@kitware.com>
References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com>
 <543D2BBC.1010306@kitware.com>
Message-ID: <0b5b33c4d1f0472782e260f9e5bce980@CO1PR07MB208.namprd07.prod.outlook.com>

Green Hills MULTI is an IDE for embedded real-time systems. It features an editor, a great debugger, and a GUI to organize and visual memory layouts: http://www.ghs.com/products/MULTI_IDE.html. There is a Linux and Windows version of it. Green Hill's real-time operating system, INTEGRITY, supports ARM, Intel x86, and other architectures: http://www.ghs.com/products/rtos/integrity.html.

It is advantageous to use CMake for its script based target management functionality, which is very useful to manage unit tests, and 3rd party finding mechanisms. Switching between IDEs is advantageous because other IDEs have better editors and built-in support to run unit tests. Also, embedded code could be ported to ease debugging without extra hardware.

I took a look at CMAKE_OSX_SYSROOT. It is similar to GHS_OS_DIR. There may be a simpler way to represent these customizations, but I don't know if there are any guarantees on standard folder structures or names.

The current patch is being used to create all the main targets and a default top level file. That generated top level file is hand edited to include custom hand edited kernel and monolith files. It is my intention to generate everything via CMake. It seems there needs to be some development to use the find boost module, because "CMAKE_FIND_LIBRARY_PREFIXES" is not set.


Geoffrey Viola
SOFTWARE ENGINEER
T

+1.435.755.2980

ext 1077
M

+1.215.896.6521


asirobots.com




-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com]
Sent: Tuesday, October 14, 2014 7:57 AM
To: Geoffrey Viola
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support

On 10/09/2014 07:36 PM, Geoffrey Viola wrote:
> Attached is a patch to make CMake generate files for the Green Hills
> MULTI IDE. These patches are in reference to this feature
> request: http://public.kitware.com/Bug/view.php?id=14992.

Thanks for working on this.

First I've extracted the comment typo fixes from the second patch:

 Fix some spelling errors in comments
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bef23e81

I've attached a patch rebasing the rest of the changes on 'master'
after integration of the typo fixes.

To aid others for review, please provide a high-level explanation of the MULTI IDE, its target platforms, and how developers might use it with CMake.

> There were some limitations. It has been restricted to Windows,
> because that is the version of the IDE that I have. There is a special
> grouping called a Monolith that includes several executables, shared
> libraries, and the kernel. These monoliths have their own set of
> compile options. I'm not sure how CMake would be able to create these.
> Also, there are some internal macros that point to the compiler's
> target BSP and OS that are currently populated via CMake variables:
> GHS_CUSTOMIZATION, GHS_OS_DIR, and GHS_BSP_NAME.

Depending on the semantics, these may belong in Modules/Platform/.cmake for some  name of the target platform.  We'll need a better understanding of their role to say for sure though.  See CMAKE_OSX_SYSROOT in Darwin*.cmake for example.

Thanks,
-Brad
This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

From ben.boeckel at kitware.com  Tue Oct 14 16:42:18 2014
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 14 Oct 2014 16:42:18 -0400
Subject: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake
 re-run if possible
In-Reply-To: <542EE420.7010406@gmail.com>
References: <542DC4EF.2000400@gmail.com> 
 <542E9D0B.1080806@kitware.com> 
 <542EE420.7010406@gmail.com>
Message-ID: <20141014204218.GA29097@megas.kitwarein.com>

On Fri, Oct 03, 2014 at 20:00:00 +0200, Sylvain Joubert wrote:
> Unlike the rerun target which is manually added by the Ninja generator,
> the install and package targets are handled in a generic way by the 
> utility target generator.
> 
> Thus, handling these targets is not as straightforward as rerun.
> I'll keep digging a bit, maybe I can find a way to do it. ;-)

It should be possible to set a property on the target(s) when they are
created. Though?looking at the docs, it seems that there's no generic
JOB_POOL property for custom targets. When that property is implemented,
setting 'console' for these targets for Ninja should be simple enough.

--Ben

From aleixpol at kde.org  Tue Oct 14 19:46:48 2014
From: aleixpol at kde.org (Aleix Pol)
Date: Wed, 15 Oct 2014 01:46:48 +0200
Subject: [cmake-developers] Extracting target metadata, IDE integration
In-Reply-To: <6761034.LHuUtODnIM@eto>
References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com>
 
 <542D4879.20204@kitware.com> <6761034.LHuUtODnIM@eto>
Message-ID: 

On Fri, Oct 3, 2014 at 3:52 PM, Rolf Eike Beer  wrote:

> Brad King wrote:
> > On 10/01/2014 07:46 PM, Aleix Pol wrote:
> > > I'm very interested in getting this in and iterating forward.
> > >
> > > Any comments? How do changes get integrated?
> >
> > My main concern is that the format has not been proven with a
> > corresponding implementation of an actual IDE/plugin to use it.
> > Once we start producing a format changing it later will be
> > problematic for compatibility.  Even though we added a version
> > number to the file, an IDE might not be updated along with a
> > CMake that produces a newer version.
>
> This probably needs a way to query for the IDE which versions the given
> CMake
> version supports, no? Otherwise a newer IDE may request version 3 and just
> get
> nothing because the CMake binary only supports 1 and 2.
>
> Eike
> --


If it's not available then it should just error out.

Aleix

PS: I'm alive, working on this, when I get some free time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From domen.vrankar at gmail.com  Wed Oct 15 03:30:23 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Wed, 15 Oct 2014 09:30:23 +0200
Subject: [cmake-developers]  CMake and CPack automated testing
Message-ID: 

Hi,

I was looking at CMake automated tests and did not quite understand how
they are intended to be written.

Do they only test for e.g. if CPack executes without errors or do they
check generated files content (e.g. diff or call for e.g. rpm -qi
some_pkg.rpm and then diff the output)? I'm not certain how in-depth the
automated tests should be.

Is there a cmake developers wiki page or some other reference with
guidelines on how to write automated tests for CMake and CPack?

Thanks,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From eric.noulard at gmail.com  Wed Oct 15 05:03:12 2014
From: eric.noulard at gmail.com (Eric Noulard)
Date: Wed, 15 Oct 2014 11:03:12 +0200
Subject: [cmake-developers] CMake and CPack automated testing
In-Reply-To: 
References: 
Message-ID: 

2014-10-15 9:30 GMT+02:00 Domen Vrankar :

> Hi,
>
> I was looking at CMake automated tests and did not quite understand how
> they are intended to be written.
>
> Do they only test for e.g. if CPack executes without errors or do they
> check generated files content (e.g. diff or call for e.g. rpm -qi
> some_pkg.rpm and then diff the output)? I'm not certain how in-depth the
> automated tests should be.
>

The current CPack test inside the CMake source tree are very simple they
only check whether if cpack runs properly in various situation
for various CPack generator. e.g. the "CPackComponentsForAll" test is run
for the available CPack generator on the current platform
and "counts" if the number of generated package file is the appropriate
one, see
/Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake

The other tests CPackComponents and CPackTestAllGenerators only verifies
that cpack run and terminates OK.
The logic of activation of the various CPack generator is in:
/Tests/CMakeLists.txt

inside this file reads e.g.: if(CTEST_RUN_CPackComponentsForAll)  and the
following lines.

Doing more "semantic checks" e.g. running rpm -qi then compare to a
reference file etc... would be indeed very nice.
The thing is the combinatorial explosion of what you can generate for each
CPack generator is high but any more "semantic"
test for any CPack generator would be (I think) a good point.


> Is there a cmake developers wiki page or some other reference with
> guidelines on how to write automated tests for CMake and CPack?
>

I don't think there is anything like that, but that would be very helpful.


>
> Thanks,
> Domen
>
> --
>
> 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
>



-- 
Erk
L'?lection n'est pas la d?mocratie -- http://www.le-message.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From guillaume.papin at parrot.com  Wed Oct 15 10:04:49 2014
From: guillaume.papin at parrot.com (Guillaume Papin)
Date: Wed, 15 Oct 2014 14:04:49 +0000
Subject: [cmake-developers] FindBoost.cmake cannot find some libraries when
	cross-compiling
Message-ID: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan>

Hello CMake developers,

I have a cross-compiled version of Boost and some other libraries under ~/my-project/CrossThirdPartyPrefix.

I invoke CMake with a CMAKE_TOOLCHAIN_FILE and also I sets CMAKE_FIND_ROOT_PATH
to the directory where my cross-compiled Boost is installed.

    cmake -DCMAKE_TOOLCHAIN_FILE=$HOME/my-project/plateforms/arm-toolchain.cmake \
        -DCMAKE_FIND_ROOT_PATH=$HOME/my-project/CrossThirdPartyPrefix \
        ~/my-projects/src/

But I have an error when using FindBoost.cmake:

In my project's CMakeLists.txt:
    find_package(Boost 1.53.0 REQUIRED COMPONENTS atomic thread system)

The error:
     CMake Error at .../share/cmake-3.0/Modules/FindBoost.cmake:1179 (message):
       Unable to find the requested Boost libraries.

       Boost version: 1.55.0

       Boost include path:
       ~/myproject/CrossThirdPartyPrefix/include


       Could not find the following Boost libraries:

               boost_thread
               boost_system

       Some (but not all) of the required Boost libraries were found.  You may
       need to install these additional Boost libraries.  Alternatively, set
       BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT
       to the location of Boost.


So the first component library (atomic) is found but not the other ones.

Looking at the code, when the first library is found, Boost_LIBRARY_DIR is set
to the directory that contains the library and then change the further calls of
find_library to use Boost_LIBRARY_DIR as the unique HINTS, and with the
NO_DEFAULT_PATH options set.

    macro(_Boost_FIND_LIBRARY var)
      find_library(${var} ${ARGN})

      if(${var})
        # If this is the first library found then save Boost_LIBRARY_DIR.
        if(NOT Boost_LIBRARY_DIR)
          get_filename_component(_dir "${${var}}" PATH)
          set(Boost_LIBRARY_DIR "${_dir}" CACHE PATH "Boost library directory" FORCE)
        endif()
      elseif(_Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT)
        # Try component-specific hints but do not save Boost_LIBRARY_DIR.
        find_library(${var} HINTS ${_Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT} ${ARGN})
      endif()

      # If Boost_LIBRARY_DIR is known then search only there.
      if(Boost_LIBRARY_DIR)
        set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
      endif()
    endmacro()

* https://github.com/Kitware/CMake/blob/1b3495d32e1523648da08e138482a654f8765333/Modules/FindBoost.cmake#L322-L325
    
The issue is that, when using CMAKE_FIND_ROOT_PATH, the Boost_LIBRARY_DIR of the
host (~/myproject/CrossThirdPartyPrefix/lib/ in my case), will be expanded against the root paths.

To find my libraries I can apply the following fix but I'm not sure if it's the
right solution or not.

    diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
    index 3642b3e..aad6575 100644
    --- a/Modules/FindBoost.cmake
    +++ b/Modules/FindBoost.cmake
    @@ -321,7 +321,7 @@ macro(_Boost_FIND_LIBRARY var)
     
       # If Boost_LIBRARY_DIR is known then search only there.
       if(Boost_LIBRARY_DIR)
    -    set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
    +    set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
       endif()
     endmacro()
     
    @@ -855,7 +855,7 @@ if(_Boost_CHANGE_LIBDIR AND NOT _Boost_LIBRARY_DIR_CHANGED)
     endif()
     
     if(Boost_LIBRARY_DIR)
    -  set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
    +  set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
     else()
       set(_boost_LIBRARY_SEARCH_DIRS "")
       if(BOOST_LIBRARYDIR)


What I'm wondering is, whether or not Boost_LIBRARY_DIR should be a path on the target or on the host?

Right now, the workaround I have that doesn't require to modify FindBoost.cmake
is to set Boost_LIBRARY_DIR to /lib/, which will be expanded against the CMAKE_FIND_ROOT_PATH.

By the way, I'm a happy CMake user, thanks for all the work!
Guillaume

From chuck.atkins at kitware.com  Wed Oct 15 10:40:42 2014
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Wed, 15 Oct 2014 10:40:42 -0400
Subject: [cmake-developers] FindBoost.cmake cannot find some libraries
 when cross-compiling
In-Reply-To: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan>
References: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan>
Message-ID: 

Can you post your toolchain file as well?  Does it set any of the
CMAKE_FIND_ROOT_PATHG_MODE_{INCLUDE,PROGRAM,LIBRARY,PACKAGE} variables to
anything?

- Chuck

On Wed, Oct 15, 2014 at 10:04 AM, Guillaume Papin <
guillaume.papin at parrot.com> wrote:

> Hello CMake developers,
>
> I have a cross-compiled version of Boost and some other libraries under
> ~/my-project/CrossThirdPartyPrefix.
>
> I invoke CMake with a CMAKE_TOOLCHAIN_FILE and also I sets
> CMAKE_FIND_ROOT_PATH
> to the directory where my cross-compiled Boost is installed.
>
>     cmake
> -DCMAKE_TOOLCHAIN_FILE=$HOME/my-project/plateforms/arm-toolchain.cmake \
>         -DCMAKE_FIND_ROOT_PATH=$HOME/my-project/CrossThirdPartyPrefix \
>         ~/my-projects/src/
>
> But I have an error when using FindBoost.cmake:
>
> In my project's CMakeLists.txt:
>     find_package(Boost 1.53.0 REQUIRED COMPONENTS atomic thread system)
>
> The error:
>      CMake Error at .../share/cmake-3.0/Modules/FindBoost.cmake:1179
> (message):
>        Unable to find the requested Boost libraries.
>
>        Boost version: 1.55.0
>
>        Boost include path:
>        ~/myproject/CrossThirdPartyPrefix/include
>
>
>        Could not find the following Boost libraries:
>
>                boost_thread
>                boost_system
>
>        Some (but not all) of the required Boost libraries were found.  You
> may
>        need to install these additional Boost libraries.  Alternatively,
> set
>        BOOST_LIBRARYDIR to the directory containing Boost libraries or
> BOOST_ROOT
>        to the location of Boost.
>
>
> So the first component library (atomic) is found but not the other ones.
>
> Looking at the code, when the first library is found, Boost_LIBRARY_DIR is
> set
> to the directory that contains the library and then change the further
> calls of
> find_library to use Boost_LIBRARY_DIR as the unique HINTS, and with the
> NO_DEFAULT_PATH options set.
>
>     macro(_Boost_FIND_LIBRARY var)
>       find_library(${var} ${ARGN})
>
>       if(${var})
>         # If this is the first library found then save Boost_LIBRARY_DIR.
>         if(NOT Boost_LIBRARY_DIR)
>           get_filename_component(_dir "${${var}}" PATH)
>           set(Boost_LIBRARY_DIR "${_dir}" CACHE PATH "Boost library
> directory" FORCE)
>         endif()
>       elseif(_Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT)
>         # Try component-specific hints but do not save Boost_LIBRARY_DIR.
>         find_library(${var} HINTS
> ${_Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT} ${ARGN})
>       endif()
>
>       # If Boost_LIBRARY_DIR is known then search only there.
>       if(Boost_LIBRARY_DIR)
>         set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR}
> NO_DEFAULT_PATH)
>       endif()
>     endmacro()
>
> *
> https://github.com/Kitware/CMake/blob/1b3495d32e1523648da08e138482a654f8765333/Modules/FindBoost.cmake#L322-L325
>
> The issue is that, when using CMAKE_FIND_ROOT_PATH, the Boost_LIBRARY_DIR
> of the
> host (~/myproject/CrossThirdPartyPrefix/lib/ in my case), will be expanded
> against the root paths.
>
> To find my libraries I can apply the following fix but I'm not sure if
> it's the
> right solution or not.
>
>     diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
>     index 3642b3e..aad6575 100644
>     --- a/Modules/FindBoost.cmake
>     +++ b/Modules/FindBoost.cmake
>     @@ -321,7 +321,7 @@ macro(_Boost_FIND_LIBRARY var)
>
>        # If Boost_LIBRARY_DIR is known then search only there.
>        if(Boost_LIBRARY_DIR)
>     -    set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR}
> NO_DEFAULT_PATH)
>     +    set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR}
> NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
>        endif()
>      endmacro()
>
>     @@ -855,7 +855,7 @@ if(_Boost_CHANGE_LIBDIR AND NOT
> _Boost_LIBRARY_DIR_CHANGED)
>      endif()
>
>      if(Boost_LIBRARY_DIR)
>     -  set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
>     +  set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH
> NO_CMAKE_FIND_ROOT_PATH)
>      else()
>        set(_boost_LIBRARY_SEARCH_DIRS "")
>        if(BOOST_LIBRARYDIR)
>
>
> What I'm wondering is, whether or not Boost_LIBRARY_DIR should be a path
> on the target or on the host?
>
> Right now, the workaround I have that doesn't require to modify
> FindBoost.cmake
> is to set Boost_LIBRARY_DIR to /lib/, which will be expanded against the
> CMAKE_FIND_ROOT_PATH.
>
> By the way, I'm a happy CMake user, thanks for all the work!
> Guillaume
> --
>
> 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 guillaume.papin at parrot.com  Wed Oct 15 10:57:29 2014
From: guillaume.papin at parrot.com (Guillaume Papin)
Date: Wed, 15 Oct 2014 14:57:29 +0000
Subject: [cmake-developers] FindBoost.cmake cannot find some libraries
 when cross-compiling
In-Reply-To: 
References: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan>,
 
Message-ID: <4037EE152A73A9448DAD73C415D4D8C0873819@MBX79.aswsp.lan>

Yes I'm setting these variables.

See my toolchain configuration below:

cmake_minimum_required(VERSION 3.0) # CMAKE_SYSROOT

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR armv7l)

set(LINARO_PACKAGE_ROOT /opt/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/)
set(CMAKE_SYSROOT /home/user/my-project/my-custom-sysroot/)

set(ONLY_CMAKE_FIND_ROOT_PATH TRUE)
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)

set(CMAKE_C_COMPILER ${LINARO_PACKAGE_ROOT}/bin/arm-linux-gnueabihf-gcc)
set(CMAKE_CXX_COMPILER ${LINARO_PACKAGE_ROOT}/bin/arm-linux-gnueabihf-g++)

set(TOOLCHAIN_COMPILE_FLAGS
  "-mtune=cortex-a15 -march=armv7-a -mthumb -mfloat-abi=hard -mfpu=neon-vfpv4")

set(CMAKE_C_FLAGS "${TOOLCHAIN_COMPILE_FLAGS}" CACHE STRING
  "Flags used by the compiler during all build types." FORCE)
set(CMAKE_CXX_FLAGS "${TOOLCHAIN_COMPILE_FLAGS} -std=c++11" CACHE STRING
  "Flags used by the compiler during all build types." FORCE)
- Guillaume

________________________________
From: Chuck Atkins [chuck.atkins at kitware.com]
Sent: 15 October 2014 16:40
To: Guillaume Papin
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] FindBoost.cmake cannot find some libraries when cross-compiling

Can you post your toolchain file as well?  Does it set any of the CMAKE_FIND_ROOT_PATHG_MODE_{INCLUDE,PROGRAM,LIBRARY,PACKAGE} variables to anything?

- Chuck

On Wed, Oct 15, 2014 at 10:04 AM, Guillaume Papin > wrote:
Hello CMake developers,

I have a cross-compiled version of Boost and some other libraries under ~/my-project/CrossThirdPartyPrefix.

I invoke CMake with a CMAKE_TOOLCHAIN_FILE and also I sets CMAKE_FIND_ROOT_PATH
to the directory where my cross-compiled Boost is installed.

    cmake -DCMAKE_TOOLCHAIN_FILE=$HOME/my-project/plateforms/arm-toolchain.cmake \
        -DCMAKE_FIND_ROOT_PATH=$HOME/my-project/CrossThirdPartyPrefix \
        ~/my-projects/src/

But I have an error when using FindBoost.cmake:

In my project's CMakeLists.txt:
    find_package(Boost 1.53.0 REQUIRED COMPONENTS atomic thread system)

The error:
     CMake Error at .../share/cmake-3.0/Modules/FindBoost.cmake:1179 (message):
       Unable to find the requested Boost libraries.

       Boost version: 1.55.0

       Boost include path:
       ~/myproject/CrossThirdPartyPrefix/include


       Could not find the following Boost libraries:

               boost_thread
               boost_system

       Some (but not all) of the required Boost libraries were found.  You may
       need to install these additional Boost libraries.  Alternatively, set
       BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT
       to the location of Boost.


So the first component library (atomic) is found but not the other ones.

Looking at the code, when the first library is found, Boost_LIBRARY_DIR is set
to the directory that contains the library and then change the further calls of
find_library to use Boost_LIBRARY_DIR as the unique HINTS, and with the
NO_DEFAULT_PATH options set.

    macro(_Boost_FIND_LIBRARY var)
      find_library(${var} ${ARGN})

      if(${var})
        # If this is the first library found then save Boost_LIBRARY_DIR.
        if(NOT Boost_LIBRARY_DIR)
          get_filename_component(_dir "${${var}}" PATH)
          set(Boost_LIBRARY_DIR "${_dir}" CACHE PATH "Boost library directory" FORCE)
        endif()
      elseif(_Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT)
        # Try component-specific hints but do not save Boost_LIBRARY_DIR.
        find_library(${var} HINTS ${_Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT} ${ARGN})
      endif()

      # If Boost_LIBRARY_DIR is known then search only there.
      if(Boost_LIBRARY_DIR)
        set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
      endif()
    endmacro()

* https://github.com/Kitware/CMake/blob/1b3495d32e1523648da08e138482a654f8765333/Modules/FindBoost.cmake#L322-L325

The issue is that, when using CMAKE_FIND_ROOT_PATH, the Boost_LIBRARY_DIR of the
host (~/myproject/CrossThirdPartyPrefix/lib/ in my case), will be expanded against the root paths.

To find my libraries I can apply the following fix but I'm not sure if it's the
right solution or not.

    diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
    index 3642b3e..aad6575 100644
    --- a/Modules/FindBoost.cmake
    +++ b/Modules/FindBoost.cmake
    @@ -321,7 +321,7 @@ macro(_Boost_FIND_LIBRARY var)

       # If Boost_LIBRARY_DIR is known then search only there.
       if(Boost_LIBRARY_DIR)
    -    set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
    +    set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
       endif()
     endmacro()

    @@ -855,7 +855,7 @@ if(_Boost_CHANGE_LIBDIR AND NOT _Boost_LIBRARY_DIR_CHANGED)
     endif()

     if(Boost_LIBRARY_DIR)
    -  set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
    +  set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
     else()
       set(_boost_LIBRARY_SEARCH_DIRS "")
       if(BOOST_LIBRARYDIR)


What I'm wondering is, whether or not Boost_LIBRARY_DIR should be a path on the target or on the host?

Right now, the workaround I have that doesn't require to modify FindBoost.cmake
is to set Boost_LIBRARY_DIR to /lib/, which will be expanded against the CMAKE_FIND_ROOT_PATH.

By the way, I'm a happy CMake user, thanks for all the work!
Guillaume
--

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 mantis at public.kitware.com  Thu Oct 16 06:14:38 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 16 Oct 2014 06:14:38 -0400
Subject: [cmake-developers] [CMake 0015208]: set_source_files_properties and
	extensions
Message-ID: <869b23f4532f195b53dc3459ea5dd64d@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15208 
====================================================================== 
Reported By:                Antoine Bussy
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15208
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-16 06:14 EDT
Last Modified:              2014-10-16 06:14 EDT
====================================================================== 
Summary:                    set_source_files_properties and extensions
Description: 
Setting a property of source file "test.c" also sets the property of the source
file named "test".

Reproduced with properties HEADER_FILE_ONLY and GENERATED.

Same problem is seen with .cpp extension but not .txt

I have attached a minimal example that reproduces the problem.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-16 06:14 Antoine Bussy  New Issue                                    
2014-10-16 06:14 Antoine Bussy  File Added: CMakeLists.txt                    
======================================================================


From mantis at public.kitware.com  Thu Oct 16 09:10:29 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 16 Oct 2014 09:10:29 -0400
Subject: [cmake-developers] [CMake 0015209]: RPM generation chokes on
	directory symlinks with latest rpmbuild
Message-ID: 


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15209 
====================================================================== 
Reported By:                Luc J. Bourhis
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15209
Category:                   CPack
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-16 09:10 EDT
Last Modified:              2014-10-16 09:10 EDT
====================================================================== 
Summary:                    RPM generation chokes on directory symlinks with
latest rpmbuild
Description: 
As stated here (https://bugzilla.redhat.com/show_bug.cgi?id=1005529), the
following specs file is no more legal as of rpmbuild 4.11

%files
%dir xxx
yyy/

when xxx or yyy are directory symlinks instead of proper directories.
Unfortunately CPack has not been taught that and it generates %dir xxx for a
directory symlink xxx.

Steps to Reproduce: 
Using the CMakeLists.txt attached to this bug report, issue "make package", on a
Linux machine with rpmbuild 4.11 (I tested with Fedora 20). You should get the
following error message:

error: Not a directory:
/home/luc/Developer/sandbox/build/_CPack_Packages/Linux/RPM/it-will-fail-0.1.1-Linux/usr/usr/share/test/project/subdir
    Not a directory:
/home/luc/Developer/sandbox/build/_CPack_Packages/Linux/RPM/it-will-fail-0.1.1-Linux/usr/usr/share/test/project/subdir

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-16 09:10 Luc J. Bourhis New Issue                                    
2014-10-16 09:10 Luc J. Bourhis File Added: CMakeLists.txt                    
======================================================================


From brad.king at kitware.com  Thu Oct 16 10:28:26 2014
From: brad.king at kitware.com (Brad King)
Date: Thu, 16 Oct 2014 10:28:26 -0400
Subject: [cmake-developers] Introduction and volunteering for the Matlab
 package
In-Reply-To: 
References: 
Message-ID: <543FD60A.5060508@kitware.com>

On 10/13/2014 02:23 PM, Raffi Enficiaud wrote:
> I had a hard time making some stuff compile again with Matlab under Linux.
> The fact is that Matlab is shipped with its own version of libC, libhdf5,
> libboost etc, and sometimes the filenames are the same (eg. hdf5, or libc)
> but the subminor versions are not. If I understand properly, the fact that
> the filenames are the same prevents the dynamic loader of Linux to load the
> files that are referred by the mex file in their respective rpath (there
> is only one libhdf51.8.2.so in the matlab process).

It's the SONAME that matters for the dynamic loader to find the libraries
at runtime.  It is a string copied into the dependents and used by the
dynamic loader to find the matching file at runtime.

> Beside that, the
> symbols also may clash: I had an implementation with a dynamic loader under
> linux, but yet the boost symbols of my mex files were not loaded because
> same symbols were already there in the process.
> I found a technical solution to this on Linux:
> - the use of -Wl,--exclude-libs,ALL for the linker.

According to "man ld" that option is only available on specific systems
(i386 PE).  As you pointed out it is not available on OS X.

I think the only reliable way to do this is to make sure your plugins
are built against the same libraries as Matlab, or to mangle the
symbols in your dependencies so they don't conflict with Matlab.

This is outside the scope of what I think the FindMatlab module can
achieve, so it will have to be left to the application author.
For now please leave out the REDUCE_VISIBILITY option.  I think
functionality like that, if provided by CMake, should be a more
general feature not specific to FindMatlab.

> I am using this FindMatlab in two projects now, under OSX 10.9,
> Win7 Visual2013 and Ubuntu12.04.

Great.  In order to keep the module working, we will also need tests
for it.  Please look at adding to the Tests/ directory a case for
using this module.  The test case can be something we enable with
some explicit option.  Then you can run a nightly build of CMake on
a machine of each platform with Matlab installed and enable the test.
Ideally you would have one for Windows, OS X, and Linux, at least.
Without regular testing the functionality is bound to regress as
changes are made to CMake.

Thanks,
-Brad

From brad.king at kitware.com  Thu Oct 16 10:29:30 2014
From: brad.king at kitware.com (Brad King)
Date: Thu, 16 Oct 2014 10:29:30 -0400
Subject: [cmake-developers] Support of codesign
In-Reply-To: <2614570.QAlDDbOxL6@stryke>
References: 
 
 
 <2614570.QAlDDbOxL6@stryke>
Message-ID: <543FD64A.1040907@kitware.com>

Andr?,

Please respond with comments or an updated patch to address Clinton's
review comments in order to help this contribution proceed.

On 09/26/2014 10:08 AM, clinton at elemtech.com wrote:
> I would suggest the SignPackage function be moved from
> cmCPackDragNDropGenerator to cmCPackBundleGenerator because
> its implementation is only usable by cmCPackBundleGenerator.
> It uses CPACK_BUNDLE_NAME which is only valid in the context
> of cmCPackBundleGenerator.

On 09/29/2014 09:55 AM, clinton at elemtech.com wrote:
> Because it appears to only work with the Bundle generator, can
> you please move the documentation from Modules/CPackDMG.cmake
> to Modules/CPackBundle.cmake?
> Or did you intend to make this feature work for both the
> DragNDrop and Bundle generator?

On 09/29/2014 02:00 PM, Clinton Stimpson wrote:
> I think application signing is generally not a CPack thing, but
> there probably isn't much of a choice if the Bundle generator
> is used.

Thanks,
-Brad

From chuck.atkins at kitware.com  Thu Oct 16 10:32:33 2014
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Thu, 16 Oct 2014 10:32:33 -0400
Subject: [cmake-developers] FindBoost.cmake cannot find some libraries
 when cross-compiling
In-Reply-To: <4037EE152A73A9448DAD73C415D4D8C0873819@MBX79.aswsp.lan>
References: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan>
 
 <4037EE152A73A9448DAD73C415D4D8C0873819@MBX79.aswsp.lan>
Message-ID: 

This looks like a reasonable way to accomplish this right now.  The
underlying prioblem is that ther's no way to specify which path types get
re-rooted and which don't.  Ideally you'd want to be able to specify in the
toolchain for something like this that all paths operate in "ONLY" mode
except HINTS, which you would want to place in NEVER mode.  I'm currently
working on just such a feature but in the meantime, forcing it like this in
the FindBoost module looks reasonable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From chuck.atkins at kitware.com  Thu Oct 16 11:09:14 2014
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Thu, 16 Oct 2014 11:09:14 -0400
Subject: [cmake-developers] FindBoost.cmake cannot find some libraries
 when cross-compiling
In-Reply-To: 
References: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan>
 
 <4037EE152A73A9448DAD73C415D4D8C0873819@MBX79.aswsp.lan>
 
Message-ID: 

Guillaume,

Please see CONTRIBUTING.rst in the top level of the CMake source tree.  If
you can please create and post a patch against cmake master then I'll work
on getting it merged into cmake next.  Thanks for the bug fix!

- Chuck

On Thu, Oct 16, 2014 at 10:32 AM, Chuck Atkins 
wrote:

> This looks like a reasonable way to accomplish this right now.  The
> underlying prioblem is that ther's no way to specify which path types get
> re-rooted and which don't.  Ideally you'd want to be able to specify in the
> toolchain for something like this that all paths operate in "ONLY" mode
> except HINTS, which you would want to place in NEVER mode.  I'm currently
> working on just such a feature but in the meantime, forcing it like this in
> the FindBoost module looks reasonable.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From brad.king at kitware.com  Thu Oct 16 11:19:36 2014
From: brad.king at kitware.com (Brad King)
Date: Thu, 16 Oct 2014 11:19:36 -0400
Subject: [cmake-developers] Refactoring search path construction
In-Reply-To: 
References: 
Message-ID: <543FE208.50200@kitware.com>

On 10/09/2014 02:45 PM, Chuck Atkins wrote:
> I've just pushed a branch to the stage for review:
> refactor-search-path-construction

Thanks.

In cmSearchPath.cxx, please include cmSearchPath.h first.
In cmSearchPath.h, please include cmStandardIncludes.h first.
Otherwise some standard library headers may not be preprocessed
consistently across translation units, which causes trouble on
some platforms (LFS support on AIX for example).

After that please merge to 'next' for testing when ready.

Thanks,
-Brad


From daniele.domenichelli at gmail.com  Thu Oct 16 11:26:10 2014
From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli)
Date: Thu, 16 Oct 2014 17:26:10 +0200
Subject: [cmake-developers] ExternalProject CMAKE_ARGS and CMAKE_CACHE_ARGS
	arguments
Message-ID: <543FE392.7020706@gmail.com>

Hello all,


I have question about CMAKE_ARGS and CMAKE_CACHE_ARGS, and I'm not sure
if this is the intended behaviour or not...


>From the documentation:

  #    [CMAKE_ARGS args...]        # Arguments to CMake command line
  #    [CMAKE_CACHE_ARGS args...]  # Initial cache arguments, of the form -Dvar:string=on

So, from what I understand, The first arguments are passed to the cmake
command line, and from the second it is created a a cache file that is
passed to cmake using -C. If the same variable is in both, CMAKE_ARGS
wins over CMAKE_CACHE_ARGS.

>From the documentation, I was expecting that the CMAKE_CACHE_ARGS would
be used only to create the initial cache, and that the user could go to
the build directory and change it, but the cache file passes the FORCE
argument to the set commands (lines 910 and 930).

  set(setArg "${setArg}${accumulator}\" CACHE ${type} \"Initial cache\" FORCE)")

This makes impossible to change a value later, and in my opinion makes
one of the 2 arguments redundant, since the final effect of the 2
variables is exactly the same.

So, is this the intended behaviour? The FORCE argument allows one to
change CMAKE_CACHE_ARGS and have the cache updated, but that's exactly
what CMAKE_ARGS does.
I don't know exactly how the -C flag works, but I was thinking that if
the FORCE argument is dropped, the 2 arguments could be used with
different purposes: CMAKE_ARGS is always enforced, CMAKE_CACHE_ARGS
could be modified by the user later. Would it work and does this make
sense for you?


Cheers,
 Daniele

From tobias.hunger at gmail.com  Fri Oct 17 06:44:03 2014
From: tobias.hunger at gmail.com (Tobias Hunger)
Date: Fri, 17 Oct 2014 12:44:03 +0200
Subject: [cmake-developers] Extracting target metadata, IDE integration
In-Reply-To: 
References: 
 
Message-ID: 

Sorry, I am a bit late with replying to this... I do not follow this
list too closely and got distracted by mails in between where I could
not contribute anything:-/

On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly  wrote:
>> The first is should this be run in a terminal or is this a GUI. Not
>> sure whether cmake has that information.
>
> CMake only knows whether the WIN32_EXECUTABLE property has been set on a
> target.
>
>  http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html
>
> The property is harmless on non-Windows, so KDE sets it on non-Windows for
> gui applications IIRC, but others may not.

This is a hint only.

If it works correctly it is nice, otherwise the user will have to
toggle some checkbox
to change it to his or her liking.

>> Secondly the linker flags would be nice to know. That way the
>> LD_LIBRARY_PATH can be set correctly by the IDE so that all the
>> libraries are found.
>
> If the linker flags were provided, you would have to parse them. Maybe a
> runtimeLinkDirectories/linkDependentLibraries can be provided, similar to
> the content passed to the option -rpath. I have no idea if similar
> information can be acquired for MSVC/Windows. As Nils said, CMake might not
> know the location of the import library.

If CMake knows the locations, then put them in, please.

If not then there is little you can do, is there?

>> Combined with CMAKE_EXPORT_COMPILE_COMMANDS this should allow for a
>> pretty good integration into creator. Ideally the exported compile
>> commands would be a bit more aggregated along the lines of "the
>> following list of files will be build using these defines/include
>> paths/flags", just because that would be way shorter and most likely
>> faster to parse.
>
> What would that looks like? I guess listing the sources in a target together
> with its includes/defines should be possible, together with extra per-source
> defines, if present?
>
> [
>   "name" : "testc1"
>   "sources" : ["foo.cpp", "bar.cpp"]
>   "defines" : ["BUILD_TEST=1", "QT_CORE_LIB"]
>   "includes" : ["/opt/bat/include", "/usr/include/qt5"]
>   "extraDefines" : {
>     "foo.cpp" : ["EXTRA_FOO=1"]
>   }
> ]

I was thinking more along the lines of a somewhat aggregated
CMAKE_EXPORT_COMPILE_COMMANDS, but this is even better:-)

But why not have groups of sources?

[
  "name": "testc1"
  "sourceGroups" [
     {
         "sources": [ "foo.cpp" ],
         "defines": ["BUILD_TEST=1", "QT_CORE_LIB", "EXTRA_FOO=1"],
         "includes": ["/opt/bat/include", "/usr/include/qt5"]
     },
     {
         "sources": [ "bar.cpp" ],
         "defines": ["BUILD_TEST=1", "QT_CORE_LIB"],
         "includes": ["/opt/bat/include", "/usr/include/qt5"]
     }
  ]
]

Would be simpler to parse for us.

>> With this target description and the compile commands there is just
>> one piece of the puzzle missing for a great Qt Creator integration: We
>> need to generate a list of files that are part of the project. I
>> currently do not know how to extract that list from cmake. This list
>> must include all the header files that belong to the project, which is
>> what makes this hard to get this information from cmake -- at least at
>> the time I stopped working with cmake.
>
> Afaik, CMake does not know all the files included by your cpp files.
> However, some buildsystems can add them to the list of sources if desired
> for better IDE integration.
>
>  https://gitorious.org/grantlee/grantlee/commit/3eb40cf94

That is the big issue I have with CMake... it makes it impossible to use
CMakeLists.txt as a sole source of project configuration.

Creator tries to not need any extra files to manage the project, so this
hits us pretty hard.

>> Ideally we could get the list of files that belong to the project in
>> general and the files that are actually part of the currently
>> configured built.
>
> In CMake master at least, the user can list config-specific files
> declaratively. Eg, add the foo_debug.cpp file only in the debug
> configuration:
>
>  add_library(foo
>    foo.cpp
>    $<$:foo_debug.cpp>
>  )
>
>> But how can I know that "something_win.h" will not be used when
>> building on my Linux box?
>
> The current style is indeed difficult to parse, where that might be inside
> an if() inside a macro etc. Again though, CMake master will allow users to
> do better:
>
>  add_library(foo
>    foo.cpp
>    $<$:foo_win.cpp>
>  )
>
> I wonder how those kinds of conditions would need to be represented in the
> ProjectTargets.json file.

This is actually a bit too detailed for my needs:-)

I want to know which files are part of the project and which are part
of the current build.

At least Qt Creator does not need information on which conditions to
be met for a file to become part of the current build.

> One option would be to write them directly to the
> json, instead of, for example, creating individual lists for each
> configuration, and expecting the consumer to evaluate the expressions. A
> possible problem with that is that consumers would have to transitively
> evaluate each property over the link closure. Apart from the potential for
> bugs, that would mean there would need to be a target entry for each
> IMPORTED target too.
>
> It would probably be easier to try to generate something like
>
>  "defines" : {
>    "noconfig" : ["FOO=1", "QT_CORE_LIB"]
>    "debug" :  ["QT_DEBUG"]
>    "release" : ["RELEASE_MODE=1"]
>   }
>
> from
>
>  target_compile_definitions(foo PRIVATE
>    FOO=1
>    $<$:RELEASE_MODE=1>
>  )
>  target_link_libraries(foo PRIVATE
>    Qt5::Core # Uses the Qt defines in the foo target.
>  )

Creator at least will not need that. We need the set of
defines/includes for the current build configuration, but not any
extra information on flags that could potentially become relevant in
other configurations.

> But that will mean adding more complexity to generator expression evaluation
> to find out which condition groups are needed (Eg, Do I need to create per-
> platform/per-config/per-compiler groups?).
>
> So, we'd have to decide how much exactness to aim for, and how much
> complexity to push to the user.
>
> Thanks,
>
> Steve.

Best Regards,
Tobias

From brad.king at kitware.com  Fri Oct 17 08:57:18 2014
From: brad.king at kitware.com (Brad King)
Date: Fri, 17 Oct 2014 08:57:18 -0400
Subject: [cmake-developers] Extracting target metadata, IDE integration
In-Reply-To: 
References: 
 
 
Message-ID: <5441122E.5020509@kitware.com>

On 10/17/2014 06:44 AM, Tobias Hunger wrote:
> On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly  wrote:
>> Afaik, CMake does not know all the files included by your cpp files.
>> However, some buildsystems can add them to the list of sources if desired
>> for better IDE integration.
>>
>>  https://gitorious.org/grantlee/grantlee/commit/3eb40cf94
> 
> That is the big issue I have with CMake... it makes it impossible to use
> CMakeLists.txt as a sole source of project configuration.
> 
> Creator tries to not need any extra files to manage the project, so this
> hits us pretty hard.

We've discussed this in the past a few times.  One solution is for
the project spec to be in a declarative format, e.g. a JSON document.
The spec would not be in a CMakeLists.txt but could be loaded by a
command invoked from it.  Then it could also be loaded and manipulated
separately by IDEs or other tools.

So, rather than having CMake generate a project spec file from the
CMakeLists.txt files, we have CMakeLists.txt files load a project
spec file.  The declarative information goes in the project spec file,
and imperative things like try_compile can be done in the CMake config
step.  The imperative step also loads the project spec and evaluates
the declarations based on discovered information about the target
platform.

Other than this basic design, no one has taken the time to design such
a format.

-Brad


From mantis at public.kitware.com  Fri Oct 17 13:36:08 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Fri, 17 Oct 2014 13:36:08 -0400
Subject: [cmake-developers] [CMake 0015210]: CMakeFindBinUtils.cmake not
	re-run when cache is deleted
Message-ID: <498d475e6b43044bb072ce0f532ccb7a@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15210 
====================================================================== 
Reported By:                Clinton Stimpson
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15210
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-17 13:36 EDT
Last Modified:              2014-10-17 13:36 EDT
====================================================================== 
Summary:                    CMakeFindBinUtils.cmake not re-run when cache is
deleted
Description: 
If I run cmake to create a build tree, then delete the CMakeCache.txt file and
re-run cmake, the cache variables from CMakeFindBinUtils.cmake are not restored.

Modules/Platform/Darwin.cmake and Modules/Platform/Windows-MSVC.cmake both
contain hacks to restore some cache variables.

In my case, a missing CMAKE_STRIP prompted this bug report because it was
possible to create packages containing debug symbols.

Steps to Reproduce: 

With /CMake and /build:

cmake ../CMake
mv CMakeCache.txt CMakeCache.txt.bak
rm CMakeCache.txt
cmake ../CMake

diff -u CMakeCache.txt.bak CMakeCache.txt
to see all of the missing variables.

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-17 13:36 Clinton StimpsonNew Issue                                    
======================================================================


From fabianjul at gmail.com  Fri Oct 17 16:16:07 2014
From: fabianjul at gmail.com (Fabian)
Date: Fri, 17 Oct 2014 22:16:07 +0200
Subject: [cmake-developers] Xcode Project: Support for DevelopmentTeam
Message-ID: 

Somewhere starting in Xcode 4 or 5, Apple added a Team dropdown to the
General tab of a target. The developer can select a development team there,
which results in a bunch of useful things, most importantly: Xcode
automatically updates the devices list in the Member Center and the
currently fitting iOS Team Provisioning Profile. This creatly simplyfies
management of development devices.

It would be very nice if CMake supported setting this option. A look at the
project.pbxproj reveals that this setting is stored in the 'attributes' in
the PBXProject section:

3B69B74659794A7B9F0C2B71 /* Project object */ = {
    isa = PBXProject;
    attributes = {
        BuildIndependentTargetsInParallel = YES;
        TargetAttributes = {
            26E66AE0CD2341D58DBF6E8B = {
                DevelopmentTeam = <10 character Team ID>;
            };
        };
    };
    ....

In the CMake source I noticed that 'BuildIndependentTargetsInParallel' is
already getting set. This could be extendet to add the 'TargetAttributes'
section. Note that the ID used in there (26E66AE0CD2341D58DBF6E8B in the
example) is the ID of the 'main' target, i.e. the one with the name of the
project.

The 10 character Team ID can be found by the developer in the member center
under Your Account. This could be set with a CMake flag.

Thanks,
Fabian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From domen.vrankar at gmail.com  Sat Oct 18 16:36:47 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Sat, 18 Oct 2014 22:36:47 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

> I also have a question. Would CPack also need something like
>> CPACK_COMPONENT__PACKAGE_SUMMARY that could be used by
>> CPACK_RPM__PACKAGE_SUMMARY as default value?
>>
>
>
> Not sure of that one.
> We already have "CPACK_COMPONENT_GROUP_CMAKE_DESCRIPTION"
> which may be a default value for "CPACK_RPM__PACKAGE_
> SUMMARY" if packaging is done "by compoent group" (which is the default):
>
> The behavior of the various CPack generator w.r.t. mono- or multi-
> file/package generation vary,
> see:
>
> http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior
>
>
I did not find CPACK_COMPONENT_GROUP__DESCRIPTION in
documentation but from the examples that I've found googling I think that
this would be a better option for CPACK_RPM__PACKAGE_DESCRIPTION
than CPACK_RPM__PACKAGE_SUMMARY. Since the patch supports all
the options that I've found in the documentation I guess that there are
enough fallback options covered.

I also wrote a test and noticed two things:
1) CPackComponentsForAll test is using component names in lower case and
 parts in variables in upper case (e.g. COMPONENT headers and
CPACK_COMPONENT_HEADERS_DESCRIPTION). Patch uses
CPACK_RPM_PACKAGE_COMPONENT variable as part of component variable name
e.g. CPACK_RPM_headers_PACKAGE_DESCRIPTION.
Because of this the fallback mechanism doesn't work correctly so is the
correct variable format CPACK_COMPONENT_headers_PACKAGE_SUMMARY, CPACK_
COMPONENT_HEADERS_PACKAGE_SUMMARY, both or case insensitive?
If case insensitive option is the correct one - how do I implement that?
Since all other RPM component variables use install( ... COMPONENT name) as
part of variable name (so in this case that means lower case) I guess that
RPM versions should stay as they are now (
CPACK_RPM_headers_PACKAGE_DESCRIPTION for the above example).

2) Package description fallback is currently written as
set(CPACK_RPM_PACKAGE_DESCRIPTION "no package description available") and
this is already in the code - not part of the patch. However if variable
CPACK_PACKAGE_DESCRIPTION_FILE is not set it points by default to
Templates/CPack.GenericDescription.txt and its content is "DESCRIPTION". So
currently the above final fallback is dead code.
Should I delete it or fix the code so that in case of default
CPACK_PACKAGE_DESCRIPTION_FILE value it ignores it and uses "no package
description available" text instead (would break the way it currently works
so I'm guessing that deleting that part of code is the preferred option)?
Can I put this change in the same patch since I am changing the fallback
mechanism in it or should this be a different patch?
If second - can I still attach the patch to the same mantis bug, do I open
a new bug report or just create a patch and post it on the mailing list?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mantis at public.kitware.com  Sat Oct 18 16:52:42 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sat, 18 Oct 2014 16:52:42 -0400
Subject: [cmake-developers] [CMake 0015211]: Faulty parsing of variables
	with multi-line content
Message-ID: <79c10ab2a551cb4c0a1aba0217c79d05@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15211 
====================================================================== 
Reported By:                Timo Korthals
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15211
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   high
Status:                     new
====================================================================== 
Date Submitted:             2014-10-18 16:52 EDT
Last Modified:              2014-10-18 16:52 EDT
====================================================================== 
Summary:                    Faulty parsing of variables with multi-line content
Description: 
cmake (above 2.8.7 up to master/head) fails to parse variables which have more
than two lines (and therefore two 'newline' character) in it. The outcome of it
is, that the project is unmakeable, because of the faulty produced makefiles.

As a minimal example I define multiple include directories in the variable
"GCC_INCLUDES" and hand it over to "include_directories", which produces the
"CXX_FLAGS" in "flags.make".
I give you first an working example with the corresponding output file, and then
an example with the faulty output:

Working "CMakeLists.txt"
-----------------------START
  cmake_minimum_required(VERSION 2.8.7 FATAL_ERROR)
  project ("helloWorld")
  set(GCC_INCLUDES "/test1\n/test2")
  include_directories(
      ${GCC_INCLUDES}
  )
  add_executable("helloWorld" main.cpp)
-----------------------END

Correct outputfile "CMakeFiles/helloWorld.dir/flags.make"
-----------------------START
# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 2.8

# compile CXX with /usr/bin/c++
CXX_FLAGS = -I/test1 -I/test2

  CXX_DEFINES = 
-----------------------END

Faulty "CMakeLists.txt"
-----------------------START
  cmake_minimum_required(VERSION 2.8.7 FATAL_ERROR)
  project ("helloWorld")
  set(GCC_INCLUDES "/test1\n/test2\n/test3")
  include_directories(
      ${GCC_INCLUDES}
  )
  add_executable("helloWorld" main.cpp)
-----------------------END

Faulty outputfile "CMakeFiles/helloWorld.dir/flags.make"
-----------------------START
# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 2.8

# compile CXX with /usr/bin/c++
CXX_FLAGS = -I/test1 -I/test2
/test3 -I/test3   

CXX_DEFINES = 
-----------------------END

Steps to Reproduce: 
Use the CMakeLists.txt files in the section "Description" and run "cmake ." to
produce the error message.

Example "main.cpp"
-----------------------START
#include 

using namespace std;

int main(void) {
 cout << "Hallo World" << endl;
 return 0;
}
-----------------------END

Additional Information: 
I tested the following cmake versions

OS: Ubuntu 12.04.4; cmake 2.8.7
Result: No parsing error

OS: Ubuntu 14.04.1; cmake 2.8.7
Result: No parsing error

OS: Ubuntu 14.04.1; cmake 2.12.2
Result: ERROR

OS: Ubuntu 14.04.1; cmake master/head (commit
d4525d7288ef935ee8b9d8cf338763498850364f)
Result: ERROR
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-18 16:52 Timo Korthals  New Issue                                    
======================================================================


From micha.hergarden at gmail.com  Sun Oct 19 07:28:14 2014
From: micha.hergarden at gmail.com (Micha Hergarden)
Date: Sun, 19 Oct 2014 13:28:14 +0200
Subject: [cmake-developers] [PATCH] Preinstall requirements support for
 CPack RPM generator
In-Reply-To: 
References: 
 <543695B3.5010201@kitware.com>
 
Message-ID: <5443A04E.7030806@gmail.com>

On 10/09/2014 07:30 PM, Evgeny Kalishenko wrote:
> Ok, thanks for the advise about STREQUAL. Explanation of s/_/(/ (from
> http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html):
> "Recent versions of RPM support context marked dependencies. This is a
> special type of a dependency that applies only in a specified
> /context/. Using this feature, one can specify dependencies for pre-
> and post(un)install scriptlets, ie. the context of a dependency is the
> execution time of the specified scriptlet.
>
> The syntax for specifying these dependencies is:
>
> Requires(/X/): foo
>               
>
> Here, /X/ can be one of *pre*, *post*, *preun*, or *postun*, which
> tells RPM that the package depends on package foo for running the
> corresponding *%pre*, *%post*, *%preun*, or *%postun* script."
>
> Modified patch attached.
>
>
> 2014-10-09 18:03 GMT+04:00 Brad King  >:
>
>     On 10/08/2014 01:48 PM, Evgeny Kalishenko wrote:
>     > I was interested in feature request
>     > http://public.kitware.com/Bug/view.php?id=14769 and made a
>     > simple patch for CPack RPM generator (attached).
>
>     Thanks.
>
>     In this hunk:
>
>     > +    # The following keywords require braces around the "pre" or
>     "post" suffix in the final RPM spec file.
>     > +    if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE"  OR 
>     "${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST")
>     > +      string(REPLACE "_" "(" _PACKAGE_HEADER_NAME
>     "${_PACKAGE_HEADER_NAME}")
>     > +      set(_PACKAGE_HEADER_NAME "${_PACKAGE_HEADER_NAME})")
>     > +    endif()
>
>     The MATCHES conditions can use simply STREQUAL instead.
>     I'm not very familiar with the spec format, so please
>     explain the purpose of the s/_/(/ subsitution in comments
>     here.
>
>     Thanks,
>     -Brad
>
>
>
>
> -- 
> ? ?????????,
> ??????? ?????????
>
>
In this hunk:
+#  May be used to set RPM postinstall dependencies (requires(post)). 
Note that you must enclose
+#  the complete requires string between quotes, for example::
+#
+#   set(CPACK_RPM_PACKAGE_REQUIRES_PRE "shadow-utils, initscripts")
+#
+#

The variable name CPACK_RPM_PACKAGE_REQUIRES_PRE should be
CPACK_RPM_PACKAGE_REQUIRES_POST.

In this hunk:
+    # The following keywords require braces around the "pre" or "post"
suffix in the final RPM spec file.
+    if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE"  OR 
"${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST")
+      string(REPLACE "_" "(" _PACKAGE_HEADER_NAME
"${_PACKAGE_HEADER_NAME}")
+      set(_PACKAGE_HEADER_NAME "${_PACKAGE_HEADER_NAME})")
+    endif()

Shouldn't braces be called parentheses here ( i.e '(' versus '{' )?

I have checked with a minimal project on a ubuntu 14.04 box (using rpm
4.11.1) and the generated package seems good. So, no further comments.

With kind regards,
Micha Hergarden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: 

From steveire at gmail.com  Sun Oct 19 08:26:14 2014
From: steveire at gmail.com (Stephen Kelly)
Date: Sun, 19 Oct 2014 14:26:14 +0200
Subject: [cmake-developers] Extracting target metadata, IDE integration
References: 
 
 
Message-ID: 

Tobias Hunger wrote:

> Sorry, I am a bit late with replying to this... I do not follow this
> list too closely and got distracted by mails in between where I could
> not contribute anything:-/

No problem, thanks! I recently discovered that Creator makes fragile guesses 
about source files and targets

https://codereview.qt-project.org/#/c/96594/1/src/plugins/cmakeprojectmanager/cmakeproject.cpp,unified

so I would really like to create a solution which makes that unnecessary.

> 
> On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly
>  wrote:
>>> The first is should this be run in a terminal or is this a GUI. Not
>>> sure whether cmake has that information.
>>
>> CMake only knows whether the WIN32_EXECUTABLE property has been set on a
>> target.
>>
>>  http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html
>>
>> The property is harmless on non-Windows, so KDE sets it on non-Windows
>> for gui applications IIRC, but others may not.
> 
> This is a hint only.
> 
> If it works correctly it is nice, otherwise the user will have to
> toggle some checkbox
> to change it to his or her liking.

Yes. I suppose beyond the WIN32_EXECUTABLE/ SUBSYSTEM:console / Mac Bundle  
stuff the gui/console distinction doesn't really fit into the buildsystem. 
Maybe such a checkbox, pre-populated with the hint, is needed anyway.

> 
>>> Secondly the linker flags would be nice to know. That way the
>>> LD_LIBRARY_PATH can be set correctly by the IDE so that all the
>>> libraries are found.
>>
>> If the linker flags were provided, you would have to parse them. Maybe a
>> runtimeLinkDirectories/linkDependentLibraries can be provided, similar to
>> the content passed to the option -rpath. I have no idea if similar
>> information can be acquired for MSVC/Windows. As Nils said, CMake might
>> not know the location of the import library.
> 
> If CMake knows the locations, then put them in, please.

I'm sure that won't be a problem.

> But why not have groups of sources?
> 
> [
>   "name": "testc1"
>   "sourceGroups" [
>      {
>          "sources": [ "foo.cpp" ],
>          "defines": ["BUILD_TEST=1", "QT_CORE_LIB", "EXTRA_FOO=1"],
>          "includes": ["/opt/bat/include", "/usr/include/qt5"]
>      },
>      {
>          "sources": [ "bar.cpp" ],
>          "defines": ["BUILD_TEST=1", "QT_CORE_LIB"],
>          "includes": ["/opt/bat/include", "/usr/include/qt5"]
>      }
>   ]
> ]
> 
> Would be simpler to parse for us.

Perhaps. CMake already has a source group concept (for IDEs to group 
sources), and your concept of a source group here seems to be about grouping 
files with common includes/defines/build properties? The two concepts may be 
in conflict.

>> Afaik, CMake does not know all the files included by your cpp files.
>> However, some buildsystems can add them to the list of sources if desired
>> for better IDE integration.
>>
>>  https://gitorious.org/grantlee/grantlee/commit/3eb40cf94
> 
> That is the big issue I have with CMake... it makes it impossible to use
> CMakeLists.txt as a sole source of project configuration.

For comparison, does any other buildsystem require header listings like 
this? With qmake, I can populate HEADERS, but I don't have to (for headers 
which do not require moc).

> I want to know which files are part of the project and which are part
> of the current build.
> 
> At least Qt Creator does not need information on which conditions to
> be met for a file to become part of the current build.

Ok, good feedback, thanks.

Steve.



From konstantin at podsvirov.pro  Mon Oct 20 02:14:54 2014
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Mon, 20 Oct 2014 10:14:54 +0400
Subject: [cmake-developers] [CPackIFW] Documentation
In-Reply-To: 
References: <1233611413437212@web15h.yandex.ru> 
Message-ID: <3515101413785694@web4o.yandex.ru>

Hello dear developers!

Appeal to developers of two projects: CMake and Qt :-)

This discussion affects both communities.

CPack IFW generator generates installers with a graphical user interface using Qt Installer Framework.

The code generator already in the thread "release":

http://www.cmake.org/gitweb?p=cmake.git;a=shortlog;h=refs/heads/release

The generator is accompanied by a documentation module CPackIFW", which is included in the CMake documentation.

I want to know that this generator has followers and users.

I want documentation about this generator was in the right places.

I need feedback and suggestions for further development.

In the discussion participated Stephen Kelly. He gave some interesting links.

19.10.2014, 17:23, "Stephen Kelly" :
> Documentation generated from the master branch is updated daily here:
>
> http://www.cmake.org/cmake/help/git-master/module/CPackIFW.html
>
>>> Also, what's the time frame for CMake version 3.1.0 ? I don't want to add
>>> links to a yet unreleased feature ...
>
> The roadmap says early November:
>
> http://public.kitware.com/Bug/roadmap_page.php
>
> but it's likely to slip some weeks if past experience is a good forecast.
>
> Whatever is true about additions to the Qt documentation, the CPackIFW
> generator looks like it should get a mention in
>
> http://www.cmake.org/cmake/help/v3.0/manual/cmake-qt.7.html
>
> One option would be to add a primary prose there and link to that from
>
> http://doc-snapshot.qt-project.org/qt5-5.3/cmake-manual.html
>
> and
>
> http://qt-project.org/doc/qt-5/deployment.html
>
> The CMake documentation can be loaded in creator
>
> http://www.kdab.com/context-sensitive-cmake-documentation-qtcreator/
>
> and CMake releases will include a qch file from now on. Eg
>
> http://www.cmake.org/cmake/help/v3.1/CMake.qch
>
> Thanks,

I can't do everything myself and hope for the community :-)

All good working week.

PS: where I live the snow :-)

Regards,
Konstantin Podsvirov

From tobias.hunger at gmail.com  Mon Oct 20 06:02:05 2014
From: tobias.hunger at gmail.com (Tobias Hunger)
Date: Mon, 20 Oct 2014 12:02:05 +0200
Subject: [cmake-developers] Extracting target metadata, IDE integration
In-Reply-To: 
References: 
 
 
 
Message-ID: 

Hey Stephen,

On Sun, Oct 19, 2014 at 2:26 PM, Stephen Kelly  wrote:
> No problem, thanks! I recently discovered that Creator makes fragile guesses
> about source files and targets
>
> https://codereview.qt-project.org/#/c/96594/1/src/plugins/cmakeprojectmanager/cmakeproject.cpp,unified
>
> so I would really like to create a solution which makes that unnecessary.

I am no expert on this part of the codebase, but I would not be
surprised if it did do some stupid things when seeing cmake. We do not
support that too well.

>> On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly
>>  wrote:
>>>> The first is should this be run in a terminal or is this a GUI. Not
>>>> sure whether cmake has that information.
>>>
>>> CMake only knows whether the WIN32_EXECUTABLE property has been set on a
>>> target.
>>>
>>>  http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html
>>>
>>> The property is harmless on non-Windows, so KDE sets it on non-Windows
>>> for gui applications IIRC, but others may not.
>>
>> This is a hint only.
>>
>> If it works correctly it is nice, otherwise the user will have to
>> toggle some checkbox
>> to change it to his or her liking.
>
> Yes. I suppose beyond the WIN32_EXECUTABLE/ SUBSYSTEM:console / Mac Bundle
> stuff the gui/console distinction doesn't really fit into the buildsystem.
> Maybe such a checkbox, pre-populated with the hint, is needed anyway.

Not into a build system, but into an IDE:-)

There is a overlap in what an IDE needs to know and what a build
system then needs to generate binaries, but it both also need some
information the other does not provide.

>> But why not have groups of sources?
>>
>> [
>>   "name": "testc1"
>>   "sourceGroups" [
>>      {
>>          "sources": [ "foo.cpp" ],
>>          "defines": ["BUILD_TEST=1", "QT_CORE_LIB", "EXTRA_FOO=1"],
>>          "includes": ["/opt/bat/include", "/usr/include/qt5"]
>>      },
>>      {
>>          "sources": [ "bar.cpp" ],
>>          "defines": ["BUILD_TEST=1", "QT_CORE_LIB"],
>>          "includes": ["/opt/bat/include", "/usr/include/qt5"]
>>      }
>>   ]
>> ]
>>
>> Would be simpler to parse for us.
>
> Perhaps. CMake already has a source group concept (for IDEs to group
> sources), and your concept of a source group here seems to be about grouping
> files with common includes/defines/build properties? The two concepts may be
> in conflict.

Right, my sourceGroups are sets of sources that have the same settings
applied to them.

I was coming from the CMAKE_EXPORT_COMPILE_COMMANDS output which does
have the information we need for the code model, but in a rather
inconvenient form. Having the files with similar flags/defines/etc.
grouped would make parsing them a lot faster. Not having to parse
compiler command lines would further improve things:-) So I am all for
you adding this information into some JSON file.

I do not think there is a conflict between CMake source groups and
what I was referring to, except maybe in my poorly chosen name.

> For comparison, does any other buildsystem require header listings like
> this? With qmake, I can populate HEADERS, but I don't have to (for headers
> which do not require moc).

I am aware that listing all headers is not necessary for the build
system. It is one of those things where the needs of an IDE and those
of a build system differ.

Qmake asks for the headers to be listed. So does Qbs, which we want to
be great for IDE integration. Both will most likely not notice if you
forget some, but they won't be listed in Creator then.

Best Regards,
Tobias

From mantis at public.kitware.com  Mon Oct 20 07:57:19 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 20 Oct 2014 07:57:19 -0400
Subject: [cmake-developers] [CMake 0015212]: FILE READ skips semicolumn ;
Message-ID: 


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15212 
====================================================================== 
Reported By:                toncho11
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15212
Category:                   (No Category)
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-20 07:57 EDT
Last Modified:              2014-10-20 07:57 EDT
====================================================================== 
Summary:                    FILE READ skips semicolumn ;
Description: 
Every time I try to read a file with semicolumns, the resulted variable does not
contain it. 



Additional Information: 
It is pretty annoying when you finally find a way to do what you want and then
you encounter a bug ...
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-20 07:57 toncho11       New Issue                                    
======================================================================


From brad.king at kitware.com  Mon Oct 20 09:52:03 2014
From: brad.king at kitware.com (Brad King)
Date: Mon, 20 Oct 2014 09:52:03 -0400
Subject: [cmake-developers] ExternalProject CMAKE_ARGS and
 CMAKE_CACHE_ARGS arguments
In-Reply-To: <543FE392.7020706@gmail.com>
References: <543FE392.7020706@gmail.com>
Message-ID: <54451383.4070809@kitware.com>

On 10/16/2014 11:26 AM, Daniele E. Domenichelli wrote:
>   #    [CMAKE_ARGS args...]        # Arguments to CMake command line
>   #    [CMAKE_CACHE_ARGS args...]  # Initial cache arguments, of the form -Dvar:string=on
> 
> So, from what I understand, The first arguments are passed to the cmake
> command line, and from the second it is created a a cache file that is
> passed to cmake using -C. If the same variable is in both, CMAKE_ARGS
> wins over CMAKE_CACHE_ARGS.
[snip]
> This makes impossible to change a value later, and in my opinion makes
> one of the 2 arguments redundant, since the final effect of the 2
> variables is exactly the same.

CMAKE_CACHE_ARGS was added here:

 Added CMAKE_CACHE_ARGS to ExternalProject.
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=68cd3fe0

to overcome command line length limits.  CMAKE_ARGS can contain
arguments other than cache values.  Therefore they are not fully
redundant although there is overlap.

The name "initial cache" is poor both here and for the -C argument
to cmake because the option can be used any time.  It just happened
to originate for purposes of pre-populating some cache values on
the first run.

If you'd like, please propose clearer wording for the docs.

Thanks,
-Brad


From ydginster at gmail.com  Mon Oct 20 12:53:48 2014
From: ydginster at gmail.com (Evgeny Kalishenko)
Date: Mon, 20 Oct 2014 20:53:48 +0400
Subject: [cmake-developers] [PATCH] Preinstall requirements support for
 CPack RPM generator
In-Reply-To: <5443A04E.7030806@gmail.com>
References: 
 <543695B3.5010201@kitware.com>
 
 <5443A04E.7030806@gmail.com>
Message-ID: 

The final patch version with erroneous spelling fixes.

2014-10-19 15:28 GMT+04:00 Micha Hergarden :

>  On 10/09/2014 07:30 PM, Evgeny Kalishenko wrote:
>
> Ok, thanks for the advise about STREQUAL. Explanation of s/_/(/ (from
> http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html
> ):
> "Recent versions of RPM support context marked dependencies. This is a
> special type of a dependency that applies only in a specified *context*.
> Using this feature, one can specify dependencies for pre- and
> post(un)install scriptlets, ie. the context of a dependency is the
> execution time of the specified scriptlet.
>
> The syntax for specifying these dependencies is:
>
> Requires(*X*): foo
>
>    Here, *X* can be one of *pre*, *post*, *preun*, or *postun*, which
> tells RPM that the package depends on package foo for running the
> corresponding *%pre*, *%post*, *%preun*, or *%postun* script."
>
> Modified patch attached.
>
> 2014-10-09 18:03 GMT+04:00 Brad King :
>
>> On 10/08/2014 01:48 PM, Evgeny Kalishenko wrote:
>> > I was interested in feature request
>> > http://public.kitware.com/Bug/view.php?id=14769 and made a
>> > simple patch for CPack RPM generator (attached).
>>
>> Thanks.
>>
>> In this hunk:
>>
>> > +    # The following keywords require braces around the "pre" or "post"
>> suffix in the final RPM spec file.
>> > +    if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE"  OR
>> "${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST")
>> > +      string(REPLACE "_" "(" _PACKAGE_HEADER_NAME
>> "${_PACKAGE_HEADER_NAME}")
>> > +      set(_PACKAGE_HEADER_NAME "${_PACKAGE_HEADER_NAME})")
>> > +    endif()
>>
>> The MATCHES conditions can use simply STREQUAL instead.
>> I'm not very familiar with the spec format, so please
>> explain the purpose of the s/_/(/ subsitution in comments
>> here.
>>
>> Thanks,
>> -Brad
>>
>>
>
>
> --
> ? ?????????,
> ??????? ?????????
>
>
>  In this hunk:
> +#  May be used to set RPM postinstall dependencies (requires(post)).
> Note that you must enclose
> +#  the complete requires string between quotes, for example::
> +#
> +#   set(CPACK_RPM_PACKAGE_REQUIRES_PRE "shadow-utils, initscripts")
> +#
> +#
>
> The variable name CPACK_RPM_PACKAGE_REQUIRES_PRE should be
> CPACK_RPM_PACKAGE_REQUIRES_POST.
>
> In this hunk:
> +    # The following keywords require braces around the "pre" or "post"
> suffix in the final RPM spec file.
> +    if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE"  OR
> "${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST")
> +      string(REPLACE "_" "(" _PACKAGE_HEADER_NAME
> "${_PACKAGE_HEADER_NAME}")
> +      set(_PACKAGE_HEADER_NAME "${_PACKAGE_HEADER_NAME})")
> +    endif()
>
> Shouldn't braces be called parentheses here ( i.e '(' versus '{' )?
>
> I have checked with a minimal project on a ubuntu 14.04 box (using rpm
> 4.11.1) and the generated package seems good. So, no further comments.
>
> With kind regards,
> Micha Hergarden
>



-- 
Regards,
Evgeny Kalishenko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pre_post_rpm_install.patch
Type: text/x-patch
Size: 7633 bytes
Desc: not available
URL: 

From steveire at gmail.com  Mon Oct 20 13:15:34 2014
From: steveire at gmail.com (Stephen Kelly)
Date: Mon, 20 Oct 2014 19:15:34 +0200
Subject: [cmake-developers] Extracting target metadata, IDE integration
References: 
 
 
 
 
Message-ID: 

Tobias Hunger wrote:

> Hey Stephen,
> 
> On Sun, Oct 19, 2014 at 2:26 PM, Stephen Kelly
>  wrote:
>> No problem, thanks! I recently discovered that Creator makes fragile
>> guesses about source files and targets
>>
>> https://codereview.qt-project.org/#/c/96594/1/src/plugins/cmakeprojectmanager/cmakeproject.cpp,unified
>>
>> so I would really like to create a solution which makes that unnecessary.
> 
> I am no expert on this part of the codebase, but I would not be
> surprised if it did do some stupid things when seeing cmake. We do not
> support that too well.

What I mean is: the problem seems to be that source files are not listed 
per-target in the codeblock files CMake generates, so creator is forced to 
guess. I don't know if better information can be put into the C::B files, 
but I think the proposed json file is a better solution anyway. I don't 
generally like that creator (and clion) have to rely on parsing a foreign 
generators files.

>> Yes. I suppose beyond the WIN32_EXECUTABLE/ SUBSYSTEM:console / Mac
>> Bundle stuff the gui/console distinction doesn't really fit into the
>> buildsystem. Maybe such a checkbox, pre-populated with the hint, is
>> needed anyway.
> 
> Not into a build system, but into an IDE:-)

Yes, I wrote 'doesn't fit into the buildsystem' - implying it fits into the 
IDE, maybe in the form of a checkbox.

> I do not think there is a conflict between CMake source groups and
> what I was referring to, except maybe in my poorly chosen name.

I was thinking about a case where the source groups defined in 

 http://www.cmake.org/cmake/help/v3.0/command/source_group.html

commands would be exported in the JSON. I don't know if that's a good idea 
or not, but if it is, then yes, namespacing may be the only issue.
 
Thanks,

Steve.



From brad.king at kitware.com  Mon Oct 20 16:42:39 2014
From: brad.king at kitware.com (Brad King)
Date: Mon, 20 Oct 2014 16:42:39 -0400
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <5437F443.3040705@kitware.com>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com>
Message-ID: <544573BF.7060002@kitware.com>

On 10/10/2014 10:59 AM, Brad King wrote:
> Everything tested cleanly!  Adam, Clinton, thanks for your help
> bringing this topic to maturity.  It was the last non-regression
> topic I'm planning to take for 3.1.  I squashed the fixes and
> revised commit messages slightly.  Then I merged to 'master':
> 
>  Merge topic 'fix-OSX-bundle-rpaths-and-Qt5'
>  http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26bffa6e

We've been having problems getting the 3.1.0-rc1 release binaries
to work on machines other than those that built them.  Ever since
this topic was merged for testing on 2014-09-30, the nightly
binaries on OS X have not worked:

 $ /Volumes/cmake-3.0.20140929-g5748a-Darwin64-universal/CMake.app/Contents/bin/cmake-gui
 (works)

 $ /Volumes/cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/bin/cmake-gui
 Qt internal error: qt_menu.nib could not be loaded. The .nib file should be placed in QtGui.framework/Versions/Current/Resources/  or in the resources directory of your application bundle.

The .nib is present in the right place, but the binary does not see
them.  Comparing the working and broken versions:

$ diff -r /Volumes/cmake-3.0.20140929-g5748a-Darwin64-universal/CMake.app/Contents \
          /Volumes/cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents |
  diffstat
 cmake-3.0.20140929-g5748a-Darwin64-universal/CMake.app/Contents/Frameworks/QtGui.framework/Resources             |only
 cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtCore.framework/Versions/4/Resources |only
 cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtCore.framework/Versions/Current     |only
 cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtGui.framework/Versions/4/Resources  |only
 cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtGui.framework/Versions/Current      |only
 ...
 cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/share/cmake-3.0/Modules/BundleUtilities.cmake    |  135 ++++++++--
 cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/share/cmake-3.0/Modules/GetPrerequisites.cmake   |   29 +-
 16 files changed, 137 insertions(+), 36 deletions(-)

we can see that something in the frameworks is different and that
one of the only other changes is the BundleUtilities module.

Adam, Clinton, please take a look at this.  If it cannot be resolved
in the next couple days I will have to revert this topic and drop it
from the 3.1 release.

Thanks,
-Brad


From ono at java.pl  Mon Oct 20 18:41:15 2014
From: ono at java.pl (Adam Strzelecki)
Date: Tue, 21 Oct 2014 00:41:15 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <544573BF.7060002@kitware.com>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
Message-ID: <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl>

> $ /Volumes/cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/bin/cmake-gui
> Qt internal error: qt_menu.nib could not be loaded. The .nib file should be placed in QtGui.framework/Versions/Current/Resources/  or in the resources directory of your application bundle.

Did you build against Qt4 SDK taken from official installer? Can you put these both binaries somewhere (zipped) in the cloud?

BTW. Any reason to not use Qt5?

-- Adam


From domen.vrankar at gmail.com  Tue Oct 21 02:18:37 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 21 Oct 2014 08:18:37 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

>
> I also wrote a test and noticed two things:
> 1) CPackComponentsForAll test is using component names in lower case and
>  parts in variables in upper case (e.g. COMPONENT headers and
> CPACK_COMPONENT_HEADERS_DESCRIPTION). Patch uses
> CPACK_RPM_PACKAGE_COMPONENT variable as part of component variable name
> e.g. CPACK_RPM_headers_PACKAGE_DESCRIPTION.
> Because of this the fallback mechanism doesn't work correctly so is the
> correct variable format CPACK_COMPONENT_headers_PACKAGE_SUMMARY, CPACK_
> COMPONENT_HEADERS_PACKAGE_SUMMARY, both or case insensitive?
> If case insensitive option is the correct one - how do I implement that?
> Since all other RPM component variables use install( ... COMPONENT name)
> as part of variable name (so in this case that means lower case) I guess
> that RPM versions should stay as they are now (
> CPACK_RPM_headers_PACKAGE_DESCRIPTION for the above example).
>
> I have fixed a bug in my previous patch -
CPACK_COMPONENT__DESCRIPTION component must be in upper case.
CPACK_RPM_* is still treated the same way as with other
variables - install( ... COMPONENT name) and name is used as it is without
changing it to upper case.
I have also added semantic check tests of component description and summary
fall backs.

Patches must be applied in order:
0001-CPackRPM-component-based-packaging-description-and-s.patch
0001-add-added-semantic-tests-for-rpm-component-descripti.patch

Could someone pleas add the patches to git as I currently don't have commit
rights?

2) Package description fallback is currently written as
> set(CPACK_RPM_PACKAGE_DESCRIPTION "no package description available") and
> this is already in the code - not part of the patch. However if variable
> CPACK_PACKAGE_DESCRIPTION_FILE is not set it points by default to
> Templates/CPack.GenericDescription.txt and its content is "DESCRIPTION". So
> currently the above final fallback is dead code.
> Should I delete it or fix the code so that in case of default
> CPACK_PACKAGE_DESCRIPTION_FILE value it ignores it and uses "no package
> description available" text instead (would break the way it currently works
> so I'm guessing that deleting that part of code is the preferred option)?
> Can I put this change in the same patch since I am changing the fallback
> mechanism in it or should this be a different patch?
> If second - can I still attach the patch to the same mantis bug, do I open
> a new bug report or just create a patch and post it on the mailing list?
>

I will create a new bug tracker in mantis for this one and create a patch
there.

Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From seandepagnier at gmail.com  Tue Oct 21 03:51:45 2014
From: seandepagnier at gmail.com (sean d'epagnier)
Date: Tue, 21 Oct 2014 15:51:45 +0800
Subject: [cmake-developers] Fixes to the FindwxWidgets module
Message-ID: 

Hi,

I have recently been working on wxQT which allows wxWidgets to sit on top
of Qt (and thus target otherwise unsupported platforms like android and ios)

I found the FindwxWidgets module had a slight bug, but was not revealed
until I attempted to build applications which use wxQT.  I have corrected
it with the attached patch.

I was informed of the recent discussion:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10679

As I use Modules/FindwxWidgets.cmake but not Modules/UsewxWidgets.cmake, I
don't think the recent change will work, further, my change corrects more
problems.   I believe the commit "e6fa6e60f6330ddf60294a0d9a6ed4cb3f27d4c4"
is probably not needed after my patch  applied.

Thanks,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
--- FindwxWidgets.cmake	2014-06-25 14:41:27.490159713 +0800
+++ /usr/local/share/cmake-3.0/Modules/FindwxWidgets.cmake	2014-08-22 11:53:11.928480401 +0800
@@ -788,11 +789,16 @@
         # parse include dirs from cxxflags; drop -I prefix
         string(REGEX MATCHALL "-I[^;]+"
           wxWidgets_INCLUDE_DIRS "${wxWidgets_CXX_FLAGS}")
-        string(REGEX REPLACE "-I[^;]+;" ""
+        string(REGEX REPLACE "-I[^;]+(;|$)" ""
+          wxWidgets_CXX_FLAGS "${wxWidgets_CXX_FLAGS}")
+        string(REGEX REPLACE ";$" ""
           wxWidgets_CXX_FLAGS "${wxWidgets_CXX_FLAGS}")
         string(REPLACE "-I" ""
           wxWidgets_INCLUDE_DIRS "${wxWidgets_INCLUDE_DIRS}")
 
+        string(REGEX REPLACE ";" " "
+          wxWidgets_CXX_FLAGS "${wxWidgets_CXX_FLAGS}")
+
         DBG_MSG_V("wxWidgets_DEFINITIONS=${wxWidgets_DEFINITIONS}")
         DBG_MSG_V("wxWidgets_INCLUDE_DIRS=${wxWidgets_INCLUDE_DIRS}")
         DBG_MSG_V("wxWidgets_CXX_FLAGS=${wxWidgets_CXX_FLAGS}")

From pascal.bach at siemens.com  Tue Oct 21 05:24:28 2014
From: pascal.bach at siemens.com (Pascal Bach)
Date: Tue, 21 Oct 2014 11:24:28 +0200
Subject: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as tests
	for Windows CE
Message-ID: <1413883468-499-1-git-send-email-pascal.bach@siemens.com>

---
 Tests/CMakeLists.txt |   30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 25cc846..fc3359e 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1835,6 +1835,36 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release
     endif()
   endif()
 
+  get_filename_component(wince_sdk "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows CE Tools\\SDKs\\SDK_AM335X_SK_WEC2013_V310]" ABSOLUTE)
+  if(WIN32 AND EXISTS ${wince_sdk})
+    macro(add_test_VSWinCE name generator systemName systemVersion generatorPlatform)
+      # TODO: Fix the tutorial to make it work in cross compile
+      # currently the MakeTable is build for target and can not be used on the host
+      # This happens in part 5 so we build only part 1-4 of the tutorial
+      foreach(STP RANGE 1 4)
+        add_test(NAME "TutorialStep${STP}.${name}" COMMAND ${CMAKE_CTEST_COMMAND}
+          --build-and-test
+          "${CMake_SOURCE_DIR}/Tests/Tutorial/Step${STP}"
+          "${CMake_BINARY_DIR}/Tests/Tutorial/Step${STP}_${name}"
+          --build-generator "${generator}"
+          --build-project Tutorial
+          --build-config $
+          --build-options -DCMAKE_SYSTEM_NAME=${systemName}
+                          -DCMAKE_SYSTEM_VERSION=${systemVersion}
+                          -DCMAKE_GENERATOR_PLATFORM=${generatorPlatform})
+        list(APPEND TEST_BUILD_DIRS "${CMake_BINARY_DIR}/Tests/Tutorial/Step${STP}_${name}")
+      endforeach()
+    endmacro()
+
+    if(vs11)
+      add_test_VSWinCE(vs11-ce80-ARM "Visual Studio 11 2012" WindowsCE 8.0 SDK_AM335X_SK_WEC2013_V310)
+    endif()
+
+    if(vs12)
+      add_test_VSWinCE(vs12-ce80-ARM "Visual Studio 12 2013" WindowsCE 8.0 SDK_AM335X_SK_WEC2013_V310)
+    endif()
+  endif()
+
   if(tegra AND NOT "${CMake_SOURCE_DIR};${CMake_BINARY_DIR}" MATCHES " ")
     macro(add_test_VSNsightTegra name generator)
       add_test(NAME VSNsightTegra.${name} COMMAND ${CMAKE_CTEST_COMMAND}
-- 
1.7.10.4


From brad.king at kitware.com  Tue Oct 21 08:28:27 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 08:28:27 -0400
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl>
Message-ID: <5446516B.9060206@kitware.com>

On 10/20/2014 06:41 PM, Adam Strzelecki wrote:
> Did you build against Qt4 SDK taken from official installer?

It's a qt 4.8.0 installed from source.

 configure --prefix=... -opensource -confirm-license \
  -nomake demos -nomake examples -cocoa -shared -release \
  -arch x86 x86_64

We also tried one with just "-arch x86_64" as part of trying to package
only that architecture, but it has the same problem.

> Can you put these both binaries somewhere (zipped) in the cloud?

Nightly binaries are always published here:

 http://www.cmake.org/files/dev/

Specifically:

 http://www.cmake.org/files/dev/cmake-3.0.20140929-g5748a-Darwin64-universal.dmg
 http://www.cmake.org/files/dev/cmake-3.0.20140930-g37776-Darwin64-universal.dmg

> BTW. Any reason to not use Qt5?

We already have the infrastructure set up to use Qt4 and it has
worked well for years.  Prior to your patch the Qt5 package did
not work for redistribution due to the plugin problem anyway.

-Brad


From robert.maynard at kitware.com  Tue Oct 21 08:47:56 2014
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 21 Oct 2014 08:47:56 -0400
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <5446516B.9060206@kitware.com>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
Message-ID: 

Also as follow up the same Qt build is used for all Darwin64 releases and
nightlies. As far as I am aware this Qt build has been producing valid
deployable frameworks since before CMake 2.8.8

On Tue, Oct 21, 2014 at 8:28 AM, Brad King  wrote:

> On 10/20/2014 06:41 PM, Adam Strzelecki wrote:
> > Did you build against Qt4 SDK taken from official installer?
>
> It's a qt 4.8.0 installed from source.
>
>  configure --prefix=... -opensource -confirm-license \
>   -nomake demos -nomake examples -cocoa -shared -release \
>   -arch x86 x86_64
>
> We also tried one with just "-arch x86_64" as part of trying to package
> only that architecture, but it has the same problem.
>
> > Can you put these both binaries somewhere (zipped) in the cloud?
>
> Nightly binaries are always published here:
>
>  http://www.cmake.org/files/dev/
>
> Specifically:
>
>
> http://www.cmake.org/files/dev/cmake-3.0.20140929-g5748a-Darwin64-universal.dmg
>
> http://www.cmake.org/files/dev/cmake-3.0.20140930-g37776-Darwin64-universal.dmg
>
> > BTW. Any reason to not use Qt5?
>
> We already have the infrastructure set up to use Qt4 and it has
> worked well for years.  Prior to your patch the Qt5 package did
> not work for redistribution due to the plugin problem anyway.
>
> -Brad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From brad.king at kitware.com  Tue Oct 21 08:50:08 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 08:50:08 -0400
Subject: [cmake-developers] [PATCH] Preinstall requirements support for
 CPack RPM generator
In-Reply-To: 
References: 	<543695B3.5010201@kitware.com>		<5443A04E.7030806@gmail.com>
 
Message-ID: <54465680.9060003@kitware.com>

On 10/20/2014 12:53 PM, Evgeny Kalishenko wrote:
> The final patch version with erroneous spelling fixes.

Thanks.  Please configure your git 'user.name' so that proper
authorship is recorded with your Real Name.  Also please squash
the spelling fixup changes back in the commit that they fixup.

>> Here, /X/ can be one of *pre*, *post*, *preun*, or *postun*

The PREUN and POSTUN patch does not add documentation of any
corresponding CPackRPM variables.  Should it?

Thanks,
-Brad


From brad.king at kitware.com  Tue Oct 21 08:52:18 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 08:52:18 -0400
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: <54465702.6010805@kitware.com>

On 10/21/2014 02:18 AM, Domen Vrankar wrote:
> Patches must be applied in order:
> 0001-CPackRPM-component-based-packaging-description-and-s.patch
> 0001-add-added-semantic-tests-for-rpm-component-descripti.patch
> 
> Could someone pleas add the patches to git as I currently don't have commit rights?

Did you mean to attach the patches to the message?

> I will create a new bug tracker in mantis for this one and create a patch there.

I prefer patches on the mailing list where they can get a broader audience
and email-based reviews.

Thanks,
-Brad


From brad.king at kitware.com  Tue Oct 21 08:58:21 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 08:58:21 -0400
Subject: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as
 tests for Windows CE
In-Reply-To: <1413883468-499-1-git-send-email-pascal.bach@siemens.com>
References: <1413883468-499-1-git-send-email-pascal.bach@siemens.com>
Message-ID: <5446586D.6010107@kitware.com>

On 10/21/2014 05:24 AM, Pascal Bach wrote:
> ---
>  Tests/CMakeLists.txt |   30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)

The Wow6432Node path component should not be needed because
CMake is aware of how to lookup different registry views.
Also we can fold the lookup into existing infrastructure
a few lines above.

Please try the attached revision to your patch.

Thanks,
-Brad

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Tests-Run-Tutorial-steps-1-4-as-tests-for-Windows-CE.patch
Type: text/x-diff
Size: 3153 bytes
Desc: not available
URL: 

From domen.vrankar at gmail.com  Tue Oct 21 09:00:38 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 21 Oct 2014 15:00:38 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: <54465702.6010805@kitware.com>
References: 
 
 
 
 
 
 
 <54465702.6010805@kitware.com>
Message-ID: 

2014-10-21 14:52 GMT+02:00 Brad King :

> On 10/21/2014 02:18 AM, Domen Vrankar wrote:
> > Patches must be applied in order:
> > 0001-CPackRPM-component-based-packaging-description-and-s.patch
> > 0001-add-added-semantic-tests-for-rpm-component-descripti.patch
> >
> > Could someone pleas add the patches to git as I currently don't have
> commit rights?
>
> Did you mean to attach the patches to the message?
>
>
I just added the patch to mantis bug report. I'm still getting used to the
process.
Here are the mentioned patches.


> > I will create a new bug tracker in mantis for this one and create a
> patch there.
>
> I prefer patches on the mailing list where they can get a broader audience
> and email-based reviews.
>

OK. I'll send it to the mailing list as soon as I write it.


>
> Thanks,
> -Brad
>
>

Thanks,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-added-semantic-tests-for-rpm-component-descripti.patch
Type: text/x-patch
Size: 6250 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-CPackRPM-component-based-packaging-description-and-s.patch
Type: text/x-patch
Size: 5040 bytes
Desc: not available
URL: 

From brad.king at kitware.com  Tue Oct 21 09:02:15 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 09:02:15 -0400
Subject: [cmake-developers] Fixes to the FindwxWidgets module
In-Reply-To: 
References: 
Message-ID: <54465957.8040600@kitware.com>

On 10/21/2014 03:51 AM, sean d'epagnier wrote:
> I was informed of the recent discussion:
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10679

Additional discussion in an issue tracker entry linked from that thread:

 http://www.cmake.org/Bug/view.php?id=15087

explains how we cannot change the value presented because projects
could be depending on the current one.  See:

 http://www.cmake.org/Bug/view.php?id=15087#c36639

-Brad


From hobbes1069 at gmail.com  Tue Oct 21 09:03:48 2014
From: hobbes1069 at gmail.com (Richard Shaw)
Date: Tue, 21 Oct 2014 08:03:48 -0500
Subject: [cmake-developers] Fixes to the FindwxWidgets module
In-Reply-To: 
References: 
Message-ID: 

On Tue, Oct 21, 2014 at 2:51 AM, sean d'epagnier 
wrote:

> Hi,
>
> I have recently been working on wxQT which allows wxWidgets to sit on top
> of Qt (and thus target otherwise unsupported platforms like android and ios)
>
> I found the FindwxWidgets module had a slight bug, but was not revealed
> until I attempted to build applications which use wxQT.  I have corrected
> it with the attached patch.
>
> As I use Modules/FindwxWidgets.cmake but not Modules/UsewxWidgets.cmake, I
> don't think the recent change will work, further, my change corrects more
> problems.   I believe the commit "e6fa6e60f6330ddf60294a0d9a6ed4cb3f27d4c4"
> is probably not needed after my patch  applied.
>

I'm not a REGEX expert, I usually just figure out what I need when I need
it :) The first half of the patch looks fine to me as it seems to be just
dealing with the end of a line or the "last flag".

I planned on implementing the 2nd half of your patch myself but was
informed that current users may be expecting a list there which is why I
moved the conversion from ";" to " " in the UsewxWidgets file.

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ono at java.pl  Tue Oct 21 09:17:57 2014
From: ono at java.pl (Adam Strzelecki)
Date: Tue, 21 Oct 2014 15:17:57 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: 
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
Message-ID: 

Please hold your breath, and don't yet revert my patches because you will end up with bundle that you cannot code-sign anyway for 10.10 and >=10.9.5 and it will be bad release that will be rejected by Gatekeeper upon launch.

First of all this is in fact Qt bug, please follow discussion at:

	http://lists.qt-project.org/pipermail/development/2014-September/018505.html

The patches I provided, especially 55707fd5, were intended to workaround that so app will code-sign with >=10.9.5, especially for Qt case where their frameworks had incorrect layout causing code sign fail for whole bundle:

	$ codesign -v --deep -s 'Developer ID' CMake.app
	CMake.app: bundle format unrecognized, invalid, or unsuitable
	In subcomponent: /private/tmp/CMake.app/Contents/Frameworks/QtCore.framework

As I used Qt5 for my own CMake build there is no problem with Qt5 here. But indeed I haven't try to build CMake against last stable Qt 4.8 (that is known to have incorrect layout).

Moreover Qt4 seeks hardly for Resources/ folder in framework root, which is not there anymore as it is not obligatory to have Resource/ symlinks. Also QtGui.framework misses Info.plist in Version/4/Resources/. So fix is as simple as:

(1) extra symlink Resources/ -> Version/Current/Resources/ (for sake of Qt SDK)
(2) ensure Info.plist in Version/4/Resources/

I'll try build Qt4 SDK myself as you do and checkout what's the bundle layout of theirs.

Cheers,
-- 
Adam

From brad.king at kitware.com  Tue Oct 21 09:19:55 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 09:19:55 -0400
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 							<54465702.6010805@kitware.com>
 
Message-ID: <54465D7B.3000005@kitware.com>

On 10/21/2014 09:00 AM, Domen Vrankar wrote:
> Here are the mentioned patches.

Thanks.  I see no reason not to squash them together since
the second one just fixes and tests the first one.  Applied:

 CPackRPM: Add component based packaging description and summary
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=603ef7fd

-Brad


From brad.king at kitware.com  Tue Oct 21 09:24:09 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 09:24:09 -0400
Subject: [cmake-developers] Xcode Project: Support for DevelopmentTeam
In-Reply-To: 
References: 
Message-ID: <54465E79.4070308@kitware.com>

On 10/17/2014 04:16 PM, Fabian wrote:
> Xcode automatically updates the devices list in the Member Center

Neat.  Please explain the developer workflow you envision to configure
the value for local build trees.  Would it be something the developer
should explicitly set in every new tree?  Should there be a common
configuration in the environment?  Can it be detected programmatically?

> In the CMake source I noticed that 'BuildIndependentTargetsInParallel'
> is already getting set. This could be extendet to add the 'TargetAttributes'
> section.

Yes, that looks like the right place if you want to try a patch.

> This could be set with a CMake flag.

The generator could check a variable like

 CMAKE_XCODE_DEVELOPMENT_TEAM

to get the value, but please answer my questions above about the
workflow.

Thanks,
-Brad

From pascal.bach at siemens.com  Tue Oct 21 09:26:34 2014
From: pascal.bach at siemens.com (Bach, Pascal)
Date: Tue, 21 Oct 2014 13:26:34 +0000
Subject: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as
 tests for Windows CE
In-Reply-To: <5446586D.6010107@kitware.com>
References: <1413883468-499-1-git-send-email-pascal.bach@siemens.com>
 <5446586D.6010107@kitware.com>
Message-ID: <355BE46A91031048906B695426A8D8E616AE6358@DEFTHW99EH4MSX.ww902.siemens.net>

Your revision looks better ;)

I even would prefer to not hardcode the SDK  but I was unable to list key entries from the registry.

Usually all installed SDKs are listed as subkeys of HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows CE Tools\\SDKs in this case it is SDK_AM335X_SK_WEC2013_V310.

I think the test would be nicer if it checks for available SDKs and just picks the first.

Any ideas how to do this?

Regards
Pascal

> -----Original Message-----
> From: Brad King [mailto:brad.king at kitware.com]
> Sent: Dienstag, 21. Oktober 2014 14:58
> To: Bach, Pascal; cmake-developers at cmake.org
> Subject: Re: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as
> tests for Windows CE
> 
> On 10/21/2014 05:24 AM, Pascal Bach wrote:
> > ---
> >  Tests/CMakeLists.txt |   30 ++++++++++++++++++++++++++++++
> >  1 file changed, 30 insertions(+)
> 
> The Wow6432Node path component should not be needed because
> CMake is aware of how to lookup different registry views.
> Also we can fold the lookup into existing infrastructure
> a few lines above.
> 
> Please try the attached revision to your patch.
> 
> Thanks,
> -Brad


From brad.king at kitware.com  Tue Oct 21 09:27:54 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 09:27:54 -0400
Subject: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as
 tests for Windows CE
In-Reply-To: <355BE46A91031048906B695426A8D8E616AE6358@DEFTHW99EH4MSX.ww902.siemens.net>
References: <1413883468-499-1-git-send-email-pascal.bach@siemens.com>
 <5446586D.6010107@kitware.com>
 <355BE46A91031048906B695426A8D8E616AE6358@DEFTHW99EH4MSX.ww902.siemens.net>
Message-ID: <54465F5A.6000208@kitware.com>

On 10/21/2014 09:26 AM, Bach, Pascal wrote:
> Your revision looks better ;)
> 
> I even would prefer to not hardcode the SDK  but I was unable to list key entries from the registry.
> 
> Usually all installed SDKs are listed as subkeys of HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows CE Tools\\SDKs in this case it is SDK_AM335X_SK_WEC2013_V310.
> 
> I think the test would be nicer if it checks for available SDKs and just picks the first.
> 
> Any ideas how to do this?

Within a block guarded by if(CMAKE_HOST_WIN32) you could
use execute_process to run the "reg" command-line tool.

-Brad


From brad.king at kitware.com  Tue Oct 21 09:35:06 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 09:35:06 -0400
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: 
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
 
Message-ID: <5446610A.8020609@kitware.com>

On 10/21/2014 09:17 AM, Adam Strzelecki wrote:
> First of all this is in fact Qt bug, please follow discussion at:
> 
> 	http://lists.qt-project.org/pipermail/development/2014-September/018505.html
> 
> The patches I provided, especially 55707fd5, were intended to workaround that
[snip]
> I'll try build Qt4 SDK myself as you do and checkout what's the bundle layout of theirs.

Regardless of where the bug lies, your changes took a packaging
case that worked and made it not work.  That is a regression.
Working around it for the packaging machine of CMake itself is
not a solution because it could happen to any project built this
way.

Please extend your changes to restore successful packaging with
no special help by adding whatever workarounds are needed.  If
the result is not signable when the workarounds are in place that
is okay because we couldn't sign before either.

Thanks,
-Brad


From robert.maynard at kitware.com  Tue Oct 21 09:42:34 2014
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 21 Oct 2014 09:42:34 -0400
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: 
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
 
Message-ID: 

We have never symlinked Resources/ to Version/Current/Resources since we
place icons on other images under the Resources/ folder.

The Info.plist has always been placed in the root of Contents, and is still
there after the changes.

On Tue, Oct 21, 2014 at 9:17 AM, Adam Strzelecki  wrote:

> Please hold your breath, and don't yet revert my patches because you will
> end up with bundle that you cannot code-sign anyway for 10.10 and >=10.9.5
> and it will be bad release that will be rejected by Gatekeeper upon launch.
>
> First of all this is in fact Qt bug, please follow discussion at:
>
>
> http://lists.qt-project.org/pipermail/development/2014-September/018505.html
>
> The patches I provided, especially 55707fd5, were intended to workaround
> that so app will code-sign with >=10.9.5, especially for Qt case where
> their frameworks had incorrect layout causing code sign fail for whole
> bundle:
>
>         $ codesign -v --deep -s 'Developer ID' CMake.app
>         CMake.app: bundle format unrecognized, invalid, or unsuitable
>         In subcomponent:
> /private/tmp/CMake.app/Contents/Frameworks/QtCore.framework
>
> As I used Qt5 for my own CMake build there is no problem with Qt5 here.
> But indeed I haven't try to build CMake against last stable Qt 4.8 (that is
> known to have incorrect layout).
>
> Moreover Qt4 seeks hardly for Resources/ folder in framework root, which
> is not there anymore as it is not obligatory to have Resource/ symlinks.
> Also QtGui.framework misses Info.plist in Version/4/Resources/. So fix is
> as simple as:
>
> (1) extra symlink Resources/ -> Version/Current/Resources/ (for sake of Qt
> SDK)
> (2) ensure Info.plist in Version/4/Resources/
>
> I'll try build Qt4 SDK myself as you do and checkout what's the bundle
> layout of theirs.
>
> Cheers,
> --
> Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ono at java.pl  Tue Oct 21 09:44:59 2014
From: ono at java.pl (Adam Strzelecki)
Date: Tue, 21 Oct 2014 15:44:59 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: 
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
 
 
Message-ID: 

> We have never symlinked Resources/ to Version/Current/Resources since we place icons on other images under the Resources/ folder.
> 
> The Info.plist has always been placed in the root of Contents, and is still there after the changes.

Sorry, maybe I it wasn't clear enough but I am talking about Framework's root and bundled Frameworks layout not app bundle layout here.

--Adam


From ono at java.pl  Tue Oct 21 09:59:19 2014
From: ono at java.pl (Adam Strzelecki)
Date: Tue, 21 Oct 2014 15:59:19 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <5446610A.8020609@kitware.com>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
  <5446610A.8020609@kitware.com>
Message-ID: <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl>

> Regardless of where the bug lies, your changes took a packaging
> case that worked and made it not work.  That is a regression.

I am sorry, but 55707fd5 in fact does it CORRECT WAY as it is expressed in:

https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html

and expected by code-sign.

Resources/ folder needs to lie in VERSION folder, so in out case QtGui.framework/Versions/4/Resources/

Previous CMake was checking and copying QtGui.framework/Resources/ which is WRONG as this is wrong place, and it may just be symlink to CORRECT place. But such symlink is not obligatory in final bundle.

It WAS working because Qt was looking in WRONG place for .nib file that was copied. Also before 10.9.5 it was code signing well because Apple put some heuristics to allow lousy bundles. But these were removed in 10.9.5 for code signed bundles.

But assuming we restore Resources/ optional symlink we can circumvent that. And I am working on the patch, just give me few minutes.

> Working around it for the packaging machine of CMake itself is
> not a solution because it could happen to any project built this
> way.

I used wrong word, this was not workaround, but introduction of correct behavior. But I will add extra change that will restore Resources/ symlinks as well.

> Please extend your changes to restore successful packaging with
> no special help by adding whatever workarounds are needed.

If I remove all workarounds and do it ONLY correct way as Apple specified then apps using currently release Qt SDKs will not work :>

Please note this has been fixes in Qt 5.4 beta, so we could remove workarounds, but then only most recent Qt SDK would work fine.

If you need more information ping me on IRC.

--Adam


From daniele.domenichelli at gmail.com  Tue Oct 21 10:01:19 2014
From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli)
Date: Tue, 21 Oct 2014 16:01:19 +0200
Subject: [cmake-developers] ExternalProject CMAKE_ARGS and
 CMAKE_CACHE_ARGS arguments
In-Reply-To: <54451383.4070809@kitware.com>
References: <543FE392.7020706@gmail.com> <54451383.4070809@kitware.com>
Message-ID: <5446672F.3070501@gmail.com>

On 20/10/14 15:52, Brad King wrote:
> On 10/16/2014 11:26 AM, Daniele E. Domenichelli wrote:
>>   #    [CMAKE_ARGS args...]        # Arguments to CMake command line
>>   #    [CMAKE_CACHE_ARGS args...]  # Initial cache arguments, of the form -Dvar:string=on
>>
>> So, from what I understand, The first arguments are passed to the cmake
>> command line, and from the second it is created a a cache file that is
>> passed to cmake using -C. If the same variable is in both, CMAKE_ARGS
>> wins over CMAKE_CACHE_ARGS.
> [snip]
>> This makes impossible to change a value later, and in my opinion makes
>> one of the 2 arguments redundant, since the final effect of the 2
>> variables is exactly the same.
> 
> CMAKE_CACHE_ARGS was added here:
> 
>  Added CMAKE_CACHE_ARGS to ExternalProject.
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=68cd3fe0
> 
> to overcome command line length limits.  CMAKE_ARGS can contain
> arguments other than cache values.  Therefore they are not fully
> redundant although there is overlap.

Ok, I see.

I would like to be able to set some some variables (for example
CMAKE_BUILD_TYPE) for all the "external project" according to the value
in the "super-project", but the same time I would like to be able to
change them (for example change CMAKE_BUILD_TYPE to Debug if I'm
building in Release mode) for just one external project without changing
it in all of them, and having to rebuild everything.
But actually I don't like the idea that all of them could be modified,
for example in my case the user should not have the control over the
CMAKE_INSTALL_PREFIX variable...

Maybe, since the "-D" is actually a convention to match the CMAKE_ARGS
argument that does some sort of conversion from "-Dvar:type=value" to a
"set(var value CACHE type "Initial cache" FORCE)" command, it could be
possible to accept some other form of string, maybe "+D", or "-", so that:

 -Dvar:type=value -> set(var value CACHE type "Initial cache" FORCE)
 +Dvar:type=value -> set(var value CACHE type "Initial cache" )

This would ensure backwards compatibility, with no extra arguments and
could allow a quick switch from forced to non-forced, just by changing
one character.

Would you accept something like this?


Cheers,
 Daniele


From clinton at elemtech.com  Tue Oct 21 10:25:10 2014
From: clinton at elemtech.com (Clinton Stimpson)
Date: Tue, 21 Oct 2014 08:25:10 -0600
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <1619747.Fr49X3lPFJ@stryke>
References: <542ACE37.1040302@kitware.com>
 <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl> <1619747.Fr49X3lPFJ@stryke>
Message-ID: <94276785.r0XvlNa4HJ@stryke>

On Tuesday, October 21, 2014 08:22:24 AM Clinton Stimpson wrote:
> On Tuesday, October 21, 2014 03:59:19 PM Adam Strzelecki wrote:
> > > Regardless of where the bug lies, your changes took a packaging
> > > case that worked and made it not work.  That is a regression.
> > 
> > I am sorry, but 55707fd5 in fact does it CORRECT WAY as it is expressed
> > in:
> > 
> > https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BP
> > Fr ameworks/Concepts/FrameworkAnatomy.html
> > 
> > and expected by code-sign.
> > 
> > Resources/ folder needs to lie in VERSION folder, so in out case
> > QtGui.framework/Versions/4/Resources/
> > 
> > Previous CMake was checking and copying QtGui.framework/Resources/ which
> > is
> > WRONG as this is wrong place, and it may just be symlink to CORRECT place.
> > But such symlink is not obligatory in final bundle.
> > 
> > It WAS working because Qt was looking in WRONG place for .nib file that
> > was
> > copied. Also before 10.9.5 it was code signing well because Apple put some
> > heuristics to allow lousy bundles. But these were removed in 10.9.5 for
> > code signed bundles.
> > 
> > But assuming we restore Resources/ optional symlink we can circumvent
> > that.
> > And I am working on the patch, just give me few minutes.
> 
> +1 for a symlink.  Handling of framework resources in BundleUtilities.cmake
> was originally based on the buggy Qt behavior.  I think Adam's suggested fix
> here is good.
> 
> 

And for the Qt internal error:

" Qt internal error: qt_menu.nib could not be loaded. The .nib file should be 
placed in QtGui.framework/Versions/Current/Resources/  or in the resources 
directory of your application bundle."

The message is incorrect.  Qt is actually looking for the resource in 
QtGui.framework/Resources/

Clint

From brad.king at kitware.com  Tue Oct 21 10:30:20 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 10:30:20 -0400
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
  <5446610A.8020609@kitware.com>
 <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl>
Message-ID: <54466DFC.4070403@kitware.com>

On 10/21/2014 09:59 AM, Adam Strzelecki wrote:
> But assuming we restore Resources/ optional symlink we can circumvent
> that. And I am working on the patch, just give me few minutes.

Great, thanks!

-Brad


From clinton at elemtech.com  Tue Oct 21 10:22:24 2014
From: clinton at elemtech.com (Clinton Stimpson)
Date: Tue, 21 Oct 2014 08:22:24 -0600
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl>
References: <542ACE37.1040302@kitware.com> <5446610A.8020609@kitware.com>
 <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl>
Message-ID: <1619747.Fr49X3lPFJ@stryke>

On Tuesday, October 21, 2014 03:59:19 PM Adam Strzelecki wrote:
> > Regardless of where the bug lies, your changes took a packaging
> > case that worked and made it not work.  That is a regression.
> 
> I am sorry, but 55707fd5 in fact does it CORRECT WAY as it is expressed in:
> 
> https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFr
> ameworks/Concepts/FrameworkAnatomy.html
> 
> and expected by code-sign.
> 
> Resources/ folder needs to lie in VERSION folder, so in out case
> QtGui.framework/Versions/4/Resources/
> 
> Previous CMake was checking and copying QtGui.framework/Resources/ which is
> WRONG as this is wrong place, and it may just be symlink to CORRECT place.
> But such symlink is not obligatory in final bundle.
> 
> It WAS working because Qt was looking in WRONG place for .nib file that was
> copied. Also before 10.9.5 it was code signing well because Apple put some
> heuristics to allow lousy bundles. But these were removed in 10.9.5 for
> code signed bundles.
> 
> But assuming we restore Resources/ optional symlink we can circumvent that.
> And I am working on the patch, just give me few minutes.

+1 for a symlink.  Handling of framework resources in BundleUtilities.cmake 
was originally based on the buggy Qt behavior.  I think Adam's suggested fix 
here is good.


Clint


> > Working around it for the packaging machine of CMake itself is
> > not a solution because it could happen to any project built this
> > way.
> 
> I used wrong word, this was not workaround, but introduction of correct
> behavior. But I will add extra change that will restore Resources/ symlinks
> as well.
> > Please extend your changes to restore successful packaging with
> > no special help by adding whatever workarounds are needed.
> 
> If I remove all workarounds and do it ONLY correct way as Apple specified
> then apps using currently release Qt SDKs will not work :>
> 
> Please note this has been fixes in Qt 5.4 beta, so we could remove
> workarounds, but then only most recent Qt SDK would work fine.
> 
> If you need more information ping me on IRC.
> 
> --Adam



From aklitzing at gmail.com  Tue Oct 21 10:37:56 2014
From: aklitzing at gmail.com (A. Klitzing)
Date: Tue, 21 Oct 2014 16:37:56 +0200
Subject: [cmake-developers] Support of codesign
In-Reply-To: <543FD64A.1040907@kitware.com>
References: 
 
 
 <2614570.QAlDDbOxL6@stryke> <543FD64A.1040907@kitware.com>
Message-ID: 

Hi,

I attached another patch to address the given issues.


On 09/26/2014 10:08 AM, clinton at elemtech.com wrote:
> > I would suggest the SignPackage function be moved from
> > cmCPackDragNDropGenerator to cmCPackBundleGenerator because
> > its implementation is only usable by cmCPackBundleGenerator.
> > It uses CPACK_BUNDLE_NAME which is only valid in the context
> > of cmCPackBundleGenerator.
>

Yes, I moved it and DragNDrop is untouched now. That was just a
copy+paste+modify mistake.


> On 09/29/2014 09:55 AM, clinton at elemtech.com wrote:
> > Because it appears to only work with the Bundle generator, can
> > you please move the documentation from Modules/CPackDMG.cmake
> > to Modules/CPackBundle.cmake?
> > Or did you intend to make this feature work for both the
> > DragNDrop and Bundle generator?
>

Same here....



> On 09/29/2014 02:00 PM, Clinton Stimpson wrote:
> > I think application signing is generally not a CPack thing, but
> > there probably isn't much of a choice if the Bundle generator
> > is used.
>

Well, it isn't possible to sign that bundle without it. There must be a
step between bundle and dmg. Maybe cmake could support that, too. So custom
processing could be more flexible.
But I think cmake should support more codesigning tools by itself to unify
the handling. For example.... we sign our MSI for windows with a custom
command. This could be integrated into a unifed CPACK variable.

Best regards
  Andr? Klitzing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-CPack-Add-support-for-code-signing-of-bundles-on-Mac.patch
Type: text/x-diff
Size: 7314 bytes
Desc: not available
URL: 

From ono at java.pl  Tue Oct 21 11:34:23 2014
From: ono at java.pl (Adam Strzelecki)
Date: Tue, 21 Oct 2014 17:34:23 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <54466DFC.4070403@kitware.com>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
  <5446610A.8020609@kitware.com>
 <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl> <54466DFC.4070403@kitware.com>
Message-ID: <5520EEFC-3B8E-4487-992E-F36700486256@java.pl>

Done. Tested with Qt5 & Qt4, pushed as f9fcea6803f636adfc9f5755d9c92c802cdc2fb6 to stage/fix-OSX-bundle-rpaths-and-Qt5 (last commit to this branch).

@Brad: Shall I make it as separate branch and merge for staging, or you can simply cherry-pick it?

--Adam

commit f9fcea6803f636adfc9f5755d9c92c802cdc2fb6
Author: Adam Strzelecki 
Date:   Tue Oct 21 16:42:33 2014 +0200

    Ensure framework symlinks and Info.plist exist
    
    This restores Qt SDK 4.8 and >= 10.6.5 codesign compatibility improving
    embedding frameworks using correct bundle layout described at:
    
    https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html
    
    1. If Versions/VERSION/Resources/Info.plist is missing, well known incorrect
       locations are checked for Info.plist and Info.plist is copied from there,
       otherwise codesign will fail.
    
    2. Root framework symlinks to binary and Resources are restored to point inside
       Versions/Current, otherwise Qt 4.8 looking for Resources/ in framework root
       will fail.


From clinton at elemtech.com  Tue Oct 21 11:44:33 2014
From: clinton at elemtech.com (Clinton Stimpson)
Date: Tue, 21 Oct 2014 09:44:33 -0600
Subject: [cmake-developers] Support of codesign
In-Reply-To: 
References: 
 <543FD64A.1040907@kitware.com>
 
Message-ID: <6639644.c5E5zbx6zX@stryke>

On Tuesday, October 21, 2014 04:37:56 PM A. Klitzing wrote:
> Hi,
> 
> I attached another patch to address the given issues.
> 
> On 09/26/2014 10:08 AM, clinton at elemtech.com wrote:
> > > I would suggest the SignPackage function be moved from
> > > cmCPackDragNDropGenerator to cmCPackBundleGenerator because
> > > its implementation is only usable by cmCPackBundleGenerator.
> > > It uses CPACK_BUNDLE_NAME which is only valid in the context
> > > of cmCPackBundleGenerator.
> 
> Yes, I moved it and DragNDrop is untouched now. That was just a
> copy+paste+modify mistake.
> 
> > On 09/29/2014 09:55 AM, clinton at elemtech.com wrote:
> > > Because it appears to only work with the Bundle generator, can
> > > you please move the documentation from Modules/CPackDMG.cmake
> > > to Modules/CPackBundle.cmake?
> > > Or did you intend to make this feature work for both the
> > > DragNDrop and Bundle generator?
> 
> Same here....
> 
> > On 09/29/2014 02:00 PM, Clinton Stimpson wrote:
> > > I think application signing is generally not a CPack thing, but
> > > there probably isn't much of a choice if the Bundle generator
> > > is used.
> 
> Well, it isn't possible to sign that bundle without it. There must be a
> step between bundle and dmg. Maybe cmake could support that, too. So custom
> processing could be more flexible.

It *is* possible by using the more customizable DragNDrop generator.  With the 
DragNDrop generator, you will have a chance to sign the bundle before its put 
into a dmg.  You also have that same chance with the PackageMaker generator.

Because the design of this Bundle generator is not consistent with the rest of 
the CPack generators, you don't have this same chance, and the only way to do 
customization is to keep adding patches like yours.


> But I think cmake should support more codesigning tools by itself to unify
> the handling. For example.... we sign our MSI for windows with a custom
> command. This could be integrated into a unifed CPACK variable.

A code signing solution in CMake would be an interesting proposition.

Clint

From brad.king at kitware.com  Tue Oct 21 11:45:07 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 11:45:07 -0400
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <5520EEFC-3B8E-4487-992E-F36700486256@java.pl>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
  <5446610A.8020609@kitware.com>
 <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl> <54466DFC.4070403@kitware.com>
 <5520EEFC-3B8E-4487-992E-F36700486256@java.pl>
Message-ID: <54467F83.4030309@kitware.com>

On 10/21/2014 11:34 AM, Adam Strzelecki wrote:
> @Brad: Shall I make it as separate branch and merge for staging,
> or you can simply cherry-pick it?

I cherry-picked it over on top of the revised/squashed copy of
the topic that was merged to 'master':

 BundleUtilities: Ensure framework symlinks and Info.plist exist
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41564ff2

I've merged it for testing in 'next'.  Thanks for taking care
of this so quickly!

-Brad


From ono at java.pl  Tue Oct 21 12:16:58 2014
From: ono at java.pl (Adam Strzelecki)
Date: Tue, 21 Oct 2014 18:16:58 +0200
Subject: [cmake-developers] CMake.app Qt5 vs Qt4 on 10.10
Message-ID: 

Following discussion regarding fix-OSX-bundle-rpaths-and-Qt5 topic I just wanted to share with you how CMake looks with Qt4 vs Qt5 on Yosemite:

	https://www.dropbox.com/s/knnybhed8fahste/CMake3.1rc1-Qt4.8.6-Yosemite.png
	https://www.dropbox.com/s/tm95rntexn4z6j6/CMake3.1rc1-Qt5.4-Yosemite.png

As you can see Qt4 has some problems with button test layout. Anyway nothing serious that prevents it from running. Please note I am using Qt 4.8.6 there not 4.8.0 as it is used for official builds (as far I understood correctly from what Robert told me on IRC).

FYI CMake bundle is 62MB with Qt4 vs 66MB with Qt5 (64-bit Intel only).

--Adam

From mantis at public.kitware.com  Tue Oct 21 14:59:24 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 21 Oct 2014 14:59:24 -0400
Subject: [cmake-developers] [CMake 0015213]: CMAKE_MODULE_LIBRARY_SUFFIX is
	not set
Message-ID: <754a7be1d7f306a670627cc40ea8b0cf@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15213 
====================================================================== 
Reported By:                Hartmut Seichter
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15213
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-21 14:59 EDT
Last Modified:              2014-10-21 14:59 EDT
====================================================================== 
Summary:                    CMAKE_MODULE_LIBRARY_SUFFIX is not set
Description: 
This might be also relevant to other OSX variants.

CMAKE_MODULE_LIBRARY_SUFFIX is not set. However, compiling shared libraries as
modules produces correctly libraries with suffix .so (unlike .dylib) ... 


Steps to Reproduce: 
create a shared library - compile as MODULE ... results in .so 
use system introspection such as a config file - CMAKE_MODULE_LIBRARY_SUFFIX
returns nothing. In comparison, CMAKE_SHARED_LIBRARY_SUFFIX correctly is set to
".dylib"
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-21 14:59 Hartmut SeichterNew Issue                                    
======================================================================


From jamesbigler at gmail.com  Tue Oct 21 17:09:18 2014
From: jamesbigler at gmail.com (James Bigler)
Date: Tue, 21 Oct 2014 15:09:18 -0600
Subject: [cmake-developers] Chaining custom commands in VS 2010
In-Reply-To: <5136351E.2020402@kitware.com>
References: 
 
 <51360EE8.5030104@kitware.com> <5136351E.2020402@kitware.com>
Message-ID: 

I never did actually submit this bug.  Do you know if this is a problem for
VS 2013?

We are running into this more and more with chains of custom commands in
CMake being processed incorrectly by VS.  It's to the point we are going to
have to generate a separate configuration (e.g. nmake or makefile) just to
compile these rules.

On Tue, Mar 5, 2013 at 11:10 AM, Brad King  wrote:

> On 03/05/2013 10:27 AM, Brad King wrote:
> > On 12/04/2012 07:30 PM, James Bigler wrote:
> >> Is there something CMake can do to correct this error/bug with VS 2010?
> >
> > I've narrowed this case down to a single hand-written test.vcxproj
> > file with no connection to CMake.  Here is a session:
>
> This also happens with VS 2012.  I modified the .vcxproj file with
> the patch below and ran msbuild with the "/p:VisualStudioVersion=11.0"
> option.  Otherwise the session is the same.
>
> -Brad
>
> @@ -12,6 +12,7 @@
>    
>     Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'"
> Label="Configuration">
>      Utility
> +    v110
>    
>    
>    
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From timothygu99 at gmail.com  Tue Oct 21 20:08:13 2014
From: timothygu99 at gmail.com (Timothy Gu)
Date: Tue, 21 Oct 2014 17:08:13 -0700
Subject: [cmake-developers] [PATCH] Windows-GNU,
	CYGWIN-GNU: Include corresponding windres script
Message-ID: <1413936493-29603-1-git-send-email-timothygu99@gmail.com>

This is my first post to the mailing list. If possible, this patch should
be backported to CMake 3.1 as well.

---->8----
GNU toolchains on Windows and Cygwin always use windres.

Fixes #7235.

Signed-off-by: Timothy Gu 
---
 Modules/Platform/CYGWIN-GNU.cmake  | 1 +
 Modules/Platform/Windows-GNU.cmake | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/Modules/Platform/CYGWIN-GNU.cmake b/Modules/Platform/CYGWIN-GNU.cmake
index fe25ab2..f193613 100644
--- a/Modules/Platform/CYGWIN-GNU.cmake
+++ b/Modules/Platform/CYGWIN-GNU.cmake
@@ -26,6 +26,7 @@ set(CMAKE_GNULD_IMAGE_VERSION
   "-Wl,--major-image-version,,--minor-image-version,")
 set(CMAKE_GENERATOR_RC windres)
 enable_language(RC)
+include(Platform/CYGWIN-windres)
 macro(__cygwin_compiler_gnu lang)
   # Binary link rules.
   set(CMAKE_${lang}_CREATE_SHARED_MODULE
diff --git a/Modules/Platform/Windows-GNU.cmake b/Modules/Platform/Windows-GNU.cmake
index ffc5657..1ea676e 100644
--- a/Modules/Platform/Windows-GNU.cmake
+++ b/Modules/Platform/Windows-GNU.cmake
@@ -61,6 +61,8 @@ if(NOT CMAKE_GENERATOR_RC AND CMAKE_GENERATOR MATCHES "Unix Makefiles")
   set(CMAKE_GENERATOR_RC windres)
 endif()
 
+include(Platform/Windows-windres)
+
 enable_language(RC)
 
 macro(__windows_compiler_gnu lang)
-- 
1.9.1


From mantis at public.kitware.com  Wed Oct 22 04:49:55 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 22 Oct 2014 04:49:55 -0400
Subject: [cmake-developers] [CMake 0015214]: Error getting iOS compiler
	identification on master
Message-ID: <075c9477771df2c5ed55212d97511b92@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15214 
====================================================================== 
Reported By:                Gregor Jasny
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15214
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-22 04:49 EDT
Last Modified:              2014-10-22 04:49 EDT
====================================================================== 
Summary:                    Error getting iOS compiler identification on master
Description: 
Hello,

If I use cmake to compile the attached example for iOS it fails to get the
compiler identification:

Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler:
Build flags:
Id flags:

The output was:
65
=== BUILD TARGET CompilerIdC OF PROJECT CompilerIdC WITH THE DEFAULT
CONFIGURATION (Debug) ===

Check dependencies
target specifies product type 'com.apple.product-type.tool', but there's no such
product type for the 'iphoneos' platform

** BUILD FAILED **
I bisected the master branch and the offending commit is:
0cce556b5fbe629dccee294aeece7c275343ed64 is the first bad commit
commit 0cce556b5fbe629dccee294aeece7c275343ed64
Author: Brad King 
Date:   Tue Apr 29 09:21:00 2014 -0400

    Xcode: Use sysroot and deployment target to identify compiler

    Use CMAKE_OSX_SYSROOT and CMAKE_OSX_DEPLOYMENT_TARGET to set the Xcode
    SDKROOT and MACOSX_DEPLOYMENT_TARGET build settings.  This is necessary
    because some versions of Xcode select a different compiler based on
    these settings.  We need to make sure the compiler identified during
    language initialization matches what will be used for the actual build.
The attached exmaple work with CMake 3.0.x but not with master. But maybe my toolchain file is incomplete? Thanks, Gregor Steps to Reproduce: unpack the attached tarball, create a build directory and run:
~/src/cmake/bin/cmake -GXcode  -DCMAKE_TOOLCHAIN_FILE=../iOS.toolchain.cmake ..
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error in :
  No CMAKE_C_COMPILER could be found.



CMake Error in :
  No CMAKE_CXX_COMPILER could be found.



-- Configuring incomplete, errors occurred!
Additional Information: Xcode 6.1 on OSX 10.10 (but fails with Xcode 5.1.1, too) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-22 04:49 Gregor Jasny New Issue 2014-10-22 04:49 Gregor Jasny File Added: cmakebug.tar.gz ====================================================================== From mantis at public.kitware.com Wed Oct 22 04:52:28 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 22 Oct 2014 04:52:28 -0400 Subject: [cmake-developers] [CMake 0015215]: Please document CMAKE_XCODE_ATTRIBUTE_* Message-ID: <7290a9580acfc468295637d9c492e96d@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15215 ====================================================================== Reported By: Gregor Jasny Assigned To: ====================================================================== Project: CMake Issue ID: 15215 Category: Documentation Reproducibility: N/A Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-22 04:52 EDT Last Modified: 2014-10-22 04:52 EDT ====================================================================== Summary: Please document CMAKE_XCODE_ATTRIBUTE_* Description: Hello, it took some time to discover how to set global Xcode variables using CMAKE_XCODE_ATTRIBUTE_*. Please document it briefly and cross link this one and XCODE_ATTRIBUTE. Thanks, Gregor ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-22 04:52 Gregor Jasny New Issue ====================================================================== From fabianjul at gmail.com Wed Oct 22 07:49:58 2014 From: fabianjul at gmail.com (Fabian) Date: Wed, 22 Oct 2014 13:49:58 +0200 Subject: [cmake-developers] Xcode Project: Support for DevelopmentTeam In-Reply-To: <54465E79.4070308@kitware.com> References: <54465E79.4070308@kitware.com> Message-ID: Thanks for your response. 2014-10-21 15:24 GMT+02:00 Brad King : > On 10/17/2014 04:16 PM, Fabian wrote: > > Xcode automatically updates the devices list in the Member Center > > Neat. Please explain the developer workflow you envision to configure > the value for local build trees. Would it be something the developer > should explicitly set in every new tree? Should there be a common > configuration in the environment? Can it be detected programmatically? > For some teams, it would probably make sense to set this for every project in the environment as it gets rid of a bunch of code signing issues. However, a membership in the developer program is needed and I do not know an easy way to detect this. An option might be to parse the output of "certtool y" for "iPhone Distribution: ()"; notice the in brackets. However, some people (myself included) have to handle memberships in multiple programs, so there would be some manual selection involved anyway. > In the CMake source I noticed that 'BuildIndependentTargetsInParallel' > > is already getting set. This could be extendet to add the > 'TargetAttributes' > > section. > > Yes, that looks like the right place if you want to try a patch. > I looked through the source for a while but I found that for me it would require too much work to fully patch it, since the target ID also needs to be read from somewhere and included in the pbxproj. I would highly appreciate it if you took the time, as it would probably require a fraction of what I would have to invest. Regards, Fabian -------------- next part -------------- An HTML attachment was scrubbed... URL: From domen.vrankar at gmail.com Wed Oct 22 08:08:59 2014 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 22 Oct 2014 14:08:59 +0200 Subject: [cmake-developers] [CMake] [CPack] RPM generator creates %dir for /usr/local/xxx In-Reply-To: References: <1413976466922-7588778.post@n2.nabble.com> <5447930E.801@classdesign.com> Message-ID: Moving the conversation to developers mailing list. More docs on this for 2.8.12: > > http://www.cmake.org/cmake/help/v2.8.12/cpack.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION > > I guess that "/usr/local" may be added to > CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST default list values. > > For Domen: see the history of this story here: > http://public.kitware.com/Bug/view.php?id=13609 > I am familiar with this variable but I haven't noticed until now that not all the paths Dubrovskiy Viacheslav listed in bug report were removed from auto listing. Currently /etc /etc/init.d /usr /usr/share /usr/share/doc /usr/bin /usr/lib /usr/lib64 /usr/include paths are removed. I can add /usr/local to the list. Are there any additional paths from the above bug report that anyone thinks should be added? I would assume that all of the directories from Linux filesystem hierarchy standard (http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard, http://www.pathname.com/fhs/pub/fhs-2.3.html) should be excluded on Linux however UNIX filesystem hierarchy has less directories listed on wiki ( http://en.wikipedia.org/wiki/Unix_filesystem) and I am not even certain that all flavours of UNIX use them. I think that at least directories that are listed both for Linux and Unix should be added. What is the opinion of others? Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Wed Oct 22 09:18:58 2014 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 22 Oct 2014 15:18:58 +0200 Subject: [cmake-developers] [CMake] [CPack] RPM generator creates %dir for /usr/local/xxx In-Reply-To: References: <1413976466922-7588778.post@n2.nabble.com> <5447930E.801@classdesign.com> Message-ID: 2014-10-22 14:08 GMT+02:00 Domen Vrankar : > Moving the conversation to developers mailing list. > > More docs on this for 2.8.12: >> >> http://www.cmake.org/cmake/help/v2.8.12/cpack.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION >> >> I guess that "/usr/local" may be added to >> CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST default list values. >> >> For Domen: see the history of this story here: >> http://public.kitware.com/Bug/view.php?id=13609 >> > > I am familiar with this variable but I haven't noticed until now that not > all the paths Dubrovskiy Viacheslav > listed in bug > report were removed from auto listing. > This was a conservative choice in order to avoid backward compatibilty issue. I wasn't sure at that time that all (RPM-based) distros had the whole list of dirs and I think there was at least some discrepancy between Fedora and SuSE. I was planning (in my mind) to craft a distro-specific list of excluded dir into CPackRPM just in case... Then ... nothing was done but the CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST* vars :-( -- Erk L'?lection n'est pas la d?mocratie -- http://www.le-message.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Wed Oct 22 09:44:36 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 22 Oct 2014 09:44:36 -0400 Subject: [cmake-developers] [CMake 0015216]: Ninja makes bad phony targets with parallel "sub" directory and custom CMAKE_LIBRARY_OUTPUT_DIRECTORY Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15216 ====================================================================== Reported By: Joseph Lisee Assigned To: ====================================================================== Project: CMake Issue ID: 15216 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-22 09:44 EDT Last Modified: 2014-10-22 09:44 EDT ====================================================================== Summary: Ninja makes bad phony targets with parallel "sub" directory and custom CMAKE_LIBRARY_OUTPUT_DIRECTORY Description: I have project where the main build directory is on the same level as some "sub" directories, for example: primary/CMakeLists.txt secondary/CMakeLists.txt primary/build/ When I use the CMAKE_LIBRARY_OUTPUT_DIRECTORY to put all the lib files into primary/lib the build fails with ninja but keeps working with Make. The ninja error: ninja: error: '../lib/libtestlib.so', needed by 'CMakeFiles/main.dir/main.cpp.o', missing and no known rule to make it Inside build.ninja the library is being built with the absolute path "/tmp/ninja-parallel-sub-test/primary/lib/libtestlib.so" while other places refer to it as "../lib/libtestlib.so". Adding the following phony rule fixes the error: build ../lib/libtestlib.so: phony /tmp/ninja-parallel-sub-test/primary/lib/libtestlib.so Steps to Reproduce: Steps: * unzip attached zip files * cd primary * mkdir build * cmake .. -G Ninja * ninja Switching to Make will result in primary/bin/main and primary/lib/libtestlib.so appearing properly. Make sure to clean up the primary/bin & primary/lib directory while switching build systems, if not done ninja will appear to work only because it's not trying to build the targets. Additional Information: This is broken with the latest git head fc9041d0249c113cb812d69ee0b8f1411f1eea15, CMake 3.0.2 and CMake 2.8.9. These bugs are related: 0014972, 0014414 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-22 09:44 Joseph Lisee New Issue 2014-10-22 09:44 Joseph Lisee File Added: ninja-parallel-sub-test.zip ====================================================================== From brad.king at kitware.com Wed Oct 22 10:42:40 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Oct 2014 10:42:40 -0400 Subject: [cmake-developers] [PATCH] Windows-GNU, CYGWIN-GNU: Include corresponding windres script In-Reply-To: <1413936493-29603-1-git-send-email-timothygu99@gmail.com> References: <1413936493-29603-1-git-send-email-timothygu99@gmail.com> Message-ID: <5447C260.8080500@kitware.com> On 10/21/2014 08:08 PM, Timothy Gu wrote: > enable_language(RC) > +include(Platform/CYGWIN-windres) [snip] > +include(Platform/Windows-windres) > + > enable_language(RC) The enable_language(RC) call should internally include those modules. In CMakeRCInformation: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeRCInformation.cmake;hb=v3.0.2#l29 the line include(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME} OPTIONAL) should do it. -Brad From pascal.bach at siemens.com Wed Oct 22 10:53:08 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Wed, 22 Oct 2014 14:53:08 +0000 Subject: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as tests for Windows CE In-Reply-To: <54465F5A.6000208@kitware.com> References: <1413883468-499-1-git-send-email-pascal.bach@siemens.com> <5446586D.6010107@kitware.com> <355BE46A91031048906B695426A8D8E616AE6358@DEFTHW99EH4MSX.ww902.siemens.net> <54465F5A.6000208@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616AE6701@DEFTHW99EH4MSX.ww902.siemens.net> > > > I even would prefer to not hardcode the SDK but I was unable to list key > entries from the registry. > > > > Usually all installed SDKs are listed as subkeys of > HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows CE Tools\\SDKs > in this case it is SDK_AM335X_SK_WEC2013_V310. > > > > I think the test would be nicer if it checks for available SDKs and just picks > the first. > > > > Any ideas how to do this? > > Within a block guarded by if(CMAKE_HOST_WIN32) you could > use execute_process to run the "reg" command-line tool. > Am I right that when using the reg tool I need to include the Wow6432Node again? Pascal From brad.king at kitware.com Wed Oct 22 10:59:30 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Oct 2014 10:59:30 -0400 Subject: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as tests for Windows CE In-Reply-To: <355BE46A91031048906B695426A8D8E616AE6701@DEFTHW99EH4MSX.ww902.siemens.net> References: <1413883468-499-1-git-send-email-pascal.bach@siemens.com> <5446586D.6010107@kitware.com> <355BE46A91031048906B695426A8D8E616AE6358@DEFTHW99EH4MSX.ww902.siemens.net> <54465F5A.6000208@kitware.com> <355BE46A91031048906B695426A8D8E616AE6701@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <5447C652.6030402@kitware.com> On Wed, Oct 22, 2014 at 10:53 AM, Bach, Pascal wrote: > Am I right that when using the reg tool I need to include > the Wow6432Node again? Possibly. I'm not particularly familiar with it, but there are two of them: C:\Windows\System32\reg.exe C:\Windows\SysWOW64\reg.exe Perhaps they take different views. We don't know which one will be in the PATH. I don't think Wow6432Node will exist on a 32-bit host so you may need to query both with and without it. -Brad From brad.king at kitware.com Wed Oct 22 10:59:36 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Oct 2014 10:59:36 -0400 Subject: [cmake-developers] Chaining custom commands in VS 2010 In-Reply-To: References: <51360EE8.5030104@kitware.com> <5136351E.2020402@kitware.com> Message-ID: <5447C658.30909@kitware.com> On 10/21/2014 05:09 PM, James Bigler wrote: > I never did actually submit this bug. Do you know if this is a problem for VS 2013? Yes, I just tried the case I previously posted: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/44820/focus=6288 and the results are identical even after adding v120 to the project file. -Brad From brad.king at kitware.com Wed Oct 22 11:02:14 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Oct 2014 11:02:14 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <54467F83.4030309@kitware.com> References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com> <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com> <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com> <5446610A.8020609@kitware.com> <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl> <54466DFC.4070403@kitware.com> <5520EEFC-3B8E-4487-992E-F36700486256@java.pl> <54467F83.4030309@kitware.com> Message-ID: <5447C6F6.8060708@kitware.com> On 10/21/2014 11:45 AM, Brad King wrote: > I cherry-picked it over on top of the revised/squashed copy of > the topic that was merged to 'master': > > BundleUtilities: Ensure framework symlinks and Info.plist exist > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41564ff2 The nightly binary works again. The first working version after this gap is now: http://www.cmake.org/files/dev/cmake-3.1.20141021-gffa1-Darwin64-universal.dmg Thanks! -Brad From brad.king at kitware.com Wed Oct 22 11:02:36 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Oct 2014 11:02:36 -0400 Subject: [cmake-developers] CMake.app Qt5 vs Qt4 on 10.10 In-Reply-To: References: Message-ID: <5447C70C.3060203@kitware.com> On 10/21/2014 12:16 PM, Adam Strzelecki wrote: > Following discussion regarding fix-OSX-bundle-rpaths-and-Qt5 topic > I just wanted to share with you how CMake looks with Qt4 vs Qt5 on Yosemite: > > https://www.dropbox.com/s/knnybhed8fahste/CMake3.1rc1-Qt4.8.6-Yosemite.png > https://www.dropbox.com/s/tm95rntexn4z6j6/CMake3.1rc1-Qt5.4-Yosemite.png Cool, thanks for testing both versions. We'd like to switch to Qt5 when we get a chance to update our binary build infrastructure for it. Thanks, -Brad From brad.king at kitware.com Wed Oct 22 11:18:55 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Oct 2014 11:18:55 -0400 Subject: [cmake-developers] ExternalProject CMAKE_ARGS and CMAKE_CACHE_ARGS arguments In-Reply-To: <5446672F.3070501@gmail.com> References: <543FE392.7020706@gmail.com> <54451383.4070809@kitware.com> <5446672F.3070501@gmail.com> Message-ID: <5447CADF.8020804@kitware.com> On 10/21/2014 10:01 AM, Daniele E. Domenichelli wrote: > I would like to be able to set some some variables (for example > CMAKE_BUILD_TYPE) for all the "external project" according to the value > in the "super-project", but the same time I would like to be able to > change them (for example change CMAKE_BUILD_TYPE to Debug if I'm > building in Release mode) for just one external project without changing > it in all of them, and having to rebuild everything. How about a new option like "CMAKE_CACHE_DEFAULT_ARGS" for that? -Brad From ono at java.pl Wed Oct 22 13:29:00 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 22 Oct 2014 19:29:00 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <5447C6F6.8060708@kitware.com> References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com> <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com> <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com> <5446610A.8020609@kitware.com> <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl> <54466DFC.4070403@kitware.com> <5520EEFC-3B8E-4487-992E-F36700486256@java.pl> <54467F83.4030309@kitware.com> <5447C6F6.8060708@kitware.com> Message-ID: > The nightly binary works again. The first working version after > this gap is now: Great! Now, do you plan code signing the CMake.app? Do you guys have Mac Developer ID? --Adam From sean at rogue-research.com Wed Oct 22 13:33:29 2014 From: sean at rogue-research.com (Sean McBride) Date: Wed, 22 Oct 2014 13:33:29 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com> <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com> <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com> <5446610A.8020609@kitware.com> <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl> <54466DFC.4070403@kitware.com> <5520EEFC-3B8E-4487-992E-F36700486256@java.pl> <54467F83.4030309@kitware.com> <5447C6F6.8060708@kitware.com> Message-ID: <20141022173329.1241639395@mail.rogue-research.com> On Wed, 22 Oct 2014 19:29:00 +0200, Adam Strzelecki said: >> The nightly binary works again. The first working version after >> this gap is now: > >Great! Now, do you plan code signing the CMake.app? Do you guys have Mac >Developer ID? The bug for that is here BTW, created over 2 years ago now... Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From guillaume.papin at parrot.com Thu Oct 23 04:09:53 2014 From: guillaume.papin at parrot.com (Guillaume Papin) Date: Thu, 23 Oct 2014 10:09:53 +0200 Subject: [cmake-developers] FindBoost.cmake cannot find some libraries when cross-compiling In-Reply-To: References: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan> <4037EE152A73A9448DAD73C415D4D8C0873819@MBX79.aswsp.lan> Message-ID: <5448B7D1.1030604@parrot.com> Please find the patch attached to this email. Let me know if anything is wrong. Best, Guillaume On 10/16/2014 05:09 PM, Chuck Atkins wrote: > Guillaume, > > Please see CONTRIBUTING.rst in the top level of the CMake source > tree. If you can please create and post a patch against cmake master > then I'll work on getting it merged into cmake next. Thanks for the > bug fix! > > - Chuck > > On Thu, Oct 16, 2014 at 10:32 AM, Chuck Atkins > > wrote: > > This looks like a reasonable way to accomplish this right now. > The underlying prioblem is that ther's no way to specify which > path types get re-rooted and which don't. Ideally you'd want to > be able to specify in the toolchain for something like this that > all paths operate in "ONLY" mode except HINTS, which you would > want to place in NEVER mode. I'm currently working on just such a > feature but in the meantime, forcing it like this in the FindBoost > module looks reasonable. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FindBoost-fix-re-rooting.patch Type: text/x-patch Size: 1729 bytes Desc: not available URL: From konstantin at podsvirov.pro Thu Oct 23 08:45:36 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 23 Oct 2014 16:45:36 +0400 Subject: [cmake-developers] [TEST REQUEST] CPack IFW generator on OSX Message-ID: <1482491414068336@web15m.yandex.ru> Hello developers! Can anybody test IFW generator on Mac? Regards, Konstantin Podsvirov From sean at rogue-research.com Thu Oct 23 11:09:07 2014 From: sean at rogue-research.com (Sean McBride) Date: Thu, 23 Oct 2014 11:09:07 -0400 Subject: [cmake-developers] [TEST REQUEST] CPack IFW generator on OSX In-Reply-To: <1482491414068336@web15m.yandex.ru> References: <1482491414068336@web15m.yandex.ru> Message-ID: <20141023150907.2007902885@mail.rogue-research.com> On Thu, 23 Oct 2014 16:45:36 +0400, Konstantin Podsvirov said: >Can anybody test IFW generator on Mac? Probably... What is it? :) How would I test it? If you can give me clear instructions, I can update one or more of my dashboards to test it. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From brad.king at kitware.com Thu Oct 23 11:13:15 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Oct 2014 11:13:15 -0400 Subject: [cmake-developers] Support of codesign In-Reply-To: <6639644.c5E5zbx6zX@stryke> References: <543FD64A.1040907@kitware.com> <6639644.c5E5zbx6zX@stryke> Message-ID: <54491B0B.2080705@kitware.com> On 10/21/2014 11:44 AM, Clinton Stimpson wrote: > Because the design of this Bundle generator is not consistent with the rest of > the CPack generators, you don't have this same chance, and the only way to do > customization is to keep adding patches like yours. Is this something that should be refactored in CPack to address independently of the codesign changes? Thanks, -Brad From konstantin at podsvirov.pro Thu Oct 23 11:50:55 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 23 Oct 2014 19:50:55 +0400 Subject: [cmake-developers] [TEST REQUEST] CPack IFW generator on OSX In-Reply-To: <20141023150907.2007902885@mail.rogue-research.com> References: <1482491414068336@web15m.yandex.ru> <20141023150907.2007902885@mail.rogue-research.com> Message-ID: <315501414079455@web4m.yandex.ru> Hi Sean! 23.10.2014, 19:09, "Sean McBride" : > On Thu, 23 Oct 2014 16:45:36 +0400, Konstantin Podsvirov said: >> Can anybody test IFW generator on Mac? > > Probably... What is it? :) How would I test it? If you can give me clear instructions, I can update one or more of my dashboards to test it. Thanks that have responded. CPack IFW generator generates the installer with a graphical user interface. I have no ideas for automated testing. But you can try to create the installer and see how it works. On the CMake Wiki has an article "CMake:Install Component With CPack": http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack CPack IFW generator will cope with this task. Shot with a small edit to IFW generator available here: http://git.podsvirov.pro/?p=kitware/componentexample.git;a=snapshot;h=refs/heads/develop;sf=tgz You must use the latest version of CMake for developers. You can find here: http://www.cmake.org/files/dev Just need to install Qt Installer Framework from here: http://download.qt-project.org/official_releases/qt-installer-framework/1.5.0 Then initialize the project from the snapshot. Further configuration. Must be set to ON (enble) advanced variable CPACK_BINARY_IFW. Also must be set to OFF (disable) the rest CPACK_BINARY_{XXX} variables. Start the generation. Make the target "package" and get the installer in the folder Assembly. Run the installer. We should see the installer similar to what is specified in the Wiki. For Linux and Windows I got these installers: http://ifw.podsvirov.pro/cmake/old/cpackifw-componentexample-linux.png http://ifw.podsvirov.pro/cmake/old/cpackifw-componentexample-windows.png Then click "next" and check that mylibapp start. Here is an approximate algorithm. Regards, Konstantin Podsvirov From clinton at elemtech.com Thu Oct 23 12:21:31 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Thu, 23 Oct 2014 10:21:31 -0600 Subject: [cmake-developers] Support of codesign In-Reply-To: <54491B0B.2080705@kitware.com> References: <6639644.c5E5zbx6zX@stryke> <54491B0B.2080705@kitware.com> Message-ID: <235694142.S1LGzdHcBU@stryke> On Thursday, October 23, 2014 11:13:15 AM Brad King wrote: > On 10/21/2014 11:44 AM, Clinton Stimpson wrote: > > Because the design of this Bundle generator is not consistent with the > > rest of the CPack generators, you don't have this same chance, and the > > only way to do customization is to keep adding patches like yours. > > Is this something that should be refactored in CPack to address > independently of the codesign changes? Actually, the design is intentional -- that is, it has the feature of creating the application bundle for you, which involves handling for icons, Info.plist, and now the proposed code signing. Alternatively, we have handling for icons and Info.plist in add_executable(... MACOSX_BUNDLE ...). So basically, its duplicated functionality. There are 2 approaches: 1. set(INSTALL_LIB_DIR lib) set(INSTALL_BIN_DIR bin) add_library(foolib ...) install(TARGETS foolib RUNTIME DESTINATION ${INSTALL_LIB_DIR}) add_executable(foo ...) target_link_libraries(foo foolib) add_executable(foo2 ...) target_link_libraries(foo2 foolib) install(TARGETS foo foo2 RUNTIME DESTINATION ${INSTALL_BIN_DIR}) set(CPACK_GENERATOR Bundle) set(CPACK_BUNDLE_STARTUP_COMMAND "StartScript") include(CPack) The end result is a foo.app/Contents/MacOS/foo (renamed from StartScript) foo.app/Contents/MacOS/bin/foo foo.app/Contents/MacOS/bin/foo2 foo.app/Contents/MacOS/lib/libfoo.dylib If any other CPack generator is used (TGZ, DragNDrop, PackageMaker, etc...), the package layout will be bin/foo bin/foo2 lib/libfoo.dylib 2. set(INSTALL_LIB_DIR foo.app/Contents/MacOS) set(INSTALL_BIN_DIR foo.app/Contents/MacOS) add_library(foolib ...) install(TARGETS foolib RUNTIME DESTINATION ${INSTALL_LIB_DIR}) add_executable(foo MACOSX_BUNDLE ...) target_link_libraries(foo foolib) add_executable(foo2 MACOSX_BUNDLE ...) target_link_libraries(foo2 foolib) install(TARGETS foo foo2 BUNDLE DESTINATION . RUNTIME DESTINATION ${INSTALL_BIN_DIR}) include(CPack) The end result is a foo.app/Contents/MacOS/foo foo.app/Contents/MacOS/foo2 foo.app/Contents/MacOS/libfoo.dylib This gives consistent results with all CPack generators (TGZ, DragNDrop, PackageMaker, etc..) except for the Bundle generator. Similar to #2, CMake itself uses an interesting approach of modifying CMAKE_INSTALL_PREFIX to redirect the installation into the CMake.app bundle, without modifying the DESTINATION option to the install() commands. If the Bundle generator is changed to be made consistent with other cpack generators (which implies you lose the bundle making feature), you end up with what the DragNDrop generator is. And now there is code signing.... There is a chance that code signing will be introduced into CMake using another mechanism that works across platforms and across cpack generators. How that will interact with the propose patch, I do not know, so I do have some concern about adding this patch. So Brad, does this give you some idea of the situation? Do you have some thoughts on merging the patch? Clint From ono at java.pl Thu Oct 23 13:01:39 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 23 Oct 2014 19:01:39 +0200 Subject: [cmake-developers] Support of codesign In-Reply-To: <235694142.S1LGzdHcBU@stryke> References: <6639644.c5E5zbx6zX@stryke> <54491B0B.2080705@kitware.com> <235694142.S1LGzdHcBU@stryke> Message-ID: <3699002F-4034-4D0D-94B8-CD409DBA9A23@java.pl> Let me put my 2?. I have feeling that we are mixing up signing (install) packages, such as .pkg (OSX) or .msi (Windows), with signing bundles .app or whatever OSX binaries (that can keep signature inside macho). I think that CPack should be responsible of signing only what it creates. Since CPack does not create .app bundle but just packs it into .pkg, .dmg or whatever else it shouldn't touch .app. Then code signing .app bundle should be part of install (cmake_install.cmake), triggered once the .app bundle is complete (final), probably after fixup_bundle. Once may not even want to use CPack, but still want to code-sign .app when installing. But this is just my personal opinion, Also I don't see any reason we need to implement that in C++ as this can be handled with cmake scripting capabilities. --Adam From brad.king at kitware.com Thu Oct 23 13:40:58 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Oct 2014 13:40:58 -0400 Subject: [cmake-developers] Support of codesign In-Reply-To: <3699002F-4034-4D0D-94B8-CD409DBA9A23@java.pl> References: <6639644.c5E5zbx6zX@stryke> <54491B0B.2080705@kitware.com> <235694142.S1LGzdHcBU@stryke> <3699002F-4034-4D0D-94B8-CD409DBA9A23@java.pl> Message-ID: <54493DAA.1040600@kitware.com> On 10/23/2014 12:21 PM, Clinton Stimpson wrote: > Actually, the design is intentional -- that is, it has the feature of creating > the application bundle for you, which involves handling for icons, Info.plist, > and now the proposed code signing. Alternatively, we have handling for icons > and Info.plist in add_executable(... MACOSX_BUNDLE ...). So basically, its > duplicated functionality. Okay, so IIUC the CPack Bundle generator helps create .app bundles out of projects that are not aware of them. Projects that are aware and that use MACOSX_BUNDLE should probably not use the CPack Bundle generator and instead use the DragNDrop generator. > If the Bundle generator is changed to be made consistent with other cpack > generators (which implies you lose the bundle making feature), you end up with > what the DragNDrop generator is. Okay, so it does not make sense to change it. > And now there is code signing.... There is a chance that code signing will be > introduced into CMake using another mechanism that works across platforms and > across cpack generators. How that will interact with the propose patch, I do > not know, so I do have some concern about adding this patch. [snip] On 10/23/2014 01:01 PM, Adam Strzelecki wrote: > I think that CPack should be responsible of signing only what it creates. > Since CPack does not create .app bundle ... it shouldn't touch .app. > Then code signing .app bundle should be part of install (cmake_install.cmake) I think Adam's suggestion makes sense. However, in the case of the Bundle generator that the proposed patch modifies CPack *is* creating the .app bundle and so should be able to sign it. Therefore the patch will not get in the way of future CMake support for signing .app during installation, especially because it requires both explicit configuration and use of the CPack Bundle generator that according to the above recommendation should not be used for projects aware of MACOSX_BUNDLE. In order to keep it further out of the way, the related variables should be specific to the Bundle generator. Instead of: CPACK_APPLE_CERT_APP CPACK_APPLE_ENTITLEMENTS CPACK_APPLE_CODESIGN_FILES perhaps they should be called: CPACK_BUNDLE_APPLE_CERT_APP CPACK_BUNDLE_APPLE_ENTITLEMENTS CPACK_BUNDLE_APPLE_CODESIGN_FILES Thanks, -Brad From bill.hoffman at kitware.com Thu Oct 23 17:40:05 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 23 Oct 2014 17:40:05 -0400 Subject: [cmake-developers] Fwd: Re: Severe behavioural change regressions in release branch In-Reply-To: References: Message-ID: <544975B5.7070002@kitware.com> FYI, a conversation on the KDE mailing list. -------- Forwarded Message -------- Subject: Re: Severe behavioural change regressions in release branch Date: Fri, 24 Oct 2014 10:11:02 +1300 From: Ben Cooksley Reply-To: KDE build system (cmake) To: kde-frameworks-devel at kde.org CC: kde-core-devel , KDE build system (cmake) On Fri, Oct 24, 2014 at 10:05 AM, Ben Cooksley wrote: > Hi all, > > It would appear that CMake 3.0 to 3.1 introduces a colossal change in > behaviour. This change totally breaks all KDE projects which use > Extra-CMake-Modules, as necessary headers are no longer installed. > > This has become an issue following http://build.kde.org/job/cmake/160/ > which has led to a significant number of our projects failing to build > from source as can be seen here - > http://build.kde.org/view/Frameworks/ > > Someone needs to investigate this before CMake 3.1.0 goes out the door > and fix it. I've no idea what the policy is in the CMake world, but in > the KDE world this sort of compatibility breakage would be a release > blocker. And it would seem that the CMake developers prefer to live in their own closed off little bubble. My post was automatically rejected. Someone who is subscribed there will have to take this up with them. I'm extremely displeased. If they release CMake 3.1.0 with this regression, we should consider forking CMake as their developers can't be trusted to ensure our code remains buildable. > > Regards, > Ben Cooksley > KDE Sysadmin Regards, Ben _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem at kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem From ben.boeckel at kitware.com Thu Oct 23 22:34:27 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 23 Oct 2014 22:34:27 -0400 Subject: [cmake-developers] Fwd: Re: Severe behavioural change regressions in release branch In-Reply-To: <544975B5.7070002@kitware.com> References: <544975B5.7070002@kitware.com> Message-ID: <20141024023427.GA11952@bronto-burt.dev.benboeckel.net> [ Adding Ben Cooksley to the CC list; feel free to reply privately and I'll forward to the list if you keep getting rejected from it. ] Hi, > > It would appear that CMake 3.0 to 3.1 introduces a colossal change in > > behaviour. This change totally breaks all KDE projects which use > > Extra-CMake-Modules, as necessary headers are no longer installed. This is indeed true (between the new variable expansion code (CMP0053) and 'if()' variable expansion rules (CMP0054), there's a lot of changes otherwise); however, all you should get are warnings about the change, not the actual behavior change without actually bumping your minimum version or enabling the policy explicitly. > > This has become an issue following http://build.kde.org/job/cmake/160/ > > which has led to a significant number of our projects failing to build > > from source as can be seen here - > > http://build.kde.org/view/Frameworks/ So looking at kdelibs4support, I see lots of CMP0053 warnings (due to the @var@ expansion in normal CMakeLists.txt processing which was obscure and undocumented) and CMP0048 warnings (I'm not familiar with it, but it's about project() offering version variables). In kdelibs, I see CMP0022 and CMP0046 warnings (both related to target_link_libraries and things which are likely bugs anyways such as depending on non-existent targets or a mismatch between INTERFACE_LINK_LIBRARIES and LINK_INTERFACE_LIBRARIES). However, I do see: 04:35:39 -- Installing: /srv/jenkins/workspace/kdelibs_master/local-inst/srv/jenkins/install/linux/x86_64/g++/latest-qt4/kde/kdelibs/inst/include/kpluginfactory.h in kdelibs' logs, so it makes me think that: /srv/jenkins/workspace/kdelibs4support_master_qt5/src/kssl/kcm/kcmssl.cpp:27:28: fatal error: kpluginfactory.h: No such file or directory implies the build isn't getting the include directories plumbed through properly. I'll try a build tomorrow (or if it'd be possible to run a Jenkins build of kdelibs4support with make VERBOSE=1, that'd be great too since the environment would be consistent then). My gut feeling is some CMP0054 corner case isn't caught and falls through to the new behavior without a warning (or the old behavior was subtly changed in the process), but that's just a shot in the dark. > > Someone needs to investigate this before CMake 3.1.0 goes out the door > > and fix it. I've no idea what the policy is in the CMake world, but in > > the KDE world this sort of compatibility breakage would be a release > > blocker. Thanks for testing the rc; it should be a blocker on our side too. It would indeed be bad for 3.1.0 to release with such breaking changes. We try really hard for backwards compatibility. Obviously our test coverage is lacking somewhere. > And it would seem that the CMake developers prefer to live in their > own closed off little bubble. My post was automatically rejected. > Someone who is subscribed there will have to take this up with them. > I'm extremely displeased. > > If they release CMake 3.1.0 with this regression, we should consider > forking CMake as their developers can't be trusted to ensure our code > remains buildable. For preventing this in the future, would it be possible to set up Jenkins build to submit builds for kdelibs and a few other libraries which would test CMake master and submit to CMake's dashboard some results nightly so we can catch these problems more quickly? There are examples in: https://github.com/Kitware/CMake/tree/master/Tests/Contracts for how this is done for other projects already. The instance would then just to set something like CMAKE_CONTRACT_PROJECTS=kdelibs and run CMake's test suite and submit to the dashboard. Thanks, --Ben From mantis at public.kitware.com Fri Oct 24 02:50:59 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 24 Oct 2014 02:50:59 -0400 Subject: [cmake-developers] [CMake 0015217]: CPack make wrong dependencies between components Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15217 ====================================================================== Reported By: sudakov_ivan Assigned To: ====================================================================== Project: CMake Issue ID: 15217 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-24 02:50 EDT Last Modified: 2014-10-24 02:50 EDT ====================================================================== Summary: CPack make wrong dependencies between components Description: I have three components: a,b,c and code: install(FILES ${CMAKE_CURRENT_LIST_FILE} DESTINATION /tmp COMPONENT a) install(FILES ${CMAKE_CURRENT_LIST_FILE} DESTINATION /tmp COMPONENT b) install(FILES ${CMAKE_CURRENT_LIST_FILE} DESTINATION /tmp COMPONENT c) SET(CPACK_RPM_a_PACKAGE_REQUIRES "d") SET(CPACK_RPM_c_PACKAGE_REQUIRES "e") In result: a requires d - ok b requires d - wrong c requires e - ok There is the same situation with PROVIDES Additional Information: If I set REQUIRES for ALL components it's work fine: SET(CPACK_RPM_a_PACKAGE_REQUIRES "d") SET(CPACK_RPM_c_PACKAGE_REQUIRES "e") SET(CPACK_RPM_b_PACKAGE_REQUIRES "") ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-24 02:50 sudakov_ivan New Issue ====================================================================== From pascal.bach at siemens.com Fri Oct 24 09:21:11 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Fri, 24 Oct 2014 15:21:11 +0200 Subject: [cmake-developers] [PATCHv2] Tests: Run Tutorial steps 1-4 as tests for Windows CE In-Reply-To: <5446586D.6010107@kitware.com> References: <5446586D.6010107@kitware.com> Message-ID: <1414156871-28308-1-git-send-email-pascal.bach@siemens.com> --- Tests/CMakeLists.txt | 46 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 45 insertions(+), 1 deletion(-) diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt index 25cc846..2ac13c2 100644 --- a/Tests/CMakeLists.txt +++ b/Tests/CMakeLists.txt @@ -1781,6 +1781,20 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release endif() if(WIN32) + # Macro to search for available Windows CE SDKs in the windows Registry + macro(select_wince_sdk selected_sdk) + if(CMAKE_HOST_WIN32) + execute_process(COMMAND reg QUERY "HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows CE Tools\\SDKs" + OUTPUT_VARIABLE sdk_reg + ERROR_VARIABLE my_err) + string(REGEX REPLACE "HKEY_LOCAL_MACHINE\\\\SOFTWARE\\\\Wow6432Node\\\\Microsoft\\\\Windows CE Tools\\\\SDKs\\\\" ";" sdk_list "${sdk_reg}") + list(LENGTH sdk_list sdk_list_len) + if (${sdk_list_len} GREATER 1) + list(GET sdk_list 1 ${selected_sdk}) # The first entry is always empty due to the regex replace above + endif() + endif(CMAKE_HOST_WIN32) + endmacro(select_wince_sdk) + set(reg_vs10 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\10.0;InstallDir]") set(reg_vs11 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\11.0;InstallDir]") set(reg_vs12 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\12.0;InstallDir]") @@ -1788,8 +1802,9 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release set(reg_ws81 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v8.1;InstallationFolder]") set(reg_wp80 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\WindowsPhone\\v8.0;InstallationFolder]") set(reg_wp81 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\WindowsPhone\\v8.1;InstallationFolder]") + select_wince_sdk(reg_wince) set(reg_tegra "[HKEY_LOCAL_MACHINE\\SOFTWARE\\NVIDIA Corporation\\Nsight Tegra;sdkRoot]") - foreach(reg vs10 vs11 vs12 ws80 ws81 wp80 wp81 tegra) + foreach(reg vs10 vs11 vs12 ws80 ws81 wp80 wp81 wince tegra) get_filename_component(r "${reg_${reg}}" ABSOLUTE) if(IS_DIRECTORY "${r}") set(${reg} 1) @@ -1835,6 +1850,35 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release endif() endif() + if(WIN32 AND reg_wince) + macro(add_test_VSWinCE name generator systemName systemVersion generatorPlatform) + # TODO: Fix the tutorial to make it work in cross compile + # currently the MakeTable is build for target and can not be used on the host + # This happens in part 5 so we build only part 1-4 of the tutorial + foreach(STP RANGE 1 4) + add_test(NAME "TutorialStep${STP}.${name}" COMMAND ${CMAKE_CTEST_COMMAND} + --build-and-test + "${CMake_SOURCE_DIR}/Tests/Tutorial/Step${STP}" + "${CMake_BINARY_DIR}/Tests/Tutorial/Step${STP}_${name}" + --build-generator "${generator}" + --build-project Tutorial + --build-config $ + --build-options -DCMAKE_SYSTEM_NAME=${systemName} + -DCMAKE_SYSTEM_VERSION=${systemVersion} + -DCMAKE_GENERATOR_PLATFORM=${generatorPlatform}) + list(APPEND TEST_BUILD_DIRS "${CMake_BINARY_DIR}/Tests/Tutorial/Step${STP}_${name}") + endforeach() + endmacro() + + if(vs11) + add_test_VSWinCE(vs11-ce80-ARM "Visual Studio 11 2012" WindowsCE 8.0 ${reg_wince}) + endif() + + if(vs12) + add_test_VSWinCE(vs12-ce80-ARM "Visual Studio 12 2013" WindowsCE 8.0 ${reg_wince}) + endif() + endif() + if(tegra AND NOT "${CMake_SOURCE_DIR};${CMake_BINARY_DIR}" MATCHES " ") macro(add_test_VSNsightTegra name generator) add_test(NAME VSNsightTegra.${name} COMMAND ${CMAKE_CTEST_COMMAND} -- 1.7.10.4 From brad.king at kitware.com Fri Oct 24 09:50:17 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 24 Oct 2014 09:50:17 -0400 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: <20141024023427.GA11952@bronto-burt.dev.benboeckel.net> References: <544975B5.7070002@kitware.com> <20141024023427.GA11952@bronto-burt.dev.benboeckel.net> Message-ID: <544A5919.6000804@kitware.com> On 10/23/2014 10:34 PM, Ben Boeckel wrote: > implies the build isn't getting the include directories plumbed through > properly. I reproduced it locally far enough to find that kcoreaddons is not installing headers like include/KF5/KCoreAddons/kpluginfactory.h when built with 3.1 but is with 3.0. I narrowed it down to a test case using just ECM: ------------------------------------------------------------------- $ cat CMakeLists.txt cmake_minimum_required(VERSION 3.0) project(Minimal NONE) file(WRITE "${CMAKE_CURRENT_SOURCE_DIR}/header.h" "header") find_package(ECM 1.3.0 REQUIRED NO_MODULE) set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH}) include(ECMGenerateHeaders) ecm_generate_headers(headers HEADER_NAMES header REQUIRED_HEADERS headers ) message(WARNING " headers=[${headers}]") ecm_generate_headers(headers HEADER_NAMES header REQUIRED_HEADERS headers ) message(FATAL_ERROR " headers=[${headers}]") ------------------------------------------------------------------- With 3.0 we see the list of headers accumulate. With 3.1 just the first one works and the rest do not. -Brad From brad.king at kitware.com Fri Oct 24 10:02:31 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 24 Oct 2014 10:02:31 -0400 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: <544A5919.6000804@kitware.com> References: <544975B5.7070002@kitware.com> <20141024023427.GA11952@bronto-burt.dev.benboeckel.net> <544A5919.6000804@kitware.com> Message-ID: <544A5BF7.2000800@kitware.com> On 10/24/2014 09:50 AM, Brad King wrote: > With 3.0 we see the list of headers accumulate. With 3.1 just the > first one works and the rest do not. I bisected it down to: commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49 Author: Ben Boeckel Date: Wed Mar 12 14:01:45 2014 -0400 cmDefinitions: Don't store parent lookups When looking up scopes, it is faster to not store the lookup locally to keep the maps smaller and avoid extra allocations and rebalancing. -Brad From brad.king at kitware.com Fri Oct 24 10:20:42 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 24 Oct 2014 10:20:42 -0400 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: <544A5BF7.2000800@kitware.com> References: <544975B5.7070002@kitware.com> <20141024023427.GA11952@bronto-burt.dev.benboeckel.net> <544A5919.6000804@kitware.com> <544A5BF7.2000800@kitware.com> Message-ID: <544A603A.4030505@kitware.com> On 10/24/2014 10:02 AM, Brad King wrote: > I bisected it down to: > > commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49 > Author: Ben Boeckel > Date: Wed Mar 12 14:01:45 2014 -0400 > > cmDefinitions: Don't store parent lookups > > When looking up scopes, it is faster to not store the lookup locally to > keep the maps smaller and avoid extra allocations and rebalancing. Here is a minimal standalone example: $ cat regression.cmake function(func var_name) list(APPEND ${var_name} value) set(${var_name} ${${var_name}} PARENT_SCOPE) set(${var_name} ${${var_name}} PARENT_SCOPE) endfunction() func(var) message(STATUS " var=[${var}]") func(var) message(STATUS " var=[${var}]") $ cmake-3.0 -P regression.cmake -- var=[value] -- var=[value;value] $ cmake-3.1 -P regression.cmake -- var=[value] -- var=[value] -Brad From ben.boeckel at kitware.com Fri Oct 24 10:22:49 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 24 Oct 2014 10:22:49 -0400 Subject: [cmake-developers] [bcooksley@kde.org: Re: Fwd: Re: Severe behavioural change regressions in release branch] Message-ID: <20141024142249.GA6450@megas.kitwarein.com> [ Forward from Ben Cooksley. ] ----- Forwarded message from Ben Cooksley ----- Date: Fri, 24 Oct 2014 19:55:23 +1300 From: Ben Cooksley To: ben.boeckel at kitware.com Cc: Bill Hoffman , "cmake-developers at cmake.org" Subject: Re: [cmake-developers] Fwd: Re: Severe behavioural change regressions in release branch On Fri, Oct 24, 2014 at 3:34 PM, Ben Boeckel wrote: > [ Adding Ben Cooksley to the CC list; feel free to reply privately and > I'll forward to the list if you keep getting rejected from it. ] Duly noted, will do. > > Hi, Hi, > >> > It would appear that CMake 3.0 to 3.1 introduces a colossal change in >> > behaviour. This change totally breaks all KDE projects which use >> > Extra-CMake-Modules, as necessary headers are no longer installed. > > This is indeed true (between the new variable expansion code (CMP0053) > and 'if()' variable expansion rules (CMP0054), there's a lot of > changes otherwise); however, all you should get are warnings about the > change, not the actual behavior change without actually bumping your > minimum version or enabling the policy explicitly. Oki, that sounds about right. > >> > This has become an issue following http://build.kde.org/job/cmake/160/ >> > which has led to a significant number of our projects failing to build >> > from source as can be seen here - >> > http://build.kde.org/view/Frameworks/ > > So looking at kdelibs4support, I see lots of CMP0053 warnings (due to > the @var@ expansion in normal CMakeLists.txt processing which was > obscure and undocumented) and CMP0048 warnings (I'm not familiar with > it, but it's about project() offering version variables). In kdelibs, I > see CMP0022 and CMP0046 warnings (both related to target_link_libraries > and things which are likely bugs anyways such as depending on > non-existent targets or a mismatch between INTERFACE_LINK_LIBRARIES and > LINK_INTERFACE_LIBRARIES). > > However, I do see: > > 04:35:39 -- Installing: /srv/jenkins/workspace/kdelibs_master/local-inst/srv/jenkins/install/linux/x86_64/g++/latest-qt4/kde/kdelibs/inst/include/kpluginfactory.h > > in kdelibs' logs, so it makes me think that: > > /srv/jenkins/workspace/kdelibs4support_master_qt5/src/kssl/kcm/kcmssl.cpp:27:28: fatal error: kpluginfactory.h: No such file or directory > > implies the build isn't getting the include directories plumbed through > properly. I'll try a build tomorrow (or if it'd be possible to run a > Jenkins build of kdelibs4support with make VERBOSE=1, that'd be great > too since the environment would be consistent then). My gut feeling is > some CMP0054 corner case isn't caught and falls through to the new > behavior without a warning (or the old behavior was subtly changed in > the process), but that's just a shot in the dark. Slight bit of confusion here, sorry about that. kdelibs_master is for the KDE 4 (Qt 4 based) series of software. kdelibs4support_master_qt5 is for the Frameworks 5 (Qt 5 based) series of software. In this case, kpluginfactory.h should come from kcoreaddons. It's build log can be found here - http://build.kde.org/job/kcoreaddons_master_qt5/153/consoleText I can't see a sign of kpluginfactory.h being installed there unfortunately. Others have done a bit of digging already it seems as to what might be the cause. Please see https://mail.kde.org/pipermail/kde-frameworks-devel/2014-October/019906.html for that. If you're still interested in a VERBOSE=1 build of some of our projects, i'll be more than happy to supply such a log. > >> > Someone needs to investigate this before CMake 3.1.0 goes out the door >> > and fix it. I've no idea what the policy is in the CMake world, but in >> > the KDE world this sort of compatibility breakage would be a release >> > blocker. > > Thanks for testing the rc; it should be a blocker on our side too. It > would indeed be bad for 3.1.0 to release with such breaking changes. > We try really hard for backwards compatibility. Obviously our test > coverage is lacking somewhere. That is a relief to know. > >> And it would seem that the CMake developers prefer to live in their >> own closed off little bubble. My post was automatically rejected. >> Someone who is subscribed there will have to take this up with them. >> I'm extremely displeased. >> >> If they release CMake 3.1.0 with this regression, we should consider >> forking CMake as their developers can't be trusted to ensure our code >> remains buildable. Sorry for that - I got a bit caught up in the heat of the moment. > > For preventing this in the future, would it be possible to set up > Jenkins build to submit builds for kdelibs and a few other libraries > which would test CMake master and submit to CMake's dashboard some > results nightly so we can catch these problems more quickly? There are > examples in: > > https://github.com/Kitware/CMake/tree/master/Tests/Contracts > > for how this is done for other projects already. The instance would > then just to set something like CMAKE_CONTRACT_PROJECTS=kdelibs and run > CMake's test suite and submit to the dashboard. Theoretically that is possible, although a little complicated. We would have to chain two or more Frameworks builds (each one relying on the results of the prior build) in this case in order to detect the regression which tripped us up here. It is something which would need some adjustments to how our CI scripts work, but is certainly feasible. Just to be sure, such a job would: 1) Build the latest CMake (branch next) 2) Use the newly built CMake to compile all of the Frameworks, run their unit tests and submit each one to CDash. 3) Execute the CMake unit tests and submit this to CDash as well. For each submission to CDash, would the same CMAKE_CONTRACT_PROJECTS variable apply? ie. they would all be kde-frameworks or similar, even though we're making multiple submissions? > > Thanks, > > --Ben Thanks, Ben ----- End forwarded message ----- From alex.merry at kde.org Fri Oct 24 10:15:35 2014 From: alex.merry at kde.org (Alex Merry) Date: Fri, 24 Oct 2014 15:15:35 +0100 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: <544A5BF7.2000800@kitware.com> References: <544A5919.6000804@kitware.com> <544A5BF7.2000800@kitware.com> Message-ID: <9204499.9BDeAiUES7@kyoshi> On Friday 24 October 2014 10:02:31 Brad King wrote: > On 10/24/2014 09:50 AM, Brad King wrote: > > With 3.0 we see the list of headers accumulate. With 3.1 just the > > first one works and the rest do not. > > I bisected it down to: > > commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49 > Author: Ben Boeckel > Date: Wed Mar 12 14:01:45 2014 -0400 > > cmDefinitions: Don't store parent lookups > > When looking up scopes, it is faster to not store the lookup locally to > keep the maps smaller and avoid extra allocations and rebalancing. > > -Brad Which matches my trimmed-down testcase: ----------------------------------------------------------------- cmake_minimum_required(VERSION 3.0) project(Minimal NONE) function(test_append varname entry) list(APPEND ${varname} "${entry}") set(${varname} ${${varname}} PARENT_SCOPE) set(${varname} ${${varname}} PARENT_SCOPE) endfunction() test_append(blah entry1) message(STATUS "blah=${blah}") test_append(blah entry2) message(FATAL_ERROR "blah=${blah}") ----------------------------------------------------------------- It's that double-setting of the variable in the parent scope that seems to be the killer. Alex From alex.merry at kde.org Fri Oct 24 10:24:57 2014 From: alex.merry at kde.org (Alex Merry) Date: Fri, 24 Oct 2014 15:24:57 +0100 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: <544A603A.4030505@kitware.com> References: <544A5BF7.2000800@kitware.com> <544A603A.4030505@kitware.com> Message-ID: <2355239.vjbPdPHlH4@kyoshi> On Friday 24 October 2014 10:20:42 Brad King wrote: > On 10/24/2014 10:02 AM, Brad King wrote: > > I bisected it down to: > > > > commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49 > > Author: Ben Boeckel > > Date: Wed Mar 12 14:01:45 2014 -0400 > > > > cmDefinitions: Don't store parent lookups > > > > When looking up scopes, it is faster to not store the lookup locally > > to > > keep the maps smaller and avoid extra allocations and rebalancing. > > Here is a minimal standalone example: > > $ cat regression.cmake > function(func var_name) > list(APPEND ${var_name} value) > set(${var_name} ${${var_name}} PARENT_SCOPE) > set(${var_name} ${${var_name}} PARENT_SCOPE) > endfunction() > func(var) > message(STATUS " var=[${var}]") > func(var) > message(STATUS " var=[${var}]") > > $ cmake-3.0 -P regression.cmake > -- var=[value] > -- var=[value;value] > > $ cmake-3.1 -P regression.cmake > -- var=[value] > -- var=[value] > > -Brad Even simpler: ------------------------------------------- cmake_minimum_required(VERSION 3.0) project(Minimal NONE) function(test_set) set(blah "value2") message(STATUS "before PARENT_SCOPE blah=${blah}") set(blah ${blah} PARENT_SCOPE) message(STATUS "after PARENT_SCOPE blah=${blah}") endfunction() set(blah value1) test_set() message(FATAL_ERROR "in parent scope, blah=${blah}") ------------------------------------------ With CMake master: -- before PARENT_SCOPE blah=value2 -- after PARENT_SCOPE blah=value1 CMake Error at CMakeLists.txt:13 (message): in parent scope, blah=value2 With CMake 3.0.2: -- before PARENT_SCOPE blah=value2 -- after PARENT_SCOPE blah=value2 CMake Error at CMakeLists.txt:13 (message): in parent scope, blah=value2 From ben.boeckel at kitware.com Fri Oct 24 10:54:17 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 24 Oct 2014 10:54:17 -0400 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: <2355239.vjbPdPHlH4@kyoshi> References: <544A5BF7.2000800@kitware.com> <544A603A.4030505@kitware.com> <2355239.vjbPdPHlH4@kyoshi> Message-ID: <20141024145417.GB6450@megas.kitwarein.com> On Fri, Oct 24, 2014 at 15:24:57 +0100, Alex Merry wrote: > On Friday 24 October 2014 10:20:42 Brad King wrote: > > On 10/24/2014 10:02 AM, Brad King wrote: > > > commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49 > > > Author: Ben Boeckel > > > Date: Wed Mar 12 14:01:45 2014 -0400 > > > > > > cmDefinitions: Don't store parent lookups > > > > > > When looking up scopes, it is faster to not store the lookup locally > > > to > > > keep the maps smaller and avoid extra allocations and rebalancing. So the problem was that when redoing the "pull" logic for PARENT_SCOPE, it was unconditional when it should be skipped if the variable is already local. Pushed to stage as: variable-pull-failure > ------------------------------------------- > cmake_minimum_required(VERSION 3.0) > project(Minimal NONE) > > function(test_set) > set(blah "value2") > message(STATUS "before PARENT_SCOPE blah=${blah}") > set(blah ${blah} PARENT_SCOPE) > message(STATUS "after PARENT_SCOPE blah=${blah}") > endfunction() > > set(blah value1) > test_set() > message(FATAL_ERROR "in parent scope, blah=${blah}") > ------------------------------------------ Now added as a test in CMake (with minor changes). Thanks, --Ben From ben.boeckel at kitware.com Fri Oct 24 11:36:40 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 24 Oct 2014 11:36:40 -0400 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: <20141024145417.GB6450@megas.kitwarein.com> References: <544A5BF7.2000800@kitware.com> <544A603A.4030505@kitware.com> <2355239.vjbPdPHlH4@kyoshi> <20141024145417.GB6450@megas.kitwarein.com> Message-ID: <20141024153640.GA6124@megas.kitwarein.com> On Fri, Oct 24, 2014 at 10:54:17 -0400, Ben Boeckel wrote: > On Fri, Oct 24, 2014 at 15:24:57 +0100, Alex Merry wrote: > > On Friday 24 October 2014 10:20:42 Brad King wrote: > > > On 10/24/2014 10:02 AM, Brad King wrote: > > > > commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49 > > > > Author: Ben Boeckel > > > > Date: Wed Mar 12 14:01:45 2014 -0400 > > > > > > > > cmDefinitions: Don't store parent lookups > > > > > > > > When looking up scopes, it is faster to not store the lookup locally > > > > to > > > > keep the maps smaller and avoid extra allocations and rebalancing. > > So the problem was that when redoing the "pull" logic for PARENT_SCOPE, > it was unconditional when it should be skipped if the variable is > already local. So after discussion with Brad, this commit breaks other subtle behaviors as well, so the plan is to just revert it instead and defer its optimizations until after 3.1 once proper tests are in place (more under development now). --Ben From florent.castelli at gmail.com Wed Oct 1 02:47:37 2014 From: florent.castelli at gmail.com (Florent Castelli) Date: Wed, 1 Oct 2014 08:47:37 +0200 Subject: [cmake-developers] iOS support In-Reply-To: References: Message-ID: Thanks for the detailed information. My "hackweek" starts on Monday and I'll start working on these issues then. I'll work on finding a way to unify toolchain files for simulator and devices first. I don't think I'll try to work on iOS8 features since my company is shipping for iOS6 and there are so many things to do :) Though, I'm not really an iOS developer, there's probably a ton of things I'll miss. But I have great devs in my company and I'm sure it'll be okay! I'll keep you updated of my progress during the week and hopefully, I won't have to call for help here too often :) /Orphis On 1 Oct 2014 01:42, "Eric Wing" wrote: > Thought of one more. > I hate how the top, default target is ALL_BUILD. This is problematic > for both Xcode and Visual Studio because when you use the big giant > "run" button in the UI, the IDE is confused because ALL_BUILD is an > aggregate target and not a real thing that can be run. At least for > Xcode, a bunch of options change dynamically based on the type of > target selected and building/launching to the device/simulator is not > an option when on an aggregate target. > > It's an annoyance because it interferes with the normal workflow for > those familiar with the IDEs. And it's an annoyance for those who are > not familiar with the IDEs because the big giant buttons do nothing > and they don't understand the IDEs well enough on how to correct the > issue. > > (It's also more work invoking xcodebuild and msbuild because you can't > rely on the default targets.) > > Thanks, > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Wed Oct 1 09:09:08 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 1 Oct 2014 09:09:08 -0400 Subject: [cmake-developers] [CMake 0015183]: CMAKE_XCODE_ATTRIBUTE_INSTALL_PATH setting makes archiving impossible Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15183 ====================================================================== Reported By: Jan R?egg Assigned To: ====================================================================== Project: CMake Issue ID: 15183 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-01 09:09 EDT Last Modified: 2014-10-01 09:09 EDT ====================================================================== Summary: CMAKE_XCODE_ATTRIBUTE_INSTALL_PATH setting makes archiving impossible Description: CMake sets CMAKE_XCODE_ATTRIBUTE_INSTALL_PATH to an empty string ("") when generating xcode projects. For whatever reason archiving projects only works when - INSTALL_PATH is NOT set - INSTALL_PATH is set to some value other than the empty string ("") It does NOT work when - INSTALL_PATH is set to the empty string So I propose for CMake to not set this value at all, then XCode takes some default which works for archiving files. See also here: http://web.archiveorange.com/archive/v/5y7PklO3CkRUMmyHhIlr and here: http://public.kitware.com/pipermail/cmake/2011-June/045159.html and here: http://stackoverflow.com/a/8102602/369009 Steps to Reproduce: - Create XCode project with CMake (for example for ios). - Try to archive it "Product->Archive" - Nothing happens ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-01 09:09 Jan R?egg New Issue ====================================================================== From mantis at public.kitware.com Wed Oct 1 11:09:31 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 1 Oct 2014 11:09:31 -0400 Subject: [cmake-developers] [CMake 0015185]: Allow for partial customization of WiX.template.in Message-ID: <18d07f8d8c4f2f83117c52ceb25bc74a@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15185 ====================================================================== Reported By: Richard Ulrich Assigned To: ====================================================================== Project: CMake Issue ID: 15185 Category: CPack Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-01 11:09 EDT Last Modified: 2014-10-01 11:09 EDT ====================================================================== Summary: Allow for partial customization of WiX.template.in Description: At the moment I have my own copy of WiX.template.in in my project specific Modules directory. In the discussion of http://public.kitware.com/Bug/view.php?id=15165 I realized that it would be beneficial, if there was a way to only extend WiX.template.in without having to completely maintain it myself. * One approach would be to include a custom.wxi file in WiX.template.in and ship an empty custom.wxi file that could be overridden. * Another approach would be to extend the patching mechanism to the tag. As at the moment it only work on tags that are generated by the cpack c++ code, it's not just a matter of adding an ApplyPatch() line in the correct place. Things I customized in my WiX.template.in: * Product.Language="!(loc.LANG)" -> this could be tricky. It's not covered by both of the above approaches. -> shipping also a default lang.wxl file could make it work. * Adding Components or ComponentRefs that need to be in the Product tag. -> this is the easy part, solved by both approaches. * Adding a second UiRef (WixUI_ErrorProgressText) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-01 11:09 Richard Ulrich New Issue ====================================================================== From aleixpol at kde.org Wed Oct 1 19:46:09 2014 From: aleixpol at kde.org (Aleix Pol) Date: Thu, 2 Oct 2014 01:46:09 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> <22742143.8V0LQmVuST@tuxedo.neundorf.net> <540DA65F.4030501@kitware.com> <541C6B8D.2020404@kitware.com> <5422CD5E.7020008@kitware.com> Message-ID: On Wed, Sep 24, 2014 at 6:51 PM, Aleix Pol wrote: > On Wed, Sep 24, 2014 at 3:55 PM, Brad King wrote: > >> On 09/22/2014 07:15 PM, Aleix Pol wrote: >> > { >> > version: "1.0", >> > targets: [...] >> > } >> >> Yes. The version number could either be maintained as its own >> thing, or just the CMake version number could be used. Either way >> the Help/variable/CMAKE_OUTPUT_PROJECT_TARGETS.rst documentation >> should specify the format of each version. >> >> BTW, the phrase "output project targets" is not particularly >> clear without knowing the feature already. Perhaps some other >> name like "CMAKE_EXPORT_IDE_METADATA" would be better? >> >> > I've never worked with those, but it sounds like it would make sense. >> What about: >> > >> > { >> > version: .. >> > configurations: { >> > { name: "Debug", targets: [...] }, >> > { name: "Release", targets: [...] } >> > } >> > } >> >> Yes, something like that. I think you meant to use [] rather than >> {} around the list of configurations. In the case that there is >> only one configuration for the generator we should still use a >> list but have only one entry. >> > Sure :) > > >> >> -Brad >> >> > Hi, > Here's another iteration of the patch [1]. > > Basically adopts the possibility to move some information to depend on the > configuration. Currently it's only showing the I source files, I guess > location, directory and installed should be moved as well. Correct? > > Aleix > > [1] > New patch: > http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch > New output: http://proli.net/meu/kdevelop/ProjectTargets.json > Bump. I'm very interested in getting this in and iterating forward. Any comments? How do changes get integrated? Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Oct 2 08:43:37 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 02 Oct 2014 08:43:37 -0400 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> <22742143.8V0LQmVuST@tuxedo.neundorf.net> <540DA65F.4030501@kitware.com> <541C6B8D.2020404@kitware.com> <5422CD5E.7020008@kitware.com> Message-ID: <542D4879.20204@kitware.com> On 10/01/2014 07:46 PM, Aleix Pol wrote: > I'm very interested in getting this in and iterating forward. > > Any comments? How do changes get integrated? My main concern is that the format has not been proven with a corresponding implementation of an actual IDE/plugin to use it. Once we start producing a format changing it later will be problematic for compatibility. Even though we added a version number to the file, an IDE might not be updated along with a CMake that produces a newer version. Perhaps rather than a boolean "CMAKE_EXPORT_IDE_METADATA" setting to enable this, the value should be a version number. That way enabling it requires explicit specification of which format version is desired. In this case we would need to use a format version number that is independent of th CMake version number. It would simply be incremented every time changes are made. If the version number has the form . then we could increment the minor number whenever fields are added and the major number whenever fields are removed or changed. -Brad From samho5888 at gmail.com Thu Oct 2 08:52:08 2014 From: samho5888 at gmail.com (Sam H.) Date: Thu, 2 Oct 2014 20:52:08 +0800 Subject: [cmake-developers] Integrate fixdep for kconfig In-Reply-To: <542ACBD0.3030209@kitware.com> References: <542ACBD0.3030209@kitware.com> Message-ID: Hi Brad, I try my best to describe my understanding. kconfig ( https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kbuild ) is a language for configuration. After user finish configuration, it will generate files, e.g. autoconf.h for C language and auto.conf for makefile, and it will parse configuration to generate proper pseudo file for dependency. For example, CONFIG_A_B_C will be expanded as include/config/a/b/c.h, CONFIG_TST1 will be expanded as include/config/tst1.h So that files use CONFIG_A_B_C will have a dependency to include/config/a/b/c.h. C codes will check CONFIG_A_B_C that will be defined in autoconf.h Since autoconf.h will be re-generated every time when configuration is changed. Files depend to autoconf.h will all be built even CONFIG it used is not modified. So autoconf.h need to be removed from dependency file and pseudo config file refereed need to be added in. Linux kernel build codes with -Wp,-MD,src/path/.file.o.d It will generate dependency list that .h used. Then fixdep will re-parse .file.o.d. It will 1. Remove common file like autoconf.h 2. Add dependency of CONFIG pseudo file. The comments show more information about what fixdep do: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/basic/fixdep.c My prototype patch is try to do what fixdep do in CMake. Attached file is my test sample. (tested on Ubuntu 12.04 with CMake 3.0.1 patched) After extract file. 1. Do configuration by: $ make allyesconfig 2. Generate CONFIG pseudo files: $ make silentoldconfig 3. Do CMake $ mkdir build $ cmake .. $ make 4. Do more configuration: $ cd .. $ make menuconfig $ make silentoldconfig 5. Test CMake again: $ cd build $ make Because the license issue and mmap() issue, codes need to be re-implement. However, I'm not familiar with CMake codes and C++. So what can I do if this feature could be accepted? Thanks, Sam 2014-09-30 23:27 GMT+08:00 Brad King : > On 09/24/2014 07:18 AM, Sam H. wrote: > > I would like to use kconfig from Linux for my project settings. > > So I integrate fixdep tools into CMake for parsing CONFIG_xxx key words > > and set proper dependency of files that are generated by kconfig. > > For those of us unfamiliar with kconfig/fixdep, please provide a > high level explanation of how they work and why CMake dependency > scanning needs to be modified. > > > However, here come some issues. > > 1. The codes from fixdep is declared as GPL. But CMake use BSD. > > 2. fixed use mmap(). But this API is not support well on Windows. > > Both of these need to be addressed before a patch would be accepted. > We cannot link GPLed code, and we need a portable implementation. > > Thanks, > -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: -------------- next part -------------- A non-text attachment was scrubbed... Name: tst_kconfig.tar.bz2 Type: application/x-bzip2 Size: 153547 bytes Desc: not available URL: From brad.king at kitware.com Thu Oct 2 09:02:08 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 02 Oct 2014 09:02:08 -0400 Subject: [cmake-developers] iOS support In-Reply-To: References: <54217E53.2070902@kitware.com> <54218A16.1010008@kitware.com> Message-ID: <542D4CD0.8020304@kitware.com> On 09/23/2014 11:42 AM, Florent Castelli wrote: > On 23 Sep 2014, at 16:56, Bill Hoffman wrote: >> Much of the stuff found in these toolchains: >> https://github.com/Kitware/VTK/blob/master/CMake/ios.toolchain.xcode.cmake >> https://github.com/Kitware/VTK/blob/master/CMake/ios.simulator.toolchain.cmake >> https://github.com/Kitware/VTK/blob/master/CMake/ios.device.toolchain.cmake >> Should be in Platform files. If we created ios platform files we could > remove most of the stuff from those toolchain files. > > The problem is that I want a project that is usable by developers directly > and you can't really force them to target just the simulator. It should work > for targeting both simulator and real device. So having a generic iOS toolchain > that can generate both in one project is a requirement for me. Ideally a toolchain file should have only settings specific to the local machine where it will be used, such as the paths to staging prefixes where dependencies built for the target arch may be installed. All information that is general to the iOS platform should be in a module that comes with CMake, and only the local system info should be the toolchain file (which does not come with CMake). To clarify Bill's suggestion, much of the content in third-party iOS toolchain files is stuff like this: set (CMAKE_SHARED_LIBRARY_PREFIX "lib") set (CMAKE_SHARED_LIBRARY_SUFFIX ".dylib") set (CMAKE_SHARED_MODULE_PREFIX "lib") set (CMAKE_SHARED_MODULE_SUFFIX ".so") set (CMAKE_MODULE_EXISTS 1) set (CMAKE_DL_LIBS "") set (CMAKE_PLATFORM_HAS_INSTALLNAME 1) set (CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS "-dynamiclib -headerpad_max_install_names") set (CMAKE_SHARED_MODULE_CREATE_C_FLAGS "-bundle -headerpad_max_install_names") set (CMAKE_SHARED_MODULE_LOADER_C_FLAG "-Wl,-bundle_loader,") set (CMAKE_SHARED_MODULE_LOADER_CXX_FLAG "-Wl,-bundle_loader,") set (CMAKE_FIND_LIBRARY_SUFFIXES ".dylib" ".so" ".a") These kind of settings belong in a CMake Platform/.cmake file. For example, see the platform file for OS X: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin.cmake;hb=v3.0.2 Furthermore, commonly used third-party iOS toolchain files start with this: set (CMAKE_SYSTEM_NAME Darwin) Instead an iOS toolchain file should start with: set (CMAKE_SYSTEM_NAME iOS) and there should be a Modules/Platform/iOS.cmake file that comes with CMake to contain settings like those above. The code for finding the iOS SDK path should also be in a platform module. It should go either in iOS.cmake itself, or in an iOS-Inititalize.cmake file similar to Darwin-Initialize.cmake: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin-Initialize.cmake;hb=f640b2a4 Once such modules come with CMake, toolchain files can be very short and only need to say they are for iOS and then specify local system information. -Brad From mantis at public.kitware.com Thu Oct 2 09:41:35 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 2 Oct 2014 09:41:35 -0400 Subject: [cmake-developers] [CMake 0015186]: target names restricted to ascii since 3.0 Message-ID: <2892a1db25c9ffdac508917f4885baa5@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15186 ====================================================================== Reported By: Clinton Stimpson Assigned To: ====================================================================== Project: CMake Issue ID: 15186 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-02 09:41 EDT Last Modified: 2014-10-02 09:41 EDT ====================================================================== Summary: target names restricted to ascii since 3.0 Description: Using the project attached here: http://www.cmake.org/Bug/view.php?id=14934 I get a warning: CMake Warning (dev) at CMakeLists.txt:31 (add_executable): Policy CMP0037 is not set: Target names should not be reserved and should match a validity pattern. Run "cmake --help-policy CMP0037" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The target name "????" is reserved or not valid for certain CMake features, such as generator expressions, and may result in undefined behavior. Additional Information: cmGeneratorExpression::IsValidTargetName() has this: static cmsys::RegularExpression targetNameValidator("^[A-Za-z0-9_.:+-]+$"); return targetNameValidator.find(input); Perhaps the regex can be inverted and specific characters which are disallowed should be searched for. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-02 09:41 Clinton StimpsonNew Issue ====================================================================== From joubert.sy at gmail.com Thu Oct 2 17:34:39 2014 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Thu, 02 Oct 2014 23:34:39 +0200 Subject: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible Message-ID: <542DC4EF.2000400@gmail.com> Hi, Since Ninja 1.5, a pre-defined pool 'console' can be used for non buffered output. See http://martine.github.io/ninja/manual.html#_the_literal_console_literal_pool This patch specifies that special pool for the "build.ninja" build block if the Ninja version used is at least 1.5 This is useful for projects that have a long and verbose CMake run step. The idea is to get the output as soon as possible. It also adds the generation of the minimal required version of Ninja in the build.ninja file. The default version is 1.3 since the generator uses features from that version. If the Ninja version is 1.5 or greater, then the generator will use the 'console' pool and the build.ninja file requires at least Ninja 1.5 Regards, Sylvain -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Ninja-Use-console-pool-for-CMake-re-run-if-possible.patch Type: text/x-patch Size: 5378 bytes Desc: not available URL: From mw_triad at users.sourceforge.net Thu Oct 2 18:08:07 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 02 Oct 2014 18:08:07 -0400 Subject: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible In-Reply-To: <542DC4EF.2000400@gmail.com> References: <542DC4EF.2000400@gmail.com> Message-ID: On 2014-10-02 17:34, Sylvain Joubert wrote: > Since Ninja 1.5, a pre-defined pool 'console' can be used for non > buffered output. > See > http://martine.github.io/ninja/manual.html#_the_literal_console_literal_pool > > This patch specifies that special pool for the "build.ninja" build block > if the Ninja version used is at least 1.5 I haven't tried it yet, but I've been wanting this feature; thanks for the patch! Please see also http://public.kitware.com/Bug/view.php?id=14915 which it sounds like this (partly) fixes; you may want to reference that in your patch or vice versa. (The "partly" is that the request is also for the 'install' target to use the console pool; not sure if you did that, want to tackle that, etc., but in any case this is a step in the right direction.) -- Matthew From ewmailing at gmail.com Thu Oct 2 21:10:59 2014 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 2 Oct 2014 18:10:59 -0700 Subject: [cmake-developers] iOS support In-Reply-To: <542D4CD0.8020304@kitware.com> References: <54217E53.2070902@kitware.com> <54218A16.1010008@kitware.com> <542D4CD0.8020304@kitware.com> Message-ID: > Ideally a toolchain file should have only settings specific to > the local machine where it will be used, such as the paths to > staging prefixes where dependencies built for the target arch > may be installed. All information that is general to the iOS > platform should be in a module that comes with CMake, and only > the local system info should be the toolchain file (which does > not come with CMake). Agreed. > The code for > finding the iOS SDK path should also be in a platform module. I think we should nuance and improve this if possible. One thing I really would like fixed is the CMake asserting itself by specifying an explicit path to the iOS SDK. A few years ago, Apple added a generic option for "Latest SDK". This was to address the problem that we always have a new Xcode beta version in flight and new SDKs every year (both iOS and Mac). Additionally, because Apple re-routes the SDK path dynamically based on whether you selected Device or Simulator. Whatever mechanism CMake is using to assert itself seems to be somewhat incompatible with this feature because CMake forces it to just one or the other. I relaxed a few settings in my toolchain and it seems to work better, though I still have problems from time to time. I originally was going to say the path to Xcode is the most important thing, but I'm wondering if that is really important at all. Apple also knows how to automatically root the SDKs relative to the Xcode project that you opened in. This is really valuable to us developers too because it is common that we need to switch back and forth between the current stable and current beta of Xcode (and sometimes multiple betas.) So it would be nice if CMake didn't have to write any information to paths to Xcode and just leverage Apple's generic placeholder values. I'm using a minor fork of one of the open source iOS toolchains. To advance the cause, I would be happy to share it and also give access to my upcoming (commercial) SDK for context (which includes the entire CMake build system I use with all the things I'm trying to accomplish). Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ From mantis at public.kitware.com Fri Oct 3 01:06:09 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 3 Oct 2014 01:06:09 -0400 Subject: [cmake-developers] [CMake 0015191]: find_program should search commands in PATHEXT env. Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15191 ====================================================================== Reported By: Yoshisato Yanagisawa Assigned To: ====================================================================== Project: CMake Issue ID: 15191 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-03 01:06 EDT Last Modified: 2014-10-03 01:06 EDT ====================================================================== Summary: find_program should search commands in PATHEXT env. Description: find_program (http://www.cmake.org/cmake/help/v3.0/command/find_program.html) expected to find an executable that has an extension listed in PATHEXT on Windows. However, it only tries .com and .exe. http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/kwsys/SystemTools.cxx;h=b1221e3a8f7fee97bca54a002590198e5fb0183f;hb=HEAD#l2785 Steps to Reproduce: 1. put foo.bat in the PATH. 2. put CMakeLists.txt like: cmake_minimum_required (VERSION 2.8.11) project (HELLO) find_program(Foo foo PATHS) if (NOT Foo) message (FATAL_ERROR "Foo not found") endif() message("Foo ${Foo}") 3. cmake ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-03 01:06 Yoshisato YanagisawaNew Issue ====================================================================== From eike at sf-mail.de Fri Oct 3 03:35:05 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 03 Oct 2014 09:35:05 +0200 Subject: [cmake-developers] Improving the version selection behavior of EXACT Message-ID: <2265519.UlzGx0ETMW@caliban.sf-tec.de> find_package(foo 2.0 EXACT) means EXACT, i.e. only "2.0" is allowed. In most cases this behavior is not the one that one would expect or need. Most people would instead allow any 2.0.x version to match. This sort of selection is currently impossible without additional effort in every Find*.cmake that is used. I came over this when I tried converting FindLua5[01].cmake to use FindLua.cmake, but I can't do "find_package(Lua 5.0 EXACT)" in there because e.g. 5.0.1 would not be accepted then, and I neither can do "find_package(Lua 5.0)" because that may return e.g. 5.2 instead. Since we can't change this because of the usual backward compatibility concerns I think we should introduce a new version mode, e.g. EXACT_OR_MINOR (or any other naming you find more appropiate). In case this is aggreed on I would try to create a patch ASAP to be able to still land it in 3.1. Opinions? Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From DLRdave at aol.com Fri Oct 3 06:06:01 2014 From: DLRdave at aol.com (David Cole) Date: Fri, 3 Oct 2014 06:06:01 -0400 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <2265519.UlzGx0ETMW@caliban.sf-tec.de> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> Message-ID: How about IN_RANGE and/or IN_SET options? Where IN_RANGE takes two version numbers (low and high) and does the equivalent of: if ( (NOT ver VERSION_LESS low) AND (ver VERSION_LESS high) ) Or possibly even IN_RANGES with multiple ranges... And IN_SET takes a list of explicit version numbers and looks for exact matches among multiple choices...? It's all pie in the sky until you reach up and pull one down. ;-) D On Fri, Oct 3, 2014 at 3:35 AM, Rolf Eike Beer wrote: > find_package(foo 2.0 EXACT) means EXACT, i.e. only "2.0" is allowed. In most > cases this behavior is not the one that one would expect or need. Most people > would instead allow any 2.0.x version to match. This sort of selection is > currently impossible without additional effort in every Find*.cmake that is > used. > > I came over this when I tried converting FindLua5[01].cmake to use > FindLua.cmake, but I can't do "find_package(Lua 5.0 EXACT)" in there because > e.g. 5.0.1 would not be accepted then, and I neither can do "find_package(Lua > 5.0)" because that may return e.g. 5.2 instead. > > Since we can't change this because of the usual backward compatibility > concerns I think we should introduce a new version mode, e.g. EXACT_OR_MINOR > (or any other naming you find more appropiate). > > In case this is aggreed on I would try to create a patch ASAP to be able to > still land it in 3.1. > > Opinions? > > Eike > -- > > 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 brad.king at kitware.com Fri Oct 3 08:27:56 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 08:27:56 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 Message-ID: <542E964C.1050104@kitware.com> Hi Folks, In preparation for the first 3.1 release candidate I will feature- freeze master as of 2014-10-09. As of now there are several open topics in 'next' that we should try to land in master by then, but please refrain from adding non-trivial changes in the meantime. Thanks, -Brad From brad.king at kitware.com Fri Oct 3 08:41:47 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 08:41:47 -0400 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <2265519.UlzGx0ETMW@caliban.sf-tec.de> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> Message-ID: <542E998B.9010202@kitware.com> On 10/03/2014 03:35 AM, Rolf Eike Beer wrote: > find_package(foo 2.0 EXACT) means EXACT, i.e. only "2.0" is allowed. In most > cases this behavior is not the one that one would expect or need. Most people > would instead allow any 2.0.x version to match. Yes. The "EXACT" should refer to exactly matching whatever components are given by the caller. Following components should still be free to vary. If the caller wants them to be exact too then they should be specified. > This sort of selection is currently impossible without additional effort > in every Find*.cmake that is used. Is that because of FPHSA's implementation? > Since we can't change this because of the usual backward compatibility > concerns I think we should introduce a new version mode, e.g. EXACT_OR_MINOR > (or any other naming you find more appropiate). > > In case this is aggreed on I would try to create a patch ASAP to be able to > still land it in 3.1. I'd rather not introduce a new API in an important command like find_package immediately before a release. However, the documentation of find_package has always said that it is up to the Find module (or package version file in Config mode) for each package to decide whether a version matches. I think FPHSA could be changed to implement the expected behavior for EXACT discussed above. The current implementation effectively adds unlimited implicit ".0.0.0" to the caller's components as part of if(VERSION_EQUAL). Instead FPHSA could truncate the available version to match the number of components provided by the caller's version request before using if(VERSION_EQUAL). -Brad From eike at sf-mail.de Fri Oct 3 08:43:57 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 03 Oct 2014 14:43:57 +0200 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <542E998B.9010202@kitware.com> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <542E998B.9010202@kitware.com> Message-ID: <3958318.nxOjhsD5xf@caliban.sf-tec.de> Am Freitag, 3. Oktober 2014, 08:41:47 schrieb Brad King: > On 10/03/2014 03:35 AM, Rolf Eike Beer wrote: > > find_package(foo 2.0 EXACT) means EXACT, i.e. only "2.0" is allowed. In > > most cases this behavior is not the one that one would expect or need. > > Most people would instead allow any 2.0.x version to match. > > Yes. The "EXACT" should refer to exactly matching whatever components are > given by the caller. Following components should still be free to vary. > If the caller wants them to be exact too then they should be specified. > > > This sort of selection is currently impossible without additional effort > > in every Find*.cmake that is used. > > Is that because of FPHSA's implementation? I think that is the main reason. > > Since we can't change this because of the usual backward compatibility > > concerns I think we should introduce a new version mode, e.g. > > EXACT_OR_MINOR (or any other naming you find more appropiate). > > > > In case this is aggreed on I would try to create a patch ASAP to be able > > to > > still land it in 3.1. > > I'd rather not introduce a new API in an important command like find_package > immediately before a release. However, the documentation of find_package > has always said that it is up to the Find module (or package version file > in Config mode) for each package to decide whether a version matches. > > I think FPHSA could be changed to implement the expected behavior for > EXACT discussed above. The current implementation effectively adds > unlimited implicit ".0.0.0" to the caller's components as part of > if(VERSION_EQUAL). Instead FPHSA could truncate the available version > to match the number of components provided by the caller's version > request before using if(VERSION_EQUAL). If it is acceptable to change FPHSA in that way I can just go for it. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Fri Oct 3 08:47:04 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 08:47:04 -0400 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <3958318.nxOjhsD5xf@caliban.sf-tec.de> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <542E998B.9010202@kitware.com> <3958318.nxOjhsD5xf@caliban.sf-tec.de> Message-ID: <542E9AC8.9030907@kitware.com> On 10/03/2014 08:43 AM, Rolf Eike Beer wrote: >> I think FPHSA could be changed to implement the expected behavior for >> EXACT > > If it is acceptable to change FPHSA in that way I can just go for it. Yes, please try it. Thanks, -Brad From brad.king at kitware.com Fri Oct 3 08:56:43 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 08:56:43 -0400 Subject: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible In-Reply-To: References: <542DC4EF.2000400@gmail.com> Message-ID: <542E9D0B.1080806@kitware.com> On 10/02/2014 06:08 PM, Matthew Woehlke wrote: > I haven't tried it yet, but I've been wanting this feature; thanks for > the patch! I tried the patch and it works well. When ninja reruns CMake one can now see the output immediately. > Please see also > http://public.kitware.com/Bug/view.php?id=14915 which it sounds like > this (partly) fixes; you may want to reference that in your patch or > vice versa. I've applied the patch here and added the issue reference: Ninja: Use 'console' pool for CMake re-run if possible (#14915) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f32a241 > (The "partly" is that the request is also for the 'install' target to > use the console pool; not sure if you did that, want to tackle that, > etc., but in any case this is a step in the right direction.) I'll leave that to a follow-up patch if anyone wants to do it. Thanks, -Brad From mantis at public.kitware.com Fri Oct 3 09:01:58 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 3 Oct 2014 09:01:58 -0400 Subject: [cmake-developers] [CMake 0015193]: Error when one of the parent directory is a symlink to it's parent directory Message-ID: <5948bd215798319654adc894f9bb5c82@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15193 ====================================================================== Reported By: Yichao Yu Assigned To: ====================================================================== Project: CMake Issue ID: 15193 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-03 09:01 EDT Last Modified: 2014-10-03 09:01 EDT ====================================================================== Summary: Error when one of the parent directory is a symlink to it's parent directory Description: If one of the parent directory of the source directory is a symlink to one of its parent directory, cmake fails at configure time on add_subdirectory. Directory structure to reproduce this: ``` % tree . ??? 1 ??? ??? 2 ??? ??? ??? cmake ??? ??? ??? a ??? ??? ??? ??? CMakeLists.txt ??? ??? ??? CMakeLists.txt ??? ??? 4 -> . ??? 3 -> 1 6 directories, 2 files ``` The higher level `CMakeLists.txt` is ``` % cat 1/2/cmake/CMakeLists.txt project(cmake-test) cmake_minimum_required(VERSION 2.8) add_subdirectory(a) ``` and the lower level `CMakeLists.txt` is empty. When trying to build in `1/4/2/cmake/build` ``` % cmake .. -- The C compiler identification is GNU 4.9.1 -- The CXX compiler identification is GNU 4.9.1 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Error at CMakeLists.txt:3 (add_subdirectory): add_subdirectory not given a binary directory but the given source directory "/home/yuyichao/tmp/cmake-test/1/4/4/4/2/cmake/a" is not a subdirectory of "/home/yuyichao/tmp/cmake-test/1/4/4/2/cmake". When specifying an out-of-tree source a binary directory must be explicitly specified. -- Configuring incomplete, errors occurred! See also "/home/yuyichao/tmp/cmake-test/1/4/2/cmake/build/CMakeFiles/CMakeOutput.log". ``` Another real life example can be found in the comment here[1] and the qtcurve issue here[2]. [1] http://kde-look.org/content/show.php?content=40492 [2] https://github.com/QtCurve/qtcurve/issues/77 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-03 09:01 Yichao Yu New Issue ====================================================================== From brad.king at kitware.com Fri Oct 3 09:14:06 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 09:14:06 -0400 Subject: [cmake-developers] Integrate fixdep for kconfig In-Reply-To: References: <542ACBD0.3030209@kitware.com> Message-ID: <542EA11E.3090805@kitware.com> On 10/02/2014 08:52 AM, Sam H. wrote: > I try my best to describe my understanding. Thanks for the explanation. > My prototype patch is try to do what fixdep do in CMake. It is do-able in the CMake "Makefile" generator but AFAICT cannot possibly work for the Ninja generator or the VS/Xcode generators. Those all let the build tool do their own dependencies. > 4. Do more configuration: > $ cd .. > $ make menuconfig > $ make silentoldconfig In plain CMake, configuration like this is normally kept in CMake cache variables and edited with ccmake or cmake-gui. It's not the same interface as menuconfig but it has the same capabilities and works on all platforms CMake supports. > Because the license issue and mmap() issue, codes need to be re-implement. Yes. The implementor also shouldn't look at the original source. > However, I'm not familiar with CMake codes and C++. > So what can I do if this feature could be accepted? Personally I see little value in supporting an auxiliary configuration system in a way that works only with one of our generators. However, if it can be implemented in a way that is not intrusive and can be enabled optionally then it would be an acceptable patch. There must still be a way to follow autoconf.h with normal scanning if the kconfig part is not enabled. -Brad From aleixpol at kde.org Fri Oct 3 09:44:43 2014 From: aleixpol at kde.org (Aleix Pol) Date: Fri, 3 Oct 2014 15:44:43 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <542D4879.20204@kitware.com> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> <22742143.8V0LQmVuST@tuxedo.neundorf.net> <540DA65F.4030501@kitware.com> <541C6B8D.2020404@kitware.com> <5422CD5E.7020008@kitware.com> <542D4879.20204@kitware.com> Message-ID: On Thu, Oct 2, 2014 at 2:43 PM, Brad King wrote: > On 10/01/2014 07:46 PM, Aleix Pol wrote: > > I'm very interested in getting this in and iterating forward. > > > > Any comments? How do changes get integrated? > > My main concern is that the format has not been proven with a > corresponding implementation of an actual IDE/plugin to use it. > Once we start producing a format changing it later will be > problematic for compatibility. Even though we added a version > number to the file, an IDE might not be updated along with a > CMake that produces a newer version. > > Perhaps rather than a boolean "CMAKE_EXPORT_IDE_METADATA" > setting to enable this, the value should be a version number. > That way enabling it requires explicit specification of which > format version is desired. In this case we would need to use > a format version number that is independent of th CMake version > number. It would simply be incremented every time changes are > made. If the version number has the form . then > we could increment the minor number whenever fields are added > and the major number whenever fields are removed or changed. > > -Brad > > Ok, I can start working on it in a KDevelop branch and see what needs to be changed. Regarding passing the version rather than "ON" probably makes sense. I'll work on a patch to make it work this way. Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Fri Oct 3 09:52:01 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 03 Oct 2014 15:52:01 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <542D4879.20204@kitware.com> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <542D4879.20204@kitware.com> Message-ID: <6761034.LHuUtODnIM@eto> Brad King wrote: > On 10/01/2014 07:46 PM, Aleix Pol wrote: > > I'm very interested in getting this in and iterating forward. > > > > Any comments? How do changes get integrated? > > My main concern is that the format has not been proven with a > corresponding implementation of an actual IDE/plugin to use it. > Once we start producing a format changing it later will be > problematic for compatibility. Even though we added a version > number to the file, an IDE might not be updated along with a > CMake that produces a newer version. This probably needs a way to query for the IDE which versions the given CMake version supports, no? Otherwise a newer IDE may request version 3 and just get nothing because the CMake binary only supports 1 and 2. Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mw_triad at users.sourceforge.net Fri Oct 3 11:36:44 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 03 Oct 2014 11:36:44 -0400 Subject: [cmake-developers] CMake, Ninja generator, and ExternalProjects In-Reply-To: References: Message-ID: On 2014-07-25 17:05, Williams, Norman K wrote: > There?s also the ?console pool? facility that would allow > ExternalProject builds to display output, though that would get back > to the Gmake issue of different processes interleaving output. It wouldn't; the 'console' pool only permits one job at a time. So your outer build would run serially, directly showing the output of whatever (*one*) inner build is running at the time. -- Matthew From mw_triad at users.sourceforge.net Fri Oct 3 11:41:23 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 03 Oct 2014 11:41:23 -0400 Subject: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible In-Reply-To: <542E9D0B.1080806@kitware.com> References: <542DC4EF.2000400@gmail.com> <542E9D0B.1080806@kitware.com> Message-ID: On 2014-10-03 08:56, Brad King wrote: > On 10/02/2014 06:08 PM, Matthew Woehlke wrote: >> Please see also >> http://public.kitware.com/Bug/view.php?id=14915 which it sounds like >> this (partly) fixes; you may want to reference that in your patch or >> vice versa. > > I've applied the patch here and added the issue reference: > > Ninja: Use 'console' pool for CMake re-run if possible (#14915) > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f32a241 > >> (The "partly" is that the request is also for the 'install' target to >> use the console pool; not sure if you did that, want to tackle that, >> etc., but in any case this is a step in the right direction.) > > I'll leave that to a follow-up patch if anyone wants to do it. I was sort-of hoping / encouraging that Sylvain might be interested :-). Anyway, thanks! (Re-running CMake is the more important task, I think, as that's known to take minutes in some cases... install, while also an obvious candidate for such treatment, I believe tends to be quicker, so it less "important".) -- Matthew From eike at sf-mail.de Fri Oct 3 11:53:29 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 03 Oct 2014 17:53:29 +0200 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <542E9AC8.9030907@kitware.com> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <3958318.nxOjhsD5xf@caliban.sf-tec.de> <542E9AC8.9030907@kitware.com> Message-ID: <1613841.KYJJi9OZnb@eto> Brad King wrote: > On 10/03/2014 08:43 AM, Rolf Eike Beer wrote: > >> I think FPHSA could be changed to implement the expected behavior for > >> EXACT > > > > If it is acceptable to change FPHSA in that way I can just go for it. > > Yes, please try it. It looks like this line is the culprit: if (NOT "${${_NAME}_FIND_VERSION}" VERSION_EQUAL "${VERSION}") I can solve this in CMake language, but the question is again if it may be worth solving in the command itself? Meanwhile I'll prepare an implementation in CMake code, we can replace that with anything better anytime later. Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Fri Oct 3 12:14:38 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 12:14:38 -0400 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <1613841.KYJJi9OZnb@eto> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <3958318.nxOjhsD5xf@caliban.sf-tec.de> <542E9AC8.9030907@kitware.com> <1613841.KYJJi9OZnb@eto> Message-ID: <542ECB6E.8000307@kitware.com> On 10/03/2014 11:53 AM, Rolf Eike Beer wrote: > It looks like this line is the culprit: > > if (NOT "${${_NAME}_FIND_VERSION}" VERSION_EQUAL "${VERSION}") > > I can solve this in CMake language, but the question is again if it may be > worth solving in the command itself? Meanwhile I'll prepare an implementation > in CMake code, we can replace that with anything better anytime later. Yes, I think the command should be fixed to compare only as many components as are given on both sides, ignoring extra on one side. However, that will require a policy. Please fix it in the module by hand for now and look at adding a policy for this after the 3.1 release. Thanks, -Brad From eike at sf-mail.de Fri Oct 3 12:47:31 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 03 Oct 2014 18:47:31 +0200 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <542ECB6E.8000307@kitware.com> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <1613841.KYJJi9OZnb@eto> <542ECB6E.8000307@kitware.com> Message-ID: <7359420.jzfpyDp4lL@eto> Brad King wrote: > On 10/03/2014 11:53 AM, Rolf Eike Beer wrote: > > It looks like this line is the culprit: > > if (NOT "${${_NAME}_FIND_VERSION}" VERSION_EQUAL "${VERSION}") > > > > I can solve this in CMake language, but the question is again if it may be > > worth solving in the command itself? Meanwhile I'll prepare an > > implementation in CMake code, we can replace that with anything better > > anytime later. > Yes, I think the command should be fixed to compare only as many > components as are given on both sides, ignoring extra on one side. > However, that will require a policy. > > Please fix it in the module by hand for now and look at adding a > policy for this after the 3.1 release. Yes, that was my plan. This is what I have now (diff -b for easier review): diff --git a/Modules/FindPackageHandleStandardArgs.cmake b/Modules/FindPackageHandleStandardArgs.cmake index e8d1dfb..f8c990e 100644 --- a/Modules/FindPackageHandleStandardArgs.cmake +++ b/Modules/FindPackageHandleStandardArgs.cmake @@ -290,12 +290,38 @@ function(FIND_PACKAGE_HANDLE_STANDARD_ARGS _NAME _FIRST_ARG) if(VERSION) if(${_NAME}_FIND_VERSION_EXACT) # exact version required + # count the dots in the version string + string(REGEX REPLACE "[^.]" "" _VERSION_DOTS "${VERSION}") + # add one dot because there is one dot more than there are components + string(LENGTH "${_VERSION_DOTS}." _VERSION_DOTS) + if (_VERSION_DOTS GREATER ${_NAME}_FIND_VERSION_COUNT) + # give an exact match if the first ${NAME}_FIND_VERSION_COUNT components of the version string match + # this constructs the equivalent of "(([^.]\\.){${${_NAME}_FIND_VERSION_COUNT}})" + unset(_VERSION_REGEX) + # foreach(RANGE) doesn't like it if stop is greater start + if (${${_NAME}_FIND_VERSION_COUNT} GREATER 1) + foreach (_NUM RANGE 2 ${${_NAME}_FIND_VERSION_COUNT}) + set(_VERSION_REGEX "${_VERSION_REGEX}[^.]*\\.") + endforeach () + endif () + string(REGEX REPLACE "^(${_VERSION_REGEX}[^.]*)\\..*" "\\1" _VERSION_HEAD "${VERSION}") + unset(_VERSION_REGEX) + if (NOT ${_NAME}_FIND_VERSION VERSION_EQUAL _VERSION_HEAD) + set(VERSION_MSG "Found unsuitable version \"${VERSION}\", but required is exact version \"${${_NAME}_FIND_VERSION}\"") + set(VERSION_OK FALSE) + else () + set(VERSION_MSG "(found suitable exact version \"${VERSION}\")") + endif () + unset(_VERSION_HEAD) + else () if (NOT "${${_NAME}_FIND_VERSION}" VERSION_EQUAL "${VERSION}") set(VERSION_MSG "Found unsuitable version \"${VERSION}\", but required is exact version \"${${_NAME}_FIND_VERSION}\"") set(VERSION_OK FALSE) else () set(VERSION_MSG "(found suitable exact version \"${VERSION}\")") endif () + endif () + unset(_VERSION_DOTS) else() # minimum version specified: if ("${${_NAME}_FIND_VERSION}" VERSION_GREATER "${VERSION}") Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mantis at public.kitware.com Fri Oct 3 13:34:38 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 3 Oct 2014 13:34:38 -0400 Subject: [cmake-developers] [CMake 0015194]: Bug in CMake Xcode generator Message-ID: <5ca9a7d906c53a206bf3d2c71b453ef5@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15194 ====================================================================== Reported By: stopiccot Assigned To: ====================================================================== Project: CMake Issue ID: 15194 Category: CMake Reproducibility: always Severity: minor Priority: high Status: new ====================================================================== Date Submitted: 2014-10-03 13:34 EDT Last Modified: 2014-10-03 13:34 EDT ====================================================================== Summary: Bug in CMake Xcode generator Description: Generated project Xcode fails to build libraries with only object input files. Test repo: https://github.com/stopiccot/cmake_xcode_bug Xcode fails to create output file for "output_library_bugged" target nevertheless reporting that build succeeded. Everything is fine for "output_library_fixed" target. This actually maybe an Xcode not a CMake bug but we should consider adding this workaround into CMake. Example of real world project that suffers from this issue - https://github.com/PixarAnimationStudios/OpenSubdiv. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-03 13:34 stopiccot New Issue ====================================================================== From ben.boeckel at kitware.com Fri Oct 3 13:51:54 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 3 Oct 2014 13:51:54 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <542E964C.1050104@kitware.com> References: <542E964C.1050104@kitware.com> Message-ID: <20141003175154.GA2844@megas.kitwarein.com> On Fri, Oct 03, 2014 at 08:27:56 -0400, Brad King wrote: > In preparation for the first 3.1 release candidate I will feature- > freeze master as of 2014-10-09. As of now there are several open > topics in 'next' that we should try to land in master by then, but > please refrain from adding non-trivial changes in the meantime. I've just added the ubsan-support branch to stage (not merged yet; no new tests). It contains some documentation updates for AddressSanitizer and MEMORYCHECK_TYPE which were missed as well as support for MemoryCheckSanitizerOptions which adds key/value values to the environment variables for the sanitizers (ASAN_OPTIONS, TSAN_OPTIONS, and UBSAN_OPTIONS). Feel free to cherry-pick the documentation fixes (or I can spin out a branch) if the other changes are too late (I hope to add tests Monday, but can do it today if that's too late). --Ben From joubert.sy at gmail.com Fri Oct 3 14:00:00 2014 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Fri, 03 Oct 2014 20:00:00 +0200 Subject: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible In-Reply-To: References: <542DC4EF.2000400@gmail.com> <542E9D0B.1080806@kitware.com> Message-ID: <542EE420.7010406@gmail.com> Le 03/10/2014 17:41, Matthew Woehlke a ?crit : > On 2014-10-03 08:56, Brad King wrote: >> I'll leave that to a follow-up patch if anyone wants to do it. > > I was sort-of hoping / encouraging that Sylvain might be interested :-). > I quickly checked if it is possible. Unlike the rerun target which is manually added by the Ninja generator, the install and package targets are handled in a generic way by the utility target generator. Thus, handling these targets is not as straightforward as rerun. I'll keep digging a bit, maybe I can find a way to do it. ;-) From brad.king at kitware.com Fri Oct 3 14:34:38 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 14:34:38 -0400 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <7359420.jzfpyDp4lL@eto> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <1613841.KYJJi9OZnb@eto> <542ECB6E.8000307@kitware.com> <7359420.jzfpyDp4lL@eto> Message-ID: <542EEC3E.7050202@kitware.com> On 10/03/2014 12:47 PM, Rolf Eike Beer wrote: > + # give an exact match if the first ${NAME}_FIND_VERSION_COUNT components of the version string match > + # this constructs the equivalent of "(([^.]\\.){${${_NAME}_FIND_VERSION_COUNT}})" > + unset(_VERSION_REGEX) > + # foreach(RANGE) doesn't like it if stop is greater start > + if (${${_NAME}_FIND_VERSION_COUNT} GREATER 1) > + foreach (_NUM RANGE 2 ${${_NAME}_FIND_VERSION_COUNT}) > + set(_VERSION_REGEX "${_VERSION_REGEX}[^.]*\\.") > + endforeach () > + endif () Since _FIND_VERSION_COUNT is always [0-4], I think a hand-coded lookup table may be simpler and faster. > + string(REGEX REPLACE "^(${_VERSION_REGEX}[^.]*)\\..*" "\\1" _VERSION_HEAD "${VERSION}") Perhaps use something like if(VERSION MATCHES "^(${_VERSION_REGEX}[^.]*)\\..*") set(_VERSION_HEAD "${CMAKE_MATCH_1}") else() message(... bad VERSION in call to fphsa...) endif() in case something fails to match for some reason. Thanks, -Brad From mw_triad at users.sourceforge.net Fri Oct 3 14:43:47 2014 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 03 Oct 2014 14:43:47 -0400 Subject: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible In-Reply-To: <542EE420.7010406@gmail.com> References: <542DC4EF.2000400@gmail.com> <542E9D0B.1080806@kitware.com> <542EE420.7010406@gmail.com> Message-ID: On 2014-10-03 14:00, Sylvain Joubert wrote: > Le 03/10/2014 17:41, Matthew Woehlke a ?crit : >> On 2014-10-03 08:56, Brad King wrote: >>> I'll leave that to a follow-up patch if anyone wants to do it. >> >> I was sort-of hoping / encouraging that Sylvain might be interested :-). > > I quickly checked if it is possible. > > Unlike the rerun target which is manually added by the Ninja generator, > the install and package targets are handled in a generic way by the > utility target generator. > > Thus, handling these targets is not as straightforward as rerun. > I'll keep digging a bit, maybe I can find a way to do it. ;-) Many thanks, Sylvain. Don't worry if it's going to be a pain; I was thinking since you were in there anyway it might be easier for you. It's certainly much appreciated if you want to tackle this, but no worries if you don't. Thanks again for the re-run CMake patch! -- Matthew From eike at sf-mail.de Fri Oct 3 14:48:27 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 03 Oct 2014 20:48:27 +0200 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <542EEC3E.7050202@kitware.com> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <7359420.jzfpyDp4lL@eto> <542EEC3E.7050202@kitware.com> Message-ID: <3092690.HDODxZtjQg@caliban.sf-tec.de> Am Freitag, 3. Oktober 2014, 14:34:38 schrieb Brad King: > On 10/03/2014 12:47 PM, Rolf Eike Beer wrote: > > + # give an exact match if the first ${NAME}_FIND_VERSION_COUNT > > components of the version string match + # this constructs the > > equivalent of "(([^.]\\.){${${_NAME}_FIND_VERSION_COUNT}})" + > > unset(_VERSION_REGEX) > > + # foreach(RANGE) doesn't like it if stop is greater start > > + if (${${_NAME}_FIND_VERSION_COUNT} GREATER 1) > > + foreach (_NUM RANGE 2 ${${_NAME}_FIND_VERSION_COUNT}) > > + set(_VERSION_REGEX "${_VERSION_REGEX}[^.]*\\.") > > + endforeach () > > + endif () > > Since _FIND_VERSION_COUNT is always [0-4], I think a hand-coded lookup > table may be simpler and faster. Yes. > > + string(REGEX REPLACE "^(${_VERSION_REGEX}[^.]*)\\..*" "\\1" > > _VERSION_HEAD "${VERSION}") > Perhaps use something like > > if(VERSION MATCHES "^(${_VERSION_REGEX}[^.]*)\\..*") > set(_VERSION_HEAD "${CMAKE_MATCH_1}") > else() > message(... bad VERSION in call to fphsa...) > endif() > > in case something fails to match for some reason. I counted the number of dots before, so there must be a match. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Fri Oct 3 14:56:46 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 14:56:46 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: References: <542ACE37.1040302@kitware.com> <5370725.77ofmgz3NP@stryke> <542AE1BE.4000608@kitware.com> Message-ID: <542EF16E.7080105@kitware.com> On 09/30/2014 01:44 PM, Adam Strzelecki wrote: >> Please merge the topic to 'next' for testing when you're ready. >> We can at least see if the dashboard stays clean with it. > > Done. Since this was merged the dashboard has reported several failing instances of the BundleUtilities test. They have errors like: /usr/bin/find: invalid mode '+0111' CMake Error at .../Modules/BundleUtilities.cmake:395 (string): string sub-command REPLACE requires at least four arguments. Please extend the topic with a fix. Also use quoting like: - string(REPLACE "\n" ";" file_list ${file_list}) + string(REPLACE "\n" ";" file_list "${file_list}") to make sure the command runs when the file list is empty. After extending the topic please merge to 'next' again and check if it fixes the dashboard. Thanks, -Brad From brad.king at kitware.com Fri Oct 3 15:02:42 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 15:02:42 -0400 Subject: [cmake-developers] FindThreads-macro topic Message-ID: <542EF2D2.6090304@kitware.com> Eike, The topic adds a macro to FindThreads: > +macro(check_threads_lib LIBNAME FUNCNAME VARNAME) Since it is not meant for public use, please name it something like _threads_check_lib. Thanks, -Brad From brad.king at kitware.com Fri Oct 3 15:13:10 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Oct 2014 15:13:10 -0400 Subject: [cmake-developers] kwsys SystemTools::RelativePath() In-Reply-To: <542AB8B7.8020102@gmail.com> References: <542AB8B7.8020102@gmail.com> Message-ID: <542EF546.1050003@kitware.com> On 09/30/2014 10:05 AM, Nils Gladitz wrote: > When both operands are the same absolute path I get the empty string as > a result. > > Should it be "."? Perhaps. One would need to track down existing call sites to see where that might affect behavior. IIRC it is exposed through file(RELATIVE_PATH), so it may need a policy. That is probably overkill because there are legitimate use cases where an empty string looks better than ".". -Brad From nilsgladitz at gmail.com Fri Oct 3 15:30:21 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 03 Oct 2014 21:30:21 +0200 Subject: [cmake-developers] kwsys SystemTools::RelativePath() In-Reply-To: <542EF546.1050003@kitware.com> References: <542AB8B7.8020102@gmail.com> <542EF546.1050003@kitware.com> Message-ID: <542EF94D.7040103@gmail.com> On 03.10.2014 21:13, Brad King wrote: > On 09/30/2014 10:05 AM, Nils Gladitz wrote: >> When both operands are the same absolute path I get the empty string as >> a result. >> >> Should it be "."? > Perhaps. One would need to track down existing call sites > to see where that might affect behavior. IIRC it is exposed > through file(RELATIVE_PATH), so it may need a policy. That > is probably overkill because there are legitimate use cases > where an empty string looks better than ".". I guess that might be a matter of definition. I wouldn't consider the empty string a valid path though I understand that this may be what people expect now given that this behavior has already been established. I've worked around the issue I had with the "wix-fix-root-dir-prop" topic for now so there is no immediate need to change behavior before the 3.1 release. Thanks for the feedback. Nils From eike at sf-mail.de Fri Oct 3 16:20:05 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 03 Oct 2014 22:20:05 +0200 Subject: [cmake-developers] FindThreads-macro topic In-Reply-To: <542EF2D2.6090304@kitware.com> References: <542EF2D2.6090304@kitware.com> Message-ID: <2672065.WbbgQxofbn@caliban.sf-tec.de> Am Freitag, 3. Oktober 2014, 15:02:42 schrieb Brad King: > Eike, > > The topic adds a macro to FindThreads: > > +macro(check_threads_lib LIBNAME FUNCNAME VARNAME) > > Since it is not meant for public use, please name it something > like _threads_check_lib. Will do. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From DLRdave at aol.com Fri Oct 3 20:25:59 2014 From: DLRdave at aol.com (David Cole) Date: Fri, 3 Oct 2014 20:25:59 -0400 Subject: [cmake-developers] kwsys SystemTools::RelativePath() In-Reply-To: <542EF94D.7040103@gmail.com> References: <542AB8B7.8020102@gmail.com> <542EF546.1050003@kitware.com> <542EF94D.7040103@gmail.com> Message-ID: Is the result of RelativePath guaranteed to be a directory name, or is it possibly a file name....? If a directory, then perhaps "." makes sense and wouldn't negatively impact anything (other than cosmetically) if changed. But if a file, then "." doesn't make as much sense. "." to me implies it is the "current directory" or the "directory containing this thing" depending on the context. D On Fri, Oct 3, 2014 at 3:30 PM, Nils Gladitz wrote: > On 03.10.2014 21:13, Brad King wrote: >> >> On 09/30/2014 10:05 AM, Nils Gladitz wrote: >>> >>> When both operands are the same absolute path I get the empty string as >>> a result. >>> >>> Should it be "."? >> >> Perhaps. One would need to track down existing call sites >> to see where that might affect behavior. IIRC it is exposed >> through file(RELATIVE_PATH), so it may need a policy. That >> is probably overkill because there are legitimate use cases >> where an empty string looks better than ".". > > > I guess that might be a matter of definition. > I wouldn't consider the empty string a valid path though I understand that > this may be what people expect now given that this behavior has already been > established. > > I've worked around the issue I had with the "wix-fix-root-dir-prop" topic > for now so there is no immediate need to change behavior before the 3.1 > release. > > Thanks for the feedback. > > Nils > -- > > 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 nilsgladitz at gmail.com Sat Oct 4 02:32:48 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sat, 04 Oct 2014 08:32:48 +0200 Subject: [cmake-developers] kwsys SystemTools::RelativePath() In-Reply-To: References: <542AB8B7.8020102@gmail.com> <542EF546.1050003@kitware.com> <542EF94D.7040103@gmail.com> Message-ID: <542F9490.2020301@gmail.com> On 04.10.2014 02:25, David Cole wrote: > Is the result of RelativePath guaranteed to be a directory name, or is > it possibly a file name....? If the second operand is a path to a file the result is a path to a file. If the second operand is a path to a directory the result is a path to a directory. The first operand can only be a path to a directory. A path can not at the same time refer to a file and a directory. So when both operands are the same path this gives that they, as well as the result, can only be directory paths. Nils From ono at java.pl Sat Oct 4 11:37:18 2014 From: ono at java.pl (Adam Strzelecki) Date: Sat, 4 Oct 2014 17:37:18 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <542EF16E.7080105@kitware.com> References: <542ACE37.1040302@kitware.com> <5370725.77ofmgz3NP@stryke> <542AE1BE.4000608@kitware.com> <542EF16E.7080105@kitware.com> Message-ID: Brad, I've applied your suggestions about quoting and used portable (POSIX compliant) find call that should work now on any system. Fixup pushed to next. Thank you for your support! --Adam From konstantin at podsvirov.pro Sun Oct 5 05:18:33 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Sun, 05 Oct 2014 13:18:33 +0400 Subject: [cmake-developers] [update]: CPack IFW generator In-Reply-To: <53EA6A47.2060607@kitware.com> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> <53D66577.2050506@kitware.com> <599601406656034@web5j.yandex.ru> <53D8F040.1000505@kitware.com> <20851406730617@web26j.yandex.ru> <367461407337889@web14m.yandex.ru> <53E266EE.1070700@kitware.com> <53E8D59E.10000@kitware.com> <620911407869868@web19j.yandex.ru> <53EA6A47.2060607@kitware.com> Message-ID: <2764301412500713@web9g.yandex.ru> Hello dear developers! Hello Brad! Hello Nils! Straight to the point: Brad please apply my changes! There are only two commits. CPackIFW: Search algorithm update http://git.podsvirov.pro/?p=kitware/cmake.git;a=commit;h=f9f748745c6f4ef5b2dbf6d0732bc67a23d1cc63 And CPackIFW: Added support for multiple repositories http://git.podsvirov.pro/?p=kitware/cmake.git;a=commit;h=ed9684a22cf4babeaa1f9083f4061d789e513ba9 And now for more details. First: I got rid of CPACKE_IFW_*_EXECUTABLE_FOUND variables (this has already been asked Nils). Secondly: I've added support for multiple repositories (this is a very nice and useful for related and large projects function). Also you can now configure protected repository. Brad, I was very careful and did not make critical changes. I spent testing locally on their projects and I all works well. I hope that my changes will be applied and will have to be tested and will be included in CMake version 3.1.0-RC1. Regards, Konstantin Podsvirov From ono at java.pl Sun Oct 5 15:35:05 2014 From: ono at java.pl (Adam Strzelecki) Date: Sun, 5 Oct 2014 21:35:05 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: References: <542ACE37.1040302@kitware.com> <5370725.77ofmgz3NP@stryke> <542AE1BE.4000608@kitware.com> <542EF16E.7080105@kitware.com> Message-ID: <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> Correct me if I am wrong but it seems CDash reports no further problems with my changes. Cheers, --Adam From ruslan_baratov at yahoo.com Sun Oct 5 16:59:08 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Mon, 06 Oct 2014 00:59:08 +0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' Message-ID: <5431B11C.3010209@yahoo.com> Hi, I have CMake modules that can share resources between different instances. For now I manage it by invoking `mkdir /lock-directory` and checking the result, then removing this directory so the next instance can do the modification. The problem occurs when somebody terminate CMake. Since I can't set handler (e.g. SIGINT) to CMake, directory will not be removed and will be "locked" forever. So it can't be resolved without some low-level management. I'm thinking about `file` command sub-option like LOCK_DIRECTORY: `file(LOCK_DIRECTORY "/path/to/shared-dir")`. Does it sounds doable? Thanks, Ruslo From nilsgladitz at gmail.com Mon Oct 6 06:39:46 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 06 Oct 2014 12:39:46 +0200 Subject: [cmake-developers] CMP0053 - "Simplify variable reference and escape sequence evaluation" - regression Message-ID: <54327172.6030408@gmail.com> CMP0053 warns/fails on "$ENV{ProgramFiles(x86)}". Could "()" be added to the legal set of characters when within an $ENV{} expansion? Nils From brad.king at kitware.com Mon Oct 6 08:48:33 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Oct 2014 08:48:33 -0400 Subject: [cmake-developers] CMP0053 - "Simplify variable reference and escape sequence evaluation" - regression In-Reply-To: <54327172.6030408@gmail.com> References: <54327172.6030408@gmail.com> Message-ID: <54328FA1.1000306@kitware.com> On 10/06/2014 06:39 AM, Nils Gladitz wrote: > CMP0053 warns/fails on "$ENV{ProgramFiles(x86)}". > > Could "()" be added to the legal set of characters when within an $ENV{} > expansion? We considered that case and decided to ask users to use a nested variable reference for that case. There is a similar workaround in "Modules/Platform/WindowsPaths.cmake". One reason is that adding more characters to the allowed set, especially as a special case for $ENV{}, triggers extra tests and branches inside a tight loop that is used everywhere. -Brad From nilsgladitz at gmail.com Mon Oct 6 08:52:31 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 06 Oct 2014 14:52:31 +0200 Subject: [cmake-developers] CMP0053 - "Simplify variable reference and escape sequence evaluation" - regression In-Reply-To: <54328FA1.1000306@kitware.com> References: <54327172.6030408@gmail.com> <54328FA1.1000306@kitware.com> Message-ID: <5432908F.80909@gmail.com> On 10/06/2014 02:48 PM, Brad King wrote: > On 10/06/2014 06:39 AM, Nils Gladitz wrote: >> CMP0053 warns/fails on "$ENV{ProgramFiles(x86)}". >> >> Could "()" be added to the legal set of characters when within an $ENV{} >> expansion? > > We considered that case and decided to ask users to use a > nested variable reference for that case. There is a similar > workaround in "Modules/Platform/WindowsPaths.cmake". > > One reason is that adding more characters to the allowed set, > especially as a special case for $ENV{}, triggers extra tests > and branches inside a tight loop that is used everywhere. All right, no problem; I'll work around it. Thanks! Nils From brad.king at kitware.com Mon Oct 6 08:54:24 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Oct 2014 08:54:24 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5431B11C.3010209@yahoo.com> References: <5431B11C.3010209@yahoo.com> Message-ID: <54329100.8020502@kitware.com> On 10/05/2014 04:59 PM, Ruslan Baratov via cmake-developers wrote: > So it can't be resolved without some low-level management. I'm thinking > about `file` command sub-option like LOCK_DIRECTORY: > `file(LOCK_DIRECTORY "/path/to/shared-dir")`. Does it sounds doable? I think it is a reasonable proposal. However, more design is needed here, including at least the following items: * There needs to be a way to define the scope of the lock other than "until cmake exits". For example, "until current function exits". * There needs to be a way to explicitly unlock early, or to explicitly release management of the lock (e.g. to pass to some other process). * The implementation on Windows needs to be handled carefully. The "safe" way to delete a file there is to open it with a handle that is marked as delete-on-close, and then close the handle. That way the file is eventually deleted even if other processes currently have it open/locked. I don't know if there is an equivalent for a directory. Thanks, -Brad From brad.king at kitware.com Mon Oct 6 09:01:51 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Oct 2014 09:01:51 -0400 Subject: [cmake-developers] [update]: CPack IFW generator In-Reply-To: <2764301412500713@web9g.yandex.ru> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> <53D66577.2050506@kitware.com> <599601406656034@web5j.yandex.ru> <53D8F040.1000505@kitware.com> <20851406730617@web26j.yandex.ru> <367461407337889@web14m.yandex.ru> <53E266EE.1070700@kitware.com> <53E8D59E.10000@kitware.com> <620911407869868@web19j.yandex.ru> <53EA6A47.2060607@kitware.com> <2764301412500713@web9g.yandex.ru> Message-ID: <543292BF.1040704@kitware.com> On 10/05/2014 05:18 AM, Konstantin Podsvirov wrote: > Straight to the point: Brad please apply my changes! I've merged the topic to 'next' for testing: CPackIFW: Search algorithm update http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f9f74874 CPackIFW: Added support for multiple repositories http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed9684a2 Thanks, -Brad From brad.king at kitware.com Mon Oct 6 09:15:37 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Oct 2014 09:15:37 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> References: <542ACE37.1040302@kitware.com> <5370725.77ofmgz3NP@stryke> <542AE1BE.4000608@kitware.com> <542EF16E.7080105@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> Message-ID: <543295F9.1020705@kitware.com> On 10/04/2014 11:37 AM, Adam Strzelecki wrote: > I've applied your suggestions about quoting and used portable > (POSIX compliant) find call that should work now on any system. Thanks. On 10/05/2014 03:35 PM, Adam Strzelecki wrote: > Correct me if I am wrong but it seems CDash reports no > further problems with my changes. It's better, but the BundleUtilities test fails on OS X 10.5: http://open.cdash.org/testDetails.php?test=285651145&build=3517533 -- 6/10: fixing up '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1' install_name_tool: more than one input file specified (.../Tests/BundleUtilities/testdir1 and -delete_rpath) Usage: install_name_tool [-change old new] ... [-id name] input -- 7/10: fixing up '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/module1.so' install_name_tool: more than one input file specified (.../Tests/BundleUtilities/testdir1 and -delete_rpath) Usage: install_name_tool [-change old new] ... [-id name] input >From this message it looks like the install_name_tool does not support -delete_rpath. IIRC @rpath was first added in OS X 10.5 so it looks like that part had not yet matured. Use of -delete_rpath was previously added at install-time here: OS X: Add RPATH support for Mac. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=94e7fef2 so I think this problem existed before but was not exposed by tests. Clinton, what do you think of changing the Darwin.cmake test for enabling @rpath support to require OS X 10.6 instead of 10.5? Otherwise we may be leaking build tree RPATH entries into installed files on 10.5. Thanks, -Brad From brad.king at kitware.com Mon Oct 6 09:17:43 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Oct 2014 09:17:43 -0400 Subject: [cmake-developers] [update]: CPack IFW generator In-Reply-To: <762721412601328@web18m.yandex.ru> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> <53D66577.2050506@kitware.com> <599601406656034@web5j.yandex.ru> <53D8F040.1000505@kitware.com> <20851406730617@web26j.yandex.ru> <367461407337889@web14m.yandex.ru> <53E266EE.1070700@kitware.com> <53E8D59E.10000@kitware.com> <620911407869868@web19j.yandex.ru> <53EA6A47.2060607@kitware.com> <2764301412500713@web9g.yandex.ru> <543292BF.1040704@kitware.com> <762721412601328@web18m.yandex.ru> Message-ID: <54329677.9040305@kitware.com> On 10/06/2014 09:15 AM, Konstantin Podsvirov wrote: > Can I expect that CPack IFW generator will be in the tag v3.1.0-rc1? Anything that is in 'master' now will be in 3.1. This update should be merged in time barring catastrophic problems with it. Thanks, -Brad From konstantin at podsvirov.pro Mon Oct 6 09:15:28 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Mon, 06 Oct 2014 17:15:28 +0400 Subject: [cmake-developers] [update]: CPack IFW generator In-Reply-To: <543292BF.1040704@kitware.com> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> <53D66577.2050506@kitware.com> <599601406656034@web5j.yandex.ru> <53D8F040.1000505@kitware.com> <20851406730617@web26j.yandex.ru> <367461407337889@web14m.yandex.ru> <53E266EE.1070700@kitware.com> <53E8D59E.10000@kitware.com> <620911407869868@web19j.yandex.ru> <53EA6A47.2060607@kitware.com> <2764301412500713@web9g.yandex.ru> <543292BF.1040704@kitware.com> Message-ID: <762721412601328@web18m.yandex.ru> 06.10.2014, 17:01, "Brad King" : > On 10/05/2014 05:18 AM, Konstantin Podsvirov wrote: >> Straight to the point: Brad please apply my changes! > > I've merged the topic to 'next' for testing... Thank you :-) Can I expect that CPack IFW generator will be in the tag v3.1.0-rc1? This is my first contribution to CMake and I can't wait to see the results of its application. Regards, Konstantin Podsvirov From clinton at elemtech.com Mon Oct 6 10:14:33 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Mon, 6 Oct 2014 08:14:33 -0600 (MDT) Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <543295F9.1020705@kitware.com> References: <542ACE37.1040302@kitware.com> <542AE1BE.4000608@kitware.com> <542EF16E.7080105@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> <543295F9.1020705@kitware.com> Message-ID: <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> ----- Original Message ----- > On 10/04/2014 11:37 AM, Adam Strzelecki wrote: > > I've applied your suggestions about quoting and used portable > > (POSIX compliant) find call that should work now on any system. > > Thanks. > > On 10/05/2014 03:35 PM, Adam Strzelecki wrote: > > Correct me if I am wrong but it seems CDash reports no > > further problems with my changes. > > It's better, but the BundleUtilities test fails on OS X 10.5: > > http://open.cdash.org/testDetails.php?test=285651145&build=3517533 > > -- 6/10: fixing up > '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1' > install_name_tool: more than one input file specified > (.../Tests/BundleUtilities/testdir1 and -delete_rpath) > Usage: install_name_tool [-change old new] ... [-id name] input > -- 7/10: fixing up > '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/module1.so' > install_name_tool: more than one input file specified > (.../Tests/BundleUtilities/testdir1 and -delete_rpath) > Usage: install_name_tool [-change old new] ... [-id name] input > > From this message it looks like the install_name_tool does not > support -delete_rpath. IIRC @rpath was first added in OS X 10.5 > so it looks like that part had not yet matured. > > Use of -delete_rpath was previously added at install-time here: > > OS X: Add RPATH support for Mac. > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=94e7fef2 > > so I think this problem existed before but was not exposed by tests. > > Clinton, what do you think of changing the Darwin.cmake test for > enabling @rpath support to require OS X 10.6 instead of 10.5? > Otherwise we may be leaking build tree RPATH entries into installed > files on 10.5. Sure, I think it would be good to require 10.6. We also have uses of the -delete_rpath/-add_rpath parameters in cmInstallTargetGenerator.cxx, and the test of that already requires 10.6 or greater. Clint From ono at java.pl Mon Oct 6 10:36:43 2014 From: ono at java.pl (Adam Strzelecki) Date: Mon, 6 Oct 2014 16:36:43 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> References: <542ACE37.1040302@kitware.com> <542AE1BE.4000608@kitware.com> <542EF16E.7080105@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> Message-ID: <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> > Sure, I think it would be good to require 10.6. > We also have uses of the -delete_rpath/-add_rpath parameters in cmInstallTargetGenerator.cxx, and the test of that already requires 10.6 or greater. Moreover I believe nobody nowadays builds for 10.5 on 10.5. Since 10.6 with Xcode 3 supports 10.5 PPC and Apple allows virtualization of 10.6 Server, so if anyone still targets PPC on 10.5 or earlier then 10.6 is natural choice. --Adam From brad.king at kitware.com Mon Oct 6 11:00:33 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Oct 2014 11:00:33 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> References: <542ACE37.1040302@kitware.com> <542AE1BE.4000608@kitware.com> <542EF16E.7080105@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> Message-ID: <5432AE91.1010708@kitware.com> On 10/06/2014 10:36 AM, Adam Strzelecki wrote: >> Sure, I think it would be good to require 10.6. > > Moreover I believe nobody nowadays builds for 10.5 on 10.5. Perhaps no one has to build that way for deployment but there could still be people just building for their own host as the only computer they have. The fact that our dashboard reported this problem means we are testing that case. Clinton, I don't have a 10.5 machine anymore and the test is failing on yours. Please take whatever action you feel is appropriate to resolve the test failure on that machine. This could mean either disabling rpath altogether on 10.5 or changing the new hunk: > + foreach(rpath ${${ikey}_RPATHS}) > + set(changes ${changes} -delete_rpath "${rpath}") > + endforeach() to warn and skip removal when hosted on 10.5. Or another option you find. This needs to be resolved in the next day or two or the topic won't be in CMake 3.1. Thanks, -Brad From ben.boeckel at kitware.com Mon Oct 6 14:24:47 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 6 Oct 2014 14:24:47 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <20141003175154.GA2844@megas.kitwarein.com> References: <542E964C.1050104@kitware.com> <20141003175154.GA2844@megas.kitwarein.com> Message-ID: <20141006182447.GA7342@megas.kitwarein.com> On Fri, Oct 03, 2014 at 13:51:54 -0400, Ben Boeckel wrote: > Feel free to cherry-pick the documentation fixes (or I can spin out a > branch) if the other changes are too late (I hope to add tests Monday, > but can do it today if that's too late). A test has been added. Brad, there are some bugfixes for tsan and asan in there. Is it too late to merge the whole branch or do you want me to cherry-pick them out? --Ben From brad.king at kitware.com Mon Oct 6 14:31:58 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Oct 2014 14:31:58 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <20141006182447.GA7342@megas.kitwarein.com> References: <542E964C.1050104@kitware.com> <20141003175154.GA2844@megas.kitwarein.com> <20141006182447.GA7342@megas.kitwarein.com> Message-ID: <5432E01E.7020105@kitware.com> On 10/06/2014 02:24 PM, Ben Boeckel wrote: > On Fri, Oct 03, 2014 at 13:51:54 -0400, Ben Boeckel wrote: >> Feel free to cherry-pick the documentation fixes (or I can spin out a >> branch) if the other changes are too late (I hope to add tests Monday, >> but can do it today if that's too late). > > A test has been added. Brad, there are some bugfixes for tsan and asan > in there. Is it too late to merge the whole branch or do you want me to > cherry-pick them out? Please re-order the topic to have all the fixes first, and then the changes to add ubsan support. That way I can revert the latter if it is problematic. Then merge the whole topic for testing. Thanks, -Brad From ben.boeckel at kitware.com Mon Oct 6 15:29:53 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 6 Oct 2014 15:29:53 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <5432E01E.7020105@kitware.com> References: <542E964C.1050104@kitware.com> <20141003175154.GA2844@megas.kitwarein.com> <20141006182447.GA7342@megas.kitwarein.com> <5432E01E.7020105@kitware.com> Message-ID: <20141006192953.GB30737@megas.kitwarein.com> On Mon, Oct 06, 2014 at 14:31:58 -0400, Brad King wrote: > Please re-order the topic to have all the fixes first, and then the > changes to add ubsan support. That way I can revert the latter if > it is problematic. Then merge the whole topic for testing. Done. --Ben From eike at sf-mail.de Mon Oct 6 16:04:09 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 06 Oct 2014 22:04:09 +0200 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <542EEC3E.7050202@kitware.com> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <7359420.jzfpyDp4lL@eto> <542EEC3E.7050202@kitware.com> Message-ID: <1936223.oZsl9n5N2H@eto> Brad King wrote: > On 10/03/2014 12:47 PM, Rolf Eike Beer wrote: > > + # give an exact match if the first ${NAME}_FIND_VERSION_COUNT > > components of the version string match + # this constructs the > > equivalent of "(([^.]\\.){${${_NAME}_FIND_VERSION_COUNT}})" + > > unset(_VERSION_REGEX) > > + # foreach(RANGE) doesn't like it if stop is greater start > > + if (${${_NAME}_FIND_VERSION_COUNT} GREATER 1) > > + foreach (_NUM RANGE 2 ${${_NAME}_FIND_VERSION_COUNT}) > > + set(_VERSION_REGEX "${_VERSION_REGEX}[^.]*\\.") > > + endforeach () > > + endif () > > Since _FIND_VERSION_COUNT is always [0-4], I think a hand-coded lookup > table may be simpler and faster. Topic FPHSA_exact_version pushed to next. Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From clinton at elemtech.com Tue Oct 7 00:34:51 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Mon, 6 Oct 2014 22:34:51 -0600 (MDT) Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <5432AE91.1010708@kitware.com> References: <542ACE37.1040302@kitware.com> <542EF16E.7080105@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> <5432AE91.1010708@kitware.com> Message-ID: <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> ----- Original Message ----- > On 10/06/2014 10:36 AM, Adam Strzelecki wrote: > >> Sure, I think it would be good to require 10.6. > > > > Moreover I believe nobody nowadays builds for 10.5 on 10.5. > > Perhaps no one has to build that way for deployment but there could > still be people just building for their own host as the only computer > they have. The fact that our dashboard reported this problem means > we are testing that case. > > Clinton, I don't have a 10.5 machine anymore and the test is failing > on yours. Please take whatever action you feel is appropriate to > resolve the test failure on that machine. This could mean either > disabling rpath altogether on 10.5 or changing the new hunk: > > > + foreach(rpath ${${ikey}_RPATHS}) > > + set(changes ${changes} -delete_rpath "${rpath}") > > + endforeach() > > to warn and skip removal when hosted on 10.5. Or another option you > find. > > This needs to be resolved in the next day or two or the topic won't > be in CMake 3.1. > > Thanks, > -Brad > > I don't have a 10.5 machine, but I've put in a commit which I hope solves the problem. 36c509b9 OSX: Only enable @rpath support on OS X 10.6 or greater. Clint From ruslan_baratov at yahoo.com Tue Oct 7 02:49:21 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Tue, 07 Oct 2014 10:49:21 +0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <54329100.8020502@kitware.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> Message-ID: <54338CF1.3070304@yahoo.com> On 06-Oct-14 16:54, Brad King wrote: > On 10/05/2014 04:59 PM, Ruslan Baratov via cmake-developers wrote: >> So it can't be resolved without some low-level management. I'm thinking >> about `file` command sub-option like LOCK_DIRECTORY: >> `file(LOCK_DIRECTORY "/path/to/shared-dir")`. Does it sounds doable? > I think it is a reasonable proposal. However, more design is needed > here, including at least the following items: > > * There needs to be a way to define the scope of the lock other than > "until cmake exits". For example, "until current function exits". > > * There needs to be a way to explicitly unlock early, or > to explicitly release management of the lock (e.g. to pass to some other process). How it will looks like in terms of CMake code? > > * The implementation on Windows needs to be handled carefully. > The "safe" way to delete a file there is to open it with a handle > that is marked as delete-on-close, and then close the handle. > That way the file is eventually deleted even if other processes > currently have it open/locked. I don't know if there is an > equivalent for a directory. > > Thanks, > -Brad > From amine.khaldi at reactos.org Tue Oct 7 03:22:02 2014 From: amine.khaldi at reactos.org (Amine Khaldi) Date: Tue, 07 Oct 2014 08:22:02 +0100 Subject: [cmake-developers] Severe regression caused by #14972 fixes Message-ID: <5433949A.6060707@reactos.org> Hi, Please note that from the http://www.cmake.org/Bug/view.php?id=14972 fixes on, we can no longer compile ReactOS. We have many DEPENDS on files that exist in the source (they are simply input files, they're not generated or so) like spec files, inf files, idl files...etc and they end up in the "Unknown Build Time Dependencies" which should not happen, and did not happen with CMake 2.8.x As a result of this, it's no longer possible to use the new CMake to compile ReactOS, which makes us see this as a severe regression, considering that CMake is the build system we use to compile the project. Adam, Brad and co, can you please help ? Regards, Amine. From konstantin at podsvirov.pro Tue Oct 7 04:27:37 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 07 Oct 2014 12:27:37 +0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <542E964C.1050104@kitware.com> References: <542E964C.1050104@kitware.com> Message-ID: <2161691412670457@web14h.yandex.ru> Hello dear developers! 03.10.2014, 16:28, "Brad King" : > Hi Folks, > > In preparation for the first 3.1 release candidate I will feature- > freeze master as of 2014-10-09. As of now there are several open > topics in 'next' that we should try to land in master by then, but > please refrain from adding non-trivial changes in the meantime. > > Thanks, > -Brad CMake is a large set of tools which touches upon many topics. I think everyone is doing their questions and know little about the problems and successes of others. I noticed that the version for developers (from cmake.org/file/dev does not contain the html documentation (I checked for Windows). Fresh build documentation from 7 October: Sphinx http://ifw.podsvirov.pro/cmake/doc/sphinx Doxygen http://ifw.podsvirov.pro/cmake/doc/doxygen In the first place when the distribution CMake version is created Sphinx and it's a good documentation. But I urge you not to forget about documenting code - it will help new developers to understand and to make a contribution. The version of Doxygen documentation is not in the best form, but I have plans to work over this. And advertising: CMake 3.1 will contain the new CPack generator called "IFW", which will help to create a nice installer with a graphical user interface on the desktop. Fresh morning building (with html documentation from Sphinx) online installer with update support. Linux: http://ifw.podsvirov.pro/cmake/cmake-dev-linux-x86_64-online.run Windows: http://ifw.podsvirov.pro/cmake/cmake-dev-windows-x86-online.exe Set one is updated constantly :-) All for a good day! Regards, Konstantin Podsvirov From mantis at public.kitware.com Tue Oct 7 08:09:18 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 7 Oct 2014 08:09:18 -0400 Subject: [cmake-developers] [CMake 0015198]: ps2pdf not detected when cross-compiling Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15198 ====================================================================== Reported By: Helfer Thomas Assigned To: ====================================================================== Project: CMake Issue ID: 15198 Category: CMake Reproducibility: always Severity: minor Priority: low Status: new ====================================================================== Date Submitted: 2014-10-07 08:09 EDT Last Modified: 2014-10-07 08:09 EDT ====================================================================== Summary: ps2pdf not detected when cross-compiling Description: Hi, ps2pdf not detected when cross-compiling (and only when cross-compiling), but latex is. The main difference seems that latex is an executable and ps2pdf14 a script (I am using the standard texlive distribution). Steps to Reproduce: 1) decompress the attached archive and launch cmake in the created directory: cmake . -DCMAKE_TOOLCHAIN_FILE=../ToolChain-i686-w64-mingw32.cmake 2) check the PS2PDF_CONVERTER value in CMakeCache.txt: //Path to a program. PS2PDF_CONVERTER:FILEPATH=PS2PDF_CONVERTER-NOTFOUND Additional Information: ps2pdf is detected when no toolchain file is declared ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-07 08:09 Helfer Thomas New Issue 2014-10-07 08:09 Helfer Thomas File Added: test-cmake.tar.bz2 ====================================================================== From brad.king at kitware.com Tue Oct 7 08:25:37 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Oct 2014 08:25:37 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <54338CF1.3070304@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> Message-ID: <5433DBC1.5080800@kitware.com> On 10/07/2014 02:49 AM, Ruslan Baratov wrote: > How it will looks like in terms of CMake code? That's what I'm asking you to think through and propose ;) Thanks, -Brad From brad.king at kitware.com Tue Oct 7 08:28:37 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Oct 2014 08:28:37 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> References: <542ACE37.1040302@kitware.com> <542EF16E.7080105@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> <5432AE91.1010708@kitware.com> <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> Message-ID: <5433DC75.9010705@kitware.com> On 10/07/2014 12:34 AM, clinton at elemtech.com wrote: > I don't have a 10.5 machine Oops, I must have mixed up my browser tabs on that one. > but I've put in a commit which I hope solves the problem. > 36c509b9 OSX: Only enable @rpath support on OS X 10.6 or greater. Thanks! -Brad From brad.king at kitware.com Tue Oct 7 08:47:50 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Oct 2014 08:47:50 -0400 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <5433949A.6060707@reactos.org> References: <5433949A.6060707@reactos.org> Message-ID: <5433E0F6.2090802@kitware.com> On 10/07/2014 03:22 AM, Amine Khaldi wrote: > Please note that from the http://www.cmake.org/Bug/view.php?id=14972 > fixes on, we can no longer compile ReactOS. Thanks for trying the development version and reporting this regression before it was released. > We have many DEPENDS on files that exist in the source (they are simply > input files, they're not generated or so) like spec files, inf files, > idl files...etc and they end up in the "Unknown Build Time Dependencies" > which should not happen, and did not happen with CMake 2.8.x Would you please construct a CMake code example demonstrating this in a small test case? We'd rather not have to try building all of ReactOS to reproduce this. Also, what build-time failure do you actually get? Thanks, -Brad From bill.hoffman at kitware.com Tue Oct 7 10:09:01 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 07 Oct 2014 10:09:01 -0400 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <5433E0F6.2090802@kitware.com> References: <5433949A.6060707@reactos.org> <5433E0F6.2090802@kitware.com> Message-ID: <5433F3FD.8070602@kitware.com> On 10/7/2014 8:47 AM, Brad King wrote: > Please note that from thehttp://www.cmake.org/Bug/view.php?id=14972 >>fixes on, we can no longer compile ReactOS. Also, if you really care about ReactOS, you could run a nightly cmake dashboard. Or it is almost certain that it will get broken again. If we are not testing it, it is broken... http://www.cmake.org/testing/ Thanks. -Bill From nilsgladitz at gmail.com Tue Oct 7 10:15:20 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 07 Oct 2014 16:15:20 +0200 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <5433F3FD.8070602@kitware.com> References: <5433949A.6060707@reactos.org> <5433E0F6.2090802@kitware.com> <5433F3FD.8070602@kitware.com> Message-ID: <5433F578.9000900@gmail.com> On 10/07/2014 04:09 PM, Bill Hoffman wrote: > On 10/7/2014 8:47 AM, Brad King wrote: >> Please note that from thehttp://www.cmake.org/Bug/view.php?id=14972 >>> fixes on, we can no longer compile ReactOS. > Also, if you really care about ReactOS, you could run a nightly cmake > dashboard. Or it is almost certain that it will get broken again. If > we are not testing it, it is broken... > > http://www.cmake.org/testing/ To clarify as far as I understand it this particular issue is with building ReactOS on regular Windows rather than using CMake under ReactOS. Which of course doesn't mean that there shouldn't be a dashboard for it nonetheless :) Nils From brad.king at kitware.com Tue Oct 7 10:35:24 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Oct 2014 10:35:24 -0400 Subject: [cmake-developers] FindThreads_overhaul topic Message-ID: <5433FA2C.9070809@kitware.com> Eike, This fails on a few dashboard machines: http://open.cdash.org/testDetails.php?test=286158250&build=3519076 CMake Error at /.../Modules/FindThreads.cmake:207 (add_library): add_library cannot create imported target "CMake::Threads" because another target with the same name already exists. Instead of using a variable like HAVE_CMAKE_THREADS_TARGET, just test for the target. Look at FindOpenGL for an example: if(OPENGL_FOUND) if(NOT TARGET OpenGL::GL) add_library(OpenGL::GL UNKNOWN IMPORTED) > + add_library(CMake::Threads INTERFACE IMPORTED GLOBAL) The imported target should not be GLOBAL. Thanks, -Brad From ono at java.pl Tue Oct 7 10:42:36 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 7 Oct 2014 16:42:36 +0200 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <5433F578.9000900@gmail.com> References: <5433949A.6060707@reactos.org> <5433E0F6.2090802@kitware.com> <5433F3FD.8070602@kitware.com> <5433F578.9000900@gmail.com> Message-ID: > To clarify as far as I understand it this particular issue is with building ReactOS on regular Windows rather than using CMake under ReactOS. > > Which of course doesn't mean that there shouldn't be a dashboard for it nonetheless :) Yup, this is what I understand. It isn't a problem with compiling CMake on ReactOS, but problem of compiling ReactOS with latest CMake master. I'll follow the discussion with Amine and try to sort it out. --Adam From brad.king at kitware.com Tue Oct 7 10:43:23 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Oct 2014 10:43:23 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <542E964C.1050104@kitware.com> References: <542E964C.1050104@kitware.com> Message-ID: <5433FC0B.4060802@kitware.com> On 10/03/2014 08:27 AM, Brad King wrote: > In preparation for the first 3.1 release candidate I will feature- > freeze master as of 2014-10-09. As of now there are several open > topics in 'next' that we should try to land in master by then, but > please refrain from adding non-trivial changes in the meantime. In order to get the dashboard cleaned up for final merges to 'master' before the release, please refrain from merging any changes other than dashboard fixes and documentation updates to 'next'. Thanks, -Brad From ono at java.pl Tue Oct 7 10:56:40 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 7 Oct 2014 16:56:40 +0200 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <5433949A.6060707@reactos.org> References: <5433949A.6060707@reactos.org> Message-ID: > As a result of this, it's no longer possible to use the new CMake to compile ReactOS, which makes us see this as a severe regression, considering that CMake is the build system we use to compile the project. > Adam, Brad and co, can you please help ? If I understand correctly the change introduced by a33cf6d08853ea4c79324bdd36c04f311a23f20a (Ninja: Consider only custom commands deps as side-effects (#14972)) caused that regression? Can you please point to me any test case I can run in order to see it failing on CMake 3.x and running fine on CMake 2.8. If this is a bug I am willing to fix it ASAP. However please note that if these files are produced by some custom commands that not specify them as an output and then these are inputs (dependencies) to some regular build command, then it is expected behavior. Indeed it working was working previously in 2.8 just by coincidence, because CMake was generating suboptimal build graph simply adding all custom commands regardless of anything as implicit dependencies, even it was not necessary or expressed anywhere, causing severe clutter in Ninja build graph. So, (1) Are these .spec, .inf or .idl generated by some custom commands? (2) If yes, are these files specified as an output of these subcommand commands? If no, why? --Adam From nilsgladitz at gmail.com Tue Oct 7 11:04:14 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 07 Oct 2014 17:04:14 +0200 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: References: <5433949A.6060707@reactos.org> Message-ID: <543400EE.5090803@gmail.com> On 10/07/2014 04:56 PM, Adam Strzelecki wrote: > (1) Are these .spec, .inf or .idl generated by some custom commands? > (2) If yes, are these files specified as an output of these subcommand commands? If no, why? From what I remember from the IRC discussion ... They are regular (not generated) source files that are listed as dependencies (but not outputs) of custom commands. Nils From bill.hoffman at kitware.com Tue Oct 7 11:34:21 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 07 Oct 2014 11:34:21 -0400 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: References: <5433949A.6060707@reactos.org> <5433E0F6.2090802@kitware.com> <5433F3FD.8070602@kitware.com> <5433F578.9000900@gmail.com> Message-ID: <543407FD.8030602@kitware.com> On 10/7/2014 10:42 AM, Adam Strzelecki wrote: >> >Which of course doesn't mean that there shouldn't be a dashboard for it nonetheless:) > Yup, this is what I understand. It isn't a problem with compiling CMake on ReactOS, but problem of compiling ReactOS with latest CMake master. > > I'll follow the discussion with Amine and try to sort it out. I see. In that case a contract test might be a good thing... https://github.com/Kitware/CMake/tree/master/Tests/Contracts The idea is to add a build of a project as a test to CMake. See CMAKE_CONTRACT_PROJECTS in Tests/CMakeLists.txt for an idea of how this works. -Bill From eike at sf-mail.de Tue Oct 7 12:18:56 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 07 Oct 2014 18:18:56 +0200 Subject: [cmake-developers] FindThreads_overhaul topic In-Reply-To: <5433FA2C.9070809@kitware.com> References: <5433FA2C.9070809@kitware.com> Message-ID: <1560898.ZRjqAlt5LQ@caliban.sf-tec.de> Am Dienstag, 7. Oktober 2014, 10:35:24 schrieb Brad King: > Eike, > > This fails on a few dashboard machines: > > http://open.cdash.org/testDetails.php?test=286158250&build=3519076 > CMake Error at /.../Modules/FindThreads.cmake:207 (add_library): > add_library cannot create imported target "CMake::Threads" because > another target with the same name already exists. > > Instead of using a variable like HAVE_CMAKE_THREADS_TARGET, > just test for the target. Look at FindOpenGL for an example: > > if(OPENGL_FOUND) > if(NOT TARGET OpenGL::GL) > add_library(OpenGL::GL UNKNOWN IMPORTED) > > > + add_library(CMake::Threads INTERFACE IMPORTED GLOBAL) > > The imported target should not be GLOBAL. Both issues should be fixed now. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Tue Oct 7 14:03:57 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Oct 2014 14:03:57 -0400 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <1936223.oZsl9n5N2H@eto> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <7359420.jzfpyDp4lL@eto> <542EEC3E.7050202@kitware.com> <1936223.oZsl9n5N2H@eto> Message-ID: <54342B0D.6030809@kitware.com> On 10/06/2014 04:04 PM, Rolf Eike Beer wrote: > Topic FPHSA_exact_version pushed to next. Thanks. The impl looks okay to me. Please look at extending the FindPackageTest with a case to cover this. It already has at least one case for FPHSA. Alternatively you could add cases to RunCMake.find_package if that proves easier. Thanks, -Brad From ono at java.pl Tue Oct 7 14:21:58 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 7 Oct 2014 20:21:58 +0200 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <543400EE.5090803@gmail.com> References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> Message-ID: > From what I remember from the IRC discussion ... > They are regular (not generated) source files that are listed as dependencies (but not outputs) of custom commands. Okay now I get it. So actually 7243c951 (Ninja: Don't limit custom cmd side-effects to build folder (#14972)) is to blame not a33cf6d0 (Ninja: Consider only custom commands deps as side-effects (#14972)). Previously in 2.8 only files in build folder might have been be side-effects, but as we have discussed with Brad this is pretty inaccurate assumption. So we have decided that ANY file that is dependency of custom command may be a side effect, therefore ReactOS files landing in "Unknown Build Time Dependencies." that serve only one purpose, to not bail out Ninja on very beginning if file does not exist as file may appear later on during build. But it does NOT stop Ninja to properly relaunch custom command if the file gets modified. So I guess we may point to the wrong direction. Simple example: -- test.txt 1 2 3 test -- CMakeLists.txt cmake_minimum_required(VERSION 2.6) project(DependTest C) add_custom_command( OUTPUT test-out.txt COMMAND cp test.txt test-out.txt DEPENDS test.txt) add_custom_target(depend-test ALL cat test-out.txt DEPENDS test-out.txt) (1) first run $ ninja -v [1/2] cd /tmp/depend && cp test.txt test-out.txt [2/2] cd /tmp/depend && cat test-out.txt 1 2 3 test (2) 2nd run $ ninja -v [1/1] cd /tmp/depend && cat test-out.txt 1 2 3 test (3) touching test.txt $ touch test.txt $ ninja -v [1/2] cd /tmp/depend && cp test.txt test-out.txt [2/2] cd /tmp/depend && cat test-out.txt 1 2 3 test So with proper test case and detailed reports, something more than vague "latest CMake makes our project not to compile anymore" I am unable to help, but I am willing to help. So please either provide test case, or some info how to run this problematic build (I have access to OSX, Linux or Windows system), or find me on #cmake IRC channel under "OnO". --Adam From brad.king at kitware.com Tue Oct 7 15:58:16 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Oct 2014 15:58:16 -0400 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> Message-ID: <543445D8.1000806@kitware.com> On 10/07/2014 02:21 PM, Adam Strzelecki wrote: > So please either provide test case, or some info [snip] On 10/07/2014 03:20 PM, Adam Strzelecki wrote: > I had a talk with Amine, and the problem was that due 7243c951 > their build.ninja was getting numerous extra phony entries that > were leading Ninja to crash! So yes we could point our fingers > on Ninja and close the case, but I propose we do something > better: For reference, that commit was: Ninja: Don't limit custom cmd side-effects to build folder (#14972) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7243c951 So now a large number of phony rules for files in the source tree appear that did not before. The case in question uses custom command dependencies so is not helped by the parent change: Ninja: Consider only custom commands deps as side-effects (#14972) http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a33cf6d0 > I kindly ask to make possible side-effects phony rules as > deprecated by some new policy. Basically long story short all > these "side-effects" tricks were to make some old projects > don't explicitly specifying custom command outputs work with > Ninja that stat files once at start, so if there is a > side-effect file that isn't explicitly specified as command > output it will be NOT restat, that will lead to some other > command having that file as dependency to fail. That situation is discussed thoroughly here: Add explicit specification of custom command side effect outputs http://www.cmake.org/Bug/view.php?id=14963 and here: https://github.com/martine/ninja/issues/760#issuecomment-46540858 Ideally both CMake and Ninja will fix their pieces of the problem. Fixing the Ninja side as I propose in the above-linked comment would solve the problem outright with no further changes. The fix on the CMake side will also require projects to be updated to use the new feature, but will help generate more efficient Ninja build rules. > Since Make does restat dependencies on each rule this won't > happen with Make. So we put "side-effects" in phony ensuring > Ninja to pickup the rules even the file didn't exist when Ninja > was started. No. For build systems besides Ninja the side effects cannot be listed as outputs of custom commands. Their timestamps are not always updated when the custom command runs, so the rules may be left in an always-rerun state because the side-effect "outputs" will never be newer than inputs. Since CMake was designed for such build systems before Ninja existed, there is no interface to specify the side-effects explicitly. > My original intention was actually to limit these phony rules > and it was done by: > > (1) a33cf6d0 (Ninja: Consider only custom commands deps as > side-effects (#14972)) > > However somewhere during discussion with Brad I raised question > why such side-effect are to be in build folder in fact they can > be anywhere and it we want to ensure Ninja build won't fail > when Make build goes well we need introduced: > > (2) 7243c951 (Ninja: Don't limit custom cmd side-effects to > build folder (#14972)) > > This unfortunately lead Ninja to crash with many extra > side-effect phony rules in ReactOS case. > > So again I propose we make side-effect as policy enabled only > for projects <3.1. That is not possible because CMake currently does not have enough information to produce valid Ninja files without the phony rules. The proper fix to address issue 14963 and provide projects with an interface to specify custom command side-effects explicitly. Then dependencies can be hooked up correctly for Ninja. I invite you to propose an interface to achieve this. This will not be done before the freeze for 3.1 on Thursday. Reverting 7243c951 will resolve the problem for ReactOS in out-of-source builds. So, we either revert that or hope Ninja can be fixed to deal with the large dependency lists w/out crashing. -Brad From ono at java.pl Tue Oct 7 16:53:26 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 7 Oct 2014 22:53:26 +0200 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <543445D8.1000806@kitware.com> References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> <543445D8.1000806@kitware.com> Message-ID: <067CB9F0-D22A-4595-BD45-23A70F162C20@java.pl> > This will not be done before the freeze for 3.1 on Thursday. > Reverting 7243c951 will resolve the problem for ReactOS in > out-of-source builds. So, we either revert that or hope Ninja can > be fixed to deal with the large dependency lists w/out crashing. In meantime I've pushed stage/cmp0055-disable-ninja-side-effects that make CMake warn about this compatibility layer when such phony rules are about to be emitted. Setting policy to NEW or making all deps to be explicit outputs disables warning, setting to OLD removed warning keeping phony rules. IHMO this is win-win for everybody, since it will emit warnings once someone installs 3.1 and possibly relies on side-effect. One thing I am not sure about is if the CMP0055.rst provided is clear enough for the reader. --Adam From irwin at beluga.phys.uvic.ca Tue Oct 7 16:59:00 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 7 Oct 2014 13:59:00 -0700 (PDT) Subject: [cmake-developers] "Contract" testing of CMake Message-ID: Hi Bill: In a recent thread on list you brought up the topic of "contract" testing where apparently the idea is CMake is tested by building some git version of CMake than building some fixed version of another project against that version to make sure no regression in CMake behaviour has crept in. I would like to help CMake (and protect PLplot against potential future CMake regressions) by doing informal "contract" PLplot build tests by hand for some fixed version of PLplot to to start with. Which CMake branch would you recommend for this general purpose? Should I be following the tip of maint, master, next, or release with such tests? Of course, once I got such a contract test to work by hand, I would probably want to move to a formal automated procedure so your advice on that would be appreciated as well. 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 eike at sf-mail.de Tue Oct 7 17:18:14 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 07 Oct 2014 23:18:14 +0200 Subject: [cmake-developers] Improving the version selection behavior of EXACT In-Reply-To: <54342B0D.6030809@kitware.com> References: <2265519.UlzGx0ETMW@caliban.sf-tec.de> <1936223.oZsl9n5N2H@eto> <54342B0D.6030809@kitware.com> Message-ID: <4891641.1y26fJf6Lr@caliban.sf-tec.de> Am Dienstag, 7. Oktober 2014, 14:03:57 schrieb Brad King: > On 10/06/2014 04:04 PM, Rolf Eike Beer wrote: > > Topic FPHSA_exact_version pushed to next. > > Thanks. The impl looks okay to me. Please look at extending > the FindPackageTest with a case to cover this. It already has > at least one case for FPHSA. Alternatively you could add cases > to RunCMake.find_package if that proves easier. I extended RunCMake.FPHSA ;) And found an unrelated bug along the way. Once this is settled I would like to change the run_cmake implementation to allow for an explicitely named include. It hurts me to drop many identical test files in the directories for no good reason. But for that I wait until the dust has settled. FPHSA also has some needless variable expansion that I would like to get rid of, too. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From irwin at beluga.phys.uvic.ca Tue Oct 7 18:46:51 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 7 Oct 2014 15:46:51 -0700 (PDT) Subject: [cmake-developers] Any ideas for accessing the Dart source code? Message-ID: I thought it would be interesting to install my own local dart server to learn how to use CTest as a dart client. However, the dart server software development effort seems to have a largely broken web presence. For example, http://www.cmake.org/dart/HTML/Install.shtml points to a Dart.pdf documentation file that is a broken link. The Dart Wiki at which is recommended by the above cmake.org site is still up and running, but it also refers to that same broken link for Dart.pdf. From the Wiki the latest Dart release seems to be 1.0.9 (from 7 (!) years ago). I discovered that release does include the Dart.pdf file which is good, but only includes jar files and not source code which is bad. For example, I am concerned those 7-year old *.class files in the jar files might not run properly with modern java. Therefore, I would like to build those jar files from source. According to the above wiki you can get access to the source code using svn co http://svn.na-mic.org/svn/Dart/trunk but that command immediately returns svn: OPTIONS of 'http://svn.na-mic.org/svn/Dart/trunk': 200 OK In contrast, Dart.pdf states that source code is available using svn checkout http://svn.na-mic.org:8000/svn/Dart However, that command times out with "cannot connect to server". Does anyone here know how to access the Dart source or is that gone forever? 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 DLRdave at aol.com Tue Oct 7 19:06:32 2014 From: DLRdave at aol.com (David Cole) Date: Tue, 7 Oct 2014 19:06:32 -0400 Subject: [cmake-developers] Any ideas for accessing the Dart source code? In-Reply-To: References: Message-ID: Consider using CDash instead. It was Dart's "drop-in" replacement... and is actively maintained today. www.cdash.org On Tue, Oct 7, 2014 at 6:46 PM, Alan W. Irwin wrote: > I thought it would be interesting to install my own local dart server > to learn how to use CTest as a dart client. However, the dart server > software development effort seems to have a largely broken web > presence. For example, http://www.cmake.org/dart/HTML/Install.shtml > points to a Dart.pdf documentation file that is a broken link. The > Dart Wiki at which is > recommended by the above cmake.org site is still up and running, but > it also refers to that same broken link for Dart.pdf. From the Wiki > the latest Dart release seems to be 1.0.9 (from 7 (!) years ago). I > discovered that release does include the Dart.pdf file which is good, > but only includes jar files and not source code which is bad. For > example, I am concerned those 7-year old *.class files in the jar > files might not run properly with modern java. > > Therefore, I would like to build those jar files from source. According > to the above wiki you can get access to the source code using > > svn co http://svn.na-mic.org/svn/Dart/trunk > > but that command immediately returns > svn: OPTIONS of 'http://svn.na-mic.org/svn/Dart/trunk': 200 OK > > In contrast, Dart.pdf states that source code is available using > > svn checkout http://svn.na-mic.org:8000/svn/Dart > > However, that command times out with "cannot connect to server". > > Does anyone here know how to access the Dart source or is that gone > forever? > > 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 > __________________________ > -- > > 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 irwin at beluga.phys.uvic.ca Tue Oct 7 21:23:06 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 7 Oct 2014 18:23:06 -0700 (PDT) Subject: [cmake-developers] Any ideas for accessing the Dart source code? In-Reply-To: References: Message-ID: On 2014-10-07 19:06-0400 David Cole wrote: > Consider using CDash instead. It was Dart's "drop-in" replacement... > and is actively maintained today. > > www.cdash.org Thanks, Dave, for that information. In reviewing why I wasted my time looking at the moribund dart rather than cdash, dart clients are mentioned several times in the ctest-2.8.12.2 documentation (and I missed the one reference to cdash that also occurs there) so I did a google search, found and went galloping off in the wrong direction. :-( I have now looked at the documentation for ctest-3.0.2, and cdash is mentioned a lot more but then so is dart. I think that documentation should be updated to point users exclusively at cdash (possibly with a reference to the dart protocol or dart standard but definitely not the dart software which really is moribund or dart servers unless you are referring to the protocol and not the software). Furthermore, to prevent others being misled like I was by , could someone with write access to that web server either drop that page or modify that page so that it at least mentions that dart is no longer maintained and cdash is the suggested alternative? Currently http://www.cdash.org/overview/ does not mention dart at all which is probably the best approach and what the ctest documentation should do as well. 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 jackyalcine at gmail.com Tue Oct 7 21:24:32 2014 From: jackyalcine at gmail.com (=?UTF-8?Q?Jacky_Alcin=C3=A9?=) Date: Tue, 7 Oct 2014 21:24:32 -0400 Subject: [cmake-developers] Any ideas for accessing the Dart source code? In-Reply-To: References: Message-ID: On Tue, Oct 7, 2014 at 9:23 PM, Alan W. Irwin wrote: > On 2014-10-07 19:06-0400 David Cole wrote: > >> Consider using CDash instead. It was Dart's "drop-in" replacement... >> and is actively maintained today. >> >> www.cdash.org > > > Thanks, Dave, for that information. > > In reviewing why I wasted my time looking at the moribund dart rather > than cdash, dart clients are mentioned several times in the > ctest-2.8.12.2 documentation (and I missed the one reference to cdash > that also occurs there) so I did a google search, found > and went galloping off > in the wrong direction. :-( > > I have now looked at the documentation for ctest-3.0.2, and cdash is > mentioned a lot more but then so is dart. I think that documentation > should be updated to point users exclusively at cdash (possibly with a > reference to the dart protocol or dart standard but definitely not the > dart software which really is moribund or dart servers unless you are > referring to the protocol and not the software). > > Furthermore, to prevent others being misled like I was by > , could someone with > write access to that web server either drop that page or modify that > page so that it at least mentions that dart is no longer maintained > and cdash is the suggested alternative? > > Currently http://www.cdash.org/overview/ does not mention dart at all > which is probably the best approach and what the ctest documentation > should do as well. > > > 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 > __________________________ > -- > > 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 We should probably wipe those references or just update that for 3.0 -- Jacky Alcin? - http://jalcine.me From bill.hoffman at kitware.com Tue Oct 7 21:49:32 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 07 Oct 2014 21:49:32 -0400 Subject: [cmake-developers] "Contract" testing of CMake In-Reply-To: References: Message-ID: <5434982C.3000307@kitware.com> On 10/7/2014 4:59 PM, Alan W. Irwin wrote: > Of course, once I got such a contract test to work by hand, I would > probably want to move to a formal automated procedure so your advice > on that would be appreciated as well. The idea is to test next CMake against a version of the "contract" project that is known to work with the current release of CMake. We don't want development of the "contract" project to cause the test to fail. So, use a fixed version of PLplot and build it with next CMake. By using next CMake bugs will be noticed as soon as they are introduced. -Bill From nilsgladitz at gmail.com Wed Oct 8 01:00:47 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 08 Oct 2014 07:00:47 +0200 Subject: [cmake-developers] Any ideas for accessing the Dart source code? In-Reply-To: References: Message-ID: <5434C4FF.1000106@gmail.com> On 10/08/2014 12:46 AM, Alan W. Irwin wrote: > I thought it would be interesting to install my own local dart server > to learn how to use CTest as a dart client. You probably want the newer Kitware maintained replacement "CDash": http://www.cdash.org/ Additional instructions for a local installation can be found here: http://public.kitware.com/Wiki/CDash:Installation CMake's own CDash Dashboard can be seen in action here: http://open.cdash.org/index.php?project=CMake Nils From amine.khaldi at reactos.org Wed Oct 8 03:45:16 2014 From: amine.khaldi at reactos.org (Amine Khaldi) Date: Wed, 08 Oct 2014 08:45:16 +0100 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <543445D8.1000806@kitware.com> References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> <543445D8.1000806@kitware.com> Message-ID: <5434EB8C.109@reactos.org> > This will not be done before the freeze for 3.1 on Thursday. > Reverting 7243c951 will resolve the problem for ReactOS in > out-of-source builds. So, we either revert that or hope Ninja can > be fixed to deal with the large dependency lists w/out crashing. In the discussion with Adam, he mentioned (about input files) that CMake can not know that some file will always exist or not, and that it doesn't know files is generated unless someone tells that, *unfortunately some projects don't* Reverting this change makes more sense, because CMake has always been advertised as being designed for out-of-source builds, and we cannot penalize every single sane CMake user out there simply because some projects do not properly mark their generated input files (in custom commands) as GENERATED. I don't understand why is it okay for the CMake project (at least in ReactOS case) to introduce now a (very) huge list of our codebase *source files* (files that exist in our *repo* and not *generated* nor we can even *assume* they may not exist at some point, because they will *always* exist) simply to solve a problem that is, if some projects do *not* properly use CMake (GENERATED property, adding dependencies properly on commands/target that generate the said input files...etc) we need to do this to keep them working. The extra bloat of generating a very large list of phony rules on *source* files to solve a CMake misuse problem suggests that we're Doing It Wrong. If ninja didn't crash on us, we would probably never find out about this bloat, unless some of us randomly had the idea of diffing the old build log (from CMake 2.8.x) with this new one. From ruslan_baratov at yahoo.com Wed Oct 8 07:52:27 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 08 Oct 2014 15:52:27 +0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5433DBC1.5080800@kitware.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> Message-ID: <5435257B.80201@yahoo.com> On 07-Oct-14 16:25, Brad King wrote: > On 10/07/2014 02:49 AM, Ruslan Baratov wrote: >> How it will looks like in terms of CMake code? > That's what I'm asking you to think through and propose ;) > > Thanks, > -Brad > Okay :) I just not sure that I understand "to pass to some other process" goal correctly. * we just need to `unlock` file so the other instance will use it: file(UNLOCK_FILE "/path/to/shared/file") # now anybody can do the lock * we need other process to "inherit" the lock (what for?), i.e. move ownership (?): file(LOCK_FILE "/path/to/shared/file") execute_process(${CMAKE_COMMAND} --take-ownership "/path/to/shared/file" ...) # unlocked by execute_process Ruslo From brad.king at kitware.com Wed Oct 8 08:45:00 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 08:45:00 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5435257B.80201@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> Message-ID: <543531CC.7090103@kitware.com> On 10/08/2014 07:52 AM, Ruslan Baratov wrote: > Okay :) I just not sure that I understand "to pass to some other > process" goal correctly. That was just an example of why one might want to drop management of the lock by CMake without actually unlocking it. Perhaps the code is starting a daemon and passes off responsibility for the unlock side to the daemon process. > * we just need to `unlock` file so the other instance will use it: > file(UNLOCK_FILE "/path/to/shared/file") > # now anybody can do the lock Yes. We also need the locking API to return information about whether we really acquired the lock. > * we need other process to "inherit" the lock (what for?), i.e. move > ownership (?): > file(LOCK_FILE "/path/to/shared/file") > execute_process(${CMAKE_COMMAND} --take-ownership "/path/to/shared/file" > ...) > # unlocked by execute_process I think all we need there is a way to ask CMake to take over responsibility for a lock that it did not originally create. It can also be in the file() command. Thanks, -Brad From brad.king at kitware.com Wed Oct 8 09:16:03 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 09:16:03 -0400 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <067CB9F0-D22A-4595-BD45-23A70F162C20@java.pl> References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> <543445D8.1000806@kitware.com> <067CB9F0-D22A-4595-BD45-23A70F162C20@java.pl> Message-ID: <54353913.6010606@kitware.com> On 10/07/2014 04:53 PM, Adam Strzelecki wrote: > In meantime I've pushed stage/cmp0055-disable-ninja-side-effects > that make CMake warn about this compatibility layer when such > phony rules are about to be emitted. What I've been trying to say is that this is NOT about compatibility with broken projects. It is a *fundamental limitation* of the current CMake custom command specification interface (add_custom_command). If you start requiring explicit specification of side-effects as custom command outputs, you will make it *impossible* for project code to specify their build rules for cases involving side-effect outputs whose timestamps do not need to be newer than their inputs. Non-Ninja build systems do *not* support this. This issue: Add explicit specification of custom command side effect outputs http://www.cmake.org/Bug/view.php?id=14963 documents a few such cases. It explains that we need a new interface, perhaps as an option to add_custom_command, to specify side-effect outputs of rules. Another possible middle-ground workaround is to generate phony rules only for custom command dependencies that are marked with the GENERATED property. That would avoid the phony rule bloat and simply require projects to explicitly mark their generated side effects. We still won't be able to tell Ninja which rule generates them, but at least we could reduce the number of phony rules. However, there is no way this will be done for 3.1 by tomorrow, so it would be best to think about a full solution to #14963 to start development now and target the 3.2 release. -Brad From brad.king at kitware.com Wed Oct 8 09:16:05 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 09:16:05 -0400 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <5434EB8C.109@reactos.org> References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> <543445D8.1000806@kitware.com> <5434EB8C.109@reactos.org> Message-ID: <54353915.3010200@kitware.com> On 10/08/2014 03:45 AM, Amine Khaldi wrote: > Reverting this change makes more sense This is the simplest solution for the upcoming 3.1 release because it just restores behavior to what 3.0 does. I've done it here: Ninja: Limit custom command side-effects to build folder http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=de8e534b > simply to solve a problem that is, if some projects do *not* > properly use CMake (GENERATED property, adding dependencies > properly on commands/target that generate the said input > files...etc) we need to do this to keep them working. This is not about supporting projects that do it wrong. Ninja wants to know not just that a file is generated, but also *which* custom command generates it. We have no interface for specifying side-effect outputs whose timestamps do not need to be newer than the inputs. That is what this issue is about: Add explicit specification of custom command side effect outputs http://www.cmake.org/Bug/view.php?id=14963 The reason is that CMake was designed long before Ninja existed, and all the other build systems not only do not need this information, but have no place to put it even if we did have it. See also my reply to Adam's sibling message to yours. -Brad From ono at java.pl Wed Oct 8 09:55:16 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 8 Oct 2014 15:55:16 +0200 Subject: [cmake-developers] Severe regression caused by #14972 fixes In-Reply-To: <54353915.3010200@kitware.com> References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> <543445D8.1000806@kitware.com> <5434EB8C.109@reactos.org> <54353915.3010200@kitware.com> Message-ID: <1032790C-7E57-471E-B81C-64C14AEBD69B@java.pl> > This is the simplest solution for the upcoming 3.1 release because > it just restores behavior to what 3.0 does. I've done it here: Okay. But still I feel like this is just workaround rather than solution for the problem. > This is not about supporting projects that do it wrong. Ninja > wants to know not just that a file is generated, but also *which* > custom command generates it. We have no interface for specifying > side-effect outputs whose timestamps do not need to be newer than > the inputs. Yes, it isn't about doing anything wrong, but to make projects building fine with Make build fine with Ninja too. And you are right here, we have no means for provide proper transition to remove this implicit compatibility layer. We lack OUTPUT for add_custom_target. I can work on OUTPUT support for add_custom_target if you want? Together with new POLICY it will make sense, unless you have other opinion on that. But I guess it won't make it to 3.1? > That is what this issue is about: > Add explicit specification of custom command side effect outputs > http://www.cmake.org/Bug/view.php?id=14963 Shouldn't it be called "Add explicit specification of custom TARGET side effect outputs"? --Adam From brad.king at kitware.com Wed Oct 8 10:05:04 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 10:05:04 -0400 Subject: [cmake-developers] Any ideas for accessing the Dart source code? In-Reply-To: References: Message-ID: <54354490.9080805@kitware.com> On 10/07/2014 09:23 PM, Alan W. Irwin wrote: > I have now looked at the documentation for ctest-3.0.2, and cdash is > mentioned a lot more but then so is dart. I think that documentation > should be updated to point users exclusively at cdash Help: Replace 'Dart' with 'CDash' in ctest.1 manual http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b8aa0cdf > Furthermore, to prevent others being misled like I was by > , could someone with > write access to that web server either drop that page or modify that > page so that it at least mentions that dart is no longer maintained > and cdash is the suggested alternative? I will look at that, thanks. -Brad From brad.king at kitware.com Wed Oct 8 10:26:44 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 10:26:44 -0400 Subject: [cmake-developers] explicit custom command side-effects (was: Severe regression caused by #14972 fixes) In-Reply-To: <1032790C-7E57-471E-B81C-64C14AEBD69B@java.pl> References: <5433949A.6060707@reactos.org> <543400EE.5090803@gmail.com> <543445D8.1000806@kitware.com> <5434EB8C.109@reactos.org> <54353915.3010200@kitware.com> <1032790C-7E57-471E-B81C-64C14AEBD69B@java.pl> Message-ID: <543549A4.8070508@kitware.com> On 10/08/2014 09:55 AM, Adam Strzelecki wrote: > We lack OUTPUT for add_custom_target. > > I can work on OUTPUT support for add_custom_target if you want? This is not just about add_custom_target, and it is not about OUTPUT. Custom targets have no explicit output by design, but they can have DEPENDS on custom commands that have outputs. Both add_custom_target and add_custom_command can run operations that produce side-effects. Both commands need a way to specify any side effects they produce. Perhaps a new option like "GENERATES" can be added for this. For example: add_custom_target(Provider COMMAND some-generator -o side-effect GENERATES side-effect ) or: add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/generator-stamp.txt COMMAND some-generator -o side-effect COMMAND ${CMAKE_COMMAND} -E touch generator-stamp.txt DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/generator-input.txt GENERATES side-effect ) The GENERATES value(s) would be marked with the GENERATED property. For Ninja we would add extra outputs to the generated rule and ask Ninja to restat them to avoid the always-rebuild case. For other generators no additional build system content is needed. > Together with new POLICY it will make sense, unless you have other > opinion on that. We need some kind of transition plan that may or may not be a policy. Let's get the design of the new interface done first. > But I guess it won't make it to 3.1? Absolutely not for 3.1. The feature freeze for it is upon us NOW and we haven't even started the design for the new behavior yet. We have plenty of time before 3.2 though to get it right. -Brad From brad.king at kitware.com Wed Oct 8 10:54:12 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 10:54:12 -0400 Subject: [cmake-developers] FindThreads_overhaul topic In-Reply-To: <1560898.ZRjqAlt5LQ@caliban.sf-tec.de> References: <5433FA2C.9070809@kitware.com> <1560898.ZRjqAlt5LQ@caliban.sf-tec.de> Message-ID: <54355014.3000501@kitware.com> On 10/07/2014 12:18 PM, Rolf Eike Beer wrote: >>> + add_library(CMake::Threads INTERFACE IMPORTED GLOBAL) >> > Both issues should be fixed now. Thanks. Your use of an interface target for this is a clever way of abstracting the differences between libraries and flags. Nice. I'd rather reserve the CMake:: imported target namespace for future use. The convention in other Find modules is to prefix the imported targets with the name of the package. In this case we have no good name for the library within the namespace. Here is a brainstorming list of possible names: Threads::Threads Threads::Interface # my favorite Threads::Native Threads::System Please pick one of these or propose your own and update the topic. Thanks, -Brad From clinton at elemtech.com Wed Oct 8 11:05:03 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Wed, 8 Oct 2014 09:05:03 -0600 (MDT) Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> References: <542ACE37.1040302@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> <5432AE91.1010708@kitware.com> <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> Message-ID: <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> ----- Original Message ----- > > ----- Original Message ----- > > On 10/06/2014 10:36 AM, Adam Strzelecki wrote: > > >> Sure, I think it would be good to require 10.6. > > > > > > Moreover I believe nobody nowadays builds for 10.5 on 10.5. > > > > Perhaps no one has to build that way for deployment but there could > > still be people just building for their own host as the only computer > > they have. The fact that our dashboard reported this problem means > > we are testing that case. > > > > Clinton, I don't have a 10.5 machine anymore and the test is failing > > on yours. Please take whatever action you feel is appropriate to > > resolve the test failure on that machine. This could mean either > > disabling rpath altogether on 10.5 or changing the new hunk: > > > > > + foreach(rpath ${${ikey}_RPATHS}) > > > + set(changes ${changes} -delete_rpath "${rpath}") > > > + endforeach() > > > > to warn and skip removal when hosted on 10.5. Or another option you > > find. > > > > This needs to be resolved in the next day or two or the topic won't > > be in CMake 3.1. > > > > Thanks, > > -Brad > > > > > > I don't have a 10.5 machine, but I've put in a commit which I hope solves the > problem. > 36c509b9 OSX: Only enable @rpath support on OS X 10.6 or greater. > I pushed more fixes for this. Instead of requiring 10.6, I took the other path of warning when rpaths need changed at install time and skip it. This should also fix the CMP0042 test which started failing. By the way, Brad, your change to require 10.6 for the BundleUtilities test is no longer required on the rpath-osx-10_6 topic. However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5 topic. Clint From brad.king at kitware.com Wed Oct 8 11:17:03 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 11:17:03 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> References: <542ACE37.1040302@kitware.com> <849F7784-73C0-47A3-8CA8-1B10C5665CC1@java.pl> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> <5432AE91.1010708@kitware.com> <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> Message-ID: <5435556F.9070303@kitware.com> On 10/08/2014 11:05 AM, clinton at elemtech.com wrote: > I pushed more fixes for this. Instead of requiring 10.6, > I took the other path of warning when rpaths need changed > at install time and skip it. > This should also fix the CMP0042 test which started failing. Thanks. The message is currently: > + msg << "WARNING: Target \"" << this->Target->GetName() > + << "\" has runtime paths which cannot be changed during install. " > + << "To change runtime paths, OS X version 10.6 or newer is required. " > + << "Therefore, runtime paths will not be changed when installing."; > + cmSystemTools::Message(msg.str().c_str(), "Warning"); Can that be changed to an IssueMessage, possibly on a cmMakefile for at least a little context? Also it should suggest using CMAKE_BUILD_WITH_INSTALL_RPATH. > By the way, Brad, your change to require 10.6 for the > BundleUtilities test is no longer required on the rpath-osx-10_6 topic. > I thought it was a missing piece of your original change. Since you've reverted that I've now reverted mine so we'll see how testing goes. > However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5 topic. I rebased rpath-osx-10_6 on fix-OSX-bundle-rpaths-and-Qt5 to make local testing of both together easier. Please base the above-requested fixes on: OSX: Warn when attempting to change runtime paths on OS X 10.5 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6e58f55 Thanks, -Brad From eike at sf-mail.de Wed Oct 8 11:37:40 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 08 Oct 2014 17:37:40 +0200 Subject: [cmake-developers] FindThreads_overhaul topic In-Reply-To: <54355014.3000501@kitware.com> References: <5433FA2C.9070809@kitware.com> <1560898.ZRjqAlt5LQ@caliban.sf-tec.de> <54355014.3000501@kitware.com> Message-ID: <3327542.MMlHKRjttH@caliban.sf-tec.de> Am Mittwoch, 8. Oktober 2014, 10:54:12 schrieb Brad King: > On 10/07/2014 12:18 PM, Rolf Eike Beer wrote: > >>> + add_library(CMake::Threads INTERFACE IMPORTED GLOBAL) > > > > Both issues should be fixed now. > > Thanks. Your use of an interface target for this is a clever way > of abstracting the differences between libraries and flags. Nice. All credits go to Timo Rothenpieler, I just refactored his changes and pushed this upstream. > I'd rather reserve the CMake:: imported target namespace for future > use. The convention in other Find modules is to prefix the imported > targets with the name of the package. In this case we have no good > name for the library within the namespace. Here is a brainstorming > list of possible names: > > Threads::Threads > Threads::Interface # my favorite > Threads::Native > Threads::System > > Please pick one of these or propose your own and update the topic. I'm not sure about Threads::Interface, it sounds so "generic" or "abstract" to me, but this target offers no abstraction of the thread API. All others have different up- and downsides, so I think I'll stay with Threads::Threads, that is the one that probably results in the least blame for a badly chosen name. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Wed Oct 8 11:44:28 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 11:44:28 -0400 Subject: [cmake-developers] FindThreads_overhaul topic In-Reply-To: <3327542.MMlHKRjttH@caliban.sf-tec.de> References: <5433FA2C.9070809@kitware.com> <1560898.ZRjqAlt5LQ@caliban.sf-tec.de> <54355014.3000501@kitware.com> <3327542.MMlHKRjttH@caliban.sf-tec.de> Message-ID: <54355BDC.3050705@kitware.com> On 10/08/2014 11:37 AM, Rolf Eike Beer wrote: > All credits go to Timo Rothenpieler Okay. Please add a "Co-Author: " or "Inspired-by: " footer line to give this credit. > I'm not sure about Threads::Interface, it sounds so "generic" or "abstract" to > me, but this target offers no abstraction of the thread API. All others have > different up- and downsides, so I think I'll stay with Threads::Threads, that > is the one that probably results in the least blame for a badly chosen name. On second thought I agree Threads::Interface is too generic. It exposes an implementation detail in the name. I agree Threads::Threads is the best or now. I suspect other packages will encounter a similar double-name later. Thanks, -Brad From eike at sf-mail.de Wed Oct 8 11:48:13 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 08 Oct 2014 17:48:13 +0200 Subject: [cmake-developers] FindThreads_overhaul topic In-Reply-To: <54355BDC.3050705@kitware.com> References: <5433FA2C.9070809@kitware.com> <3327542.MMlHKRjttH@caliban.sf-tec.de> <54355BDC.3050705@kitware.com> Message-ID: <1443494.yLndqPJEr5@caliban.sf-tec.de> Am Mittwoch, 8. Oktober 2014, 11:44:28 schrieb Brad King: > On 10/08/2014 11:37 AM, Rolf Eike Beer wrote: > > All credits go to Timo Rothenpieler > > Okay. Please add a "Co-Author: " or "Inspired-by: " footer line to give > this credit. He is recorded as author of that change. Only the first and last of the 3 commits in that branch are authored by me, and recorded that way. > > I'm not sure about Threads::Interface, it sounds so "generic" or > > "abstract" to me, but this target offers no abstraction of the thread > > API. All others have different up- and downsides, so I think I'll stay > > with Threads::Threads, that is the one that probably results in the least > > blame for a badly chosen name. > On second thought I agree Threads::Interface is too generic. It exposes > an implementation detail in the name. I agree Threads::Threads is the > best or now. I suspect other packages will encounter a similar double-name > later. Will push an update soonish. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From clinton at elemtech.com Wed Oct 8 12:17:57 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Wed, 08 Oct 2014 10:17:57 -0600 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <5435556F.9070303@kitware.com> References: <542ACE37.1040302@kitware.com> <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> <5435556F.9070303@kitware.com> Message-ID: <6523826.ocfdZJFGtQ@stryke> On Wednesday, October 08, 2014 11:17:03 AM Brad King wrote: > On 10/08/2014 11:05 AM, clinton at elemtech.com wrote: > > I pushed more fixes for this. Instead of requiring 10.6, > > I took the other path of warning when rpaths need changed > > at install time and skip it. > > This should also fix the CMP0042 test which started failing. > > Thanks. The message is currently: > > + msg << "WARNING: Target \"" << this->Target->GetName() > > + << "\" has runtime paths which cannot be changed during install. > > " + << "To change runtime paths, OS X version 10.6 or newer is > > required. " + << "Therefore, runtime paths will not be changed > > when installing."; + cmSystemTools::Message(msg.str().c_str(), > > "Warning"); > > Can that be changed to an IssueMessage, possibly on a cmMakefile > for at least a little context? Also it should suggest using > CMAKE_BUILD_WITH_INSTALL_RPATH. Fixed. > > > By the way, Brad, your change to require 10.6 for the > > BundleUtilities test is no longer required on the rpath-osx-10_6 topic. > > I thought it was a missing piece of your original change. > Since you've reverted that I've now reverted mine so we'll > see how testing goes. Yeah. I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle- rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with @rpath on OS X 10.5. Perhaps it'll recognize there is no need to change rpaths. Clint From irwin at beluga.phys.uvic.ca Wed Oct 8 13:34:17 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 8 Oct 2014 10:34:17 -0700 (PDT) Subject: [cmake-developers] Any ideas for accessing the Dart source code? In-Reply-To: <54354490.9080805@kitware.com> References: <54354490.9080805@kitware.com> Message-ID: On 2014-10-08 10:05-0400 Brad King wrote: > On 10/07/2014 09:23 PM, Alan W. Irwin wrote: >> I have now looked at the documentation for ctest-3.0.2, and cdash is >> mentioned a lot more but then so is dart. I think that documentation >> should be updated to point users exclusively at cdash > > Help: Replace 'Dart' with 'CDash' in ctest.1 manual > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b8aa0cdf Thanks. That is a step in the right direction, but there are more mentions of dart then you have dealt with so far. See the results from ctest --help-full (at least for version 3.0.2). > >> Furthermore, to prevent others being misled like I was by >> , could someone with >> write access to that web server either drop that page or modify that >> page so that it at least mentions that dart is no longer maintained >> and cdash is the suggested alternative? > > I will look at that, thanks. > > -Brad > __________________________ 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 Oct 8 13:43:53 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Oct 2014 13:43:53 -0400 Subject: [cmake-developers] Any ideas for accessing the Dart source code? In-Reply-To: References: <54354490.9080805@kitware.com> Message-ID: <543577D9.6020300@kitware.com> On 10/08/2014 01:34 PM, Alan W. Irwin wrote: > Thanks. That is a step in the right direction, but there are more mentions of > dart then you have dealt with so far. See the results from > > ctest --help-full > > (at least for version 3.0.2). According to: $ git grep -i dart -- Help Modules the remaining mentions of "Dart" are in: * The FindDart module which we have to keep for compatibility. It is only linked from the list of available modules. * The Dart module which we have to keep for compatibility, and whose documentation says so and refers to the CTest module. * Discussion of the DartConfiguration.tcl configuration file, which is actually for configuring CTest (it's historical). There is no text left that suggests using "Dart" for anything in the ctest(1) manual. -Brad From ydginster at gmail.com Wed Oct 8 13:48:29 2014 From: ydginster at gmail.com (Evgeny Kalishenko) Date: Wed, 8 Oct 2014 21:48:29 +0400 Subject: [cmake-developers] [PATCH] Preinstall requirements support for CPack RPM generator Message-ID: I was interested in feature request http://public.kitware.com/Bug/view.php?id=14769 and made a simple patch for CPack RPM generator (attached). -- Regards, Evgeny Kalishenko -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pre_post_rpm_install.patch Type: text/x-patch Size: 3047 bytes Desc: not available URL: From paul at mad-scientist.net Wed Oct 8 14:36:01 2014 From: paul at mad-scientist.net (Paul Smith) Date: Wed, 08 Oct 2014 14:36:01 -0400 Subject: [cmake-developers] [CMake] Forcing colorization of output from cmake In-Reply-To: <54356C78.7060501@kitware.com> References: <1367417913.4101.127.camel@pdsdesk> <1412784946.29340.123.camel@mad-scientist.net> <54356C78.7060501@kitware.com> Message-ID: <1412793361.29340.127.camel@mad-scientist.net> On Wed, 2014-10-08 at 12:55 -0400, Brad King wrote: > On 10/08/2014 12:15 PM, Paul Smith wrote: > > Maybe we could add another valid value to --switch, like --switch=FORCE > > which would always colorize. > [snip] > > The best option seems to be to add another flag to the "color" bitflag > > variable that forces colorization always. > > Yes, I think both of the above make sense. If you want to work on > it please read CONTRIBUTING.rst from the top of our source tree > in Git ( http://cmake.org/cmake.git ) and come to the developers > list with a proposal: Hi all. Attached please find a proposed patch for the above. I still think there's some slightly awkward redundancy between AssumeTTY and the new ForceTTY, but I'm not sure these can actually be combined into one flag... certainly not without reworking more of how AssumeTTY is interpreted and used than I felt confident with. I didn't try to allow "FORCE" to be case-insensitive. It wouldn't be hard, but I wasn't sure if it was worth it. You must capitalize it as the code is written today. I found precedent for both options. Also, the check for MAKE_TERMOUT might not be something you want to keep... there's not a lot of precedent in the code, that I found, for looking at other utilities' environment variables. On the other hand it's darn handy to have this "just work" without having to export COLOR='$(if $(MAKE_TERMOUT),FORCE)' in your ~/.bashrc or whatever. There's no "GNU Makefiles" generator, and I couldn't come up with a good way to implement this in the generic Unix Makefiles generator. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-cmake-Allow-forced-color-output.patch Type: text/x-patch Size: 7424 bytes Desc: not available URL: From robert.maynard at kitware.com Wed Oct 8 14:50:03 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 8 Oct 2014 14:50:03 -0400 Subject: [cmake-developers] FindThreads_overhaul topic In-Reply-To: <1443494.yLndqPJEr5@caliban.sf-tec.de> References: <5433FA2C.9070809@kitware.com> <3327542.MMlHKRjttH@caliban.sf-tec.de> <54355BDC.3050705@kitware.com> <1443494.yLndqPJEr5@caliban.sf-tec.de> Message-ID: As an aside have we formally documented that we are reserving the CMake namespace on imported targets anywhere? On Wed, Oct 8, 2014 at 11:48 AM, Rolf Eike Beer wrote: > Am Mittwoch, 8. Oktober 2014, 11:44:28 schrieb Brad King: >> On 10/08/2014 11:37 AM, Rolf Eike Beer wrote: >> > All credits go to Timo Rothenpieler >> >> Okay. Please add a "Co-Author: " or "Inspired-by: " footer line to give >> this credit. > > He is recorded as author of that change. Only the first and last of the 3 > commits in that branch are authored by me, and recorded that way. > >> > I'm not sure about Threads::Interface, it sounds so "generic" or >> > "abstract" to me, but this target offers no abstraction of the thread >> > API. All others have different up- and downsides, so I think I'll stay >> > with Threads::Threads, that is the one that probably results in the least >> > blame for a badly chosen name. >> On second thought I agree Threads::Interface is too generic. It exposes >> an implementation detail in the name. I agree Threads::Threads is the >> best or now. I suspect other packages will encounter a similar double-name >> later. > > Will push an update soonish. > -- > > 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 konstantin at podsvirov.pro Thu Oct 9 01:55:14 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 09 Oct 2014 09:55:14 +0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <5433FC0B.4060802@kitware.com> References: <542E964C.1050104@kitware.com> <5433FC0B.4060802@kitware.com> Message-ID: <1545841412834114@web8j.yandex.ru> Hello people! 07.10.2014, 18:43, "Brad King" : > In order to get the dashboard cleaned up for final merges to > 'master' before the release, please refrain from merging any > changes other than dashboard fixes and documentation updates > to 'next'. > > Thanks, > -Brad CMake 3.0.20141008-ge5734 Documentation with the latest updates: Sphinx http://ifw.podsvirov.pro/cmake/doc/sphinx Doxygen http://ifw.podsvirov.pro/cmake/doc/doxygen Can also upgrade the components in your online installers :-) All a good day! Regards, Konstantin Podsvirov From mantis at public.kitware.com Thu Oct 9 05:11:10 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 9 Oct 2014 05:11:10 -0400 Subject: [cmake-developers] [CMake 0015199]: Better error message for export conflicts Message-ID: <705497265c31cce384ae0b2e8cfc60e0@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15199 ====================================================================== Reported By: Nico Schl?mer Assigned To: ====================================================================== Project: CMake Issue ID: 15199 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-09 05:11 EDT Last Modified: 2014-10-09 05:11 EDT ====================================================================== Summary: Better error message for export conflicts Description: If an export target depends on another target, that other target must either be * in the same export set, or * in exactly one other export set. If it is not in the same export set and in more than one other export set, CMake reports ``` CMake Error: install(EXPORT "A" ...) includes target "b" which requires target "c" that is not in this export set, but 5 times in others. ``` This error message is somewhat misleading; one could think that "c" must be in the same export set as "b". Perhaps a less ambiguous wording would be: ``` CMake Error: install(EXPORT "A" ...) includes target "b" which requires target "c" that is * not in this export set, and * in more than one other export set (5). ``` I'm sure we can do even better than that. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-09 05:11 Nico Schl?mer New Issue ====================================================================== From mantis at public.kitware.com Thu Oct 9 08:24:58 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 9 Oct 2014 08:24:58 -0400 Subject: [cmake-developers] [CMake 0015200]: Odd quoting issue when mixing single, double and escaped quotes to COMMAND Message-ID: <502dede04c486d1bc548657f61f36be2@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15200 ====================================================================== Reported By: Ray Donnelly Assigned To: ====================================================================== Project: CMake Issue ID: 15200 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-09 08:24 EDT Last Modified: 2014-10-09 08:24 EDT ====================================================================== Summary: Odd quoting issue when mixing single, double and escaped quotes to COMMAND Description: Using the following CMakeList.txt: add_executable (blender blender.c) set(TARGETDIR_VER "C:/Program Files (x86)/Blender/share/blender/2.72") add_custom_command( TARGET blender POST_BUILD MAIN_DEPENDENCY blender COMMAND ${CMAKE_COMMAND} -E echo 'now run: \"make install\" to copy runtime files and scripts to ${TARGETDIR_VER}' ) Using any old blender.c (hello world will do) And either "MSYS Makefiles" or "MinGW Makefiles" generators (actually I suspect any Makefile generator at all), we get badly quoted strings in CMakeFiles/blender.dir/build.make: /C/cmake-3.0.2-win32-x86/bin/cmake.exe -E echo 'now run: "make install" to copy runtime files and scripts to "C:/Program Files (x86)/Blender/share/blender/2.72'" It seems that the final ' and " have been swapped, which causes: /bin/sh: -c: line 0: unexpected EOF while looking for matching `"' Steps to Reproduce: unzip quote-problem.7z, and from the MSYS2 shell enter: /c/cmake-3.0.2-win32-x86/bin/cmake.exe -G'MSYS Makefiles' make and observe the error message above. Additional Information: This happens on the officially release 3.0.2 Windows binary and also on MSYS2's cmake. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-09 08:24 Ray Donnelly New Issue 2014-10-09 08:24 Ray Donnelly File Added: quote-problem.7z ====================================================================== From brad.king at kitware.com Thu Oct 9 09:24:10 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Oct 2014 09:24:10 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <6523826.ocfdZJFGtQ@stryke> References: <542ACE37.1040302@kitware.com> <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> <5435556F.9070303@kitware.com> <6523826.ocfdZJFGtQ@stryke> Message-ID: <54368C7A.8060007@kitware.com> Adam, On 10/08/2014 12:17 PM, Clinton Stimpson wrote: > Yeah. I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle- > rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with > @rpath on OS X 10.5. Perhaps it'll recognize there is no need to change > rpaths. The BundleUtilities test still fails on OS X 10.5: http://open.cdash.org/testDetails.php?test=285651145&build=3522021 -- 6/10: fixing up '/.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1' install_name_tool: more than one input file specified (/.../Tests/BundleUtilities/testdir1 and -delete_rpath) Usage: install_name_tool [-change old new] ... [-id name] input Clinton's changes in his rpath-osx-10_6 extension topic to yours teach other uses of -delete_rpath to warn on OS X 10.5 and skip deletion. I think something similar will be needed here. Please investigate. Meanwhile, on my local OS X 10.9 machine I added this patch: diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index eedab44..80e5d3b 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -755,6 +755,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) # if(changes) execute_process(COMMAND install_name_tool ${changes} "${resolved_embedded_item}") + message(STATUS "CHANGE install_name_tool ${changes} \"${resolved_embedded_item}\"") endif() endfunction() >From the test output I can see that it is trying to delete several rpath entries that do not exist and therefore do not need deletion. How is the list chosen for each binary? -Brad From clinton at elemtech.com Thu Oct 9 09:43:08 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Thu, 9 Oct 2014 07:43:08 -0600 (MDT) Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <5435556F.9070303@kitware.com> References: <542ACE37.1040302@kitware.com> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> <5432AE91.1010708@kitware.com> <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> <5435556F.9070303@kitware.com> Message-ID: <888522664.277920.1412862188537.JavaMail.zimbra@elemtech.com> ----- Original Message ----- > On 10/08/2014 11:05 AM, clinton at elemtech.com wrote: > > I pushed more fixes for this. Instead of requiring 10.6, > > I took the other path of warning when rpaths need changed > > at install time and skip it. > > This should also fix the CMP0042 test which started failing. > > Thanks. The message is currently: > > > + msg << "WARNING: Target \"" << this->Target->GetName() > > + << "\" has runtime paths which cannot be changed during install. > > " > > + << "To change runtime paths, OS X version 10.6 or newer is > > required. " > > + << "Therefore, runtime paths will not be changed when > > installing."; > > + cmSystemTools::Message(msg.str().c_str(), "Warning"); > > Can that be changed to an IssueMessage, possibly on a cmMakefile > for at least a little context? Also it should suggest using > CMAKE_BUILD_WITH_INSTALL_RPATH. > > > By the way, Brad, your change to require 10.6 for the > > BundleUtilities test is no longer required on the rpath-osx-10_6 topic. > > > > I thought it was a missing piece of your original change. > Since you've reverted that I've now reverted mine so we'll > see how testing goes. > > > However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5 > > topic. > > I rebased rpath-osx-10_6 on fix-OSX-bundle-rpaths-and-Qt5 to > make local testing of both together easier. Please base the > above-requested fixes on: > > OSX: Warn when attempting to change runtime paths on OS X 10.5 > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6e58f55 > Adam, I was looking at the BundleUtilities failure after the above fixes, and I noticed it unconditionally removes rpaths. Is there a reason for that? If the user does set_target_properties(testbundleutils1 module1 PROPERTIES INSTALL_RPATH "${CMAKE_CURRENT_BINARY_DIR}/testdir1" BUILD_WITH_INSTALL_RPATH 1) The new BundleUtilities.cmake will strip that rpath. The attempt to strip those rpaths fails on OS X 10.5, because install_name_tool does not recognize the -delete_rpath. The test fails because the -id and -change portion of the install_name_tool command is prevented by the error from the use of -delete_rpath. Perhaps we can separate the -delete_rpath part into its own call to install_name_tool. If it fails, the failure can be ignored (as it previously ignored install_name_tool failures). Or maybe there is another idea. Clint From brad.king at kitware.com Thu Oct 9 09:55:46 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Oct 2014 09:55:46 -0400 Subject: [cmake-developers] [CMake] Forcing colorization of output from cmake In-Reply-To: <1412793361.29340.127.camel@mad-scientist.net> References: <1367417913.4101.127.camel@pdsdesk> <1412784946.29340.123.camel@mad-scientist.net> <54356C78.7060501@kitware.com> <1412793361.29340.127.camel@mad-scientist.net> Message-ID: <543693E2.5090901@kitware.com> On 10/08/2014 02:36 PM, Paul Smith wrote: > Hi all. Attached please find a proposed patch for the above. I still > think there's some slightly awkward redundancy between AssumeTTY and the > new ForceTTY, but I'm not sure these can actually be combined into one > flag... certainly not without reworking more of how AssumeTTY is > interpreted and used than I felt confident with. In this hunk: > @@ -68,14 +68,16 @@ void kwsysTerminal_cfprintf(int color, FILE* stream, const char* format, ...) > #if defined(KWSYS_TERMINAL_SUPPORT_CONSOLE) > CONSOLE_SCREEN_BUFFER_INFO hOutInfo; > HANDLE hOut = kwsysTerminalGetStreamHandle(stream); > - if(GetConsoleScreenBufferInfo(hOut, &hOutInfo)) > + if(color & kwsysTerminal_Color_ForceTTY || > + GetConsoleScreenBufferInfo(hOut, &hOutInfo)) > { > pipeIsConsole = 1; > kwsysTerminalSetConsoleColor(hOut, &hOutInfo, stream, color); > } we cannot enter the if() block unless GetConsoleScreenBufferInfo returns true because otherwise the hOutInfo will not be initialized correctly. In the Windows console code path we really need a handle to the console from the stream or it cannot work. Also, once the pipeIsConsole value is true, the kwsysTerminalSetVT100Color code path should not be used, so we do not want to force the second code path either. Instead ForceTTY should just influence the return value of kwsysTerminalStreamIsVT100. The Source/kwsys part of the change actually belongs in a separate KWSys upstream first. I've added a modified version of your change for upstream review and testing here: http://review.source.kitware.com/17578 Please try out that version with the rest of your changes. > it's darn handy to have this "just work" without having to export > COLOR='$(if $(MAKE_TERMOUT),FORCE)' in your ~/.bashrc or whatever. > There's no "GNU Makefiles" generator, and I couldn't come up with a good > way to implement this in the generic Unix Makefiles generator. We already have a CMAKE_COLOR_MAKEFILE option. Perhaps instead of just ON or OFF values it could have a GNU value that enables this behavior. When initializing it in CMakeGenericSystem.cmake perhaps it is possible to detect if CMAKE_MAKE_PROGRAM is a GNU make tool and provide a good default. Thanks, -Brad From brad.king at kitware.com Thu Oct 9 10:03:31 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Oct 2014 10:03:31 -0400 Subject: [cmake-developers] [PATCH] Preinstall requirements support for CPack RPM generator In-Reply-To: References: Message-ID: <543695B3.5010201@kitware.com> On 10/08/2014 01:48 PM, Evgeny Kalishenko wrote: > I was interested in feature request > http://public.kitware.com/Bug/view.php?id=14769 and made a > simple patch for CPack RPM generator (attached). Thanks. In this hunk: > + # The following keywords require braces around the "pre" or "post" suffix in the final RPM spec file. > + if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE" OR "${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST") > + string(REPLACE "_" "(" _PACKAGE_HEADER_NAME "${_PACKAGE_HEADER_NAME}") > + set(_PACKAGE_HEADER_NAME "${_PACKAGE_HEADER_NAME})") > + endif() The MATCHES conditions can use simply STREQUAL instead. I'm not very familiar with the spec format, so please explain the purpose of the s/_/(/ subsitution in comments here. Thanks, -Brad From clinton at elemtech.com Thu Oct 9 10:16:16 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Thu, 9 Oct 2014 08:16:16 -0600 (MDT) Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <54368C7A.8060007@kitware.com> References: <542ACE37.1040302@kitware.com> <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> <5435556F.9070303@kitware.com> <6523826.ocfdZJFGtQ@stryke> <54368C7A.8060007@kitware.com> Message-ID: <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> ----- Original Message ----- > Adam, > > On 10/08/2014 12:17 PM, Clinton Stimpson wrote: > > Yeah. I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle- > > rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with > > @rpath on OS X 10.5. Perhaps it'll recognize there is no need to change > > rpaths. > > The BundleUtilities test still fails on OS X 10.5: > > http://open.cdash.org/testDetails.php?test=285651145&build=3522021 > -- 6/10: fixing up > '/.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1' > install_name_tool: more than one input file specified > (/.../Tests/BundleUtilities/testdir1 and -delete_rpath) > Usage: install_name_tool [-change old new] ... [-id name] input > > Clinton's changes in his rpath-osx-10_6 extension topic to yours teach > other uses of -delete_rpath to warn on OS X 10.5 and skip deletion. > I think something similar will be needed here. Please investigate. > > Meanwhile, on my local OS X 10.9 machine I added this patch: > > diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake > index eedab44..80e5d3b 100644 > --- a/Modules/BundleUtilities.cmake > +++ b/Modules/BundleUtilities.cmake > @@ -755,6 +755,7 @@ function(fixup_bundle_item resolved_embedded_item exepath > dirs) > # > if(changes) > execute_process(COMMAND install_name_tool ${changes} > "${resolved_embedded_item}") > + message(STATUS "CHANGE install_name_tool ${changes} > \"${resolved_embedded_item}\"") > endif() > endfunction() > > From the test output I can see that it is trying to delete several > rpath entries that do not exist and therefore do not need deletion. > How is the list chosen for each binary? > Brad, When I do the same message(), I don't see deletion of rpaths which do not exist. I see deletions of rpaths which do exist as defined in the CMakeLists.txt file: set_target_properties(testbundleutils1 module1 PROPERTIES INSTALL_RPATH "${CMAKE_CURRENT_BINARY_DIR}/testdir1" BUILD_WITH_INSTALL_RPATH 1) But, I'm wondering if INSTALL_RPATH should only be effective on OS X if MACOSX_RPATH is set. Currently MACOSX_RPATH determines whether a target uses @rpath for its id, which can result in rpaths for a consumer. In other words, whether a target has rpaths is determined by the use of @rpath in its dependencies. What do you think about the case of INSTALL_RPATH? Clint From brad.king at kitware.com Thu Oct 9 10:27:32 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Oct 2014 10:27:32 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> References: <542ACE37.1040302@kitware.com> <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> <5435556F.9070303@kitware.com> <6523826.ocfdZJFGtQ@stryke> <54368C7A.8060007@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> Message-ID: <54369B54.3040501@kitware.com> On 10/09/2014 10:16 AM, clinton at elemtech.com wrote: > When I do the same message(), I don't see deletion of rpaths which do not exist. I see them for libshared and libshared2 which have SKIP_BUILD_RPATH. > But, I'm wondering if INSTALL_RPATH should only be effective on OS X > if MACOSX_RPATH is set. > Currently MACOSX_RPATH determines whether a target uses @rpath for > its id, which can result in rpaths for a consumer. > In other words, whether a target has rpaths is determined by the > use of @rpath in its dependencies. > What do you think about the case of INSTALL_RPATH? If any dependencies have @rpath then the RPATH of a target is meaningful, and INSTALL_RPATH is how the actual search paths listed in the RPATH are to be set. INSTALL_RPATH is orthogonal to MACOSX_RPATH. The affect different fields of their target. -Brad From ono at java.pl Thu Oct 9 10:37:48 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 9 Oct 2014 16:37:48 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <888522664.277920.1412862188537.JavaMail.zimbra@elemtech.com> References: <542ACE37.1040302@kitware.com> <543295F9.1020705@kitware.com> <2013360601.322696.1412604873146.JavaMail.zimbra@elemtech.com> <63CCABD9-7194-4EED-A8A0-E753E3FC838F@java.pl> <5432AE91.1010708@kitware.com> <192762655.1444632.1412656491036.JavaMail.zimbra@elemtech.com> <1490975564.440004.1412780702995.JavaMail.zimbra@elemtech.com> <5435556F.9070303@kitware.com> <888522664.277920.1412862188537.JavaMail.zimbra@elemtech.com> Message-ID: <8EA6525C-DFC9-4162-AD46-C919B95D238F@java.pl> > I was looking at the BundleUtilities failure after the above fixes, and I noticed it unconditionally removes paths. It does that because all bundles frameworks/libraries are referenced by @executable/loader_path and all @rpath references will be replaced, so there no point to have LC_RPATH in executables that will likely point to absolute old library locations. Please note that this is just an extension to existing BundleUtilities behavior. I intentionally didn't want to support or add an option to bundle framework using @path + LC_PATH. --Adam From eric.noulard at gmail.com Thu Oct 9 10:58:55 2014 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 9 Oct 2014 16:58:55 +0200 Subject: [cmake-developers] [CPack] Call for volunteer for CPackRPM, CPackDeb maintenance. Message-ID: Hi everybody, This message is an open request to find volunteer maintainers for CPackRPM and CPackDeb which were my main contributions to CPack (CPackDeb was initially contributed by Mathieu). I have 21 Mantis tickets (http://public.kitware.com/Bug) assigned to me I will soon unassign them or "transfer" them to volunteering people. I did contribute to CMake/CPack for some time (~2007) now but my "CMake free time" is now too small to be able to test and integrate contribution/patches to CPackDeb and CPackRPM. I will be listening to the mailing lists as usual but one shall not count on a timely responsiveness from me. I shall say that this is not a lack of interest but a clear lack of time. I do continue to use CMake/CPack/CTest on a daily basis but cannot find enough time to contribute anymore. I'll try my best to help the volunteer(s) to take over. People interested may answer here and/or send me direct e-mail if they find it necessary. I shall say that the CMake developer community including Kitware people (off course) were (and are) very helpful and always kind to handle my cmake/cpack contribution. -- Erk L'?lection n'est pas la d?mocratie -- http://www.le-message.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton at elemtech.com Thu Oct 9 11:01:10 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Thu, 09 Oct 2014 09:01:10 -0600 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <54369B54.3040501@kitware.com> References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> Message-ID: <4919083.hvPr6C4Ify@stryke> On Thursday, October 09, 2014 10:27:32 AM Brad King wrote: > On 10/09/2014 10:16 AM, clinton at elemtech.com wrote: > > When I do the same message(), I don't see deletion of rpaths which do not > > exist. > I see them for libshared and libshared2 which have SKIP_BUILD_RPATH. > > > But, I'm wondering if INSTALL_RPATH should only be effective on OS X > > if MACOSX_RPATH is set. > > Currently MACOSX_RPATH determines whether a target uses @rpath for > > its id, which can result in rpaths for a consumer. > > In other words, whether a target has rpaths is determined by the > > use of @rpath in its dependencies. > > What do you think about the case of INSTALL_RPATH? > > If any dependencies have @rpath then the RPATH of a target is > meaningful, and INSTALL_RPATH is how the actual search paths > listed in the RPATH are to be set. INSTALL_RPATH is orthogonal > to MACOSX_RPATH. The affect different fields of their target. > Another justification for that is if a target does not link to any libraries with an @rpath id, it is still useful to have an rpath to support dlopen("@rpath/somelib"). Thanks, Clint From mantis at public.kitware.com Thu Oct 9 11:07:33 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 9 Oct 2014 11:07:33 -0400 Subject: [cmake-developers] [CMake 0015201]: Xcode generator is unusably slow on large projects Message-ID: <15f76c320208f2a1b0cb8bbeae291cd8@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15201 ====================================================================== Reported By: Simon Assigned To: ====================================================================== Project: CMake Issue ID: 15201 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-09 11:07 EDT Last Modified: 2014-10-09 11:07 EDT ====================================================================== Summary: Xcode generator is unusably slow on large projects Description: I am building a large project, over a thousand CMakeList.txt files resulting in hundreds of Xcode projects being generated. This takes at least 6 times longer than the same makefile generation. I have profiled cmake 3.0.2 and found a significant bottleneck in cmGlobalXCodeGenerator::FindXCodeTarget() because the objects are stored in a vector and this vector has to be iterated over each time to find a target. This is done thousands of times in the course of generating the Xcode project. As a quick fix I did the following: cmGlobalXCodeGenerator.h, added member var: std::unordered_map mXcodeObjectMap; cmGlobalXCodeGenerator.cpp void cmGlobalXCodeGenerator::ClearXCodeObjects() added to end of method: mXcodeObjectMap.clear(); cmGlobalXCodeGenerator::CreateUtilityTarget(cmTarget& cmtarget) Under call to target->SetTarget(...) added: mXcodeObjectMap[&cmtarget] = target; cmGlobalXCodeGenerator::CreateXCodeTarget(...) Under call to target->SetTarget(...) added: mXcodeObjectMap[&cmtarget] = target; cmXCodeObject* cmGlobalXCodeGenerator::FindXCodeTarget(cmTarget const* t) rewrote to: cmXCodeObject* cmGlobalXCodeGenerator::FindXCodeTarget(cmTarget const* t) { if(!t) { return 0; } std::unordered_map::iterator iter = mXcodeObjectMap.find(t); if (iter == mXcodeObjectMap.end()) { return 0; } return iter->second; } So basically rather than constantly iterating through a vector for the Xcode object with the right target, it now keeps an unordered map where the key is the target pointer, and the object is the Xcode object. This reduces the lookup time enormously. With only this change the generation of the project I'm working on goes down from well over an hour to around 10 mins, which puts it inline with the makefile generator performance. Steps to Reproduce: Build a large set of projects. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-09 11:07 Simon New Issue ====================================================================== From ono at java.pl Thu Oct 9 11:14:46 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 9 Oct 2014 17:14:46 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <4919083.hvPr6C4Ify@stryke> References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> Message-ID: <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> FYI pushed e646a14f61 BundleUtilities: Check install_name_tool has -delete_rpath which is safest way to check if we can use -delete_rpath as it was introduced somewhere in 10.6 SDK, but there's no guarantee what SDK user has even it runs more recent OSX. --Adam From brad.king at kitware.com Thu Oct 9 11:19:17 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Oct 2014 11:19:17 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> Message-ID: <5436A775.7040401@kitware.com> On 10/09/2014 11:14 AM, Adam Strzelecki wrote: > FYI pushed e646a14f61 BundleUtilities: Check install_name_tool > has -delete_rpath which is safest way to check if we can use Thanks. I moved the commit over on top of the rpath-osx-10_6 topic and then removed that topic. For now fix-OSX-bundle-rpaths-and-Qt5 will contain all these related changes. I merged it for testing in 'next'. Thanks, -Brad From ydginster at gmail.com Thu Oct 9 13:30:15 2014 From: ydginster at gmail.com (Evgeny Kalishenko) Date: Thu, 9 Oct 2014 21:30:15 +0400 Subject: [cmake-developers] [PATCH] Preinstall requirements support for CPack RPM generator In-Reply-To: <543695B3.5010201@kitware.com> References: <543695B3.5010201@kitware.com> Message-ID: Ok, thanks for the advise about STREQUAL. Explanation of s/_/(/ (from http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html): "Recent versions of RPM support context marked dependencies. This is a special type of a dependency that applies only in a specified *context*. Using this feature, one can specify dependencies for pre- and post(un)install scriptlets, ie. the context of a dependency is the execution time of the specified scriptlet. The syntax for specifying these dependencies is: Requires(*X*): foo Here, *X* can be one of *pre*, *post*, *preun*, or *postun*, which tells RPM that the package depends on package foo for running the corresponding *%pre*, *%post*, *%preun*, or *%postun* script." Modified patch attached. 2014-10-09 18:03 GMT+04:00 Brad King : > On 10/08/2014 01:48 PM, Evgeny Kalishenko wrote: > > I was interested in feature request > > http://public.kitware.com/Bug/view.php?id=14769 and made a > > simple patch for CPack RPM generator (attached). > > Thanks. > > In this hunk: > > > + # The following keywords require braces around the "pre" or "post" > suffix in the final RPM spec file. > > + if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE" OR > "${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST") > > + string(REPLACE "_" "(" _PACKAGE_HEADER_NAME > "${_PACKAGE_HEADER_NAME}") > > + set(_PACKAGE_HEADER_NAME "${_PACKAGE_HEADER_NAME})") > > + endif() > > The MATCHES conditions can use simply STREQUAL instead. > I'm not very familiar with the spec format, so please > explain the purpose of the s/_/(/ subsitution in comments > here. > > Thanks, > -Brad > > -- ? ?????????, ??????? ????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pre_post_rpm_install.patch Type: text/x-patch Size: 5997 bytes Desc: not available URL: From chuck.atkins at kitware.com Thu Oct 9 14:27:18 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 9 Oct 2014 14:27:18 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <5433FC0B.4060802@kitware.com> References: <542E964C.1050104@kitware.com> <5433FC0B.4060802@kitware.com> Message-ID: Are we still on a "stage freeze" until the release, or is it just a hold on stage/next? I ask because I've got a non-trivial branch to push to the stage for review that re-factors how search paths are constructed for find* commands. - Chuck On Tue, Oct 7, 2014 at 10:43 AM, Brad King wrote: > On 10/03/2014 08:27 AM, Brad King wrote: > > In preparation for the first 3.1 release candidate I will feature- > > freeze master as of 2014-10-09. As of now there are several open > > topics in 'next' that we should try to land in master by then, but > > please refrain from adding non-trivial changes in the meantime. > > In order to get the dashboard cleaned up for final merges to > 'master' before the release, please refrain from merging any > changes other than dashboard fixes and documentation updates > to 'next'. > > Thanks, > -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 brad.king at kitware.com Thu Oct 9 14:32:43 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Oct 2014 14:32:43 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: References: <542E964C.1050104@kitware.com> <5433FC0B.4060802@kitware.com> Message-ID: <5436D4CB.8010702@kitware.com> On 10/09/2014 02:27 PM, Chuck Atkins wrote: > I've got a non-trivial branch to push to the stage for review You can push it for review but please do not merge to 'next' yet. Thanks, -Brad From chuck.atkins at kitware.com Thu Oct 9 14:34:08 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 9 Oct 2014 14:34:08 -0400 Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1 In-Reply-To: <5436D4CB.8010702@kitware.com> References: <542E964C.1050104@kitware.com> <5433FC0B.4060802@kitware.com> <5436D4CB.8010702@kitware.com> Message-ID: Great, thanks! - Chuck On Thu, Oct 9, 2014 at 2:32 PM, Brad King wrote: > On 10/09/2014 02:27 PM, Chuck Atkins wrote: > > I've got a non-trivial branch to push to the stage for review > > You can push it for review but please do not merge to 'next' yet. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Thu Oct 9 14:45:19 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 9 Oct 2014 14:45:19 -0400 Subject: [cmake-developers] Refactoring search path construction Message-ID: I've just pushed a branch to the stage for review: refactor-search-path-construction , not merged to next due to the current release hold. Just a head's up, it's rather invasive. It's a re-factoring of how search paths get constructed for find* commands. Up until now, search paths have been incrementally constructed with the composite search path being the only result. This separates and constructs each "class" of search path separately and combines them together afterwards. This branch is a pre-cursor for new features that can manipulate groups of search paths with leaving others untouched. - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Thu Oct 9 14:55:57 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 9 Oct 2014 14:55:57 -0400 Subject: [cmake-developers] Refactoring search path construction In-Reply-To: References: Message-ID: Just to clarify, this does *NOT* change the search order. - Chuck On Thu, Oct 9, 2014 at 2:45 PM, Chuck Atkins wrote: > I've just pushed a branch to the stage for review: > refactor-search-path-construction , not merged to next due to the current > release hold. > > Just a head's up, it's rather invasive. It's a re-factoring of how search > paths get constructed for find* commands. Up until now, search paths have > been incrementally constructed with the composite search path being the > only result. This separates and constructs each "class" of search path > separately and combines them together afterwards. > > This branch is a pre-cursor for new features that can manipulate groups of > search paths with leaving others untouched. > > - Chuck > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Thu Oct 9 13:38:09 2014 From: paul at mad-scientist.net (Paul Smith) Date: Thu, 09 Oct 2014 13:38:09 -0400 Subject: [cmake-developers] [CMake] Forcing colorization of output from cmake In-Reply-To: <543693E2.5090901@kitware.com> References: <1367417913.4101.127.camel@pdsdesk> <1412784946.29340.123.camel@mad-scientist.net> <54356C78.7060501@kitware.com> <1412793361.29340.127.camel@mad-scientist.net> <543693E2.5090901@kitware.com> Message-ID: <1412876289.29340.133.camel@mad-scientist.net> Thanks Brad. I wrote a bunch more below and left it for posterity. However thinking more about this I wonder if we couldn't make this simpler. What I really want is that if MAKE_TERMOUT is set to a non-empty value, cmake should pretend that it's in a terminal regardless of what isatty() says. We can do this easily enough by adding a simple test to Terminal.c:kwsysTerminalStreamIsVT100() _without_ adding any code anywhere else: /* Check for a valid terminal. */ if(!default_vt100) { ... } + + /* If we're being run from GNU make 4.1+ see if IT thinks we have a TTY. */ + const char* termout = getenv("MAKE_TERMOUT"); + if(termout && termout[0] != '\0') + { + return 1; + } In a way this is gross, certainly, but this function already checks for environment variable such as TERM, EMACS, etc. which are set by calling utilities and handles them specially. So why not MAKE_TERMOUT as well? That one change is enough for my particular use-case, without any other changes (don't need a FORCE setting for color). I think it would be useful to allow FORCE (I think this is a good capability to provide; as I mentioned other tools that support colorization such as GCC etc. to provide an "always"-type flag) but it would be decoupled from this GNU make capability. Thoughts? On Thu, 2014-10-09 at 09:55 -0400, Brad King wrote: > The Source/kwsys part of the change actually belongs in a separate > KWSys upstream first. I've added a modified version of your change > for upstream review and testing here: > > http://review.source.kitware.com/17578 > > Please try out that version with the rest of your changes. OK. I see that in your version FORCE only comes into effect if we have a "known good" terminal (the new code comes after the check for valid terminal). Personally I would expect FORCE to be stronger than that, and return true regardless of TERM settings. Whether or not it should override EMACS env.var. I don't know... I'm on the fence. In my solution I had it really FORCE; that is, kwsysTerminalStreamIsVT100() effectively always was true if --switch=FORCE, regardless of EMACS or TERM. I'm not at all familiar with Windows so I have no strong opinions on whether FORCE should also force color output on a Windows console... although I know a number of people who do use GNU make on Windows and the Windows port of GNU make does set MAKE_TERMOUT properly. > > it's darn handy to have this "just work" without having to export > > COLOR='$(if $(MAKE_TERMOUT),FORCE)' in your ~/.bashrc or whatever. > > There's no "GNU Makefiles" generator, and I couldn't come up with a good > > way to implement this in the generic Unix Makefiles generator. > > We already have a CMAKE_COLOR_MAKEFILE option. Perhaps instead > of just ON or OFF values it could have a GNU value that enables > this behavior. When initializing it in CMakeGenericSystem.cmake > perhaps it is possible to detect if CMAKE_MAKE_PROGRAM is a GNU > make tool and provide a good default. Well, it's easy enough to detect if CMAKE_MAKE_PROGRAM is GNU make, if we can run it to test the output of "${CMAKE_MAKE_PROGRAM} --version". The question is, what do you do in the generated makefile if you see that it's GNU make? Anything you'd generate into the makefile that could choose to set --switch=FORCE would have to be GNU-specific (I can't think of a way to write it using POSIX standard makefile syntax). It would need to be the equivalent of: --switch=$(or $(COLOR),$(if $(MAKE_TERMOUT),FORCE)) to preserve the current behavior, where the COLOR variable setting can be inherited from the environment. What if someone runs cmake and it detects GNU make, but then they run "/my/other/make" which is not GNU make? That would work fine now but fail if we generated GNU-specific content in 'Unix Makefiles' generators. If we had a different generator, like 'GNU Makefiles' for example, then people who chose that would clearly expect the results would only work with GNU make, but we don't have that. From Geoffrey.Viola at asirobots.com Thu Oct 9 19:36:20 2014 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Thu, 9 Oct 2014 23:36:20 +0000 Subject: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support Message-ID: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> Attached is a patch to make CMake generate files for the Green Hills MULTI IDE. These patches are in reference to this feature request: http://public.kitware.com/Bug/view.php?id=14992. There were some limitations. It has been restricted to Windows, because that is the version of the IDE that I have. There is a special grouping called a Monolith that includes several executables, shared libraries, and the kernel. These monoliths have their own set of compile options. I'm not sure how CMake would be able to create these. Also, there are some internal macros that point to the compiler's target BSP and OS that are currently populated via CMake variables: GHS_CUSTOMIZATION, GHS_OS_DIR, and GHS_BSP_NAME. Any feedback would be appreciated. Thanks, [cid:image001.png at 01CE6DA0.CA468FE0] Geoffrey Viola Software Engineer T +1.435.755.2980 ext 1077 M +1.215.896.6521 asirobots.com This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1911 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Updated-supplementary-files-to-include-the-GHS-gener.patch Type: application/octet-stream Size: 15035 bytes Desc: 0002-Updated-supplementary-files-to-include-the-GHS-gener.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-basic-and-partial-support-for-a-Green-Hill-MUL.patch Type: application/octet-stream Size: 36468 bytes Desc: 0001-Added-basic-and-partial-support-for-a-Green-Hill-MUL.patch URL: From nilsgladitz at gmail.com Fri Oct 10 05:09:54 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Oct 2014 11:09:54 +0200 Subject: [cmake-developers] $ genex regression Message-ID: <5437A262.1050305@gmail.com> "cmTarget: Refactor ComputeLinkImplementation" (24637979): http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=24637979 Seems to have broken this reduced testcase: cmake_minimum_required(VERSION 3.0) set(LIBRARIES foobar.lib barfoo.lib ) add_executable(foo foo.cpp) target_link_libraries(foo PUBLIC $) For the Ninja generator in 3.0 this produces a "build.ninja" with: LINK_LIBRARIES = -rdynamic -lfoobar.lib -lbarfoo.lib Since 24637979 this produces: LINK_LIBRARIES = -rdynamic $ I can work around this by wrapping the libraries with $ individually or by quoting the entire genex. Given the title of the commit I'm guessing this wasn't an intentional change of behavior? Nils From nilsgladitz at gmail.com Fri Oct 10 07:10:44 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Oct 2014 13:10:44 +0200 Subject: [cmake-developers] Ninja RC cmcldeps regression Message-ID: <5437BEB4.1000208@gmail.com> Ninja on windows invokes the resource compiler through cmcldeps. When passing ${CMAKE_BINARY_DIR} as an include directory CMake used to (3.0) add the absolute path to the command line; now "-I." is being added instead. The relative path does not seem to work in context of cmcldeps/rc since headers in ${CMAKE_BINARY_DIR} aren't found anymore. Nils From ruslan_baratov at yahoo.com Fri Oct 10 07:45:14 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 10 Oct 2014 15:45:14 +0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <543531CC.7090103@kitware.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> Message-ID: <5437C6CA.3030201@yahoo.com> On 08-Oct-14 16:45, Brad King wrote: > On 10/08/2014 07:52 AM, Ruslan Baratov wrote: >> Okay :) I just not sure that I understand "to pass to some other >> process" goal correctly. > That was just an example of why one might want to drop management > of the lock by CMake without actually unlocking it. Perhaps the > code is starting a daemon and passes off responsibility for the > unlock side to the daemon process. Okay, got it. > >> * we just need to `unlock` file so the other instance will use it: >> file(UNLOCK_FILE "/path/to/shared/file") >> # now anybody can do the lock > Yes. We also need the locking API to return information about > whether we really acquired the lock. So it can be TRY_LOCK and LOCK. But does the TRY_LOCK really needed? With LOCK we can try to lock and spin until acquire, but what to do with TRY_LOCK? Just give up? > >> * we need other process to "inherit" the lock (what for?), i.e. move >> ownership (?): >> file(LOCK_FILE "/path/to/shared/file") >> execute_process(${CMAKE_COMMAND} --take-ownership "/path/to/shared/file" >> ...) >> # unlocked by execute_process > I think all we need there is a way to ask CMake to take over > responsibility for a lock that it did not originally create. > It can also be in the file() command. > > Thanks, > -Brad > Okay, so here is the commands inspired by C++: file(TRY_LOCK "/path/to/file" result) # try to lock and return TRUE on success (needed?) file(LOCK ...) # lock until unlock (unlock by further code (what if exit/crashed?) or by deamon) file(LOCK_GUARD ...) # lock for scope of current function or until exit file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD Locking directory is equivalent to locking file `cmake.lock` in directory "/path/to/shared/directory/": file(DIRECTORY_TRY_LOCK ...) file(DIRECTORY_LOCK "/path/to/shared/directory/") # == file(LOCK "/path/to/shared/directory/cmake.lock") file(DIRECTORY_LOCK_GUARD ...) file(DIRECTORY_UNLOCK ...) If any of this commands failed (e.g. have no permissions) - exit with unsuccessful code (i.e. FATAL_ERROR) ? * http://en.cppreference.com/w/cpp/thread/try_lock * http://en.cppreference.com/w/cpp/thread/lock * http://en.cppreference.com/w/cpp/thread/lock_guard * http://en.cppreference.com/w/cpp/thread/mutex/unlock From nilsgladitz at gmail.com Fri Oct 10 08:43:02 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Oct 2014 14:43:02 +0200 Subject: [cmake-developers] Ninja RC cmcldeps regression In-Reply-To: <5437BEB4.1000208@gmail.com> References: <5437BEB4.1000208@gmail.com> Message-ID: <5437D456.3030801@gmail.com> On 10/10/2014 01:10 PM, Nils Gladitz wrote: > Ninja on windows invokes the resource compiler through cmcldeps. > > When passing ${CMAKE_BINARY_DIR} as an include directory CMake used to > (3.0) add the absolute path to the command line; now "-I." is being > added instead. > > The relative path does not seem to work in context of cmcldeps/rc since > headers in ${CMAKE_BINARY_DIR} aren't found anymore. This seems to have broken with "cmLocalGenerator: Simplify GetIncludeFlags output formatting" (b9aa5041): http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=b9aa5041 I used the following test case to reproduce the issue: cmake_minimum_required(VERSION 3.0) file(WRITE foo.cpp "int main() {}") file(WRITE foo.rc "#include ") file(WRITE ${CMAKE_BINARY_DIR}/bar.rc "") add_executable(foo foo.cpp foo.rc) target_include_directories(foo PRIVATE ${CMAKE_BINARY_DIR}) Nils From brad.king at kitware.com Fri Oct 10 08:48:24 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Oct 2014 08:48:24 -0400 Subject: [cmake-developers] [CPack] Call for volunteer for CPackRPM, CPackDeb maintenance. In-Reply-To: References: Message-ID: <5437D598.30307@kitware.com> On 10/09/2014 10:58 AM, Eric Noulard wrote: > This message is an open request to find volunteer maintainers > for CPackRPM and CPackDeb > > I did contribute to CMake/CPack for some time (~2007) now but > my "CMake free time" is now too small to be able to test and > integrate contribution/patches to CPackDeb and CPackRPM. Thank you for your help over all these years, Eric! -Brad From DLRdave at aol.com Fri Oct 10 08:58:00 2014 From: DLRdave at aol.com (David Cole) Date: Fri, 10 Oct 2014 08:58:00 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5437C6CA.3030201@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> Message-ID: What is the main use case for locking files and directories from the CMake language? I feel slightly uncomfortable, without being able to put my finger on exactly why, with the prospect of adding this to CMake... Behavior when there's a lock that still exists (by bug/mistake) after CMake is done running is going to be strange and possibly hard-to-diagnose / hard-to-understand. Let's make sure the use case is quite strong before we accept the possibility of "stale locks" in CMake. Thanks, David C. On Fri, Oct 10, 2014 at 7:45 AM, Ruslan Baratov via cmake-developers wrote: > On 08-Oct-14 16:45, Brad King wrote: >> >> On 10/08/2014 07:52 AM, Ruslan Baratov wrote: >>> >>> Okay :) I just not sure that I understand "to pass to some other >>> process" goal correctly. >> >> That was just an example of why one might want to drop management >> of the lock by CMake without actually unlocking it. Perhaps the >> code is starting a daemon and passes off responsibility for the >> unlock side to the daemon process. > > Okay, got it. >> >> >>> * we just need to `unlock` file so the other instance will use it: >>> file(UNLOCK_FILE "/path/to/shared/file") >>> # now anybody can do the lock >> >> Yes. We also need the locking API to return information about >> whether we really acquired the lock. > > So it can be TRY_LOCK and LOCK. But does the TRY_LOCK really needed? With > LOCK we can try to lock and spin until acquire, but what to do with > TRY_LOCK? Just give up? >> >> >>> * we need other process to "inherit" the lock (what for?), i.e. move >>> ownership (?): >>> file(LOCK_FILE "/path/to/shared/file") >>> execute_process(${CMAKE_COMMAND} --take-ownership "/path/to/shared/file" >>> ...) >>> # unlocked by execute_process >> >> I think all we need there is a way to ask CMake to take over >> responsibility for a lock that it did not originally create. >> It can also be in the file() command. >> >> Thanks, >> -Brad >> > Okay, so here is the commands inspired by C++: > > file(TRY_LOCK "/path/to/file" result) # try to lock and return TRUE on > success (needed?) > file(LOCK ...) # lock until unlock (unlock by further code (what if > exit/crashed?) or by deamon) > file(LOCK_GUARD ...) # lock for scope of current function or until exit > file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD > > Locking directory is equivalent to locking file `cmake.lock` in directory > "/path/to/shared/directory/": > > file(DIRECTORY_TRY_LOCK ...) > file(DIRECTORY_LOCK "/path/to/shared/directory/") # == file(LOCK > "/path/to/shared/directory/cmake.lock") > file(DIRECTORY_LOCK_GUARD ...) > file(DIRECTORY_UNLOCK ...) > > If any of this commands failed (e.g. have no permissions) - exit with > unsuccessful code (i.e. FATAL_ERROR) ? > > * http://en.cppreference.com/w/cpp/thread/try_lock > * http://en.cppreference.com/w/cpp/thread/lock > * http://en.cppreference.com/w/cpp/thread/lock_guard > * http://en.cppreference.com/w/cpp/thread/mutex/unlock > > -- > > 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 brad.king at kitware.com Fri Oct 10 09:14:57 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Oct 2014 09:14:57 -0400 Subject: [cmake-developers] $ genex regression In-Reply-To: <5437A262.1050305@gmail.com> References: <5437A262.1050305@gmail.com> Message-ID: <5437DBD1.1050401@kitware.com> On 10/10/2014 05:09 AM, Nils Gladitz wrote: > set(LIBRARIES > foobar.lib > barfoo.lib > ) > > add_executable(foo foo.cpp) > target_link_libraries(foo PUBLIC $) This is basically writing: target_link_libraries(foo PUBLIC $) which was never intended to be supported. It worked only as an accident of the 3.0 implementation. In 2.8.12.2 it did not work. > I can work around this by wrapping the libraries with $ > individually or by quoting the entire genex. This was the intended interface. I'm willing to regress this because: - It restores 2.8.12 behavior - The quoting is easy to do - It is very hard to fix this without un-doing all the other improvements enabled by the refactoring that broke this. I will add mention of this in the 3.1 release notes. Thanks, -Brad From nilsgladitz at gmail.com Fri Oct 10 09:17:09 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Oct 2014 15:17:09 +0200 Subject: [cmake-developers] $ genex regression In-Reply-To: <5437DBD1.1050401@kitware.com> References: <5437A262.1050305@gmail.com> <5437DBD1.1050401@kitware.com> Message-ID: <5437DC55.1040002@gmail.com> On 10/10/2014 03:14 PM, Brad King wrote: >> I can work around this by wrapping the libraries with $ >> individually or by quoting the entire genex. > > This was the intended interface. > > I'm willing to regress this because: > > - It restores 2.8.12 behavior > - The quoting is easy to do > - It is very hard to fix this without un-doing all the other > improvements enabled by the refactoring that broke this. > > I will add mention of this in the 3.1 release notes. Good enough for me, thanks! Nils From ruslan_baratov at yahoo.com Fri Oct 10 09:59:07 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 10 Oct 2014 17:59:07 +0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> Message-ID: <5437E62B.4050903@yahoo.com> On 10-Oct-14 16:58, David Cole wrote: > What is the main use case for locking files and directories from the > CMake language? > > I feel slightly uncomfortable, without being able to put my finger on > exactly why, with the prospect of adding this to CMake... I've described the situation in the first message of this thread: sharing resources between different cmake builds. If you want the particular case: I'm developing cmake-based package manager that share the builds of ExternalProject_Add. I'm experienced problems even when working on my local machine (I've started long-build in one console, then accidentally connect to the same shared directory in other console), but the main problem here is the server auto-builds which usually start multiple jobs simultaneously. > > Behavior when there's a lock that still exists (by bug/mistake) after > CMake is done running is going to be strange and possibly > hard-to-diagnose / hard-to-understand. That's *exactly* the problem I have and why I start this discussion. Currently I'm using mkdir command which return 0 only if directory created by current process (just to clarify, not the cmake -E make_directory). This works fine for me (tested on windows (mingw, cygwin), linux and mac). But I can't (or I don't know how) make remove this directory when I Ctrl+C my build (or abort the job on jenkins server). My current implementation just keep spinning with message: "Directory locked by cmake, build started in directory at ". > > Let's make sure the use case is quite strong before we accept the > possibility of "stale locks" in CMake. Command `file(LOCK_GUARD ...)` will cover 100% of my needs. Other commands that I've mentioned used to cover suggestions from Brad K. (may be I've just understand them wrong). Ruslo Thanks, David C. On Fri, Oct 10, 2014 at 7:45 AM, Ruslan Baratov via cmake-developers wrote: >> On 08-Oct-14 16:45, Brad King wrote: >>> On 10/08/2014 07:52 AM, Ruslan Baratov wrote: >>>> Okay :) I just not sure that I understand "to pass to some other >>>> process" goal correctly. >>> That was just an example of why one might want to drop management >>> of the lock by CMake without actually unlocking it. Perhaps the >>> code is starting a daemon and passes off responsibility for the >>> unlock side to the daemon process. >> Okay, got it. >>> >>>> * we just need to `unlock` file so the other instance will use it: >>>> file(UNLOCK_FILE "/path/to/shared/file") >>>> # now anybody can do the lock >>> Yes. We also need the locking API to return information about >>> whether we really acquired the lock. >> So it can be TRY_LOCK and LOCK. But does the TRY_LOCK really needed? With >> LOCK we can try to lock and spin until acquire, but what to do with >> TRY_LOCK? Just give up? >>> >>>> * we need other process to "inherit" the lock (what for?), i.e. move >>>> ownership (?): >>>> file(LOCK_FILE "/path/to/shared/file") >>>> execute_process(${CMAKE_COMMAND} --take-ownership "/path/to/shared/file" >>>> ...) >>>> # unlocked by execute_process >>> I think all we need there is a way to ask CMake to take over >>> responsibility for a lock that it did not originally create. >>> It can also be in the file() command. >>> >>> Thanks, >>> -Brad >>> >> Okay, so here is the commands inspired by C++: >> >> file(TRY_LOCK "/path/to/file" result) # try to lock and return TRUE on >> success (needed?) >> file(LOCK ...) # lock until unlock (unlock by further code (what if >> exit/crashed?) or by deamon) >> file(LOCK_GUARD ...) # lock for scope of current function or until exit >> file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD >> >> Locking directory is equivalent to locking file `cmake.lock` in directory >> "/path/to/shared/directory/": >> >> file(DIRECTORY_TRY_LOCK ...) >> file(DIRECTORY_LOCK "/path/to/shared/directory/") # == file(LOCK >> "/path/to/shared/directory/cmake.lock") >> file(DIRECTORY_LOCK_GUARD ...) >> file(DIRECTORY_UNLOCK ...) >> >> If any of this commands failed (e.g. have no permissions) - exit with >> unsuccessful code (i.e. FATAL_ERROR) ? >> >> * http://en.cppreference.com/w/cpp/thread/try_lock >> * http://en.cppreference.com/w/cpp/thread/lock >> * http://en.cppreference.com/w/cpp/thread/lock_guard >> * http://en.cppreference.com/w/cpp/thread/mutex/unlock >> >> -- >> >> 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 brad.king at kitware.com Fri Oct 10 10:11:35 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Oct 2014 10:11:35 -0400 Subject: [cmake-developers] Ninja RC cmcldeps regression In-Reply-To: <5437D456.3030801@gmail.com> References: <5437BEB4.1000208@gmail.com> <5437D456.3030801@gmail.com> Message-ID: <5437E917.4090002@kitware.com> On 10/10/2014 08:43 AM, Nils Gladitz wrote: > This seems to have broken with "cmLocalGenerator: Simplify > GetIncludeFlags output formatting" (b9aa5041): > http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=b9aa5041 > > I used the following test case to reproduce the issue: Thanks, fixed and test added: Ninja: Fix RC include directories regression http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23c8eeb7 -Brad From nilsgladitz at gmail.com Fri Oct 10 10:18:16 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Oct 2014 16:18:16 +0200 Subject: [cmake-developers] $ genex regression In-Reply-To: <5437DC55.1040002@gmail.com> References: <5437A262.1050305@gmail.com> <5437DBD1.1050401@kitware.com> <5437DC55.1040002@gmail.com> Message-ID: <5437EAA8.2080909@gmail.com> On 10/10/2014 03:17 PM, Nils Gladitz wrote: > On 10/10/2014 03:14 PM, Brad King wrote: >>> I can work around this by wrapping the libraries with $ >>> individually or by quoting the entire genex. >> >> This was the intended interface. >> >> I'm willing to regress this because: >> >> - It restores 2.8.12 behavior >> - The quoting is easy to do >> - It is very hard to fix this without un-doing all the other >> improvements enabled by the refactoring that broke this. >> >> I will add mention of this in the 3.1 release notes. > > Good enough for me, thanks! > > Nils > As a side node for post-3.1 development it might be nice to have the Ninja generator properly escape the $ from e.g. those broken generator expressions that leak through or alternatively have CMake produce an error during generation. As it is the generated build.ninja is invalid and my local Dashboard (with launchers) showed all green for the configuration and build steps since even though ninja itself failed none of the compile/build jobs ran (and hence could not fail). In continuous builds where stale outputs still existed from previous builds there was no failure indication in the "Test" columns either. Nils From nilsgladitz at gmail.com Fri Oct 10 10:18:52 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Oct 2014 16:18:52 +0200 Subject: [cmake-developers] Ninja RC cmcldeps regression In-Reply-To: <5437E917.4090002@kitware.com> References: <5437BEB4.1000208@gmail.com> <5437D456.3030801@gmail.com> <5437E917.4090002@kitware.com> Message-ID: <5437EACC.50209@gmail.com> On 10/10/2014 04:11 PM, Brad King wrote: > Thanks, fixed and test added: > > Ninja: Fix RC include directories regression > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23c8eeb7 Thanks! Nils From brad.king at kitware.com Fri Oct 10 10:27:37 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Oct 2014 10:27:37 -0400 Subject: [cmake-developers] $ genex regression In-Reply-To: <5437EAA8.2080909@gmail.com> References: <5437A262.1050305@gmail.com> <5437DBD1.1050401@kitware.com> <5437DC55.1040002@gmail.com> <5437EAA8.2080909@gmail.com> Message-ID: <5437ECD9.301@kitware.com> On 10/10/2014 10:18 AM, Nils Gladitz wrote: > As a side node for post-3.1 development it might be nice to have the > Ninja generator properly escape the $ from e.g. those broken generator > expressions that leak through or alternatively have CMake produce an > error during generation. I think the most user-friendly approach would be an error during generation, or at least a warning. Perhaps a policy to make the warning an error. The main challenge will be deciding what to actually consider wrong without breaking real use cases. -Brad From brad.king at kitware.com Fri Oct 10 10:49:13 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Oct 2014 10:49:13 -0400 Subject: [cmake-developers] $ genex regression In-Reply-To: <5437DC55.1040002@gmail.com> References: <5437A262.1050305@gmail.com> <5437DBD1.1050401@kitware.com> <5437DC55.1040002@gmail.com> Message-ID: <5437F1E9.5080303@kitware.com> On 10/10/2014 09:17 AM, Nils Gladitz wrote: > On 10/10/2014 03:14 PM, Brad King wrote: >> I will add mention of this in the 3.1 release notes. > > Good enough for me, thanks! Here is a release note entry: Help: Add note about restoring pre-3.0 link libraries genex behavior http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8bd81981 -Brad From brad.king at kitware.com Fri Oct 10 10:59:15 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Oct 2014 10:59:15 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <5436A775.7040401@kitware.com> References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com> Message-ID: <5437F443.3040705@kitware.com> On 10/09/2014 11:19 AM, Brad King wrote: > I merged it for testing in 'next'. Everything tested cleanly! Adam, Clinton, thanks for your help bringing this topic to maturity. It was the last non-regression topic I'm planning to take for 3.1. I squashed the fixes and revised commit messages slightly. Then I merged to 'master': Merge topic 'fix-OSX-bundle-rpaths-and-Qt5' http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26bffa6e -Brad From steveire at gmail.com Fri Oct 10 11:56:38 2014 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 10 Oct 2014 17:56:38 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> Message-ID: Clinton Stimpson wrote: > Another justification for that is if a target does not link to any > libraries with an @rpath id, it is still useful to have an rpath to > support dlopen("@rpath/somelib"). Picking a message randomly, to respond to - Can someone tell me what this comment is referring to? # FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly # Qt5 Mac support is missing there. Thanks, Steve. From mantis at public.kitware.com Fri Oct 10 16:59:05 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 10 Oct 2014 16:59:05 -0400 Subject: [cmake-developers] [CMake 0015202]: BundleUtilities.cmake - function fixup_bundle_item fails with very long path Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15202 ====================================================================== Reported By: Mark Manthei Assigned To: ====================================================================== Project: CMake Issue ID: 15202 Category: CMake Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-10 16:59 EDT Last Modified: 2014-10-10 16:59 EDT ====================================================================== Summary: BundleUtilities.cmake - function fixup_bundle_item fails with very long path Description: when fixing up a very long exe inside of a bundle, the code attempts to figure out if the item is embedded in the bundle. The current logic fails because the SUBSTRING search starts at offset 0 and can fail to find the embedded item in the given length. >From debug output of BundleUtilities.cmake: -- 22/42: fixing up '/Users/autobuild/hudson/workspace/Product-Mac/build/Installed/Really Long App Name.app/Contents/MacOS/embeddeditem exe_dotapp_dir/='Installed/Really Long App Name.app/' item_substring='/Users/autobuild/hudson/workspace/R' Steps to Reproduce: Use long paths. Additional Information: Patch to fix issue, CMake version 3.0.2 attached ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-10 16:59 Mark Manthei New Issue 2014-10-10 16:59 Mark Manthei File Added: BundleUtilities.patch ====================================================================== From mantis at public.kitware.com Fri Oct 10 17:46:51 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 10 Oct 2014 17:46:51 -0400 Subject: [cmake-developers] [CMake 0015203]: CheckStructHasMember breaks on -Wunused-value Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15203 ====================================================================== Reported By: Lekensteyn Assigned To: ====================================================================== Project: CMake Issue ID: 15203 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-10 17:46 EDT Last Modified: 2014-10-10 17:46 EDT ====================================================================== Summary: CheckStructHasMember breaks on -Wunused-value Description: When CMAKE_C_FLAGS containg -Wall -Werror, CheckStructHasMember will always fail due to the generated code appearing as: int main() { struct FOO* s; s->MEMBER; return 0; } See the attached patch for a fix. Don't know whether some -std flag will also bail out on int main() rather than int main(void), but that's a different issue. This one is about breakage due to very strict warnings on a modern compiler (GCC 4.9.1). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-10 17:46 Lekensteyn New Issue 2014-10-10 17:46 Lekensteyn File Added: 0001-CheckStructHasMember-avoid-breakage-on-Wall.patch ====================================================================== From mantis at public.kitware.com Sun Oct 12 04:21:28 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 12 Oct 2014 01:21:28 -0700 Subject: [cmake-developers] [CMake 0015204]: On windows x64 system, cpack generate file names ending with AMD64, with 32 bit msvc compiler Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15204 ====================================================================== Reported By: Hong Xu Assigned To: ====================================================================== Project: CMake Issue ID: 15204 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-12 01:21 PDT Last Modified: 2014-10-12 01:21 PDT ====================================================================== Summary: On windows x64 system, cpack generate file names ending with AMD64, with 32 bit msvc compiler Description: On windows x64 system, cpack generate file names ending with AMD64, even with 32 bit msvc compiler. Packages (zip and NSIS installer) are generated with AMD64 in file name but not x86. However, the NSIS installer is an x86 executable as I tested. Output of cl command: Microsoft (R) C/C++ Optimizing Compiler Version 18.00.30723 for x86 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] Steps to Reproduce: Under 32bit compiler environment, use cpack to build the package by typing "cpack". ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-12 01:21 Hong Xu New Issue ====================================================================== From ono at java.pl Mon Oct 13 05:54:22 2014 From: ono at java.pl (Adam Strzelecki) Date: Mon, 13 Oct 2014 11:54:22 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> Message-ID: <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl> > Picking a message randomly, to respond to - Can someone tell me what this > comment is referring to? > > # FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly > # Qt5 Mac support is missing there. AFAIR it is about installing correct app bundle PlugIns. Qt provides half-baked CMake support, but some of necessary things still has to be done by user manually, such as installing cocoa platform plugin. --Adam From ben.boeckel at kitware.com Mon Oct 13 10:34:30 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 13 Oct 2014 10:34:30 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5437E62B.4050903@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> <5437E62B.4050903@yahoo.com> Message-ID: <20141013143430.GA15816@megas.kitwarein.com> On Fri, Oct 10, 2014 at 17:59:07 +0400, Ruslan Baratov via cmake-developers wrote: > > Behavior when there's a lock that still exists (by bug/mistake) after > > CMake is done running is going to be strange and possibly > > hard-to-diagnose / hard-to-understand. > That's *exactly* the problem I have and why I start this discussion. > Currently I'm using mkdir command which return 0 only if directory > created by current process (just to clarify, not the cmake -E > make_directory). This works fine for me (tested on windows (mingw, > cygwin), linux and mac). But I can't (or I don't know how) make remove > this directory when I Ctrl+C my build (or abort the job on jenkins > server). My current implementation just keep spinning with message: > "Directory locked by cmake, build started in directory > at ". Maybe we need something like the 'trap' shell builtin which runs code on various triggers rather than something like file/directory locks which are?hairy (especially in the face of things like NFS or Samba)? I can think of at least: - end of configure - end of generate - end of directory scope - end of scope (function or directory) --Ben From brad.king at kitware.com Mon Oct 13 10:39:08 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Oct 2014 10:39:08 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5437C6CA.3030201@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> Message-ID: <543BE40C.4000404@kitware.com> On 10/10/2014 07:45 AM, Ruslan Baratov wrote: > file(TRY_LOCK "/path/to/file" result) # try to lock and return TRUE on success (needed?) > file(LOCK ...) # lock until unlock (unlock by further code (what if exit/crashed?) or by deamon) The LOCK signature should have a timeout after which it returns failure instead of blocking forever. One can just use a timeout of 0 to get TRY_LOCK behavior without a separate signature for it. Or, by leaving out the timeout, one can ask to block forever waiting for the lock. > file(LOCK_GUARD ...) # lock for scope of current function or until exit I think the GUARD part can be an option to file(LOCK). We may need more than one to determine the scope, e.g. file(LOCK GUARD_FUNCTION ...) file(LOCK GUARD_PROCESS ...) > file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD Perhaps file(LOCK RELEASE ...) # unlock now file(LOCK UNGUARD ...) # drop guard > Locking directory is equivalent to locking file `cmake.lock` in > directory "/path/to/shared/directory/": I think this can be activated buy a DIRECTORY option. > If any of this commands failed (e.g. have no permissions) - exit with > unsuccessful code (i.e. FATAL_ERROR) ? The commands should all have an optional result argument so callers can find out what happened. If it is not provided, then failure can result in a FATAL_ERROR. With all the above in mind, please brainstorm and propose a more complete signature set. You can use the keyword/value pairing common in other commands to avoid needing a positional argument for every value. Also, please post a summary of how the implementation will work on each platform. Thanks, -Brad From brad.king at kitware.com Mon Oct 13 10:41:46 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Oct 2014 10:41:46 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <20141013143430.GA15816@megas.kitwarein.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> <5437E62B.4050903@yahoo.com> <20141013143430.GA15816@megas.kitwarein.com> Message-ID: <543BE4AA.5070907@kitware.com> On 10/13/2014 10:34 AM, Ben Boeckel wrote: > Maybe we need something like the 'trap' shell builtin which runs code on > various triggers That would first require an 'eval' equivalent in CMake, e.g. "cmake_eval()". This has been requested a few times. -Brad From chuck.atkins at kitware.com Mon Oct 13 11:40:10 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 13 Oct 2014 11:40:10 -0400 Subject: [cmake-developers] Proposed Feature: Selective search path re-rooting Message-ID: Following the topic branch to separately maintain each type of search path, I'm working on adding a feature for cross-compiling to separately control how each type of search path gets re-rooted. Currently, the options CMAKE_FIND_ROOT_PATH_MODE_{INCLUDE_LIBRARY_PROGRAM} can be set to ONLY, NEVER, or BOTH. This takes effect for all search paths, both CMake determined and user-specifies (through HINTS and PATHS options). Before putting the time and effort into implementing the feature this way, I wanted to get some feedback on the design first: My approach to control the path types independently is to allow the variable to be specified as either a single mode, applying to all paths, or a named list of the form "PATH_TYPE1 MODE1 PATH_TYPE2_MODE2..." much in the way that properties are specified. The following search path groups can be specified: - CMAKE_PATH - CMAKE_ENVIRONMENT_PATH - USER_HINTS_PATH - SYSTEM_ENVIRONMENT_PATH - CMAKE_SYSTEM_PATH - USER_GUESS_PATH In addition to each search path type, there will also be defined path groups: - ALL - All search paths - DEFAULT - CMAKE_PATH - CMAKE_ENVIRONMENT_PATH - SYSTEM_ENVIRONMENT_PATH - CMAKE_SYSTEM_PATH - USER - User hints and user guess paths If one had: set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ALL ONLY HINTS NEVER) Then the following modes would be set: - find_program: All search paths set to never - find_library: user hints would never be re-rooted and all others would operate in ONLY mode. - find_file: All search paths set to BOTH mode since that's the default behavior. - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Mon Oct 13 12:43:02 2014 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 13 Oct 2014 18:43:02 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl> Message-ID: Adam Strzelecki wrote: >> Picking a message randomly, to respond to - Can someone tell me what this >> comment is referring to? >> >> # FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly >> # Qt5 Mac support is missing there. > > AFAIR it is about installing correct app bundle PlugIns. Qt provides > half-baked CMake support, but some of necessary things still has to be > done by user manually, such as installing cocoa platform plugin. If you can be more specific or explain why the Qt5 CMake files should install a plugin for you, or whatever it should should do, feel free to file bug reports or patches. Thanks, Steve. From brad.king at kitware.com Mon Oct 13 13:31:54 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Oct 2014 13:31:54 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl> References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl> Message-ID: <543C0C8A.8010509@kitware.com> On 10/13/2014 05:54 AM, Adam Strzelecki wrote: > Qt provides half-baked CMake support Side note: this is not a fair characterization of Qt's support for CMake. Qt5 is an outstanding example of how an upstream can make it easy to use a project with CMake even when the upstream itself does not use CMake. Qt5 provides package configuration files for find_package(), and once loaded they provide imported targets with usage requirements. Building a CMake-based project against Qt5 couldn't be much easier IMO. Furthermore, all the CMake-related files come with Qt5 and are maintained there rather than in CMake. This is much easier than Qt4, where FindQt4 in CMake has needed maintenance with every new upstream version. -Brad From micha.hergarden at gmail.com Mon Oct 13 13:36:21 2014 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Mon, 13 Oct 2014 19:36:21 +0200 Subject: [cmake-developers] [CPack] Call for volunteer for CPackRPM, CPackDeb maintenance. In-Reply-To: References: Message-ID: <543C0D95.9090109@gmail.com> On 10/09/2014 04:58 PM, Eric Noulard wrote: > Hi everybody, > > This message is an open request to find volunteer maintainers for > CPackRPM and CPackDeb > which were my main contributions to CPack (CPackDeb was initially > contributed by Mathieu). > > I have 21 Mantis tickets (http://public.kitware.com/Bug) assigned to > me I will soon > unassign them or "transfer" them to volunteering people. > > I did contribute to CMake/CPack for some time (~2007) now but my > "CMake free time" > is now too small to be able to test and integrate contribution/patches > to CPackDeb and > CPackRPM. > > I will be listening to the mailing lists as usual but one shall not > count on a timely responsiveness > from me. I shall say that this is not a lack of interest but a clear > lack of time. > I do continue to use CMake/CPack/CTest on a daily basis but cannot > find enough time > to contribute anymore. > > I'll try my best to help the volunteer(s) to take over. People > interested may answer here > and/or send me direct e-mail if they find it necessary. > > I shall say that the CMake developer community including Kitware > people (off course) > were (and are) very helpful and always kind to handle my cmake/cpack > contribution. > > > -- > Erk > L'?lection n'est pas la d?mocratie -- http://www.le-message.org > > Hello list, With this mail I would like to help out maintaining these modules. I have been reading this list for a while, and been a happy CMake user for several years now. It has saved me a lot of time, so I deceided it was time I contributed some of it back. With kind regards, Micha Hergarden -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From brad.king at kitware.com Mon Oct 13 14:00:56 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Oct 2014 14:00:56 -0400 Subject: [cmake-developers] [CPack] Call for volunteer for CPackRPM, CPackDeb maintenance. In-Reply-To: <543C0D95.9090109@gmail.com> References: <543C0D95.9090109@gmail.com> Message-ID: <543C1358.8090502@kitware.com> On 10/13/2014 01:36 PM, Micha Hergarden wrote: > With this mail I would like to help out maintaining these modules. Wonderful, thanks! To others: this does not close the call. We can have more than one maintainer with overlapping responsibilities. Micha, please start by taking a look at the proposal here: [PATCH] Preinstall requirements support for CPack RPM generator http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11235/focus=11253 and the corresponding issue tracker entry: CPackRPM: need CPACK_RPM__PACKAGE_
_REQUIRES
 http://www.cmake.org/Bug/view.php?id=14769

Thanks,
-Brad



From raffi.enficiaud at free.fr  Mon Oct 13 14:23:27 2014
From: raffi.enficiaud at free.fr (Raffi Enficiaud)
Date: Mon, 13 Oct 2014 20:23:27 +0200
Subject: [cmake-developers] Introduction and volunteering for the Matlab
	package
Message-ID: 

Hi Brad,

(Sorry for the late answer (again).)
I addressed your comments in the files attached to this email (please see the remarks below). I have not yet addressed your comment about ?MATLAB_ADDITIONAL_VERSIONS? but I think it is a better proposition, so I will do it next.
I updated the documentation also, I think it looks now understandable.

I had a hard time making some stuff compile again with Matlab under Linux. The fact is that Matlab is shipped with its own version of libC, libhdf5, libboost etc, and sometimes the filenames are the same (eg. hdf5, or libc) but the subminor versions are not. If I understand properly, the fact that the filenames are the same prevents the dynamic loader of Linux to load the files that are referred by the mex file in their respective rpath (there is only one libhdf51.8.2.so in the matlab process). Beside that, the symbols also may clash: I had an implementation with a dynamic loader under linux, but yet the boost symbols of my mex files were not loaded because same symbols were already there in the process. 
I found a technical solution to this on Linux: 
- the use of -Wl,--exclude-libs,ALL for the linker. 
- the symbol hiding (both include and function definition) from within the mex file
- exporting only the mexFunction symbol

I know that this scheme is working for statically linked libraries, that then should be recompiled with -fPIC. I know also that this is working for shared libraries that do not have the same name (eg. boost1.49.so vs. boost1.55.so). But I think there is nothing more I can do for the shared library having the same name (like hdf51.8.2.so), having the same symbols but apparently having a different ABI.

I do not know how to do that properly under OSX neither. There is no -Wl,--exclude-libs,ALL option in Clang.

Also, I am checking against CMAKE_CXX_COMPILER_ID, which is I think a not so good idea. Is there anything for having the -Wl,--exclude-libs,ALL like the variable CXX_VISIBILITY_PRESET in cmake? I started using a .map file on these two platforms, but also I would prefer limiting the number of files. 

I am using this FindMatlab in two projects now, under OSX 10.9, Win7 Visual2013 and Ubuntu12.04. 

Best,
Raffi




??????

> Hi Raffi,
> 
> Thanks for your continuing work on this module.
> 
> I've made some whitespace and quoting tweaks to the files.  See attached
> updated versions.  I also renamed the test helper to not start in "Find"
> since no one should call find_package(Matlab_TestsRedirect).  See further
> comments below.
> 
> On 07/04/2014 08:02 PM, Raffi Enficiaud wrote:
>>> Many of our tests use "cmake -P" to run a cmake script that performs
>>> the test inside.  You can use -Dvar=${val} before the -P option to
>>> pass options to the script, such as $.
>> 
>> Done: this is the add_matlab_unit_test function. In fact, I think I can
>> remove the log files since they are redundant with the tests logs.
> 
> I see no problem with that, but I'm not familiar with the tools.
> 
>> I added a function add_matlab_mex that is like a add_library
> 
> Please make all APIs start in "matlab_?.

Done

> 
> The documentation blocks for each command also need to start in "#.rst:"
> 
> #.rst:
> # .. command:: add_matlab_mex
> 
> or they will not be included in the processed documentation.

Ok. I checked the documentation again, and I think it contains now all the necessary information, plus it is now visually more appealing. 


> 
>> for creating MEX (compiled) extensions. There is an option to this
>> function called REDUCE_VISIBILITY
> 
> I see that implemented here:
> 
>> if(HAS_VISIBILITY_INLINE_HIDDEN)
>>  target_compile_options(${${prefix}_NAME} PRIVATE "-fvisibility-inlines-hidden")
>> endif()
>> if(HAS_VISIBILITY_HIDDEN)
>>  target_compile_options(${${prefix}_NAME} PRIVATE "-fvisibility=hidden")
>> endif()
> 
> An upstream version of the module should use the builtin features
> for visibility settings:
> 
> 
> http://www.cmake.org/cmake/help/v3.0/prop_tgt/LANG_VISIBILITY_PRESET.html
> 
> 
> http://www.cmake.org/cmake/help/v3.0/prop_tgt/VISIBILITY_INLINES_HIDDEN.html

I am not sure how to do that, please have a look at my changes. It looks ok to me (generated compilation command include the visibility element) but maybe there is something better.



> 
> 
>> #    set(MATLAB_ADDITIONAL_VERSIONS
>> #       "release_name1" "corresponding_version1"
>> #       "release_name2" "corresponding_version2"
>> #       ...
>> #       )
> 
> Rather than relying on matched pairs, perhaps use "=" to separate:
> 
> #    set(MATLAB_ADDITIONAL_VERSIONS
> #       "release_name1=corresponding_version1"
> #       "release_name2=corresponding_version2"
> 
> ?

Right, it is better.


> 
>> I am not sure how my implementation is compatible with the previous
>> FindMatlab package. The requirements are to define the same variables,
>> right? Is there anything else?
> 
> It needs to produce the same result variables and also respond to
> the old "input" variables (like find_ command cached results) that
> the old module did.  That way existing build scripts can continue
> to work.

This is something I should now check deeper. Is it an option to call it FindMatlab2 ?



> 
>> +# * ``MATLAB_USER_ROOT`` the root of the Matlab installation. This is given by the user.
> 
> This should be documented in its own section of variables that the
> user can set to control the search.  See FindZLIB for example.
> 
>> +  # list the keys under HKEY_LOCAL_MACHINE\SOFTWARE\mathworks but the call to reg does not work
>> +  # from cmake, curiously, as is. The command provides the desired result under the command line though.
>> +  # Fix: this is because "/reg:64" should appended to the command, otherwise it gets on the 32 bits software
> key (curiously again)
> 
> This is because it gets the registry view of the calling CMake
> unless you tell it what view to use.

Ok

> 
>> +  find_program(MATLAB_REG_EXE_LOCATION "reg")
>> +  file(TO_NATIVE_PATH ${MATLAB_REG_EXE_LOCATION} MATLAB_REG_EXE_LOCATION)
> 
> The second line should not be needed.  The execute_process command
> will take care of the path format.

Done

> 
>> +  if((NOT DEFINED MATLAB_USER_ROOT) OR (NOT MATLAB_USER_ROOT))
> 
> This can be shortened to
> 
> if(NOT MATLAB_USER_ROOT)

Done

> 
>> +    if(NOT ${Matlab_PROGRAM})
> 
> and this to
> 
> if(NOT Matlab_PROGRAM)

Done

> 
>> BTW, is there any variable that tells the current cmake list,
>> even in function in packages?
> 
> In the attached version I added
> 
> set(_FindMatlab_SELF_DIR "${CMAKE_CURRENT_LIST_DIR}")
> 
> to the top of the file to save the location of the file for re-use
> inside function calls later.

Good. 

> 
> Thanks,
> -Brad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FindMatlab.cmake
Type: application/octet-stream
Size: 42524 bytes
Desc: not available
URL: 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MatlabTestsRedirect.cmake
Type: application/octet-stream
Size: 2039 bytes
Desc: not available
URL: 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From domen.vrankar at gmail.com  Mon Oct 13 15:51:08 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Mon, 13 Oct 2014 21:51:08 +0200
Subject: [cmake-developers] [CPack] Call for volunteer for CPackRPM,
 CPackDeb maintenance.
In-Reply-To: <543C1358.8090502@kitware.com>
References: 
 <543C0D95.9090109@gmail.com> <543C1358.8090502@kitware.com>
Message-ID: 

Hello,

I have been talking with Eric for the past few days now and would also like
to help out with maintaining these two modules.
I am a CMake user for about six years now and have also been using CPackRPM
but for now I haven no experience with CPackDeb.

As suggested by Eric I'll start with issue tracker:
http://public.kitware.com/Bug/view.php?id=13176

Regards,
Domen

2014-10-13 20:00 GMT+02:00 Brad King :

> On 10/13/2014 01:36 PM, Micha Hergarden wrote:
> > With this mail I would like to help out maintaining these modules.
>
> Wonderful, thanks!
>
> To others: this does not close the call.  We can have more than
> one maintainer with overlapping responsibilities.
>
> Micha, please start by taking a look at the proposal here:
>
>  [PATCH] Preinstall requirements support for CPack RPM generator
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11235/focus=11253
>
> and the corresponding issue tracker entry:
>
>  CPackRPM: need CPACK_RPM__PACKAGE_
_REQUIRES
>  http://www.cmake.org/Bug/view.php?id=14769
>
> Thanks,
> -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 brad.king at kitware.com  Mon Oct 13 15:57:07 2014
From: brad.king at kitware.com (Brad King)
Date: Mon, 13 Oct 2014 15:57:07 -0400
Subject: [cmake-developers] [CPack] Call for volunteer for CPackRPM,
 CPackDeb maintenance.
In-Reply-To: 
References: 	<543C0D95.9090109@gmail.com>	<543C1358.8090502@kitware.com>
 
Message-ID: <543C2E93.6060205@kitware.com>

On 10/13/2014 03:51 PM, Domen Vrankar wrote:
> would also like to help out with maintaining these two modules.

Thanks for volunteering too!

> As suggested by Eric I'll start with issue tracker:
> http://public.kitware.com/Bug/view.php?id=13176

Sounds good!

Thanks,
-Brad



From ono at java.pl  Mon Oct 13 16:04:41 2014
From: ono at java.pl (Adam Strzelecki)
Date: Mon, 13 Oct 2014 22:04:41 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <543C0C8A.8010509@kitware.com>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
  <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl>
 <543C0C8A.8010509@kitware.com>
Message-ID: 

> Side note: this is not a fair characterization of Qt's support for CMake.
> (?)
> Furthermore, all the CMake-related files come with Qt5 and are maintained
> there rather than in CMake.  This is much easier than Qt4, where FindQt4
> in CMake has needed maintenance with every new upstream version.

Of course it is great that THEY provide official CMake support. Maybe "half-baked" is a bit harsh, but everything goes smooth until you try to run your freshly compiled Qt5 app in on the any other machine that the one it was compiled on.

First you realize you miss some Qt libraries you were linking to. Fine, fixup_bundle should do the job, but it doesn't.

----
$ hello.app/Contents/MacOS/hello 
This application failed to start because it could not find or load the Qt platform plugin "cocoa".

Available platform plugins are: cocoa, minimal, offscreen.

Reinstalling the application may fix this problem.
----

The message isn't really helpful.

Finally after seeking googling for an answer you find out that there are "platform plugins" and there is no function or module that will help you to bundle them and create proper qt.conf. So all apps that are willing to use Qt5 (not Qt4 legacy version) need to have that manually.

This is why I call it half-baked.

But to be fair, Qt team is really welcoming and open for improvements, I am sure complete support will arrive sooner or later.

FYI I was working hard on relocatable Qt SDK for OSX for a while, it is almost complete. We were to release it for 5.4 but due some fancy testing suite problems probably this will be delayed. This was one of the reasons of my rpath support here. Otherwise once Qt SDK uses rpath it will immediately break CMake compatibility.

--Adam

From steveire at gmail.com  Mon Oct 13 17:11:12 2014
From: steveire at gmail.com (Stephen Kelly)
Date: Mon, 13 Oct 2014 23:11:12 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
  <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl>
 <543C0C8A.8010509@kitware.com> 
Message-ID: 

Adam Strzelecki wrote:

> But to be fair, Qt team is really welcoming and open for improvements, I
> am sure complete support will arrive sooner or later.
> 

As the person who wrote what Qt ships, I can say that it won't be 'complete' 
sooner or later unless someone with enough interest communicates/contributes 
what is missing. I don't have the requisite mac experience.

I also think there might be a generic solution (or partial solution) to 
implement in CMake first (an interface for determining the package 
dependencies perhaps, etc).

What makes this a Qt issue instead of a generic issue?

Thanks,

Steve.




From domen.vrankar at gmail.com  Mon Oct 13 18:17:15 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 14 Oct 2014 00:17:15 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176 CPackRPM
 support for per-component summary and description
Message-ID: 

Hi,

I extended the proposed patch for ticket 13176 with:
- documentation section
- CPACK_RPM__PACKAGE_DESCRIPTION fallback to
CPACK_COMPONENT__DESCRIPTION
- handling of cases when one component sets its variable and the other
doesn't


Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From domen.vrankar at gmail.com  Mon Oct 13 18:23:55 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 14 Oct 2014 00:23:55 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 
Message-ID: 

Message was sent to early by accident so I'm resending the rest.

2014-10-14 0:17 GMT+02:00 Domen Vrankar :

> Hi,
>
> I extended the proposed patch for ticket 13176 with:
> - documentation section
> - CPACK_RPM__PACKAGE_DESCRIPTION fallback to
> CPACK_COMPONENT__DESCRIPTION
> - handling of cases when one component sets its variable and the other
> doesn't
>

e.g.
#set(CPACK_RPM_test_PACKAGE_SUMMARY "test_summary")
set(CPACK_RPM_bin_PACKAGE_SUMMARY "bin_summary")

Could somebody please review the patch attached to this mail?


>
> Regards,
> Domen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CPackRPM_component_summary_description.patch
Type: text/x-diff
Size: 5245 bytes
Desc: not available
URL: 

From mantis at public.kitware.com  Tue Oct 14 02:08:27 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 14 Oct 2014 02:08:27 -0400
Subject: [cmake-developers] [CMake 0015205]: support for osx resource
	toolchain
Message-ID: <5753f570c86d52e36f72b4e6128854dc@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15205 
====================================================================== 
Reported By:                tim blechmann
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15205
Category:                   CMake
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-14 02:08 EDT
Last Modified:              2014-10-14 02:08 EDT
====================================================================== 
Summary:                    support for osx resource toolchain
Description: 
CMake supports windows resource files (.rc) out of the box. OSX has a similar
concept, .r files which compile resource forks of a file.

the toolchain includes Rez (to compile a resource) and ResMerger (to merge
different resources into one file).

xcode supports this toolchain natively, but when using cmake, one has to set up
the toolchain manually via POST_BUILD custom commands, which does not scale
well. so it would be great if cmake would support this natively.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-14 02:08 tim blechmann  New Issue                                    
======================================================================



From mantis at public.kitware.com  Tue Oct 14 02:28:20 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 14 Oct 2014 02:28:20 -0400
Subject: [cmake-developers] [CMake 0015206]: add_jar() in UseJava.cmake uses
	wrong classpath seperator when cross-compiling under Windows
Message-ID: <117c88e6fc2ed7e5ecf29519449c0715@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15206 
====================================================================== 
Reported By:                Lorenz Witte
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15206
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-14 02:28 EDT
Last Modified:              2014-10-14 02:28 EDT
====================================================================== 
Summary:                    add_jar() in UseJava.cmake uses wrong classpath
seperator when cross-compiling under Windows
Description: 
The condition to use ";" as classpath separator includes a check for the switch
"WIN32" which is a target switch. When cross-compiling for a non-windows target,
this switch is not present and the separator defaults to ":".

I think it should rather check for "CMAKE_HOST_WIN32" instead.

Steps to Reproduce: 
Call add_jar() during a cross-compilation on a Windows host.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-14 02:28 Lorenz Witte   New Issue                                    
2014-10-14 02:28 Lorenz Witte   File Added:
0001-fixed-classpath-separator-on-WIN32-cross-compilation.patch                 
  
======================================================================



From domen.vrankar at gmail.com  Tue Oct 14 03:03:01 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 14 Oct 2014 09:03:01 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 
 
Message-ID: 

Sorry for spamming...

I noticed that the previous patch would break user provided rpm spec files
so I'm attaching a new patch that fixes that problem with a bit more
variable juggling.

I also have a question. Would CPack also need something like
CPACK_COMPONENT__PACKAGE_SUMMARY that could be used by
CPACK_RPM__PACKAGE_SUMMARY as default value?

Thanks,
Domen


2014-10-14 0:23 GMT+02:00 Domen Vrankar :

> Message was sent to early by accident so I'm resending the rest.
>
> 2014-10-14 0:17 GMT+02:00 Domen Vrankar :
>
>> Hi,
>>
>> I extended the proposed patch for ticket 13176 with:
>> - documentation section
>> - CPACK_RPM__PACKAGE_DESCRIPTION fallback to
>> CPACK_COMPONENT__DESCRIPTION
>> - handling of cases when one component sets its variable and the other
>> doesn't
>>
>
> e.g.
> #set(CPACK_RPM_test_PACKAGE_SUMMARY "test_summary")
> set(CPACK_RPM_bin_PACKAGE_SUMMARY "bin_summary")
>
> Could somebody please review the patch attached to this mail?
>
>
>>
>> Regards,
>> Domen
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-CPackRPM-component-based-packaging-description-and-s.patch
Type: text/x-diff
Size: 5040 bytes
Desc: not available
URL: 

From eric.noulard at gmail.com  Tue Oct 14 03:28:18 2014
From: eric.noulard at gmail.com (Eric Noulard)
Date: Tue, 14 Oct 2014 09:28:18 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 
 
 
Message-ID: 

2014-10-14 9:03 GMT+02:00 Domen Vrankar :

> Sorry for spamming...
>
> I noticed that the previous patch would break user provided rpm spec files
> so I'm attaching a new patch that fixes that problem with a bit more
> variable juggling.
>


Hi Domen,

I did re-assign the bug entry to you
http://public.kitware.com/Bug/view.php?id=13176

Then we discussing various patches I suggest you to attach the patch
directly to the tracker
that way it's easy to see the patch history and if ever some patch version
is obsolete you may simply remove it from the tracker.


>
> I also have a question. Would CPack also need something like
> CPACK_COMPONENT__PACKAGE_SUMMARY that could be used by
> CPACK_RPM__PACKAGE_SUMMARY as default value?
>


Not sure of that one.
We already have "CPACK_COMPONENT_GROUP_CMAKE_DESCRIPTION"
which may be a default value for "CPACK_RPM__PACKAGE_
SUMMARY" if packaging is done "by compoent group" (which is the default):

The behavior of the various CPack generator w.r.t. mono- or multi-
file/package generation vary,
see:
http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior

e.g. for NSIS or PackageMaker I don't know what you can do with
"CPACK_COMPONENT__
PACKAGE_SUMMARY" because there is only one package.

Otherwise I only read the patch and it looks good.

However you should at least:
  1) run ctest -R CPack  --> this the "minimal" way to run CPack related
tests in the CMake tree
  2) enhance or provide a specific test for the new behavior.


 Eric

>
> Thanks,
> Domen
>
>
> 2014-10-14 0:23 GMT+02:00 Domen Vrankar :
>
>> Message was sent to early by accident so I'm resending the rest.
>>
>> 2014-10-14 0:17 GMT+02:00 Domen Vrankar :
>>
>>> Hi,
>>>
>>> I extended the proposed patch for ticket 13176 with:
>>> - documentation section
>>> - CPACK_RPM__PACKAGE_DESCRIPTION fallback to
>>> CPACK_COMPONENT__DESCRIPTION
>>> - handling of cases when one component sets its variable and the other
>>> doesn't
>>>
>>
>> e.g.
>> #set(CPACK_RPM_test_PACKAGE_SUMMARY "test_summary")
>> set(CPACK_RPM_bin_PACKAGE_SUMMARY "bin_summary")
>>
>> Could somebody please review the patch attached to this mail?
>>
>>
>>>
>>> Regards,
>>> Domen
>>>
>>
>>
>
> --
>
> 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
>



-- 
Erk
L'?lection n'est pas la d?mocratie -- http://www.le-message.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From domen.vrankar at gmail.com  Tue Oct 14 03:59:11 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 14 Oct 2014 09:59:11 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 
 
 
 
Message-ID: 

2014-10-14 9:28 GMT+02:00 Eric Noulard :

>
>
> 2014-10-14 9:03 GMT+02:00 Domen Vrankar :
>
>> Sorry for spamming...
>>
>> I noticed that the previous patch would break user provided rpm spec
>> files so I'm attaching a new patch that fixes that problem with a bit more
>> variable juggling.
>>
>
>
> Hi Domen,
>
> I did re-assign the bug entry to you
> http://public.kitware.com/Bug/view.php?id=13176
>

Noticed that. Thanks. I did not notice that I can reassign bugs myself.


>
> Then we discussing various patches I suggest you to attach the patch
> directly to the tracker
> that way it's easy to see the patch history and if ever some patch version
> is obsolete you may simply remove it from the tracker.
>
>

Done.


>
>> I also have a question. Would CPack also need something like
>> CPACK_COMPONENT__PACKAGE_SUMMARY that could be used by
>> CPACK_RPM__PACKAGE_SUMMARY as default value?
>>
>
>
> Not sure of that one.
> We already have "CPACK_COMPONENT_GROUP_CMAKE_DESCRIPTION"
> which may be a default value for "CPACK_RPM__PACKAGE_
> SUMMARY" if packaging is done "by compoent group" (which is the default):
>
> The behavior of the various CPack generator w.r.t. mono- or multi-
> file/package generation vary,
> see:
>
> http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior
>
>
I'll read it in the afternoon.


> e.g. for NSIS or PackageMaker I don't know what you can do with
> "CPACK_COMPONENT__
> PACKAGE_SUMMARY" because there is only one package.
>
> Otherwise I only read the patch and it looks good.
>

> However you should at least:
>   1) run ctest -R CPack  --> this the "minimal" way to run CPack related
> tests in the CMake tree
>

Forgot to run the tests the first time but remembered afterwards.


>   2) enhance or provide a specific test for the new behavior.
>
>
Will do this in the afternoon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ono at java.pl  Tue Oct 14 05:32:50 2014
From: ono at java.pl (Adam Strzelecki)
Date: Tue, 14 Oct 2014 11:32:50 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: 
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
  <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl>
 <543C0C8A.8010509@kitware.com> 
 
Message-ID: <29F6DD1A-D501-4CC3-AD77-3032BB454C45@java.pl>

> As the person who wrote what Qt ships, I can say that it won't be 'complete' 
> sooner or later unless someone with enough interest communicates/contributes 
> what is missing. I don't have the requisite mac experience.

Sure, I believe someone will sooner or later submit patches to Qt.

> I also think there might be a generic solution (or partial solution) to 
> implement in CMake first (an interface for determining the package 
> dependencies perhaps, etc).

CMake has everything necessary there install(...) & fixup_bundle(...).

> What makes this a Qt issue instead of a generic issue?

$ git show 9b98fd52

install_qt5_plugin writing qt.conf and launching fixup_bundle should be part of Qt5 CMake support not part of app specific CMakeLists.txt (in this case CMake.app), e.g. single function install_qt5_bundle that does it all, selects default platform plugins and it is clearly documented somewhere.

Also on Qt SDK side there are couple of things to be done: QTBUG-14150 QTBUG-31814

--Adam

From brad.king at kitware.com  Tue Oct 14 09:48:14 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 14 Oct 2014 09:48:14 -0400
Subject: [cmake-developers] Preparing for CMake 3.1.0-rc1
In-Reply-To: <542E964C.1050104@kitware.com>
References: <542E964C.1050104@kitware.com>
Message-ID: <543D299E.6050201@kitware.com>

On 10/03/2014 08:27 AM, Brad King wrote:
> please refrain from adding non-trivial changes in the meantime.

I've branched 'release' for 3.1.  The repository is now open for
post-3.1 development.  Please rebase any open topics on 'master'
before merging to 'next'.

Thanks,
-Brad



From brad.king at kitware.com  Tue Oct 14 09:57:16 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 14 Oct 2014 09:57:16 -0400
Subject: [cmake-developers] Initial Attempt at Green Hill MULTI IDE
 Generator Support
In-Reply-To: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com>
References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com>
Message-ID: <543D2BBC.1010306@kitware.com>

On 10/09/2014 07:36 PM, Geoffrey Viola wrote:
> Attached is a patch to make CMake generate files for the Green
> Hills MULTI IDE. These patches are in reference to this feature
> request: http://public.kitware.com/Bug/view.php?id=14992.

Thanks for working on this.

First I've extracted the comment typo fixes from the second patch:

 Fix some spelling errors in comments
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bef23e81

I've attached a patch rebasing the rest of the changes on 'master'
after integration of the typo fixes.

To aid others for review, please provide a high-level explanation
of the MULTI IDE, its target platforms, and how developers might
use it with CMake.

> There were some limitations. It has been restricted to Windows,
> because that is the version of the IDE that I have. There is a
> special grouping called a Monolith that includes several
> executables, shared libraries, and the kernel. These monoliths
> have their own set of compile options. I?m not sure how CMake
> would be able to create these. Also, there are some internal
> macros that point to the compiler?s target BSP and OS that are
> currently populated via CMake variables: GHS_CUSTOMIZATION,
> GHS_OS_DIR, and GHS_BSP_NAME.

Depending on the semantics, these may belong in
Modules/Platform/.cmake for some  name of the target
platform.  We'll need a better understanding of their role to
say for sure though.  See CMAKE_OSX_SYSROOT in Darwin*.cmake
for example.

Thanks,
-Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Added-basic-and-partial-support-for-a-Green-Hill-MUL.patch
Type: text/x-diff
Size: 37840 bytes
Desc: not available
URL: 

From brad.king at kitware.com  Tue Oct 14 10:04:54 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 14 Oct 2014 10:04:54 -0400
Subject: [cmake-developers] [CMake] Forcing colorization of output from
	cmake
In-Reply-To: <1412876289.29340.133.camel@mad-scientist.net>
References: <1367417913.4101.127.camel@pdsdesk>		
 <1412784946.29340.123.camel@mad-scientist.net>		
 <54356C78.7060501@kitware.com>	
 <1412793361.29340.127.camel@mad-scientist.net>	
 <543693E2.5090901@kitware.com> <1412876289.29340.133.camel@mad-scientist.net>
Message-ID: <543D2D86.3060801@kitware.com>

On 10/09/2014 01:38 PM, Paul Smith wrote:
> What I really want is that if MAKE_TERMOUT is set to a non-empty value,
> cmake should pretend that it's in a terminal regardless of what isatty()
> says.  We can do this easily enough by adding a simple test to
> Terminal.c:kwsysTerminalStreamIsVT100() _without_ adding any code
> anywhere else:

One problem with this is that non-make processes launched by make may
run their own children to capture the output through pipes and not
unset MAKE_TERMOUT.  We need it to be 'make' that evaluates that env
variable.  Your original command-line approach did this.

> In a way this is gross, certainly, but this function already checks for
> environment variable such as TERM, EMACS, etc. which are set by calling
> utilities and handles them specially.  So why not MAKE_TERMOUT as well?

The TERM and EMACS variables are checked to determine whether the
terminal supports color when isatty() returns true.  That is not
the same as forcing tty behavior.

> I would expect FORCE to be stronger than that, and return
> true regardless of TERM settings.

Okay, but the internal API in KWSys Terminal needs to be more granular
than that.  Please revise your patch to use my KWSys part but also
add a ForceVT100 setting that causes TERM and EMACS to be ignored.
Then the --switch=FORCE can set both the ForceTTY and ForceVT100
setting internally.

> I'm not at all familiar with Windows so I have no strong opinions on
> whether FORCE should also force color output on a Windows console...
> although I know a number of people who do use GNU make on Windows and
> the Windows port of GNU make does set MAKE_TERMOUT properly.

Native Windows terminals do not support the color escape sequences
at all.  We need to get a handle to the underlying console buffer and
set parameters on it directly.  If the output pipe is not connected
to a real console then we cannot get the console handle and print
color at all.

>> We already have a CMAKE_COLOR_MAKEFILE option.  Perhaps instead
>> of just ON or OFF values it could have a GNU value that enables
> 
> Well, it's easy enough to detect if CMAKE_MAKE_PROGRAM is GNU make, if
> we can run it to test the output of "${CMAKE_MAKE_PROGRAM} --version".
> 
> The question is, what do you do in the generated makefile if you see
> that it's GNU make?

The CMake generator would recognize CMAKE_COLOR_MAKEFILE==GNU and
enable the GNU-specific content.  CMAKE_COLOR_MAKEFILE is a cache
setting the user could set if they don't like the default.  We can
set the default based on whether the CMAKE_MAKE_PROGRAM is GNU.

> It would need to be the equivalent of:
> 
>    --switch=$(or $(COLOR),$(if $(MAKE_TERMOUT),FORCE))
> 
> to preserve the current behavior, where the COLOR variable setting can
> be inherited from the environment.

Yes.

> What if someone runs cmake and it detects GNU make, but then they run
> "/my/other/make" which is not GNU make?  That would work fine now but
> fail if we generated GNU-specific content in 'Unix Makefiles'
> generators.

The user could always set CMAKE_COLOR_MAKEFILE to ON instead of GNU
to work with other make tools.

> If we had a different generator, like 'GNU Makefiles' for example, then
> people who chose that would clearly expect the results would only work
> with GNU make, but we don't have that.

One day we may create a 'GNU Makefiles' generator to enable use of
GNU-specific features, but that would need to be a more comprehensive
effort than just changing the color option.

Thanks,
-Brad



From mantis at public.kitware.com  Tue Oct 14 10:31:32 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 14 Oct 2014 10:31:32 -0400
Subject: [cmake-developers] [CMake 0015207]: FindJNI does not work when
	compiling 32-bit target on 64-bit host
Message-ID: <752725d05636fb5cc34874da9bddec26@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15207 
====================================================================== 
Reported By:                Stepan Schejbal
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15207
Category:                   Modules
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-14 10:31 EDT
Last Modified:              2014-10-14 10:31 EDT
====================================================================== 
Summary:                    FindJNI does not work when compiling 32-bit target
on 64-bit host
Description: 
When compiling 32-bit linux target using "-m32", FindJNI breaks, because it is
based on CMAKE_SYSTEM_PROCESSOR which does not match the target architecture.
This is related to issue http://public.kitware.com/Bug/view.php?id=9611.

Steps to Reproduce: 
find_package(JNI REQUIRED)

export CC=gcc-4.8
export CXX=g++-4.8
export JAVA_HOME=/opt/jdk1.7.0_55-i586
export CFLAGS=-m32
export CXXFLAGS=-m32
export LDFALGS=-m32
cmake...
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-14 10:31 Stepan SchejbalNew Issue                                    
======================================================================



From steveire at gmail.com  Tue Oct 14 12:19:24 2014
From: steveire at gmail.com (Stephen Kelly)
Date: Tue, 14 Oct 2014 18:19:24 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
  <2F4A0CDE-DDC5-47A1-B31A-92A29F5F8DDD@java.pl>
 <543C0C8A.8010509@kitware.com> 
  <29F6DD1A-D501-4CC3-AD77-3032BB454C45@java.pl>
Message-ID: 

Adam Strzelecki wrote:

>> What makes this a Qt issue instead of a generic issue?
> 
> $ git show 9b98fd52

[Ignoring the qt.conf part]

Again, what is Qt-specific about bundling a plugin with an application? What 
is non-generic about that?

Why can't CMake targets communicate what needs to be bundled with them? Why 
can't some CMake interface consume such information? 

Why would a install_qt5_bundle function bundle only the platform plugin, but 
not other plugins?

Thanks,

Steve.




From Geoffrey.Viola at asirobots.com  Tue Oct 14 12:48:09 2014
From: Geoffrey.Viola at asirobots.com (Geoffrey Viola)
Date: Tue, 14 Oct 2014 16:48:09 +0000
Subject: [cmake-developers] Initial Attempt at Green Hill MULTI IDE
 Generator Support
In-Reply-To: <543D2BBC.1010306@kitware.com>
References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com>
 <543D2BBC.1010306@kitware.com>
Message-ID: <0b5b33c4d1f0472782e260f9e5bce980@CO1PR07MB208.namprd07.prod.outlook.com>

Green Hills MULTI is an IDE for embedded real-time systems. It features an editor, a great debugger, and a GUI to organize and visual memory layouts: http://www.ghs.com/products/MULTI_IDE.html. There is a Linux and Windows version of it. Green Hill's real-time operating system, INTEGRITY, supports ARM, Intel x86, and other architectures: http://www.ghs.com/products/rtos/integrity.html.

It is advantageous to use CMake for its script based target management functionality, which is very useful to manage unit tests, and 3rd party finding mechanisms. Switching between IDEs is advantageous because other IDEs have better editors and built-in support to run unit tests. Also, embedded code could be ported to ease debugging without extra hardware.

I took a look at CMAKE_OSX_SYSROOT. It is similar to GHS_OS_DIR. There may be a simpler way to represent these customizations, but I don't know if there are any guarantees on standard folder structures or names.

The current patch is being used to create all the main targets and a default top level file. That generated top level file is hand edited to include custom hand edited kernel and monolith files. It is my intention to generate everything via CMake. It seems there needs to be some development to use the find boost module, because "CMAKE_FIND_LIBRARY_PREFIXES" is not set.


Geoffrey Viola
SOFTWARE ENGINEER
T

+1.435.755.2980

ext 1077
M

+1.215.896.6521


asirobots.com




-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com]
Sent: Tuesday, October 14, 2014 7:57 AM
To: Geoffrey Viola
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support

On 10/09/2014 07:36 PM, Geoffrey Viola wrote:
> Attached is a patch to make CMake generate files for the Green Hills
> MULTI IDE. These patches are in reference to this feature
> request: http://public.kitware.com/Bug/view.php?id=14992.

Thanks for working on this.

First I've extracted the comment typo fixes from the second patch:

 Fix some spelling errors in comments
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bef23e81

I've attached a patch rebasing the rest of the changes on 'master'
after integration of the typo fixes.

To aid others for review, please provide a high-level explanation of the MULTI IDE, its target platforms, and how developers might use it with CMake.

> There were some limitations. It has been restricted to Windows,
> because that is the version of the IDE that I have. There is a special
> grouping called a Monolith that includes several executables, shared
> libraries, and the kernel. These monoliths have their own set of
> compile options. I'm not sure how CMake would be able to create these.
> Also, there are some internal macros that point to the compiler's
> target BSP and OS that are currently populated via CMake variables:
> GHS_CUSTOMIZATION, GHS_OS_DIR, and GHS_BSP_NAME.

Depending on the semantics, these may belong in Modules/Platform/.cmake for some  name of the target platform.  We'll need a better understanding of their role to say for sure though.  See CMAKE_OSX_SYSROOT in Darwin*.cmake for example.

Thanks,
-Brad
This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.


From ben.boeckel at kitware.com  Tue Oct 14 16:42:18 2014
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 14 Oct 2014 16:42:18 -0400
Subject: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake
 re-run if possible
In-Reply-To: <542EE420.7010406@gmail.com>
References: <542DC4EF.2000400@gmail.com> 
 <542E9D0B.1080806@kitware.com> 
 <542EE420.7010406@gmail.com>
Message-ID: <20141014204218.GA29097@megas.kitwarein.com>

On Fri, Oct 03, 2014 at 20:00:00 +0200, Sylvain Joubert wrote:
> Unlike the rerun target which is manually added by the Ninja generator,
> the install and package targets are handled in a generic way by the 
> utility target generator.
> 
> Thus, handling these targets is not as straightforward as rerun.
> I'll keep digging a bit, maybe I can find a way to do it. ;-)

It should be possible to set a property on the target(s) when they are
created. Though?looking at the docs, it seems that there's no generic
JOB_POOL property for custom targets. When that property is implemented,
setting 'console' for these targets for Ninja should be simple enough.

--Ben


From aleixpol at kde.org  Tue Oct 14 19:46:48 2014
From: aleixpol at kde.org (Aleix Pol)
Date: Wed, 15 Oct 2014 01:46:48 +0200
Subject: [cmake-developers] Extracting target metadata, IDE integration
In-Reply-To: <6761034.LHuUtODnIM@eto>
References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com>
 
 <542D4879.20204@kitware.com> <6761034.LHuUtODnIM@eto>
Message-ID: 

On Fri, Oct 3, 2014 at 3:52 PM, Rolf Eike Beer  wrote:

> Brad King wrote:
> > On 10/01/2014 07:46 PM, Aleix Pol wrote:
> > > I'm very interested in getting this in and iterating forward.
> > >
> > > Any comments? How do changes get integrated?
> >
> > My main concern is that the format has not been proven with a
> > corresponding implementation of an actual IDE/plugin to use it.
> > Once we start producing a format changing it later will be
> > problematic for compatibility.  Even though we added a version
> > number to the file, an IDE might not be updated along with a
> > CMake that produces a newer version.
>
> This probably needs a way to query for the IDE which versions the given
> CMake
> version supports, no? Otherwise a newer IDE may request version 3 and just
> get
> nothing because the CMake binary only supports 1 and 2.
>
> Eike
> --


If it's not available then it should just error out.

Aleix

PS: I'm alive, working on this, when I get some free time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From domen.vrankar at gmail.com  Wed Oct 15 03:30:23 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Wed, 15 Oct 2014 09:30:23 +0200
Subject: [cmake-developers]  CMake and CPack automated testing
Message-ID: 

Hi,

I was looking at CMake automated tests and did not quite understand how
they are intended to be written.

Do they only test for e.g. if CPack executes without errors or do they
check generated files content (e.g. diff or call for e.g. rpm -qi
some_pkg.rpm and then diff the output)? I'm not certain how in-depth the
automated tests should be.

Is there a cmake developers wiki page or some other reference with
guidelines on how to write automated tests for CMake and CPack?

Thanks,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From eric.noulard at gmail.com  Wed Oct 15 05:03:12 2014
From: eric.noulard at gmail.com (Eric Noulard)
Date: Wed, 15 Oct 2014 11:03:12 +0200
Subject: [cmake-developers] CMake and CPack automated testing
In-Reply-To: 
References: 
Message-ID: 

2014-10-15 9:30 GMT+02:00 Domen Vrankar :

> Hi,
>
> I was looking at CMake automated tests and did not quite understand how
> they are intended to be written.
>
> Do they only test for e.g. if CPack executes without errors or do they
> check generated files content (e.g. diff or call for e.g. rpm -qi
> some_pkg.rpm and then diff the output)? I'm not certain how in-depth the
> automated tests should be.
>

The current CPack test inside the CMake source tree are very simple they
only check whether if cpack runs properly in various situation
for various CPack generator. e.g. the "CPackComponentsForAll" test is run
for the available CPack generator on the current platform
and "counts" if the number of generated package file is the appropriate
one, see
/Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake

The other tests CPackComponents and CPackTestAllGenerators only verifies
that cpack run and terminates OK.
The logic of activation of the various CPack generator is in:
/Tests/CMakeLists.txt

inside this file reads e.g.: if(CTEST_RUN_CPackComponentsForAll)  and the
following lines.

Doing more "semantic checks" e.g. running rpm -qi then compare to a
reference file etc... would be indeed very nice.
The thing is the combinatorial explosion of what you can generate for each
CPack generator is high but any more "semantic"
test for any CPack generator would be (I think) a good point.


> Is there a cmake developers wiki page or some other reference with
> guidelines on how to write automated tests for CMake and CPack?
>

I don't think there is anything like that, but that would be very helpful.


>
> Thanks,
> Domen
>
> --
>
> 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
>



-- 
Erk
L'?lection n'est pas la d?mocratie -- http://www.le-message.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From guillaume.papin at parrot.com  Wed Oct 15 10:04:49 2014
From: guillaume.papin at parrot.com (Guillaume Papin)
Date: Wed, 15 Oct 2014 14:04:49 +0000
Subject: [cmake-developers] FindBoost.cmake cannot find some libraries when
	cross-compiling
Message-ID: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan>

Hello CMake developers,

I have a cross-compiled version of Boost and some other libraries under ~/my-project/CrossThirdPartyPrefix.

I invoke CMake with a CMAKE_TOOLCHAIN_FILE and also I sets CMAKE_FIND_ROOT_PATH
to the directory where my cross-compiled Boost is installed.

    cmake -DCMAKE_TOOLCHAIN_FILE=$HOME/my-project/plateforms/arm-toolchain.cmake \
        -DCMAKE_FIND_ROOT_PATH=$HOME/my-project/CrossThirdPartyPrefix \
        ~/my-projects/src/

But I have an error when using FindBoost.cmake:

In my project's CMakeLists.txt:
    find_package(Boost 1.53.0 REQUIRED COMPONENTS atomic thread system)

The error:
     CMake Error at .../share/cmake-3.0/Modules/FindBoost.cmake:1179 (message):
       Unable to find the requested Boost libraries.

       Boost version: 1.55.0

       Boost include path:
       ~/myproject/CrossThirdPartyPrefix/include


       Could not find the following Boost libraries:

               boost_thread
               boost_system

       Some (but not all) of the required Boost libraries were found.  You may
       need to install these additional Boost libraries.  Alternatively, set
       BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT
       to the location of Boost.


So the first component library (atomic) is found but not the other ones.

Looking at the code, when the first library is found, Boost_LIBRARY_DIR is set
to the directory that contains the library and then change the further calls of
find_library to use Boost_LIBRARY_DIR as the unique HINTS, and with the
NO_DEFAULT_PATH options set.

    macro(_Boost_FIND_LIBRARY var)
      find_library(${var} ${ARGN})

      if(${var})
        # If this is the first library found then save Boost_LIBRARY_DIR.
        if(NOT Boost_LIBRARY_DIR)
          get_filename_component(_dir "${${var}}" PATH)
          set(Boost_LIBRARY_DIR "${_dir}" CACHE PATH "Boost library directory" FORCE)
        endif()
      elseif(_Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT)
        # Try component-specific hints but do not save Boost_LIBRARY_DIR.
        find_library(${var} HINTS ${_Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT} ${ARGN})
      endif()

      # If Boost_LIBRARY_DIR is known then search only there.
      if(Boost_LIBRARY_DIR)
        set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
      endif()
    endmacro()

* https://github.com/Kitware/CMake/blob/1b3495d32e1523648da08e138482a654f8765333/Modules/FindBoost.cmake#L322-L325
    
The issue is that, when using CMAKE_FIND_ROOT_PATH, the Boost_LIBRARY_DIR of the
host (~/myproject/CrossThirdPartyPrefix/lib/ in my case), will be expanded against the root paths.

To find my libraries I can apply the following fix but I'm not sure if it's the
right solution or not.

    diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
    index 3642b3e..aad6575 100644
    --- a/Modules/FindBoost.cmake
    +++ b/Modules/FindBoost.cmake
    @@ -321,7 +321,7 @@ macro(_Boost_FIND_LIBRARY var)
     
       # If Boost_LIBRARY_DIR is known then search only there.
       if(Boost_LIBRARY_DIR)
    -    set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
    +    set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
       endif()
     endmacro()
     
    @@ -855,7 +855,7 @@ if(_Boost_CHANGE_LIBDIR AND NOT _Boost_LIBRARY_DIR_CHANGED)
     endif()
     
     if(Boost_LIBRARY_DIR)
    -  set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
    +  set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
     else()
       set(_boost_LIBRARY_SEARCH_DIRS "")
       if(BOOST_LIBRARYDIR)


What I'm wondering is, whether or not Boost_LIBRARY_DIR should be a path on the target or on the host?

Right now, the workaround I have that doesn't require to modify FindBoost.cmake
is to set Boost_LIBRARY_DIR to /lib/, which will be expanded against the CMAKE_FIND_ROOT_PATH.

By the way, I'm a happy CMake user, thanks for all the work!
Guillaume


From chuck.atkins at kitware.com  Wed Oct 15 10:40:42 2014
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Wed, 15 Oct 2014 10:40:42 -0400
Subject: [cmake-developers] FindBoost.cmake cannot find some libraries
 when cross-compiling
In-Reply-To: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan>
References: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan>
Message-ID: 

Can you post your toolchain file as well?  Does it set any of the
CMAKE_FIND_ROOT_PATHG_MODE_{INCLUDE,PROGRAM,LIBRARY,PACKAGE} variables to
anything?

- Chuck

On Wed, Oct 15, 2014 at 10:04 AM, Guillaume Papin <
guillaume.papin at parrot.com> wrote:

> Hello CMake developers,
>
> I have a cross-compiled version of Boost and some other libraries under
> ~/my-project/CrossThirdPartyPrefix.
>
> I invoke CMake with a CMAKE_TOOLCHAIN_FILE and also I sets
> CMAKE_FIND_ROOT_PATH
> to the directory where my cross-compiled Boost is installed.
>
>     cmake
> -DCMAKE_TOOLCHAIN_FILE=$HOME/my-project/plateforms/arm-toolchain.cmake \
>         -DCMAKE_FIND_ROOT_PATH=$HOME/my-project/CrossThirdPartyPrefix \
>         ~/my-projects/src/
>
> But I have an error when using FindBoost.cmake:
>
> In my project's CMakeLists.txt:
>     find_package(Boost 1.53.0 REQUIRED COMPONENTS atomic thread system)
>
> The error:
>      CMake Error at .../share/cmake-3.0/Modules/FindBoost.cmake:1179
> (message):
>        Unable to find the requested Boost libraries.
>
>        Boost version: 1.55.0
>
>        Boost include path:
>        ~/myproject/CrossThirdPartyPrefix/include
>
>
>        Could not find the following Boost libraries:
>
>                boost_thread
>                boost_system
>
>        Some (but not all) of the required Boost libraries were found.  You
> may
>        need to install these additional Boost libraries.  Alternatively,
> set
>        BOOST_LIBRARYDIR to the directory containing Boost libraries or
> BOOST_ROOT
>        to the location of Boost.
>
>
> So the first component library (atomic) is found but not the other ones.
>
> Looking at the code, when the first library is found, Boost_LIBRARY_DIR is
> set
> to the directory that contains the library and then change the further
> calls of
> find_library to use Boost_LIBRARY_DIR as the unique HINTS, and with the
> NO_DEFAULT_PATH options set.
>
>     macro(_Boost_FIND_LIBRARY var)
>       find_library(${var} ${ARGN})
>
>       if(${var})
>         # If this is the first library found then save Boost_LIBRARY_DIR.
>         if(NOT Boost_LIBRARY_DIR)
>           get_filename_component(_dir "${${var}}" PATH)
>           set(Boost_LIBRARY_DIR "${_dir}" CACHE PATH "Boost library
> directory" FORCE)
>         endif()
>       elseif(_Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT)
>         # Try component-specific hints but do not save Boost_LIBRARY_DIR.
>         find_library(${var} HINTS
> ${_Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT} ${ARGN})
>       endif()
>
>       # If Boost_LIBRARY_DIR is known then search only there.
>       if(Boost_LIBRARY_DIR)
>         set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR}
> NO_DEFAULT_PATH)
>       endif()
>     endmacro()
>
> *
> https://github.com/Kitware/CMake/blob/1b3495d32e1523648da08e138482a654f8765333/Modules/FindBoost.cmake#L322-L325
>
> The issue is that, when using CMAKE_FIND_ROOT_PATH, the Boost_LIBRARY_DIR
> of the
> host (~/myproject/CrossThirdPartyPrefix/lib/ in my case), will be expanded
> against the root paths.
>
> To find my libraries I can apply the following fix but I'm not sure if
> it's the
> right solution or not.
>
>     diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
>     index 3642b3e..aad6575 100644
>     --- a/Modules/FindBoost.cmake
>     +++ b/Modules/FindBoost.cmake
>     @@ -321,7 +321,7 @@ macro(_Boost_FIND_LIBRARY var)
>
>        # If Boost_LIBRARY_DIR is known then search only there.
>        if(Boost_LIBRARY_DIR)
>     -    set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR}
> NO_DEFAULT_PATH)
>     +    set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR}
> NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
>        endif()
>      endmacro()
>
>     @@ -855,7 +855,7 @@ if(_Boost_CHANGE_LIBDIR AND NOT
> _Boost_LIBRARY_DIR_CHANGED)
>      endif()
>
>      if(Boost_LIBRARY_DIR)
>     -  set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
>     +  set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH
> NO_CMAKE_FIND_ROOT_PATH)
>      else()
>        set(_boost_LIBRARY_SEARCH_DIRS "")
>        if(BOOST_LIBRARYDIR)
>
>
> What I'm wondering is, whether or not Boost_LIBRARY_DIR should be a path
> on the target or on the host?
>
> Right now, the workaround I have that doesn't require to modify
> FindBoost.cmake
> is to set Boost_LIBRARY_DIR to /lib/, which will be expanded against the
> CMAKE_FIND_ROOT_PATH.
>
> By the way, I'm a happy CMake user, thanks for all the work!
> Guillaume
> --
>
> 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 guillaume.papin at parrot.com  Wed Oct 15 10:57:29 2014
From: guillaume.papin at parrot.com (Guillaume Papin)
Date: Wed, 15 Oct 2014 14:57:29 +0000
Subject: [cmake-developers] FindBoost.cmake cannot find some libraries
 when cross-compiling
In-Reply-To: 
References: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan>,
 
Message-ID: <4037EE152A73A9448DAD73C415D4D8C0873819@MBX79.aswsp.lan>

Yes I'm setting these variables.

See my toolchain configuration below:

cmake_minimum_required(VERSION 3.0) # CMAKE_SYSROOT

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR armv7l)

set(LINARO_PACKAGE_ROOT /opt/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/)
set(CMAKE_SYSROOT /home/user/my-project/my-custom-sysroot/)

set(ONLY_CMAKE_FIND_ROOT_PATH TRUE)
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)

set(CMAKE_C_COMPILER ${LINARO_PACKAGE_ROOT}/bin/arm-linux-gnueabihf-gcc)
set(CMAKE_CXX_COMPILER ${LINARO_PACKAGE_ROOT}/bin/arm-linux-gnueabihf-g++)

set(TOOLCHAIN_COMPILE_FLAGS
  "-mtune=cortex-a15 -march=armv7-a -mthumb -mfloat-abi=hard -mfpu=neon-vfpv4")

set(CMAKE_C_FLAGS "${TOOLCHAIN_COMPILE_FLAGS}" CACHE STRING
  "Flags used by the compiler during all build types." FORCE)
set(CMAKE_CXX_FLAGS "${TOOLCHAIN_COMPILE_FLAGS} -std=c++11" CACHE STRING
  "Flags used by the compiler during all build types." FORCE)
- Guillaume

________________________________
From: Chuck Atkins [chuck.atkins at kitware.com]
Sent: 15 October 2014 16:40
To: Guillaume Papin
Cc: cmake-developers at cmake.org
Subject: Re: [cmake-developers] FindBoost.cmake cannot find some libraries when cross-compiling

Can you post your toolchain file as well?  Does it set any of the CMAKE_FIND_ROOT_PATHG_MODE_{INCLUDE,PROGRAM,LIBRARY,PACKAGE} variables to anything?

- Chuck

On Wed, Oct 15, 2014 at 10:04 AM, Guillaume Papin > wrote:
Hello CMake developers,

I have a cross-compiled version of Boost and some other libraries under ~/my-project/CrossThirdPartyPrefix.

I invoke CMake with a CMAKE_TOOLCHAIN_FILE and also I sets CMAKE_FIND_ROOT_PATH
to the directory where my cross-compiled Boost is installed.

    cmake -DCMAKE_TOOLCHAIN_FILE=$HOME/my-project/plateforms/arm-toolchain.cmake \
        -DCMAKE_FIND_ROOT_PATH=$HOME/my-project/CrossThirdPartyPrefix \
        ~/my-projects/src/

But I have an error when using FindBoost.cmake:

In my project's CMakeLists.txt:
    find_package(Boost 1.53.0 REQUIRED COMPONENTS atomic thread system)

The error:
     CMake Error at .../share/cmake-3.0/Modules/FindBoost.cmake:1179 (message):
       Unable to find the requested Boost libraries.

       Boost version: 1.55.0

       Boost include path:
       ~/myproject/CrossThirdPartyPrefix/include


       Could not find the following Boost libraries:

               boost_thread
               boost_system

       Some (but not all) of the required Boost libraries were found.  You may
       need to install these additional Boost libraries.  Alternatively, set
       BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT
       to the location of Boost.


So the first component library (atomic) is found but not the other ones.

Looking at the code, when the first library is found, Boost_LIBRARY_DIR is set
to the directory that contains the library and then change the further calls of
find_library to use Boost_LIBRARY_DIR as the unique HINTS, and with the
NO_DEFAULT_PATH options set.

    macro(_Boost_FIND_LIBRARY var)
      find_library(${var} ${ARGN})

      if(${var})
        # If this is the first library found then save Boost_LIBRARY_DIR.
        if(NOT Boost_LIBRARY_DIR)
          get_filename_component(_dir "${${var}}" PATH)
          set(Boost_LIBRARY_DIR "${_dir}" CACHE PATH "Boost library directory" FORCE)
        endif()
      elseif(_Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT)
        # Try component-specific hints but do not save Boost_LIBRARY_DIR.
        find_library(${var} HINTS ${_Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT} ${ARGN})
      endif()

      # If Boost_LIBRARY_DIR is known then search only there.
      if(Boost_LIBRARY_DIR)
        set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
      endif()
    endmacro()

* https://github.com/Kitware/CMake/blob/1b3495d32e1523648da08e138482a654f8765333/Modules/FindBoost.cmake#L322-L325

The issue is that, when using CMAKE_FIND_ROOT_PATH, the Boost_LIBRARY_DIR of the
host (~/myproject/CrossThirdPartyPrefix/lib/ in my case), will be expanded against the root paths.

To find my libraries I can apply the following fix but I'm not sure if it's the
right solution or not.

    diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
    index 3642b3e..aad6575 100644
    --- a/Modules/FindBoost.cmake
    +++ b/Modules/FindBoost.cmake
    @@ -321,7 +321,7 @@ macro(_Boost_FIND_LIBRARY var)

       # If Boost_LIBRARY_DIR is known then search only there.
       if(Boost_LIBRARY_DIR)
    -    set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
    +    set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
       endif()
     endmacro()

    @@ -855,7 +855,7 @@ if(_Boost_CHANGE_LIBDIR AND NOT _Boost_LIBRARY_DIR_CHANGED)
     endif()

     if(Boost_LIBRARY_DIR)
    -  set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
    +  set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
     else()
       set(_boost_LIBRARY_SEARCH_DIRS "")
       if(BOOST_LIBRARYDIR)


What I'm wondering is, whether or not Boost_LIBRARY_DIR should be a path on the target or on the host?

Right now, the workaround I have that doesn't require to modify FindBoost.cmake
is to set Boost_LIBRARY_DIR to /lib/, which will be expanded against the CMAKE_FIND_ROOT_PATH.

By the way, I'm a happy CMake user, thanks for all the work!
Guillaume
--

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 mantis at public.kitware.com  Thu Oct 16 06:14:38 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 16 Oct 2014 06:14:38 -0400
Subject: [cmake-developers] [CMake 0015208]: set_source_files_properties and
	extensions
Message-ID: <869b23f4532f195b53dc3459ea5dd64d@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15208 
====================================================================== 
Reported By:                Antoine Bussy
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15208
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-16 06:14 EDT
Last Modified:              2014-10-16 06:14 EDT
====================================================================== 
Summary:                    set_source_files_properties and extensions
Description: 
Setting a property of source file "test.c" also sets the property of the source
file named "test".

Reproduced with properties HEADER_FILE_ONLY and GENERATED.

Same problem is seen with .cpp extension but not .txt

I have attached a minimal example that reproduces the problem.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-16 06:14 Antoine Bussy  New Issue                                    
2014-10-16 06:14 Antoine Bussy  File Added: CMakeLists.txt                    
======================================================================



From mantis at public.kitware.com  Thu Oct 16 09:10:29 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Thu, 16 Oct 2014 09:10:29 -0400
Subject: [cmake-developers] [CMake 0015209]: RPM generation chokes on
	directory symlinks with latest rpmbuild
Message-ID: 


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15209 
====================================================================== 
Reported By:                Luc J. Bourhis
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15209
Category:                   CPack
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-16 09:10 EDT
Last Modified:              2014-10-16 09:10 EDT
====================================================================== 
Summary:                    RPM generation chokes on directory symlinks with
latest rpmbuild
Description: 
As stated here (https://bugzilla.redhat.com/show_bug.cgi?id=1005529), the
following specs file is no more legal as of rpmbuild 4.11

%files
%dir xxx
yyy/

when xxx or yyy are directory symlinks instead of proper directories.
Unfortunately CPack has not been taught that and it generates %dir xxx for a
directory symlink xxx.

Steps to Reproduce: 
Using the CMakeLists.txt attached to this bug report, issue "make package", on a
Linux machine with rpmbuild 4.11 (I tested with Fedora 20). You should get the
following error message:

error: Not a directory:
/home/luc/Developer/sandbox/build/_CPack_Packages/Linux/RPM/it-will-fail-0.1.1-Linux/usr/usr/share/test/project/subdir
    Not a directory:
/home/luc/Developer/sandbox/build/_CPack_Packages/Linux/RPM/it-will-fail-0.1.1-Linux/usr/usr/share/test/project/subdir

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-16 09:10 Luc J. Bourhis New Issue                                    
2014-10-16 09:10 Luc J. Bourhis File Added: CMakeLists.txt                    
======================================================================



From brad.king at kitware.com  Thu Oct 16 10:28:26 2014
From: brad.king at kitware.com (Brad King)
Date: Thu, 16 Oct 2014 10:28:26 -0400
Subject: [cmake-developers] Introduction and volunteering for the Matlab
 package
In-Reply-To: 
References: 
Message-ID: <543FD60A.5060508@kitware.com>

On 10/13/2014 02:23 PM, Raffi Enficiaud wrote:
> I had a hard time making some stuff compile again with Matlab under Linux.
> The fact is that Matlab is shipped with its own version of libC, libhdf5,
> libboost etc, and sometimes the filenames are the same (eg. hdf5, or libc)
> but the subminor versions are not. If I understand properly, the fact that
> the filenames are the same prevents the dynamic loader of Linux to load the
> files that are referred by the mex file in their respective rpath (there
> is only one libhdf51.8.2.so in the matlab process).

It's the SONAME that matters for the dynamic loader to find the libraries
at runtime.  It is a string copied into the dependents and used by the
dynamic loader to find the matching file at runtime.

> Beside that, the
> symbols also may clash: I had an implementation with a dynamic loader under
> linux, but yet the boost symbols of my mex files were not loaded because
> same symbols were already there in the process.
> I found a technical solution to this on Linux:
> - the use of -Wl,--exclude-libs,ALL for the linker.

According to "man ld" that option is only available on specific systems
(i386 PE).  As you pointed out it is not available on OS X.

I think the only reliable way to do this is to make sure your plugins
are built against the same libraries as Matlab, or to mangle the
symbols in your dependencies so they don't conflict with Matlab.

This is outside the scope of what I think the FindMatlab module can
achieve, so it will have to be left to the application author.
For now please leave out the REDUCE_VISIBILITY option.  I think
functionality like that, if provided by CMake, should be a more
general feature not specific to FindMatlab.

> I am using this FindMatlab in two projects now, under OSX 10.9,
> Win7 Visual2013 and Ubuntu12.04.

Great.  In order to keep the module working, we will also need tests
for it.  Please look at adding to the Tests/ directory a case for
using this module.  The test case can be something we enable with
some explicit option.  Then you can run a nightly build of CMake on
a machine of each platform with Matlab installed and enable the test.
Ideally you would have one for Windows, OS X, and Linux, at least.
Without regular testing the functionality is bound to regress as
changes are made to CMake.

Thanks,
-Brad


From brad.king at kitware.com  Thu Oct 16 10:29:30 2014
From: brad.king at kitware.com (Brad King)
Date: Thu, 16 Oct 2014 10:29:30 -0400
Subject: [cmake-developers] Support of codesign
In-Reply-To: <2614570.QAlDDbOxL6@stryke>
References: 
 
 
 <2614570.QAlDDbOxL6@stryke>
Message-ID: <543FD64A.1040907@kitware.com>

Andr?,

Please respond with comments or an updated patch to address Clinton's
review comments in order to help this contribution proceed.

On 09/26/2014 10:08 AM, clinton at elemtech.com wrote:
> I would suggest the SignPackage function be moved from
> cmCPackDragNDropGenerator to cmCPackBundleGenerator because
> its implementation is only usable by cmCPackBundleGenerator.
> It uses CPACK_BUNDLE_NAME which is only valid in the context
> of cmCPackBundleGenerator.

On 09/29/2014 09:55 AM, clinton at elemtech.com wrote:
> Because it appears to only work with the Bundle generator, can
> you please move the documentation from Modules/CPackDMG.cmake
> to Modules/CPackBundle.cmake?
> Or did you intend to make this feature work for both the
> DragNDrop and Bundle generator?

On 09/29/2014 02:00 PM, Clinton Stimpson wrote:
> I think application signing is generally not a CPack thing, but
> there probably isn't much of a choice if the Bundle generator
> is used.

Thanks,
-Brad


From chuck.atkins at kitware.com  Thu Oct 16 10:32:33 2014
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Thu, 16 Oct 2014 10:32:33 -0400
Subject: [cmake-developers] FindBoost.cmake cannot find some libraries
 when cross-compiling
In-Reply-To: <4037EE152A73A9448DAD73C415D4D8C0873819@MBX79.aswsp.lan>
References: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan>
 
 <4037EE152A73A9448DAD73C415D4D8C0873819@MBX79.aswsp.lan>
Message-ID: 

This looks like a reasonable way to accomplish this right now.  The
underlying prioblem is that ther's no way to specify which path types get
re-rooted and which don't.  Ideally you'd want to be able to specify in the
toolchain for something like this that all paths operate in "ONLY" mode
except HINTS, which you would want to place in NEVER mode.  I'm currently
working on just such a feature but in the meantime, forcing it like this in
the FindBoost module looks reasonable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From chuck.atkins at kitware.com  Thu Oct 16 11:09:14 2014
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Thu, 16 Oct 2014 11:09:14 -0400
Subject: [cmake-developers] FindBoost.cmake cannot find some libraries
 when cross-compiling
In-Reply-To: 
References: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan>
 
 <4037EE152A73A9448DAD73C415D4D8C0873819@MBX79.aswsp.lan>
 
Message-ID: 

Guillaume,

Please see CONTRIBUTING.rst in the top level of the CMake source tree.  If
you can please create and post a patch against cmake master then I'll work
on getting it merged into cmake next.  Thanks for the bug fix!

- Chuck

On Thu, Oct 16, 2014 at 10:32 AM, Chuck Atkins 
wrote:

> This looks like a reasonable way to accomplish this right now.  The
> underlying prioblem is that ther's no way to specify which path types get
> re-rooted and which don't.  Ideally you'd want to be able to specify in the
> toolchain for something like this that all paths operate in "ONLY" mode
> except HINTS, which you would want to place in NEVER mode.  I'm currently
> working on just such a feature but in the meantime, forcing it like this in
> the FindBoost module looks reasonable.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From brad.king at kitware.com  Thu Oct 16 11:19:36 2014
From: brad.king at kitware.com (Brad King)
Date: Thu, 16 Oct 2014 11:19:36 -0400
Subject: [cmake-developers] Refactoring search path construction
In-Reply-To: 
References: 
Message-ID: <543FE208.50200@kitware.com>

On 10/09/2014 02:45 PM, Chuck Atkins wrote:
> I've just pushed a branch to the stage for review:
> refactor-search-path-construction

Thanks.

In cmSearchPath.cxx, please include cmSearchPath.h first.
In cmSearchPath.h, please include cmStandardIncludes.h first.
Otherwise some standard library headers may not be preprocessed
consistently across translation units, which causes trouble on
some platforms (LFS support on AIX for example).

After that please merge to 'next' for testing when ready.

Thanks,
-Brad



From daniele.domenichelli at gmail.com  Thu Oct 16 11:26:10 2014
From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli)
Date: Thu, 16 Oct 2014 17:26:10 +0200
Subject: [cmake-developers] ExternalProject CMAKE_ARGS and CMAKE_CACHE_ARGS
	arguments
Message-ID: <543FE392.7020706@gmail.com>

Hello all,


I have question about CMAKE_ARGS and CMAKE_CACHE_ARGS, and I'm not sure
if this is the intended behaviour or not...


>From the documentation:

  #    [CMAKE_ARGS args...]        # Arguments to CMake command line
  #    [CMAKE_CACHE_ARGS args...]  # Initial cache arguments, of the form -Dvar:string=on

So, from what I understand, The first arguments are passed to the cmake
command line, and from the second it is created a a cache file that is
passed to cmake using -C. If the same variable is in both, CMAKE_ARGS
wins over CMAKE_CACHE_ARGS.

>From the documentation, I was expecting that the CMAKE_CACHE_ARGS would
be used only to create the initial cache, and that the user could go to
the build directory and change it, but the cache file passes the FORCE
argument to the set commands (lines 910 and 930).

  set(setArg "${setArg}${accumulator}\" CACHE ${type} \"Initial cache\" FORCE)")

This makes impossible to change a value later, and in my opinion makes
one of the 2 arguments redundant, since the final effect of the 2
variables is exactly the same.

So, is this the intended behaviour? The FORCE argument allows one to
change CMAKE_CACHE_ARGS and have the cache updated, but that's exactly
what CMAKE_ARGS does.
I don't know exactly how the -C flag works, but I was thinking that if
the FORCE argument is dropped, the 2 arguments could be used with
different purposes: CMAKE_ARGS is always enforced, CMAKE_CACHE_ARGS
could be modified by the user later. Would it work and does this make
sense for you?


Cheers,
 Daniele


From tobias.hunger at gmail.com  Fri Oct 17 06:44:03 2014
From: tobias.hunger at gmail.com (Tobias Hunger)
Date: Fri, 17 Oct 2014 12:44:03 +0200
Subject: [cmake-developers] Extracting target metadata, IDE integration
In-Reply-To: 
References: 
 
Message-ID: 

Sorry, I am a bit late with replying to this... I do not follow this
list too closely and got distracted by mails in between where I could
not contribute anything:-/

On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly  wrote:
>> The first is should this be run in a terminal or is this a GUI. Not
>> sure whether cmake has that information.
>
> CMake only knows whether the WIN32_EXECUTABLE property has been set on a
> target.
>
>  http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html
>
> The property is harmless on non-Windows, so KDE sets it on non-Windows for
> gui applications IIRC, but others may not.

This is a hint only.

If it works correctly it is nice, otherwise the user will have to
toggle some checkbox
to change it to his or her liking.

>> Secondly the linker flags would be nice to know. That way the
>> LD_LIBRARY_PATH can be set correctly by the IDE so that all the
>> libraries are found.
>
> If the linker flags were provided, you would have to parse them. Maybe a
> runtimeLinkDirectories/linkDependentLibraries can be provided, similar to
> the content passed to the option -rpath. I have no idea if similar
> information can be acquired for MSVC/Windows. As Nils said, CMake might not
> know the location of the import library.

If CMake knows the locations, then put them in, please.

If not then there is little you can do, is there?

>> Combined with CMAKE_EXPORT_COMPILE_COMMANDS this should allow for a
>> pretty good integration into creator. Ideally the exported compile
>> commands would be a bit more aggregated along the lines of "the
>> following list of files will be build using these defines/include
>> paths/flags", just because that would be way shorter and most likely
>> faster to parse.
>
> What would that looks like? I guess listing the sources in a target together
> with its includes/defines should be possible, together with extra per-source
> defines, if present?
>
> [
>   "name" : "testc1"
>   "sources" : ["foo.cpp", "bar.cpp"]
>   "defines" : ["BUILD_TEST=1", "QT_CORE_LIB"]
>   "includes" : ["/opt/bat/include", "/usr/include/qt5"]
>   "extraDefines" : {
>     "foo.cpp" : ["EXTRA_FOO=1"]
>   }
> ]

I was thinking more along the lines of a somewhat aggregated
CMAKE_EXPORT_COMPILE_COMMANDS, but this is even better:-)

But why not have groups of sources?

[
  "name": "testc1"
  "sourceGroups" [
     {
         "sources": [ "foo.cpp" ],
         "defines": ["BUILD_TEST=1", "QT_CORE_LIB", "EXTRA_FOO=1"],
         "includes": ["/opt/bat/include", "/usr/include/qt5"]
     },
     {
         "sources": [ "bar.cpp" ],
         "defines": ["BUILD_TEST=1", "QT_CORE_LIB"],
         "includes": ["/opt/bat/include", "/usr/include/qt5"]
     }
  ]
]

Would be simpler to parse for us.

>> With this target description and the compile commands there is just
>> one piece of the puzzle missing for a great Qt Creator integration: We
>> need to generate a list of files that are part of the project. I
>> currently do not know how to extract that list from cmake. This list
>> must include all the header files that belong to the project, which is
>> what makes this hard to get this information from cmake -- at least at
>> the time I stopped working with cmake.
>
> Afaik, CMake does not know all the files included by your cpp files.
> However, some buildsystems can add them to the list of sources if desired
> for better IDE integration.
>
>  https://gitorious.org/grantlee/grantlee/commit/3eb40cf94

That is the big issue I have with CMake... it makes it impossible to use
CMakeLists.txt as a sole source of project configuration.

Creator tries to not need any extra files to manage the project, so this
hits us pretty hard.

>> Ideally we could get the list of files that belong to the project in
>> general and the files that are actually part of the currently
>> configured built.
>
> In CMake master at least, the user can list config-specific files
> declaratively. Eg, add the foo_debug.cpp file only in the debug
> configuration:
>
>  add_library(foo
>    foo.cpp
>    $<$:foo_debug.cpp>
>  )
>
>> But how can I know that "something_win.h" will not be used when
>> building on my Linux box?
>
> The current style is indeed difficult to parse, where that might be inside
> an if() inside a macro etc. Again though, CMake master will allow users to
> do better:
>
>  add_library(foo
>    foo.cpp
>    $<$:foo_win.cpp>
>  )
>
> I wonder how those kinds of conditions would need to be represented in the
> ProjectTargets.json file.

This is actually a bit too detailed for my needs:-)

I want to know which files are part of the project and which are part
of the current build.

At least Qt Creator does not need information on which conditions to
be met for a file to become part of the current build.

> One option would be to write them directly to the
> json, instead of, for example, creating individual lists for each
> configuration, and expecting the consumer to evaluate the expressions. A
> possible problem with that is that consumers would have to transitively
> evaluate each property over the link closure. Apart from the potential for
> bugs, that would mean there would need to be a target entry for each
> IMPORTED target too.
>
> It would probably be easier to try to generate something like
>
>  "defines" : {
>    "noconfig" : ["FOO=1", "QT_CORE_LIB"]
>    "debug" :  ["QT_DEBUG"]
>    "release" : ["RELEASE_MODE=1"]
>   }
>
> from
>
>  target_compile_definitions(foo PRIVATE
>    FOO=1
>    $<$:RELEASE_MODE=1>
>  )
>  target_link_libraries(foo PRIVATE
>    Qt5::Core # Uses the Qt defines in the foo target.
>  )

Creator at least will not need that. We need the set of
defines/includes for the current build configuration, but not any
extra information on flags that could potentially become relevant in
other configurations.

> But that will mean adding more complexity to generator expression evaluation
> to find out which condition groups are needed (Eg, Do I need to create per-
> platform/per-config/per-compiler groups?).
>
> So, we'd have to decide how much exactness to aim for, and how much
> complexity to push to the user.
>
> Thanks,
>
> Steve.

Best Regards,
Tobias


From brad.king at kitware.com  Fri Oct 17 08:57:18 2014
From: brad.king at kitware.com (Brad King)
Date: Fri, 17 Oct 2014 08:57:18 -0400
Subject: [cmake-developers] Extracting target metadata, IDE integration
In-Reply-To: 
References: 
 
 
Message-ID: <5441122E.5020509@kitware.com>

On 10/17/2014 06:44 AM, Tobias Hunger wrote:
> On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly  wrote:
>> Afaik, CMake does not know all the files included by your cpp files.
>> However, some buildsystems can add them to the list of sources if desired
>> for better IDE integration.
>>
>>  https://gitorious.org/grantlee/grantlee/commit/3eb40cf94
> 
> That is the big issue I have with CMake... it makes it impossible to use
> CMakeLists.txt as a sole source of project configuration.
> 
> Creator tries to not need any extra files to manage the project, so this
> hits us pretty hard.

We've discussed this in the past a few times.  One solution is for
the project spec to be in a declarative format, e.g. a JSON document.
The spec would not be in a CMakeLists.txt but could be loaded by a
command invoked from it.  Then it could also be loaded and manipulated
separately by IDEs or other tools.

So, rather than having CMake generate a project spec file from the
CMakeLists.txt files, we have CMakeLists.txt files load a project
spec file.  The declarative information goes in the project spec file,
and imperative things like try_compile can be done in the CMake config
step.  The imperative step also loads the project spec and evaluates
the declarations based on discovered information about the target
platform.

Other than this basic design, no one has taken the time to design such
a format.

-Brad



From mantis at public.kitware.com  Fri Oct 17 13:36:08 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Fri, 17 Oct 2014 13:36:08 -0400
Subject: [cmake-developers] [CMake 0015210]: CMakeFindBinUtils.cmake not
	re-run when cache is deleted
Message-ID: <498d475e6b43044bb072ce0f532ccb7a@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15210 
====================================================================== 
Reported By:                Clinton Stimpson
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15210
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-17 13:36 EDT
Last Modified:              2014-10-17 13:36 EDT
====================================================================== 
Summary:                    CMakeFindBinUtils.cmake not re-run when cache is
deleted
Description: 
If I run cmake to create a build tree, then delete the CMakeCache.txt file and
re-run cmake, the cache variables from CMakeFindBinUtils.cmake are not restored.

Modules/Platform/Darwin.cmake and Modules/Platform/Windows-MSVC.cmake both
contain hacks to restore some cache variables.

In my case, a missing CMAKE_STRIP prompted this bug report because it was
possible to create packages containing debug symbols.

Steps to Reproduce: 

With /CMake and /build:

cmake ../CMake
mv CMakeCache.txt CMakeCache.txt.bak
rm CMakeCache.txt
cmake ../CMake

diff -u CMakeCache.txt.bak CMakeCache.txt
to see all of the missing variables.

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-17 13:36 Clinton StimpsonNew Issue                                    
======================================================================



From fabianjul at gmail.com  Fri Oct 17 16:16:07 2014
From: fabianjul at gmail.com (Fabian)
Date: Fri, 17 Oct 2014 22:16:07 +0200
Subject: [cmake-developers] Xcode Project: Support for DevelopmentTeam
Message-ID: 

Somewhere starting in Xcode 4 or 5, Apple added a Team dropdown to the
General tab of a target. The developer can select a development team there,
which results in a bunch of useful things, most importantly: Xcode
automatically updates the devices list in the Member Center and the
currently fitting iOS Team Provisioning Profile. This creatly simplyfies
management of development devices.

It would be very nice if CMake supported setting this option. A look at the
project.pbxproj reveals that this setting is stored in the 'attributes' in
the PBXProject section:

3B69B74659794A7B9F0C2B71 /* Project object */ = {
    isa = PBXProject;
    attributes = {
        BuildIndependentTargetsInParallel = YES;
        TargetAttributes = {
            26E66AE0CD2341D58DBF6E8B = {
                DevelopmentTeam = <10 character Team ID>;
            };
        };
    };
    ....

In the CMake source I noticed that 'BuildIndependentTargetsInParallel' is
already getting set. This could be extendet to add the 'TargetAttributes'
section. Note that the ID used in there (26E66AE0CD2341D58DBF6E8B in the
example) is the ID of the 'main' target, i.e. the one with the name of the
project.

The 10 character Team ID can be found by the developer in the member center
under Your Account. This could be set with a CMake flag.

Thanks,
Fabian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From domen.vrankar at gmail.com  Sat Oct 18 16:36:47 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Sat, 18 Oct 2014 22:36:47 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

> I also have a question. Would CPack also need something like
>> CPACK_COMPONENT__PACKAGE_SUMMARY that could be used by
>> CPACK_RPM__PACKAGE_SUMMARY as default value?
>>
>
>
> Not sure of that one.
> We already have "CPACK_COMPONENT_GROUP_CMAKE_DESCRIPTION"
> which may be a default value for "CPACK_RPM__PACKAGE_
> SUMMARY" if packaging is done "by compoent group" (which is the default):
>
> The behavior of the various CPack generator w.r.t. mono- or multi-
> file/package generation vary,
> see:
>
> http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior
>
>
I did not find CPACK_COMPONENT_GROUP__DESCRIPTION in
documentation but from the examples that I've found googling I think that
this would be a better option for CPACK_RPM__PACKAGE_DESCRIPTION
than CPACK_RPM__PACKAGE_SUMMARY. Since the patch supports all
the options that I've found in the documentation I guess that there are
enough fallback options covered.

I also wrote a test and noticed two things:
1) CPackComponentsForAll test is using component names in lower case and
 parts in variables in upper case (e.g. COMPONENT headers and
CPACK_COMPONENT_HEADERS_DESCRIPTION). Patch uses
CPACK_RPM_PACKAGE_COMPONENT variable as part of component variable name
e.g. CPACK_RPM_headers_PACKAGE_DESCRIPTION.
Because of this the fallback mechanism doesn't work correctly so is the
correct variable format CPACK_COMPONENT_headers_PACKAGE_SUMMARY, CPACK_
COMPONENT_HEADERS_PACKAGE_SUMMARY, both or case insensitive?
If case insensitive option is the correct one - how do I implement that?
Since all other RPM component variables use install( ... COMPONENT name) as
part of variable name (so in this case that means lower case) I guess that
RPM versions should stay as they are now (
CPACK_RPM_headers_PACKAGE_DESCRIPTION for the above example).

2) Package description fallback is currently written as
set(CPACK_RPM_PACKAGE_DESCRIPTION "no package description available") and
this is already in the code - not part of the patch. However if variable
CPACK_PACKAGE_DESCRIPTION_FILE is not set it points by default to
Templates/CPack.GenericDescription.txt and its content is "DESCRIPTION". So
currently the above final fallback is dead code.
Should I delete it or fix the code so that in case of default
CPACK_PACKAGE_DESCRIPTION_FILE value it ignores it and uses "no package
description available" text instead (would break the way it currently works
so I'm guessing that deleting that part of code is the preferred option)?
Can I put this change in the same patch since I am changing the fallback
mechanism in it or should this be a different patch?
If second - can I still attach the patch to the same mantis bug, do I open
a new bug report or just create a patch and post it on the mailing list?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mantis at public.kitware.com  Sat Oct 18 16:52:42 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Sat, 18 Oct 2014 16:52:42 -0400
Subject: [cmake-developers] [CMake 0015211]: Faulty parsing of variables
	with multi-line content
Message-ID: <79c10ab2a551cb4c0a1aba0217c79d05@public.kitware.com>


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15211 
====================================================================== 
Reported By:                Timo Korthals
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15211
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   high
Status:                     new
====================================================================== 
Date Submitted:             2014-10-18 16:52 EDT
Last Modified:              2014-10-18 16:52 EDT
====================================================================== 
Summary:                    Faulty parsing of variables with multi-line content
Description: 
cmake (above 2.8.7 up to master/head) fails to parse variables which have more
than two lines (and therefore two 'newline' character) in it. The outcome of it
is, that the project is unmakeable, because of the faulty produced makefiles.

As a minimal example I define multiple include directories in the variable
"GCC_INCLUDES" and hand it over to "include_directories", which produces the
"CXX_FLAGS" in "flags.make".
I give you first an working example with the corresponding output file, and then
an example with the faulty output:

Working "CMakeLists.txt"
-----------------------START
  cmake_minimum_required(VERSION 2.8.7 FATAL_ERROR)
  project ("helloWorld")
  set(GCC_INCLUDES "/test1\n/test2")
  include_directories(
      ${GCC_INCLUDES}
  )
  add_executable("helloWorld" main.cpp)
-----------------------END

Correct outputfile "CMakeFiles/helloWorld.dir/flags.make"
-----------------------START
# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 2.8

# compile CXX with /usr/bin/c++
CXX_FLAGS = -I/test1 -I/test2

  CXX_DEFINES = 
-----------------------END

Faulty "CMakeLists.txt"
-----------------------START
  cmake_minimum_required(VERSION 2.8.7 FATAL_ERROR)
  project ("helloWorld")
  set(GCC_INCLUDES "/test1\n/test2\n/test3")
  include_directories(
      ${GCC_INCLUDES}
  )
  add_executable("helloWorld" main.cpp)
-----------------------END

Faulty outputfile "CMakeFiles/helloWorld.dir/flags.make"
-----------------------START
# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 2.8

# compile CXX with /usr/bin/c++
CXX_FLAGS = -I/test1 -I/test2
/test3 -I/test3   

CXX_DEFINES = 
-----------------------END

Steps to Reproduce: 
Use the CMakeLists.txt files in the section "Description" and run "cmake ." to
produce the error message.

Example "main.cpp"
-----------------------START
#include 

using namespace std;

int main(void) {
 cout << "Hallo World" << endl;
 return 0;
}
-----------------------END

Additional Information: 
I tested the following cmake versions

OS: Ubuntu 12.04.4; cmake 2.8.7
Result: No parsing error

OS: Ubuntu 14.04.1; cmake 2.8.7
Result: No parsing error

OS: Ubuntu 14.04.1; cmake 2.12.2
Result: ERROR

OS: Ubuntu 14.04.1; cmake master/head (commit
d4525d7288ef935ee8b9d8cf338763498850364f)
Result: ERROR
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-18 16:52 Timo Korthals  New Issue                                    
======================================================================



From micha.hergarden at gmail.com  Sun Oct 19 07:28:14 2014
From: micha.hergarden at gmail.com (Micha Hergarden)
Date: Sun, 19 Oct 2014 13:28:14 +0200
Subject: [cmake-developers] [PATCH] Preinstall requirements support for
 CPack RPM generator
In-Reply-To: 
References: 
 <543695B3.5010201@kitware.com>
 
Message-ID: <5443A04E.7030806@gmail.com>

On 10/09/2014 07:30 PM, Evgeny Kalishenko wrote:
> Ok, thanks for the advise about STREQUAL. Explanation of s/_/(/ (from
> http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html):
> "Recent versions of RPM support context marked dependencies. This is a
> special type of a dependency that applies only in a specified
> /context/. Using this feature, one can specify dependencies for pre-
> and post(un)install scriptlets, ie. the context of a dependency is the
> execution time of the specified scriptlet.
>
> The syntax for specifying these dependencies is:
>
> Requires(/X/): foo
>               
>
> Here, /X/ can be one of *pre*, *post*, *preun*, or *postun*, which
> tells RPM that the package depends on package foo for running the
> corresponding *%pre*, *%post*, *%preun*, or *%postun* script."
>
> Modified patch attached.
>
>
> 2014-10-09 18:03 GMT+04:00 Brad King  >:
>
>     On 10/08/2014 01:48 PM, Evgeny Kalishenko wrote:
>     > I was interested in feature request
>     > http://public.kitware.com/Bug/view.php?id=14769 and made a
>     > simple patch for CPack RPM generator (attached).
>
>     Thanks.
>
>     In this hunk:
>
>     > +    # The following keywords require braces around the "pre" or
>     "post" suffix in the final RPM spec file.
>     > +    if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE"  OR 
>     "${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST")
>     > +      string(REPLACE "_" "(" _PACKAGE_HEADER_NAME
>     "${_PACKAGE_HEADER_NAME}")
>     > +      set(_PACKAGE_HEADER_NAME "${_PACKAGE_HEADER_NAME})")
>     > +    endif()
>
>     The MATCHES conditions can use simply STREQUAL instead.
>     I'm not very familiar with the spec format, so please
>     explain the purpose of the s/_/(/ subsitution in comments
>     here.
>
>     Thanks,
>     -Brad
>
>
>
>
> -- 
> ? ?????????,
> ??????? ?????????
>
>
In this hunk:
+#  May be used to set RPM postinstall dependencies (requires(post)). 
Note that you must enclose
+#  the complete requires string between quotes, for example::
+#
+#   set(CPACK_RPM_PACKAGE_REQUIRES_PRE "shadow-utils, initscripts")
+#
+#

The variable name CPACK_RPM_PACKAGE_REQUIRES_PRE should be
CPACK_RPM_PACKAGE_REQUIRES_POST.

In this hunk:
+    # The following keywords require braces around the "pre" or "post"
suffix in the final RPM spec file.
+    if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE"  OR 
"${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST")
+      string(REPLACE "_" "(" _PACKAGE_HEADER_NAME
"${_PACKAGE_HEADER_NAME}")
+      set(_PACKAGE_HEADER_NAME "${_PACKAGE_HEADER_NAME})")
+    endif()

Shouldn't braces be called parentheses here ( i.e '(' versus '{' )?

I have checked with a minimal project on a ubuntu 14.04 box (using rpm
4.11.1) and the generated package seems good. So, no further comments.

With kind regards,
Micha Hergarden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: 

From steveire at gmail.com  Sun Oct 19 08:26:14 2014
From: steveire at gmail.com (Stephen Kelly)
Date: Sun, 19 Oct 2014 14:26:14 +0200
Subject: [cmake-developers] Extracting target metadata, IDE integration
References: 
 
 
Message-ID: 

Tobias Hunger wrote:

> Sorry, I am a bit late with replying to this... I do not follow this
> list too closely and got distracted by mails in between where I could
> not contribute anything:-/

No problem, thanks! I recently discovered that Creator makes fragile guesses 
about source files and targets

https://codereview.qt-project.org/#/c/96594/1/src/plugins/cmakeprojectmanager/cmakeproject.cpp,unified

so I would really like to create a solution which makes that unnecessary.

> 
> On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly
>  wrote:
>>> The first is should this be run in a terminal or is this a GUI. Not
>>> sure whether cmake has that information.
>>
>> CMake only knows whether the WIN32_EXECUTABLE property has been set on a
>> target.
>>
>>  http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html
>>
>> The property is harmless on non-Windows, so KDE sets it on non-Windows
>> for gui applications IIRC, but others may not.
> 
> This is a hint only.
> 
> If it works correctly it is nice, otherwise the user will have to
> toggle some checkbox
> to change it to his or her liking.

Yes. I suppose beyond the WIN32_EXECUTABLE/ SUBSYSTEM:console / Mac Bundle  
stuff the gui/console distinction doesn't really fit into the buildsystem. 
Maybe such a checkbox, pre-populated with the hint, is needed anyway.

> 
>>> Secondly the linker flags would be nice to know. That way the
>>> LD_LIBRARY_PATH can be set correctly by the IDE so that all the
>>> libraries are found.
>>
>> If the linker flags were provided, you would have to parse them. Maybe a
>> runtimeLinkDirectories/linkDependentLibraries can be provided, similar to
>> the content passed to the option -rpath. I have no idea if similar
>> information can be acquired for MSVC/Windows. As Nils said, CMake might
>> not know the location of the import library.
> 
> If CMake knows the locations, then put them in, please.

I'm sure that won't be a problem.

> But why not have groups of sources?
> 
> [
>   "name": "testc1"
>   "sourceGroups" [
>      {
>          "sources": [ "foo.cpp" ],
>          "defines": ["BUILD_TEST=1", "QT_CORE_LIB", "EXTRA_FOO=1"],
>          "includes": ["/opt/bat/include", "/usr/include/qt5"]
>      },
>      {
>          "sources": [ "bar.cpp" ],
>          "defines": ["BUILD_TEST=1", "QT_CORE_LIB"],
>          "includes": ["/opt/bat/include", "/usr/include/qt5"]
>      }
>   ]
> ]
> 
> Would be simpler to parse for us.

Perhaps. CMake already has a source group concept (for IDEs to group 
sources), and your concept of a source group here seems to be about grouping 
files with common includes/defines/build properties? The two concepts may be 
in conflict.

>> Afaik, CMake does not know all the files included by your cpp files.
>> However, some buildsystems can add them to the list of sources if desired
>> for better IDE integration.
>>
>>  https://gitorious.org/grantlee/grantlee/commit/3eb40cf94
> 
> That is the big issue I have with CMake... it makes it impossible to use
> CMakeLists.txt as a sole source of project configuration.

For comparison, does any other buildsystem require header listings like 
this? With qmake, I can populate HEADERS, but I don't have to (for headers 
which do not require moc).

> I want to know which files are part of the project and which are part
> of the current build.
> 
> At least Qt Creator does not need information on which conditions to
> be met for a file to become part of the current build.

Ok, good feedback, thanks.

Steve.




From konstantin at podsvirov.pro  Mon Oct 20 02:14:54 2014
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Mon, 20 Oct 2014 10:14:54 +0400
Subject: [cmake-developers] [CPackIFW] Documentation
In-Reply-To: 
References: <1233611413437212@web15h.yandex.ru> 
Message-ID: <3515101413785694@web4o.yandex.ru>

Hello dear developers!

Appeal to developers of two projects: CMake and Qt :-)

This discussion affects both communities.

CPack IFW generator generates installers with a graphical user interface using Qt Installer Framework.

The code generator already in the thread "release":

http://www.cmake.org/gitweb?p=cmake.git;a=shortlog;h=refs/heads/release

The generator is accompanied by a documentation module CPackIFW", which is included in the CMake documentation.

I want to know that this generator has followers and users.

I want documentation about this generator was in the right places.

I need feedback and suggestions for further development.

In the discussion participated Stephen Kelly. He gave some interesting links.

19.10.2014, 17:23, "Stephen Kelly" :
> Documentation generated from the master branch is updated daily here:
>
> http://www.cmake.org/cmake/help/git-master/module/CPackIFW.html
>
>>> Also, what's the time frame for CMake version 3.1.0 ? I don't want to add
>>> links to a yet unreleased feature ...
>
> The roadmap says early November:
>
> http://public.kitware.com/Bug/roadmap_page.php
>
> but it's likely to slip some weeks if past experience is a good forecast.
>
> Whatever is true about additions to the Qt documentation, the CPackIFW
> generator looks like it should get a mention in
>
> http://www.cmake.org/cmake/help/v3.0/manual/cmake-qt.7.html
>
> One option would be to add a primary prose there and link to that from
>
> http://doc-snapshot.qt-project.org/qt5-5.3/cmake-manual.html
>
> and
>
> http://qt-project.org/doc/qt-5/deployment.html
>
> The CMake documentation can be loaded in creator
>
> http://www.kdab.com/context-sensitive-cmake-documentation-qtcreator/
>
> and CMake releases will include a qch file from now on. Eg
>
> http://www.cmake.org/cmake/help/v3.1/CMake.qch
>
> Thanks,

I can't do everything myself and hope for the community :-)

All good working week.

PS: where I live the snow :-)

Regards,
Konstantin Podsvirov


From tobias.hunger at gmail.com  Mon Oct 20 06:02:05 2014
From: tobias.hunger at gmail.com (Tobias Hunger)
Date: Mon, 20 Oct 2014 12:02:05 +0200
Subject: [cmake-developers] Extracting target metadata, IDE integration
In-Reply-To: 
References: 
 
 
 
Message-ID: 

Hey Stephen,

On Sun, Oct 19, 2014 at 2:26 PM, Stephen Kelly  wrote:
> No problem, thanks! I recently discovered that Creator makes fragile guesses
> about source files and targets
>
> https://codereview.qt-project.org/#/c/96594/1/src/plugins/cmakeprojectmanager/cmakeproject.cpp,unified
>
> so I would really like to create a solution which makes that unnecessary.

I am no expert on this part of the codebase, but I would not be
surprised if it did do some stupid things when seeing cmake. We do not
support that too well.

>> On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly
>>  wrote:
>>>> The first is should this be run in a terminal or is this a GUI. Not
>>>> sure whether cmake has that information.
>>>
>>> CMake only knows whether the WIN32_EXECUTABLE property has been set on a
>>> target.
>>>
>>>  http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html
>>>
>>> The property is harmless on non-Windows, so KDE sets it on non-Windows
>>> for gui applications IIRC, but others may not.
>>
>> This is a hint only.
>>
>> If it works correctly it is nice, otherwise the user will have to
>> toggle some checkbox
>> to change it to his or her liking.
>
> Yes. I suppose beyond the WIN32_EXECUTABLE/ SUBSYSTEM:console / Mac Bundle
> stuff the gui/console distinction doesn't really fit into the buildsystem.
> Maybe such a checkbox, pre-populated with the hint, is needed anyway.

Not into a build system, but into an IDE:-)

There is a overlap in what an IDE needs to know and what a build
system then needs to generate binaries, but it both also need some
information the other does not provide.

>> But why not have groups of sources?
>>
>> [
>>   "name": "testc1"
>>   "sourceGroups" [
>>      {
>>          "sources": [ "foo.cpp" ],
>>          "defines": ["BUILD_TEST=1", "QT_CORE_LIB", "EXTRA_FOO=1"],
>>          "includes": ["/opt/bat/include", "/usr/include/qt5"]
>>      },
>>      {
>>          "sources": [ "bar.cpp" ],
>>          "defines": ["BUILD_TEST=1", "QT_CORE_LIB"],
>>          "includes": ["/opt/bat/include", "/usr/include/qt5"]
>>      }
>>   ]
>> ]
>>
>> Would be simpler to parse for us.
>
> Perhaps. CMake already has a source group concept (for IDEs to group
> sources), and your concept of a source group here seems to be about grouping
> files with common includes/defines/build properties? The two concepts may be
> in conflict.

Right, my sourceGroups are sets of sources that have the same settings
applied to them.

I was coming from the CMAKE_EXPORT_COMPILE_COMMANDS output which does
have the information we need for the code model, but in a rather
inconvenient form. Having the files with similar flags/defines/etc.
grouped would make parsing them a lot faster. Not having to parse
compiler command lines would further improve things:-) So I am all for
you adding this information into some JSON file.

I do not think there is a conflict between CMake source groups and
what I was referring to, except maybe in my poorly chosen name.

> For comparison, does any other buildsystem require header listings like
> this? With qmake, I can populate HEADERS, but I don't have to (for headers
> which do not require moc).

I am aware that listing all headers is not necessary for the build
system. It is one of those things where the needs of an IDE and those
of a build system differ.

Qmake asks for the headers to be listed. So does Qbs, which we want to
be great for IDE integration. Both will most likely not notice if you
forget some, but they won't be listed in Creator then.

Best Regards,
Tobias


From mantis at public.kitware.com  Mon Oct 20 07:57:19 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 20 Oct 2014 07:57:19 -0400
Subject: [cmake-developers] [CMake 0015212]: FILE READ skips semicolumn ;
Message-ID: 


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15212 
====================================================================== 
Reported By:                toncho11
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15212
Category:                   (No Category)
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-20 07:57 EDT
Last Modified:              2014-10-20 07:57 EDT
====================================================================== 
Summary:                    FILE READ skips semicolumn ;
Description: 
Every time I try to read a file with semicolumns, the resulted variable does not
contain it. 



Additional Information: 
It is pretty annoying when you finally find a way to do what you want and then
you encounter a bug ...
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-20 07:57 toncho11       New Issue                                    
======================================================================



From brad.king at kitware.com  Mon Oct 20 09:52:03 2014
From: brad.king at kitware.com (Brad King)
Date: Mon, 20 Oct 2014 09:52:03 -0400
Subject: [cmake-developers] ExternalProject CMAKE_ARGS and
 CMAKE_CACHE_ARGS arguments
In-Reply-To: <543FE392.7020706@gmail.com>
References: <543FE392.7020706@gmail.com>
Message-ID: <54451383.4070809@kitware.com>

On 10/16/2014 11:26 AM, Daniele E. Domenichelli wrote:
>   #    [CMAKE_ARGS args...]        # Arguments to CMake command line
>   #    [CMAKE_CACHE_ARGS args...]  # Initial cache arguments, of the form -Dvar:string=on
> 
> So, from what I understand, The first arguments are passed to the cmake
> command line, and from the second it is created a a cache file that is
> passed to cmake using -C. If the same variable is in both, CMAKE_ARGS
> wins over CMAKE_CACHE_ARGS.
[snip]
> This makes impossible to change a value later, and in my opinion makes
> one of the 2 arguments redundant, since the final effect of the 2
> variables is exactly the same.

CMAKE_CACHE_ARGS was added here:

 Added CMAKE_CACHE_ARGS to ExternalProject.
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=68cd3fe0

to overcome command line length limits.  CMAKE_ARGS can contain
arguments other than cache values.  Therefore they are not fully
redundant although there is overlap.

The name "initial cache" is poor both here and for the -C argument
to cmake because the option can be used any time.  It just happened
to originate for purposes of pre-populating some cache values on
the first run.

If you'd like, please propose clearer wording for the docs.

Thanks,
-Brad



From ydginster at gmail.com  Mon Oct 20 12:53:48 2014
From: ydginster at gmail.com (Evgeny Kalishenko)
Date: Mon, 20 Oct 2014 20:53:48 +0400
Subject: [cmake-developers] [PATCH] Preinstall requirements support for
 CPack RPM generator
In-Reply-To: <5443A04E.7030806@gmail.com>
References: 
 <543695B3.5010201@kitware.com>
 
 <5443A04E.7030806@gmail.com>
Message-ID: 

The final patch version with erroneous spelling fixes.

2014-10-19 15:28 GMT+04:00 Micha Hergarden :

>  On 10/09/2014 07:30 PM, Evgeny Kalishenko wrote:
>
> Ok, thanks for the advise about STREQUAL. Explanation of s/_/(/ (from
> http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html
> ):
> "Recent versions of RPM support context marked dependencies. This is a
> special type of a dependency that applies only in a specified *context*.
> Using this feature, one can specify dependencies for pre- and
> post(un)install scriptlets, ie. the context of a dependency is the
> execution time of the specified scriptlet.
>
> The syntax for specifying these dependencies is:
>
> Requires(*X*): foo
>
>    Here, *X* can be one of *pre*, *post*, *preun*, or *postun*, which
> tells RPM that the package depends on package foo for running the
> corresponding *%pre*, *%post*, *%preun*, or *%postun* script."
>
> Modified patch attached.
>
> 2014-10-09 18:03 GMT+04:00 Brad King :
>
>> On 10/08/2014 01:48 PM, Evgeny Kalishenko wrote:
>> > I was interested in feature request
>> > http://public.kitware.com/Bug/view.php?id=14769 and made a
>> > simple patch for CPack RPM generator (attached).
>>
>> Thanks.
>>
>> In this hunk:
>>
>> > +    # The following keywords require braces around the "pre" or "post"
>> suffix in the final RPM spec file.
>> > +    if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE"  OR
>> "${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST")
>> > +      string(REPLACE "_" "(" _PACKAGE_HEADER_NAME
>> "${_PACKAGE_HEADER_NAME}")
>> > +      set(_PACKAGE_HEADER_NAME "${_PACKAGE_HEADER_NAME})")
>> > +    endif()
>>
>> The MATCHES conditions can use simply STREQUAL instead.
>> I'm not very familiar with the spec format, so please
>> explain the purpose of the s/_/(/ subsitution in comments
>> here.
>>
>> Thanks,
>> -Brad
>>
>>
>
>
> --
> ? ?????????,
> ??????? ?????????
>
>
>  In this hunk:
> +#  May be used to set RPM postinstall dependencies (requires(post)).
> Note that you must enclose
> +#  the complete requires string between quotes, for example::
> +#
> +#   set(CPACK_RPM_PACKAGE_REQUIRES_PRE "shadow-utils, initscripts")
> +#
> +#
>
> The variable name CPACK_RPM_PACKAGE_REQUIRES_PRE should be
> CPACK_RPM_PACKAGE_REQUIRES_POST.
>
> In this hunk:
> +    # The following keywords require braces around the "pre" or "post"
> suffix in the final RPM spec file.
> +    if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE"  OR
> "${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST")
> +      string(REPLACE "_" "(" _PACKAGE_HEADER_NAME
> "${_PACKAGE_HEADER_NAME}")
> +      set(_PACKAGE_HEADER_NAME "${_PACKAGE_HEADER_NAME})")
> +    endif()
>
> Shouldn't braces be called parentheses here ( i.e '(' versus '{' )?
>
> I have checked with a minimal project on a ubuntu 14.04 box (using rpm
> 4.11.1) and the generated package seems good. So, no further comments.
>
> With kind regards,
> Micha Hergarden
>



-- 
Regards,
Evgeny Kalishenko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pre_post_rpm_install.patch
Type: text/x-patch
Size: 7633 bytes
Desc: not available
URL: 

From steveire at gmail.com  Mon Oct 20 13:15:34 2014
From: steveire at gmail.com (Stephen Kelly)
Date: Mon, 20 Oct 2014 19:15:34 +0200
Subject: [cmake-developers] Extracting target metadata, IDE integration
References: 
 
 
 
 
Message-ID: 

Tobias Hunger wrote:

> Hey Stephen,
> 
> On Sun, Oct 19, 2014 at 2:26 PM, Stephen Kelly
>  wrote:
>> No problem, thanks! I recently discovered that Creator makes fragile
>> guesses about source files and targets
>>
>> https://codereview.qt-project.org/#/c/96594/1/src/plugins/cmakeprojectmanager/cmakeproject.cpp,unified
>>
>> so I would really like to create a solution which makes that unnecessary.
> 
> I am no expert on this part of the codebase, but I would not be
> surprised if it did do some stupid things when seeing cmake. We do not
> support that too well.

What I mean is: the problem seems to be that source files are not listed 
per-target in the codeblock files CMake generates, so creator is forced to 
guess. I don't know if better information can be put into the C::B files, 
but I think the proposed json file is a better solution anyway. I don't 
generally like that creator (and clion) have to rely on parsing a foreign 
generators files.

>> Yes. I suppose beyond the WIN32_EXECUTABLE/ SUBSYSTEM:console / Mac
>> Bundle stuff the gui/console distinction doesn't really fit into the
>> buildsystem. Maybe such a checkbox, pre-populated with the hint, is
>> needed anyway.
> 
> Not into a build system, but into an IDE:-)

Yes, I wrote 'doesn't fit into the buildsystem' - implying it fits into the 
IDE, maybe in the form of a checkbox.

> I do not think there is a conflict between CMake source groups and
> what I was referring to, except maybe in my poorly chosen name.

I was thinking about a case where the source groups defined in 

 http://www.cmake.org/cmake/help/v3.0/command/source_group.html

commands would be exported in the JSON. I don't know if that's a good idea 
or not, but if it is, then yes, namespacing may be the only issue.
 
Thanks,

Steve.




From brad.king at kitware.com  Mon Oct 20 16:42:39 2014
From: brad.king at kitware.com (Brad King)
Date: Mon, 20 Oct 2014 16:42:39 -0400
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <5437F443.3040705@kitware.com>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com>
Message-ID: <544573BF.7060002@kitware.com>

On 10/10/2014 10:59 AM, Brad King wrote:
> Everything tested cleanly!  Adam, Clinton, thanks for your help
> bringing this topic to maturity.  It was the last non-regression
> topic I'm planning to take for 3.1.  I squashed the fixes and
> revised commit messages slightly.  Then I merged to 'master':
> 
>  Merge topic 'fix-OSX-bundle-rpaths-and-Qt5'
>  http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26bffa6e

We've been having problems getting the 3.1.0-rc1 release binaries
to work on machines other than those that built them.  Ever since
this topic was merged for testing on 2014-09-30, the nightly
binaries on OS X have not worked:

 $ /Volumes/cmake-3.0.20140929-g5748a-Darwin64-universal/CMake.app/Contents/bin/cmake-gui
 (works)

 $ /Volumes/cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/bin/cmake-gui
 Qt internal error: qt_menu.nib could not be loaded. The .nib file should be placed in QtGui.framework/Versions/Current/Resources/  or in the resources directory of your application bundle.

The .nib is present in the right place, but the binary does not see
them.  Comparing the working and broken versions:

$ diff -r /Volumes/cmake-3.0.20140929-g5748a-Darwin64-universal/CMake.app/Contents \
          /Volumes/cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents |
  diffstat
 cmake-3.0.20140929-g5748a-Darwin64-universal/CMake.app/Contents/Frameworks/QtGui.framework/Resources             |only
 cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtCore.framework/Versions/4/Resources |only
 cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtCore.framework/Versions/Current     |only
 cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtGui.framework/Versions/4/Resources  |only
 cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtGui.framework/Versions/Current      |only
 ...
 cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/share/cmake-3.0/Modules/BundleUtilities.cmake    |  135 ++++++++--
 cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/share/cmake-3.0/Modules/GetPrerequisites.cmake   |   29 +-
 16 files changed, 137 insertions(+), 36 deletions(-)

we can see that something in the frameworks is different and that
one of the only other changes is the BundleUtilities module.

Adam, Clinton, please take a look at this.  If it cannot be resolved
in the next couple days I will have to revert this topic and drop it
from the 3.1 release.

Thanks,
-Brad



From ono at java.pl  Mon Oct 20 18:41:15 2014
From: ono at java.pl (Adam Strzelecki)
Date: Tue, 21 Oct 2014 00:41:15 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <544573BF.7060002@kitware.com>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
Message-ID: <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl>

> $ /Volumes/cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/bin/cmake-gui
> Qt internal error: qt_menu.nib could not be loaded. The .nib file should be placed in QtGui.framework/Versions/Current/Resources/  or in the resources directory of your application bundle.

Did you build against Qt4 SDK taken from official installer? Can you put these both binaries somewhere (zipped) in the cloud?

BTW. Any reason to not use Qt5?

-- Adam



From domen.vrankar at gmail.com  Tue Oct 21 02:18:37 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 21 Oct 2014 08:18:37 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

>
> I also wrote a test and noticed two things:
> 1) CPackComponentsForAll test is using component names in lower case and
>  parts in variables in upper case (e.g. COMPONENT headers and
> CPACK_COMPONENT_HEADERS_DESCRIPTION). Patch uses
> CPACK_RPM_PACKAGE_COMPONENT variable as part of component variable name
> e.g. CPACK_RPM_headers_PACKAGE_DESCRIPTION.
> Because of this the fallback mechanism doesn't work correctly so is the
> correct variable format CPACK_COMPONENT_headers_PACKAGE_SUMMARY, CPACK_
> COMPONENT_HEADERS_PACKAGE_SUMMARY, both or case insensitive?
> If case insensitive option is the correct one - how do I implement that?
> Since all other RPM component variables use install( ... COMPONENT name)
> as part of variable name (so in this case that means lower case) I guess
> that RPM versions should stay as they are now (
> CPACK_RPM_headers_PACKAGE_DESCRIPTION for the above example).
>
> I have fixed a bug in my previous patch -
CPACK_COMPONENT__DESCRIPTION component must be in upper case.
CPACK_RPM_* is still treated the same way as with other
variables - install( ... COMPONENT name) and name is used as it is without
changing it to upper case.
I have also added semantic check tests of component description and summary
fall backs.

Patches must be applied in order:
0001-CPackRPM-component-based-packaging-description-and-s.patch
0001-add-added-semantic-tests-for-rpm-component-descripti.patch

Could someone pleas add the patches to git as I currently don't have commit
rights?

2) Package description fallback is currently written as
> set(CPACK_RPM_PACKAGE_DESCRIPTION "no package description available") and
> this is already in the code - not part of the patch. However if variable
> CPACK_PACKAGE_DESCRIPTION_FILE is not set it points by default to
> Templates/CPack.GenericDescription.txt and its content is "DESCRIPTION". So
> currently the above final fallback is dead code.
> Should I delete it or fix the code so that in case of default
> CPACK_PACKAGE_DESCRIPTION_FILE value it ignores it and uses "no package
> description available" text instead (would break the way it currently works
> so I'm guessing that deleting that part of code is the preferred option)?
> Can I put this change in the same patch since I am changing the fallback
> mechanism in it or should this be a different patch?
> If second - can I still attach the patch to the same mantis bug, do I open
> a new bug report or just create a patch and post it on the mailing list?
>

I will create a new bug tracker in mantis for this one and create a patch
there.

Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From seandepagnier at gmail.com  Tue Oct 21 03:51:45 2014
From: seandepagnier at gmail.com (sean d'epagnier)
Date: Tue, 21 Oct 2014 15:51:45 +0800
Subject: [cmake-developers] Fixes to the FindwxWidgets module
Message-ID: 

Hi,

I have recently been working on wxQT which allows wxWidgets to sit on top
of Qt (and thus target otherwise unsupported platforms like android and ios)

I found the FindwxWidgets module had a slight bug, but was not revealed
until I attempted to build applications which use wxQT.  I have corrected
it with the attached patch.

I was informed of the recent discussion:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10679

As I use Modules/FindwxWidgets.cmake but not Modules/UsewxWidgets.cmake, I
don't think the recent change will work, further, my change corrects more
problems.   I believe the commit "e6fa6e60f6330ddf60294a0d9a6ed4cb3f27d4c4"
is probably not needed after my patch  applied.

Thanks,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
--- FindwxWidgets.cmake	2014-06-25 14:41:27.490159713 +0800
+++ /usr/local/share/cmake-3.0/Modules/FindwxWidgets.cmake	2014-08-22 11:53:11.928480401 +0800
@@ -788,11 +789,16 @@
         # parse include dirs from cxxflags; drop -I prefix
         string(REGEX MATCHALL "-I[^;]+"
           wxWidgets_INCLUDE_DIRS "${wxWidgets_CXX_FLAGS}")
-        string(REGEX REPLACE "-I[^;]+;" ""
+        string(REGEX REPLACE "-I[^;]+(;|$)" ""
+          wxWidgets_CXX_FLAGS "${wxWidgets_CXX_FLAGS}")
+        string(REGEX REPLACE ";$" ""
           wxWidgets_CXX_FLAGS "${wxWidgets_CXX_FLAGS}")
         string(REPLACE "-I" ""
           wxWidgets_INCLUDE_DIRS "${wxWidgets_INCLUDE_DIRS}")
 
+        string(REGEX REPLACE ";" " "
+          wxWidgets_CXX_FLAGS "${wxWidgets_CXX_FLAGS}")
+
         DBG_MSG_V("wxWidgets_DEFINITIONS=${wxWidgets_DEFINITIONS}")
         DBG_MSG_V("wxWidgets_INCLUDE_DIRS=${wxWidgets_INCLUDE_DIRS}")
         DBG_MSG_V("wxWidgets_CXX_FLAGS=${wxWidgets_CXX_FLAGS}")

From pascal.bach at siemens.com  Tue Oct 21 05:24:28 2014
From: pascal.bach at siemens.com (Pascal Bach)
Date: Tue, 21 Oct 2014 11:24:28 +0200
Subject: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as tests
	for Windows CE
Message-ID: <1413883468-499-1-git-send-email-pascal.bach@siemens.com>

---
 Tests/CMakeLists.txt |   30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 25cc846..fc3359e 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1835,6 +1835,36 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release
     endif()
   endif()
 
+  get_filename_component(wince_sdk "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows CE Tools\\SDKs\\SDK_AM335X_SK_WEC2013_V310]" ABSOLUTE)
+  if(WIN32 AND EXISTS ${wince_sdk})
+    macro(add_test_VSWinCE name generator systemName systemVersion generatorPlatform)
+      # TODO: Fix the tutorial to make it work in cross compile
+      # currently the MakeTable is build for target and can not be used on the host
+      # This happens in part 5 so we build only part 1-4 of the tutorial
+      foreach(STP RANGE 1 4)
+        add_test(NAME "TutorialStep${STP}.${name}" COMMAND ${CMAKE_CTEST_COMMAND}
+          --build-and-test
+          "${CMake_SOURCE_DIR}/Tests/Tutorial/Step${STP}"
+          "${CMake_BINARY_DIR}/Tests/Tutorial/Step${STP}_${name}"
+          --build-generator "${generator}"
+          --build-project Tutorial
+          --build-config $
+          --build-options -DCMAKE_SYSTEM_NAME=${systemName}
+                          -DCMAKE_SYSTEM_VERSION=${systemVersion}
+                          -DCMAKE_GENERATOR_PLATFORM=${generatorPlatform})
+        list(APPEND TEST_BUILD_DIRS "${CMake_BINARY_DIR}/Tests/Tutorial/Step${STP}_${name}")
+      endforeach()
+    endmacro()
+
+    if(vs11)
+      add_test_VSWinCE(vs11-ce80-ARM "Visual Studio 11 2012" WindowsCE 8.0 SDK_AM335X_SK_WEC2013_V310)
+    endif()
+
+    if(vs12)
+      add_test_VSWinCE(vs12-ce80-ARM "Visual Studio 12 2013" WindowsCE 8.0 SDK_AM335X_SK_WEC2013_V310)
+    endif()
+  endif()
+
   if(tegra AND NOT "${CMake_SOURCE_DIR};${CMake_BINARY_DIR}" MATCHES " ")
     macro(add_test_VSNsightTegra name generator)
       add_test(NAME VSNsightTegra.${name} COMMAND ${CMAKE_CTEST_COMMAND}
-- 
1.7.10.4



From brad.king at kitware.com  Tue Oct 21 08:28:27 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 08:28:27 -0400
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl>
Message-ID: <5446516B.9060206@kitware.com>

On 10/20/2014 06:41 PM, Adam Strzelecki wrote:
> Did you build against Qt4 SDK taken from official installer?

It's a qt 4.8.0 installed from source.

 configure --prefix=... -opensource -confirm-license \
  -nomake demos -nomake examples -cocoa -shared -release \
  -arch x86 x86_64

We also tried one with just "-arch x86_64" as part of trying to package
only that architecture, but it has the same problem.

> Can you put these both binaries somewhere (zipped) in the cloud?

Nightly binaries are always published here:

 http://www.cmake.org/files/dev/

Specifically:

 http://www.cmake.org/files/dev/cmake-3.0.20140929-g5748a-Darwin64-universal.dmg
 http://www.cmake.org/files/dev/cmake-3.0.20140930-g37776-Darwin64-universal.dmg

> BTW. Any reason to not use Qt5?

We already have the infrastructure set up to use Qt4 and it has
worked well for years.  Prior to your patch the Qt5 package did
not work for redistribution due to the plugin problem anyway.

-Brad



From robert.maynard at kitware.com  Tue Oct 21 08:47:56 2014
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 21 Oct 2014 08:47:56 -0400
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <5446516B.9060206@kitware.com>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
Message-ID: 

Also as follow up the same Qt build is used for all Darwin64 releases and
nightlies. As far as I am aware this Qt build has been producing valid
deployable frameworks since before CMake 2.8.8

On Tue, Oct 21, 2014 at 8:28 AM, Brad King  wrote:

> On 10/20/2014 06:41 PM, Adam Strzelecki wrote:
> > Did you build against Qt4 SDK taken from official installer?
>
> It's a qt 4.8.0 installed from source.
>
>  configure --prefix=... -opensource -confirm-license \
>   -nomake demos -nomake examples -cocoa -shared -release \
>   -arch x86 x86_64
>
> We also tried one with just "-arch x86_64" as part of trying to package
> only that architecture, but it has the same problem.
>
> > Can you put these both binaries somewhere (zipped) in the cloud?
>
> Nightly binaries are always published here:
>
>  http://www.cmake.org/files/dev/
>
> Specifically:
>
>
> http://www.cmake.org/files/dev/cmake-3.0.20140929-g5748a-Darwin64-universal.dmg
>
> http://www.cmake.org/files/dev/cmake-3.0.20140930-g37776-Darwin64-universal.dmg
>
> > BTW. Any reason to not use Qt5?
>
> We already have the infrastructure set up to use Qt4 and it has
> worked well for years.  Prior to your patch the Qt5 package did
> not work for redistribution due to the plugin problem anyway.
>
> -Brad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From brad.king at kitware.com  Tue Oct 21 08:50:08 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 08:50:08 -0400
Subject: [cmake-developers] [PATCH] Preinstall requirements support for
 CPack RPM generator
In-Reply-To: 
References: 	<543695B3.5010201@kitware.com>		<5443A04E.7030806@gmail.com>
 
Message-ID: <54465680.9060003@kitware.com>

On 10/20/2014 12:53 PM, Evgeny Kalishenko wrote:
> The final patch version with erroneous spelling fixes.

Thanks.  Please configure your git 'user.name' so that proper
authorship is recorded with your Real Name.  Also please squash
the spelling fixup changes back in the commit that they fixup.

>> Here, /X/ can be one of *pre*, *post*, *preun*, or *postun*

The PREUN and POSTUN patch does not add documentation of any
corresponding CPackRPM variables.  Should it?

Thanks,
-Brad



From brad.king at kitware.com  Tue Oct 21 08:52:18 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 08:52:18 -0400
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: <54465702.6010805@kitware.com>

On 10/21/2014 02:18 AM, Domen Vrankar wrote:
> Patches must be applied in order:
> 0001-CPackRPM-component-based-packaging-description-and-s.patch
> 0001-add-added-semantic-tests-for-rpm-component-descripti.patch
> 
> Could someone pleas add the patches to git as I currently don't have commit rights?

Did you mean to attach the patches to the message?

> I will create a new bug tracker in mantis for this one and create a patch there.

I prefer patches on the mailing list where they can get a broader audience
and email-based reviews.

Thanks,
-Brad



From brad.king at kitware.com  Tue Oct 21 08:58:21 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 08:58:21 -0400
Subject: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as
 tests for Windows CE
In-Reply-To: <1413883468-499-1-git-send-email-pascal.bach@siemens.com>
References: <1413883468-499-1-git-send-email-pascal.bach@siemens.com>
Message-ID: <5446586D.6010107@kitware.com>

On 10/21/2014 05:24 AM, Pascal Bach wrote:
> ---
>  Tests/CMakeLists.txt |   30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)

The Wow6432Node path component should not be needed because
CMake is aware of how to lookup different registry views.
Also we can fold the lookup into existing infrastructure
a few lines above.

Please try the attached revision to your patch.

Thanks,
-Brad

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Tests-Run-Tutorial-steps-1-4-as-tests-for-Windows-CE.patch
Type: text/x-diff
Size: 3153 bytes
Desc: not available
URL: 

From domen.vrankar at gmail.com  Tue Oct 21 09:00:38 2014
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Tue, 21 Oct 2014 15:00:38 +0200
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: <54465702.6010805@kitware.com>
References: 
 
 
 
 
 
 
 <54465702.6010805@kitware.com>
Message-ID: 

2014-10-21 14:52 GMT+02:00 Brad King :

> On 10/21/2014 02:18 AM, Domen Vrankar wrote:
> > Patches must be applied in order:
> > 0001-CPackRPM-component-based-packaging-description-and-s.patch
> > 0001-add-added-semantic-tests-for-rpm-component-descripti.patch
> >
> > Could someone pleas add the patches to git as I currently don't have
> commit rights?
>
> Did you mean to attach the patches to the message?
>
>
I just added the patch to mantis bug report. I'm still getting used to the
process.
Here are the mentioned patches.


> > I will create a new bug tracker in mantis for this one and create a
> patch there.
>
> I prefer patches on the mailing list where they can get a broader audience
> and email-based reviews.
>

OK. I'll send it to the mailing list as soon as I write it.


>
> Thanks,
> -Brad
>
>

Thanks,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-added-semantic-tests-for-rpm-component-descripti.patch
Type: text/x-patch
Size: 6250 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-CPackRPM-component-based-packaging-description-and-s.patch
Type: text/x-patch
Size: 5040 bytes
Desc: not available
URL: 

From brad.king at kitware.com  Tue Oct 21 09:02:15 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 09:02:15 -0400
Subject: [cmake-developers] Fixes to the FindwxWidgets module
In-Reply-To: 
References: 
Message-ID: <54465957.8040600@kitware.com>

On 10/21/2014 03:51 AM, sean d'epagnier wrote:
> I was informed of the recent discussion:
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10679

Additional discussion in an issue tracker entry linked from that thread:

 http://www.cmake.org/Bug/view.php?id=15087

explains how we cannot change the value presented because projects
could be depending on the current one.  See:

 http://www.cmake.org/Bug/view.php?id=15087#c36639

-Brad



From hobbes1069 at gmail.com  Tue Oct 21 09:03:48 2014
From: hobbes1069 at gmail.com (Richard Shaw)
Date: Tue, 21 Oct 2014 08:03:48 -0500
Subject: [cmake-developers] Fixes to the FindwxWidgets module
In-Reply-To: 
References: 
Message-ID: 

On Tue, Oct 21, 2014 at 2:51 AM, sean d'epagnier 
wrote:

> Hi,
>
> I have recently been working on wxQT which allows wxWidgets to sit on top
> of Qt (and thus target otherwise unsupported platforms like android and ios)
>
> I found the FindwxWidgets module had a slight bug, but was not revealed
> until I attempted to build applications which use wxQT.  I have corrected
> it with the attached patch.
>
> As I use Modules/FindwxWidgets.cmake but not Modules/UsewxWidgets.cmake, I
> don't think the recent change will work, further, my change corrects more
> problems.   I believe the commit "e6fa6e60f6330ddf60294a0d9a6ed4cb3f27d4c4"
> is probably not needed after my patch  applied.
>

I'm not a REGEX expert, I usually just figure out what I need when I need
it :) The first half of the patch looks fine to me as it seems to be just
dealing with the end of a line or the "last flag".

I planned on implementing the 2nd half of your patch myself but was
informed that current users may be expecting a list there which is why I
moved the conversion from ";" to " " in the UsewxWidgets file.

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ono at java.pl  Tue Oct 21 09:17:57 2014
From: ono at java.pl (Adam Strzelecki)
Date: Tue, 21 Oct 2014 15:17:57 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: 
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
Message-ID: 

Please hold your breath, and don't yet revert my patches because you will end up with bundle that you cannot code-sign anyway for 10.10 and >=10.9.5 and it will be bad release that will be rejected by Gatekeeper upon launch.

First of all this is in fact Qt bug, please follow discussion at:

	http://lists.qt-project.org/pipermail/development/2014-September/018505.html

The patches I provided, especially 55707fd5, were intended to workaround that so app will code-sign with >=10.9.5, especially for Qt case where their frameworks had incorrect layout causing code sign fail for whole bundle:

	$ codesign -v --deep -s 'Developer ID' CMake.app
	CMake.app: bundle format unrecognized, invalid, or unsuitable
	In subcomponent: /private/tmp/CMake.app/Contents/Frameworks/QtCore.framework

As I used Qt5 for my own CMake build there is no problem with Qt5 here. But indeed I haven't try to build CMake against last stable Qt 4.8 (that is known to have incorrect layout).

Moreover Qt4 seeks hardly for Resources/ folder in framework root, which is not there anymore as it is not obligatory to have Resource/ symlinks. Also QtGui.framework misses Info.plist in Version/4/Resources/. So fix is as simple as:

(1) extra symlink Resources/ -> Version/Current/Resources/ (for sake of Qt SDK)
(2) ensure Info.plist in Version/4/Resources/

I'll try build Qt4 SDK myself as you do and checkout what's the bundle layout of theirs.

Cheers,
-- 
Adam

From brad.king at kitware.com  Tue Oct 21 09:19:55 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 09:19:55 -0400
Subject: [cmake-developers] [CPack] [CPackRPM] mantis ticket 13176
 CPackRPM support for per-component summary and description
In-Reply-To: 
References: 							<54465702.6010805@kitware.com>
 
Message-ID: <54465D7B.3000005@kitware.com>

On 10/21/2014 09:00 AM, Domen Vrankar wrote:
> Here are the mentioned patches.

Thanks.  I see no reason not to squash them together since
the second one just fixes and tests the first one.  Applied:

 CPackRPM: Add component based packaging description and summary
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=603ef7fd

-Brad



From brad.king at kitware.com  Tue Oct 21 09:24:09 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 09:24:09 -0400
Subject: [cmake-developers] Xcode Project: Support for DevelopmentTeam
In-Reply-To: 
References: 
Message-ID: <54465E79.4070308@kitware.com>

On 10/17/2014 04:16 PM, Fabian wrote:
> Xcode automatically updates the devices list in the Member Center

Neat.  Please explain the developer workflow you envision to configure
the value for local build trees.  Would it be something the developer
should explicitly set in every new tree?  Should there be a common
configuration in the environment?  Can it be detected programmatically?

> In the CMake source I noticed that 'BuildIndependentTargetsInParallel'
> is already getting set. This could be extendet to add the 'TargetAttributes'
> section.

Yes, that looks like the right place if you want to try a patch.

> This could be set with a CMake flag.

The generator could check a variable like

 CMAKE_XCODE_DEVELOPMENT_TEAM

to get the value, but please answer my questions above about the
workflow.

Thanks,
-Brad


From pascal.bach at siemens.com  Tue Oct 21 09:26:34 2014
From: pascal.bach at siemens.com (Bach, Pascal)
Date: Tue, 21 Oct 2014 13:26:34 +0000
Subject: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as
 tests for Windows CE
In-Reply-To: <5446586D.6010107@kitware.com>
References: <1413883468-499-1-git-send-email-pascal.bach@siemens.com>
 <5446586D.6010107@kitware.com>
Message-ID: <355BE46A91031048906B695426A8D8E616AE6358@DEFTHW99EH4MSX.ww902.siemens.net>

Your revision looks better ;)

I even would prefer to not hardcode the SDK  but I was unable to list key entries from the registry.

Usually all installed SDKs are listed as subkeys of HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows CE Tools\\SDKs in this case it is SDK_AM335X_SK_WEC2013_V310.

I think the test would be nicer if it checks for available SDKs and just picks the first.

Any ideas how to do this?

Regards
Pascal

> -----Original Message-----
> From: Brad King [mailto:brad.king at kitware.com]
> Sent: Dienstag, 21. Oktober 2014 14:58
> To: Bach, Pascal; cmake-developers at cmake.org
> Subject: Re: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as
> tests for Windows CE
> 
> On 10/21/2014 05:24 AM, Pascal Bach wrote:
> > ---
> >  Tests/CMakeLists.txt |   30 ++++++++++++++++++++++++++++++
> >  1 file changed, 30 insertions(+)
> 
> The Wow6432Node path component should not be needed because
> CMake is aware of how to lookup different registry views.
> Also we can fold the lookup into existing infrastructure
> a few lines above.
> 
> Please try the attached revision to your patch.
> 
> Thanks,
> -Brad



From brad.king at kitware.com  Tue Oct 21 09:27:54 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 09:27:54 -0400
Subject: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as
 tests for Windows CE
In-Reply-To: <355BE46A91031048906B695426A8D8E616AE6358@DEFTHW99EH4MSX.ww902.siemens.net>
References: <1413883468-499-1-git-send-email-pascal.bach@siemens.com>
 <5446586D.6010107@kitware.com>
 <355BE46A91031048906B695426A8D8E616AE6358@DEFTHW99EH4MSX.ww902.siemens.net>
Message-ID: <54465F5A.6000208@kitware.com>

On 10/21/2014 09:26 AM, Bach, Pascal wrote:
> Your revision looks better ;)
> 
> I even would prefer to not hardcode the SDK  but I was unable to list key entries from the registry.
> 
> Usually all installed SDKs are listed as subkeys of HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows CE Tools\\SDKs in this case it is SDK_AM335X_SK_WEC2013_V310.
> 
> I think the test would be nicer if it checks for available SDKs and just picks the first.
> 
> Any ideas how to do this?

Within a block guarded by if(CMAKE_HOST_WIN32) you could
use execute_process to run the "reg" command-line tool.

-Brad



From brad.king at kitware.com  Tue Oct 21 09:35:06 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 09:35:06 -0400
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: 
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
 
Message-ID: <5446610A.8020609@kitware.com>

On 10/21/2014 09:17 AM, Adam Strzelecki wrote:
> First of all this is in fact Qt bug, please follow discussion at:
> 
> 	http://lists.qt-project.org/pipermail/development/2014-September/018505.html
> 
> The patches I provided, especially 55707fd5, were intended to workaround that
[snip]
> I'll try build Qt4 SDK myself as you do and checkout what's the bundle layout of theirs.

Regardless of where the bug lies, your changes took a packaging
case that worked and made it not work.  That is a regression.
Working around it for the packaging machine of CMake itself is
not a solution because it could happen to any project built this
way.

Please extend your changes to restore successful packaging with
no special help by adding whatever workarounds are needed.  If
the result is not signable when the workarounds are in place that
is okay because we couldn't sign before either.

Thanks,
-Brad



From robert.maynard at kitware.com  Tue Oct 21 09:42:34 2014
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 21 Oct 2014 09:42:34 -0400
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: 
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
 
Message-ID: 

We have never symlinked Resources/ to Version/Current/Resources since we
place icons on other images under the Resources/ folder.

The Info.plist has always been placed in the root of Contents, and is still
there after the changes.

On Tue, Oct 21, 2014 at 9:17 AM, Adam Strzelecki  wrote:

> Please hold your breath, and don't yet revert my patches because you will
> end up with bundle that you cannot code-sign anyway for 10.10 and >=10.9.5
> and it will be bad release that will be rejected by Gatekeeper upon launch.
>
> First of all this is in fact Qt bug, please follow discussion at:
>
>
> http://lists.qt-project.org/pipermail/development/2014-September/018505.html
>
> The patches I provided, especially 55707fd5, were intended to workaround
> that so app will code-sign with >=10.9.5, especially for Qt case where
> their frameworks had incorrect layout causing code sign fail for whole
> bundle:
>
>         $ codesign -v --deep -s 'Developer ID' CMake.app
>         CMake.app: bundle format unrecognized, invalid, or unsuitable
>         In subcomponent:
> /private/tmp/CMake.app/Contents/Frameworks/QtCore.framework
>
> As I used Qt5 for my own CMake build there is no problem with Qt5 here.
> But indeed I haven't try to build CMake against last stable Qt 4.8 (that is
> known to have incorrect layout).
>
> Moreover Qt4 seeks hardly for Resources/ folder in framework root, which
> is not there anymore as it is not obligatory to have Resource/ symlinks.
> Also QtGui.framework misses Info.plist in Version/4/Resources/. So fix is
> as simple as:
>
> (1) extra symlink Resources/ -> Version/Current/Resources/ (for sake of Qt
> SDK)
> (2) ensure Info.plist in Version/4/Resources/
>
> I'll try build Qt4 SDK myself as you do and checkout what's the bundle
> layout of theirs.
>
> Cheers,
> --
> Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ono at java.pl  Tue Oct 21 09:44:59 2014
From: ono at java.pl (Adam Strzelecki)
Date: Tue, 21 Oct 2014 15:44:59 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: 
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
 
 
Message-ID: 

> We have never symlinked Resources/ to Version/Current/Resources since we place icons on other images under the Resources/ folder.
> 
> The Info.plist has always been placed in the root of Contents, and is still there after the changes.

Sorry, maybe I it wasn't clear enough but I am talking about Framework's root and bundled Frameworks layout not app bundle layout here.

--Adam



From ono at java.pl  Tue Oct 21 09:59:19 2014
From: ono at java.pl (Adam Strzelecki)
Date: Tue, 21 Oct 2014 15:59:19 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <5446610A.8020609@kitware.com>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
  <5446610A.8020609@kitware.com>
Message-ID: <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl>

> Regardless of where the bug lies, your changes took a packaging
> case that worked and made it not work.  That is a regression.

I am sorry, but 55707fd5 in fact does it CORRECT WAY as it is expressed in:

https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html

and expected by code-sign.

Resources/ folder needs to lie in VERSION folder, so in out case QtGui.framework/Versions/4/Resources/

Previous CMake was checking and copying QtGui.framework/Resources/ which is WRONG as this is wrong place, and it may just be symlink to CORRECT place. But such symlink is not obligatory in final bundle.

It WAS working because Qt was looking in WRONG place for .nib file that was copied. Also before 10.9.5 it was code signing well because Apple put some heuristics to allow lousy bundles. But these were removed in 10.9.5 for code signed bundles.

But assuming we restore Resources/ optional symlink we can circumvent that. And I am working on the patch, just give me few minutes.

> Working around it for the packaging machine of CMake itself is
> not a solution because it could happen to any project built this
> way.

I used wrong word, this was not workaround, but introduction of correct behavior. But I will add extra change that will restore Resources/ symlinks as well.

> Please extend your changes to restore successful packaging with
> no special help by adding whatever workarounds are needed.

If I remove all workarounds and do it ONLY correct way as Apple specified then apps using currently release Qt SDKs will not work :>

Please note this has been fixes in Qt 5.4 beta, so we could remove workarounds, but then only most recent Qt SDK would work fine.

If you need more information ping me on IRC.

--Adam



From daniele.domenichelli at gmail.com  Tue Oct 21 10:01:19 2014
From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli)
Date: Tue, 21 Oct 2014 16:01:19 +0200
Subject: [cmake-developers] ExternalProject CMAKE_ARGS and
 CMAKE_CACHE_ARGS arguments
In-Reply-To: <54451383.4070809@kitware.com>
References: <543FE392.7020706@gmail.com> <54451383.4070809@kitware.com>
Message-ID: <5446672F.3070501@gmail.com>

On 20/10/14 15:52, Brad King wrote:
> On 10/16/2014 11:26 AM, Daniele E. Domenichelli wrote:
>>   #    [CMAKE_ARGS args...]        # Arguments to CMake command line
>>   #    [CMAKE_CACHE_ARGS args...]  # Initial cache arguments, of the form -Dvar:string=on
>>
>> So, from what I understand, The first arguments are passed to the cmake
>> command line, and from the second it is created a a cache file that is
>> passed to cmake using -C. If the same variable is in both, CMAKE_ARGS
>> wins over CMAKE_CACHE_ARGS.
> [snip]
>> This makes impossible to change a value later, and in my opinion makes
>> one of the 2 arguments redundant, since the final effect of the 2
>> variables is exactly the same.
> 
> CMAKE_CACHE_ARGS was added here:
> 
>  Added CMAKE_CACHE_ARGS to ExternalProject.
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=68cd3fe0
> 
> to overcome command line length limits.  CMAKE_ARGS can contain
> arguments other than cache values.  Therefore they are not fully
> redundant although there is overlap.

Ok, I see.

I would like to be able to set some some variables (for example
CMAKE_BUILD_TYPE) for all the "external project" according to the value
in the "super-project", but the same time I would like to be able to
change them (for example change CMAKE_BUILD_TYPE to Debug if I'm
building in Release mode) for just one external project without changing
it in all of them, and having to rebuild everything.
But actually I don't like the idea that all of them could be modified,
for example in my case the user should not have the control over the
CMAKE_INSTALL_PREFIX variable...

Maybe, since the "-D" is actually a convention to match the CMAKE_ARGS
argument that does some sort of conversion from "-Dvar:type=value" to a
"set(var value CACHE type "Initial cache" FORCE)" command, it could be
possible to accept some other form of string, maybe "+D", or "-", so that:

 -Dvar:type=value -> set(var value CACHE type "Initial cache" FORCE)
 +Dvar:type=value -> set(var value CACHE type "Initial cache" )

This would ensure backwards compatibility, with no extra arguments and
could allow a quick switch from forced to non-forced, just by changing
one character.

Would you accept something like this?


Cheers,
 Daniele



From clinton at elemtech.com  Tue Oct 21 10:25:10 2014
From: clinton at elemtech.com (Clinton Stimpson)
Date: Tue, 21 Oct 2014 08:25:10 -0600
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <1619747.Fr49X3lPFJ@stryke>
References: <542ACE37.1040302@kitware.com>
 <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl> <1619747.Fr49X3lPFJ@stryke>
Message-ID: <94276785.r0XvlNa4HJ@stryke>

On Tuesday, October 21, 2014 08:22:24 AM Clinton Stimpson wrote:
> On Tuesday, October 21, 2014 03:59:19 PM Adam Strzelecki wrote:
> > > Regardless of where the bug lies, your changes took a packaging
> > > case that worked and made it not work.  That is a regression.
> > 
> > I am sorry, but 55707fd5 in fact does it CORRECT WAY as it is expressed
> > in:
> > 
> > https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BP
> > Fr ameworks/Concepts/FrameworkAnatomy.html
> > 
> > and expected by code-sign.
> > 
> > Resources/ folder needs to lie in VERSION folder, so in out case
> > QtGui.framework/Versions/4/Resources/
> > 
> > Previous CMake was checking and copying QtGui.framework/Resources/ which
> > is
> > WRONG as this is wrong place, and it may just be symlink to CORRECT place.
> > But such symlink is not obligatory in final bundle.
> > 
> > It WAS working because Qt was looking in WRONG place for .nib file that
> > was
> > copied. Also before 10.9.5 it was code signing well because Apple put some
> > heuristics to allow lousy bundles. But these were removed in 10.9.5 for
> > code signed bundles.
> > 
> > But assuming we restore Resources/ optional symlink we can circumvent
> > that.
> > And I am working on the patch, just give me few minutes.
> 
> +1 for a symlink.  Handling of framework resources in BundleUtilities.cmake
> was originally based on the buggy Qt behavior.  I think Adam's suggested fix
> here is good.
> 
> 

And for the Qt internal error:

" Qt internal error: qt_menu.nib could not be loaded. The .nib file should be 
placed in QtGui.framework/Versions/Current/Resources/  or in the resources 
directory of your application bundle."

The message is incorrect.  Qt is actually looking for the resource in 
QtGui.framework/Resources/

Clint


From brad.king at kitware.com  Tue Oct 21 10:30:20 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 10:30:20 -0400
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
  <5446610A.8020609@kitware.com>
 <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl>
Message-ID: <54466DFC.4070403@kitware.com>

On 10/21/2014 09:59 AM, Adam Strzelecki wrote:
> But assuming we restore Resources/ optional symlink we can circumvent
> that. And I am working on the patch, just give me few minutes.

Great, thanks!

-Brad



From clinton at elemtech.com  Tue Oct 21 10:22:24 2014
From: clinton at elemtech.com (Clinton Stimpson)
Date: Tue, 21 Oct 2014 08:22:24 -0600
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl>
References: <542ACE37.1040302@kitware.com> <5446610A.8020609@kitware.com>
 <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl>
Message-ID: <1619747.Fr49X3lPFJ@stryke>

On Tuesday, October 21, 2014 03:59:19 PM Adam Strzelecki wrote:
> > Regardless of where the bug lies, your changes took a packaging
> > case that worked and made it not work.  That is a regression.
> 
> I am sorry, but 55707fd5 in fact does it CORRECT WAY as it is expressed in:
> 
> https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFr
> ameworks/Concepts/FrameworkAnatomy.html
> 
> and expected by code-sign.
> 
> Resources/ folder needs to lie in VERSION folder, so in out case
> QtGui.framework/Versions/4/Resources/
> 
> Previous CMake was checking and copying QtGui.framework/Resources/ which is
> WRONG as this is wrong place, and it may just be symlink to CORRECT place.
> But such symlink is not obligatory in final bundle.
> 
> It WAS working because Qt was looking in WRONG place for .nib file that was
> copied. Also before 10.9.5 it was code signing well because Apple put some
> heuristics to allow lousy bundles. But these were removed in 10.9.5 for
> code signed bundles.
> 
> But assuming we restore Resources/ optional symlink we can circumvent that.
> And I am working on the patch, just give me few minutes.

+1 for a symlink.  Handling of framework resources in BundleUtilities.cmake 
was originally based on the buggy Qt behavior.  I think Adam's suggested fix 
here is good.


Clint


> > Working around it for the packaging machine of CMake itself is
> > not a solution because it could happen to any project built this
> > way.
> 
> I used wrong word, this was not workaround, but introduction of correct
> behavior. But I will add extra change that will restore Resources/ symlinks
> as well.
> > Please extend your changes to restore successful packaging with
> > no special help by adding whatever workarounds are needed.
> 
> If I remove all workarounds and do it ONLY correct way as Apple specified
> then apps using currently release Qt SDKs will not work :>
> 
> Please note this has been fixes in Qt 5.4 beta, so we could remove
> workarounds, but then only most recent Qt SDK would work fine.
> 
> If you need more information ping me on IRC.
> 
> --Adam




From aklitzing at gmail.com  Tue Oct 21 10:37:56 2014
From: aklitzing at gmail.com (A. Klitzing)
Date: Tue, 21 Oct 2014 16:37:56 +0200
Subject: [cmake-developers] Support of codesign
In-Reply-To: <543FD64A.1040907@kitware.com>
References: 
 
 
 <2614570.QAlDDbOxL6@stryke> <543FD64A.1040907@kitware.com>
Message-ID: 

Hi,

I attached another patch to address the given issues.


On 09/26/2014 10:08 AM, clinton at elemtech.com wrote:
> > I would suggest the SignPackage function be moved from
> > cmCPackDragNDropGenerator to cmCPackBundleGenerator because
> > its implementation is only usable by cmCPackBundleGenerator.
> > It uses CPACK_BUNDLE_NAME which is only valid in the context
> > of cmCPackBundleGenerator.
>

Yes, I moved it and DragNDrop is untouched now. That was just a
copy+paste+modify mistake.


> On 09/29/2014 09:55 AM, clinton at elemtech.com wrote:
> > Because it appears to only work with the Bundle generator, can
> > you please move the documentation from Modules/CPackDMG.cmake
> > to Modules/CPackBundle.cmake?
> > Or did you intend to make this feature work for both the
> > DragNDrop and Bundle generator?
>

Same here....



> On 09/29/2014 02:00 PM, Clinton Stimpson wrote:
> > I think application signing is generally not a CPack thing, but
> > there probably isn't much of a choice if the Bundle generator
> > is used.
>

Well, it isn't possible to sign that bundle without it. There must be a
step between bundle and dmg. Maybe cmake could support that, too. So custom
processing could be more flexible.
But I think cmake should support more codesigning tools by itself to unify
the handling. For example.... we sign our MSI for windows with a custom
command. This could be integrated into a unifed CPACK variable.

Best regards
  Andr? Klitzing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-CPack-Add-support-for-code-signing-of-bundles-on-Mac.patch
Type: text/x-diff
Size: 7314 bytes
Desc: not available
URL: 

From ono at java.pl  Tue Oct 21 11:34:23 2014
From: ono at java.pl (Adam Strzelecki)
Date: Tue, 21 Oct 2014 17:34:23 +0200
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <54466DFC.4070403@kitware.com>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
  <5446610A.8020609@kitware.com>
 <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl> <54466DFC.4070403@kitware.com>
Message-ID: <5520EEFC-3B8E-4487-992E-F36700486256@java.pl>

Done. Tested with Qt5 & Qt4, pushed as f9fcea6803f636adfc9f5755d9c92c802cdc2fb6 to stage/fix-OSX-bundle-rpaths-and-Qt5 (last commit to this branch).

@Brad: Shall I make it as separate branch and merge for staging, or you can simply cherry-pick it?

--Adam

commit f9fcea6803f636adfc9f5755d9c92c802cdc2fb6
Author: Adam Strzelecki 
Date:   Tue Oct 21 16:42:33 2014 +0200

    Ensure framework symlinks and Info.plist exist
    
    This restores Qt SDK 4.8 and >= 10.6.5 codesign compatibility improving
    embedding frameworks using correct bundle layout described at:
    
    https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html
    
    1. If Versions/VERSION/Resources/Info.plist is missing, well known incorrect
       locations are checked for Info.plist and Info.plist is copied from there,
       otherwise codesign will fail.
    
    2. Root framework symlinks to binary and Resources are restored to point inside
       Versions/Current, otherwise Qt 4.8 looking for Resources/ in framework root
       will fail.



From clinton at elemtech.com  Tue Oct 21 11:44:33 2014
From: clinton at elemtech.com (Clinton Stimpson)
Date: Tue, 21 Oct 2014 09:44:33 -0600
Subject: [cmake-developers] Support of codesign
In-Reply-To: 
References: 
 <543FD64A.1040907@kitware.com>
 
Message-ID: <6639644.c5E5zbx6zX@stryke>

On Tuesday, October 21, 2014 04:37:56 PM A. Klitzing wrote:
> Hi,
> 
> I attached another patch to address the given issues.
> 
> On 09/26/2014 10:08 AM, clinton at elemtech.com wrote:
> > > I would suggest the SignPackage function be moved from
> > > cmCPackDragNDropGenerator to cmCPackBundleGenerator because
> > > its implementation is only usable by cmCPackBundleGenerator.
> > > It uses CPACK_BUNDLE_NAME which is only valid in the context
> > > of cmCPackBundleGenerator.
> 
> Yes, I moved it and DragNDrop is untouched now. That was just a
> copy+paste+modify mistake.
> 
> > On 09/29/2014 09:55 AM, clinton at elemtech.com wrote:
> > > Because it appears to only work with the Bundle generator, can
> > > you please move the documentation from Modules/CPackDMG.cmake
> > > to Modules/CPackBundle.cmake?
> > > Or did you intend to make this feature work for both the
> > > DragNDrop and Bundle generator?
> 
> Same here....
> 
> > On 09/29/2014 02:00 PM, Clinton Stimpson wrote:
> > > I think application signing is generally not a CPack thing, but
> > > there probably isn't much of a choice if the Bundle generator
> > > is used.
> 
> Well, it isn't possible to sign that bundle without it. There must be a
> step between bundle and dmg. Maybe cmake could support that, too. So custom
> processing could be more flexible.

It *is* possible by using the more customizable DragNDrop generator.  With the 
DragNDrop generator, you will have a chance to sign the bundle before its put 
into a dmg.  You also have that same chance with the PackageMaker generator.

Because the design of this Bundle generator is not consistent with the rest of 
the CPack generators, you don't have this same chance, and the only way to do 
customization is to keep adding patches like yours.


> But I think cmake should support more codesigning tools by itself to unify
> the handling. For example.... we sign our MSI for windows with a custom
> command. This could be integrated into a unifed CPACK variable.

A code signing solution in CMake would be an interesting proposition.

Clint


From brad.king at kitware.com  Tue Oct 21 11:45:07 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 21 Oct 2014 11:45:07 -0400
Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
In-Reply-To: <5520EEFC-3B8E-4487-992E-F36700486256@java.pl>
References: <542ACE37.1040302@kitware.com>
 <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com>
 <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke>
 <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com>
 <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com>
 <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com>
 
  <5446610A.8020609@kitware.com>
 <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl> <54466DFC.4070403@kitware.com>
 <5520EEFC-3B8E-4487-992E-F36700486256@java.pl>
Message-ID: <54467F83.4030309@kitware.com>

On 10/21/2014 11:34 AM, Adam Strzelecki wrote:
> @Brad: Shall I make it as separate branch and merge for staging,
> or you can simply cherry-pick it?

I cherry-picked it over on top of the revised/squashed copy of
the topic that was merged to 'master':

 BundleUtilities: Ensure framework symlinks and Info.plist exist
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41564ff2

I've merged it for testing in 'next'.  Thanks for taking care
of this so quickly!

-Brad



From ono at java.pl  Tue Oct 21 12:16:58 2014
From: ono at java.pl (Adam Strzelecki)
Date: Tue, 21 Oct 2014 18:16:58 +0200
Subject: [cmake-developers] CMake.app Qt5 vs Qt4 on 10.10
Message-ID: 

Following discussion regarding fix-OSX-bundle-rpaths-and-Qt5 topic I just wanted to share with you how CMake looks with Qt4 vs Qt5 on Yosemite:

	https://www.dropbox.com/s/knnybhed8fahste/CMake3.1rc1-Qt4.8.6-Yosemite.png
	https://www.dropbox.com/s/tm95rntexn4z6j6/CMake3.1rc1-Qt5.4-Yosemite.png

As you can see Qt4 has some problems with button test layout. Anyway nothing serious that prevents it from running. Please note I am using Qt 4.8.6 there not 4.8.0 as it is used for official builds (as far I understood correctly from what Robert told me on IRC).

FYI CMake bundle is 62MB with Qt4 vs 66MB with Qt5 (64-bit Intel only).

--Adam

From mantis at public.kitware.com  Tue Oct 21 14:59:24 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Tue, 21 Oct 2014 14:59:24 -0400
Subject: [cmake-developers] [CMake 0015213]: CMAKE_MODULE_LIBRARY_SUFFIX is
	not set
Message-ID: <754a7be1d7f306a670627cc40ea8b0cf@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15213 
====================================================================== 
Reported By:                Hartmut Seichter
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15213
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-21 14:59 EDT
Last Modified:              2014-10-21 14:59 EDT
====================================================================== 
Summary:                    CMAKE_MODULE_LIBRARY_SUFFIX is not set
Description: 
This might be also relevant to other OSX variants.

CMAKE_MODULE_LIBRARY_SUFFIX is not set. However, compiling shared libraries as
modules produces correctly libraries with suffix .so (unlike .dylib) ... 


Steps to Reproduce: 
create a shared library - compile as MODULE ... results in .so 
use system introspection such as a config file - CMAKE_MODULE_LIBRARY_SUFFIX
returns nothing. In comparison, CMAKE_SHARED_LIBRARY_SUFFIX correctly is set to
".dylib"
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2014-10-21 14:59 Hartmut SeichterNew Issue                                    
======================================================================



From jamesbigler at gmail.com  Tue Oct 21 17:09:18 2014
From: jamesbigler at gmail.com (James Bigler)
Date: Tue, 21 Oct 2014 15:09:18 -0600
Subject: [cmake-developers] Chaining custom commands in VS 2010
In-Reply-To: <5136351E.2020402@kitware.com>
References: 
 
 <51360EE8.5030104@kitware.com> <5136351E.2020402@kitware.com>
Message-ID: 

I never did actually submit this bug.  Do you know if this is a problem for
VS 2013?

We are running into this more and more with chains of custom commands in
CMake being processed incorrectly by VS.  It's to the point we are going to
have to generate a separate configuration (e.g. nmake or makefile) just to
compile these rules.

On Tue, Mar 5, 2013 at 11:10 AM, Brad King  wrote:

> On 03/05/2013 10:27 AM, Brad King wrote:
> > On 12/04/2012 07:30 PM, James Bigler wrote:
> >> Is there something CMake can do to correct this error/bug with VS 2010?
> >
> > I've narrowed this case down to a single hand-written test.vcxproj
> > file with no connection to CMake.  Here is a session:
>
> This also happens with VS 2012.  I modified the .vcxproj file with
> the patch below and ran msbuild with the "/p:VisualStudioVersion=11.0"
> option.  Otherwise the session is the same.
>
> -Brad
>
> @@ -12,6 +12,7 @@
>    
>     Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'"
> Label="Configuration">
>      Utility
> +    v110
>    
>    
>    
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From timothygu99 at gmail.com  Tue Oct 21 20:08:13 2014
From: timothygu99 at gmail.com (Timothy Gu)
Date: Tue, 21 Oct 2014 17:08:13 -0700
Subject: [cmake-developers] [PATCH] Windows-GNU,
	CYGWIN-GNU: Include corresponding windres script
Message-ID: <1413936493-29603-1-git-send-email-timothygu99@gmail.com>

This is my first post to the mailing list. If possible, this patch should
be backported to CMake 3.1 as well.

---->8----
GNU toolchains on Windows and Cygwin always use windres.

Fixes #7235.

Signed-off-by: Timothy Gu 
---
 Modules/Platform/CYGWIN-GNU.cmake  | 1 +
 Modules/Platform/Windows-GNU.cmake | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/Modules/Platform/CYGWIN-GNU.cmake b/Modules/Platform/CYGWIN-GNU.cmake
index fe25ab2..f193613 100644
--- a/Modules/Platform/CYGWIN-GNU.cmake
+++ b/Modules/Platform/CYGWIN-GNU.cmake
@@ -26,6 +26,7 @@ set(CMAKE_GNULD_IMAGE_VERSION
   "-Wl,--major-image-version,,--minor-image-version,")
 set(CMAKE_GENERATOR_RC windres)
 enable_language(RC)
+include(Platform/CYGWIN-windres)
 macro(__cygwin_compiler_gnu lang)
   # Binary link rules.
   set(CMAKE_${lang}_CREATE_SHARED_MODULE
diff --git a/Modules/Platform/Windows-GNU.cmake b/Modules/Platform/Windows-GNU.cmake
index ffc5657..1ea676e 100644
--- a/Modules/Platform/Windows-GNU.cmake
+++ b/Modules/Platform/Windows-GNU.cmake
@@ -61,6 +61,8 @@ if(NOT CMAKE_GENERATOR_RC AND CMAKE_GENERATOR MATCHES "Unix Makefiles")
   set(CMAKE_GENERATOR_RC windres)
 endif()
 
+include(Platform/Windows-windres)
+
 enable_language(RC)
 
 macro(__windows_compiler_gnu lang)
-- 
1.9.1



From mantis at public.kitware.com  Wed Oct 22 04:49:55 2014
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Wed, 22 Oct 2014 04:49:55 -0400
Subject: [cmake-developers] [CMake 0015214]: Error getting iOS compiler
	identification on master
Message-ID: <075c9477771df2c5ed55212d97511b92@www.cmake.org>


The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=15214 
====================================================================== 
Reported By:                Gregor Jasny
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15214
Category:                   CMake
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2014-10-22 04:49 EDT
Last Modified:              2014-10-22 04:49 EDT
====================================================================== 
Summary:                    Error getting iOS compiler identification on master
Description: 
Hello,

If I use cmake to compile the attached example for iOS it fails to get the
compiler identification:

Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler:
Build flags:
Id flags:

The output was:
65
=== BUILD TARGET CompilerIdC OF PROJECT CompilerIdC WITH THE DEFAULT
CONFIGURATION (Debug) ===

Check dependencies
target specifies product type 'com.apple.product-type.tool', but there's no such
product type for the 'iphoneos' platform

** BUILD FAILED **
I bisected the master branch and the offending commit is:
0cce556b5fbe629dccee294aeece7c275343ed64 is the first bad commit
commit 0cce556b5fbe629dccee294aeece7c275343ed64
Author: Brad King 
Date:   Tue Apr 29 09:21:00 2014 -0400

    Xcode: Use sysroot and deployment target to identify compiler

    Use CMAKE_OSX_SYSROOT and CMAKE_OSX_DEPLOYMENT_TARGET to set the Xcode
    SDKROOT and MACOSX_DEPLOYMENT_TARGET build settings.  This is necessary
    because some versions of Xcode select a different compiler based on
    these settings.  We need to make sure the compiler identified during
    language initialization matches what will be used for the actual build.
The attached exmaple work with CMake 3.0.x but not with master. But maybe my toolchain file is incomplete? Thanks, Gregor Steps to Reproduce: unpack the attached tarball, create a build directory and run:
~/src/cmake/bin/cmake -GXcode  -DCMAKE_TOOLCHAIN_FILE=../iOS.toolchain.cmake ..
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error in :
  No CMAKE_C_COMPILER could be found.



CMake Error in :
  No CMAKE_CXX_COMPILER could be found.



-- Configuring incomplete, errors occurred!
Additional Information: Xcode 6.1 on OSX 10.10 (but fails with Xcode 5.1.1, too) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-22 04:49 Gregor Jasny New Issue 2014-10-22 04:49 Gregor Jasny File Added: cmakebug.tar.gz ====================================================================== From mantis at public.kitware.com Wed Oct 22 04:52:28 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 22 Oct 2014 04:52:28 -0400 Subject: [cmake-developers] [CMake 0015215]: Please document CMAKE_XCODE_ATTRIBUTE_* Message-ID: <7290a9580acfc468295637d9c492e96d@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15215 ====================================================================== Reported By: Gregor Jasny Assigned To: ====================================================================== Project: CMake Issue ID: 15215 Category: Documentation Reproducibility: N/A Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-22 04:52 EDT Last Modified: 2014-10-22 04:52 EDT ====================================================================== Summary: Please document CMAKE_XCODE_ATTRIBUTE_* Description: Hello, it took some time to discover how to set global Xcode variables using CMAKE_XCODE_ATTRIBUTE_*. Please document it briefly and cross link this one and XCODE_ATTRIBUTE. Thanks, Gregor ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-22 04:52 Gregor Jasny New Issue ====================================================================== From fabianjul at gmail.com Wed Oct 22 07:49:58 2014 From: fabianjul at gmail.com (Fabian) Date: Wed, 22 Oct 2014 13:49:58 +0200 Subject: [cmake-developers] Xcode Project: Support for DevelopmentTeam In-Reply-To: <54465E79.4070308@kitware.com> References: <54465E79.4070308@kitware.com> Message-ID: Thanks for your response. 2014-10-21 15:24 GMT+02:00 Brad King : > On 10/17/2014 04:16 PM, Fabian wrote: > > Xcode automatically updates the devices list in the Member Center > > Neat. Please explain the developer workflow you envision to configure > the value for local build trees. Would it be something the developer > should explicitly set in every new tree? Should there be a common > configuration in the environment? Can it be detected programmatically? > For some teams, it would probably make sense to set this for every project in the environment as it gets rid of a bunch of code signing issues. However, a membership in the developer program is needed and I do not know an easy way to detect this. An option might be to parse the output of "certtool y" for "iPhone Distribution: ()"; notice the in brackets. However, some people (myself included) have to handle memberships in multiple programs, so there would be some manual selection involved anyway. > In the CMake source I noticed that 'BuildIndependentTargetsInParallel' > > is already getting set. This could be extendet to add the > 'TargetAttributes' > > section. > > Yes, that looks like the right place if you want to try a patch. > I looked through the source for a while but I found that for me it would require too much work to fully patch it, since the target ID also needs to be read from somewhere and included in the pbxproj. I would highly appreciate it if you took the time, as it would probably require a fraction of what I would have to invest. Regards, Fabian -------------- next part -------------- An HTML attachment was scrubbed... URL: From domen.vrankar at gmail.com Wed Oct 22 08:08:59 2014 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 22 Oct 2014 14:08:59 +0200 Subject: [cmake-developers] [CMake] [CPack] RPM generator creates %dir for /usr/local/xxx In-Reply-To: References: <1413976466922-7588778.post@n2.nabble.com> <5447930E.801@classdesign.com> Message-ID: Moving the conversation to developers mailing list. More docs on this for 2.8.12: > > http://www.cmake.org/cmake/help/v2.8.12/cpack.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION > > I guess that "/usr/local" may be added to > CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST default list values. > > For Domen: see the history of this story here: > http://public.kitware.com/Bug/view.php?id=13609 > I am familiar with this variable but I haven't noticed until now that not all the paths Dubrovskiy Viacheslav listed in bug report were removed from auto listing. Currently /etc /etc/init.d /usr /usr/share /usr/share/doc /usr/bin /usr/lib /usr/lib64 /usr/include paths are removed. I can add /usr/local to the list. Are there any additional paths from the above bug report that anyone thinks should be added? I would assume that all of the directories from Linux filesystem hierarchy standard (http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard, http://www.pathname.com/fhs/pub/fhs-2.3.html) should be excluded on Linux however UNIX filesystem hierarchy has less directories listed on wiki ( http://en.wikipedia.org/wiki/Unix_filesystem) and I am not even certain that all flavours of UNIX use them. I think that at least directories that are listed both for Linux and Unix should be added. What is the opinion of others? Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Wed Oct 22 09:18:58 2014 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 22 Oct 2014 15:18:58 +0200 Subject: [cmake-developers] [CMake] [CPack] RPM generator creates %dir for /usr/local/xxx In-Reply-To: References: <1413976466922-7588778.post@n2.nabble.com> <5447930E.801@classdesign.com> Message-ID: 2014-10-22 14:08 GMT+02:00 Domen Vrankar : > Moving the conversation to developers mailing list. > > More docs on this for 2.8.12: >> >> http://www.cmake.org/cmake/help/v2.8.12/cpack.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION >> >> I guess that "/usr/local" may be added to >> CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST default list values. >> >> For Domen: see the history of this story here: >> http://public.kitware.com/Bug/view.php?id=13609 >> > > I am familiar with this variable but I haven't noticed until now that not > all the paths Dubrovskiy Viacheslav > listed in bug > report were removed from auto listing. > This was a conservative choice in order to avoid backward compatibilty issue. I wasn't sure at that time that all (RPM-based) distros had the whole list of dirs and I think there was at least some discrepancy between Fedora and SuSE. I was planning (in my mind) to craft a distro-specific list of excluded dir into CPackRPM just in case... Then ... nothing was done but the CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST* vars :-( -- Erk L'?lection n'est pas la d?mocratie -- http://www.le-message.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Wed Oct 22 09:44:36 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 22 Oct 2014 09:44:36 -0400 Subject: [cmake-developers] [CMake 0015216]: Ninja makes bad phony targets with parallel "sub" directory and custom CMAKE_LIBRARY_OUTPUT_DIRECTORY Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15216 ====================================================================== Reported By: Joseph Lisee Assigned To: ====================================================================== Project: CMake Issue ID: 15216 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-22 09:44 EDT Last Modified: 2014-10-22 09:44 EDT ====================================================================== Summary: Ninja makes bad phony targets with parallel "sub" directory and custom CMAKE_LIBRARY_OUTPUT_DIRECTORY Description: I have project where the main build directory is on the same level as some "sub" directories, for example: primary/CMakeLists.txt secondary/CMakeLists.txt primary/build/ When I use the CMAKE_LIBRARY_OUTPUT_DIRECTORY to put all the lib files into primary/lib the build fails with ninja but keeps working with Make. The ninja error: ninja: error: '../lib/libtestlib.so', needed by 'CMakeFiles/main.dir/main.cpp.o', missing and no known rule to make it Inside build.ninja the library is being built with the absolute path "/tmp/ninja-parallel-sub-test/primary/lib/libtestlib.so" while other places refer to it as "../lib/libtestlib.so". Adding the following phony rule fixes the error: build ../lib/libtestlib.so: phony /tmp/ninja-parallel-sub-test/primary/lib/libtestlib.so Steps to Reproduce: Steps: * unzip attached zip files * cd primary * mkdir build * cmake .. -G Ninja * ninja Switching to Make will result in primary/bin/main and primary/lib/libtestlib.so appearing properly. Make sure to clean up the primary/bin & primary/lib directory while switching build systems, if not done ninja will appear to work only because it's not trying to build the targets. Additional Information: This is broken with the latest git head fc9041d0249c113cb812d69ee0b8f1411f1eea15, CMake 3.0.2 and CMake 2.8.9. These bugs are related: 0014972, 0014414 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-22 09:44 Joseph Lisee New Issue 2014-10-22 09:44 Joseph Lisee File Added: ninja-parallel-sub-test.zip ====================================================================== From brad.king at kitware.com Wed Oct 22 10:42:40 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Oct 2014 10:42:40 -0400 Subject: [cmake-developers] [PATCH] Windows-GNU, CYGWIN-GNU: Include corresponding windres script In-Reply-To: <1413936493-29603-1-git-send-email-timothygu99@gmail.com> References: <1413936493-29603-1-git-send-email-timothygu99@gmail.com> Message-ID: <5447C260.8080500@kitware.com> On 10/21/2014 08:08 PM, Timothy Gu wrote: > enable_language(RC) > +include(Platform/CYGWIN-windres) [snip] > +include(Platform/Windows-windres) > + > enable_language(RC) The enable_language(RC) call should internally include those modules. In CMakeRCInformation: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeRCInformation.cmake;hb=v3.0.2#l29 the line include(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME} OPTIONAL) should do it. -Brad From pascal.bach at siemens.com Wed Oct 22 10:53:08 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Wed, 22 Oct 2014 14:53:08 +0000 Subject: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as tests for Windows CE In-Reply-To: <54465F5A.6000208@kitware.com> References: <1413883468-499-1-git-send-email-pascal.bach@siemens.com> <5446586D.6010107@kitware.com> <355BE46A91031048906B695426A8D8E616AE6358@DEFTHW99EH4MSX.ww902.siemens.net> <54465F5A.6000208@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616AE6701@DEFTHW99EH4MSX.ww902.siemens.net> > > > I even would prefer to not hardcode the SDK but I was unable to list key > entries from the registry. > > > > Usually all installed SDKs are listed as subkeys of > HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows CE Tools\\SDKs > in this case it is SDK_AM335X_SK_WEC2013_V310. > > > > I think the test would be nicer if it checks for available SDKs and just picks > the first. > > > > Any ideas how to do this? > > Within a block guarded by if(CMAKE_HOST_WIN32) you could > use execute_process to run the "reg" command-line tool. > Am I right that when using the reg tool I need to include the Wow6432Node again? Pascal From brad.king at kitware.com Wed Oct 22 10:59:30 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Oct 2014 10:59:30 -0400 Subject: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as tests for Windows CE In-Reply-To: <355BE46A91031048906B695426A8D8E616AE6701@DEFTHW99EH4MSX.ww902.siemens.net> References: <1413883468-499-1-git-send-email-pascal.bach@siemens.com> <5446586D.6010107@kitware.com> <355BE46A91031048906B695426A8D8E616AE6358@DEFTHW99EH4MSX.ww902.siemens.net> <54465F5A.6000208@kitware.com> <355BE46A91031048906B695426A8D8E616AE6701@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <5447C652.6030402@kitware.com> On Wed, Oct 22, 2014 at 10:53 AM, Bach, Pascal wrote: > Am I right that when using the reg tool I need to include > the Wow6432Node again? Possibly. I'm not particularly familiar with it, but there are two of them: C:\Windows\System32\reg.exe C:\Windows\SysWOW64\reg.exe Perhaps they take different views. We don't know which one will be in the PATH. I don't think Wow6432Node will exist on a 32-bit host so you may need to query both with and without it. -Brad From brad.king at kitware.com Wed Oct 22 10:59:36 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Oct 2014 10:59:36 -0400 Subject: [cmake-developers] Chaining custom commands in VS 2010 In-Reply-To: References: <51360EE8.5030104@kitware.com> <5136351E.2020402@kitware.com> Message-ID: <5447C658.30909@kitware.com> On 10/21/2014 05:09 PM, James Bigler wrote: > I never did actually submit this bug. Do you know if this is a problem for VS 2013? Yes, I just tried the case I previously posted: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/44820/focus=6288 and the results are identical even after adding v120 to the project file. -Brad From brad.king at kitware.com Wed Oct 22 11:02:14 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Oct 2014 11:02:14 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <54467F83.4030309@kitware.com> References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com> <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com> <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com> <5446610A.8020609@kitware.com> <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl> <54466DFC.4070403@kitware.com> <5520EEFC-3B8E-4487-992E-F36700486256@java.pl> <54467F83.4030309@kitware.com> Message-ID: <5447C6F6.8060708@kitware.com> On 10/21/2014 11:45 AM, Brad King wrote: > I cherry-picked it over on top of the revised/squashed copy of > the topic that was merged to 'master': > > BundleUtilities: Ensure framework symlinks and Info.plist exist > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41564ff2 The nightly binary works again. The first working version after this gap is now: http://www.cmake.org/files/dev/cmake-3.1.20141021-gffa1-Darwin64-universal.dmg Thanks! -Brad From brad.king at kitware.com Wed Oct 22 11:02:36 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Oct 2014 11:02:36 -0400 Subject: [cmake-developers] CMake.app Qt5 vs Qt4 on 10.10 In-Reply-To: References: Message-ID: <5447C70C.3060203@kitware.com> On 10/21/2014 12:16 PM, Adam Strzelecki wrote: > Following discussion regarding fix-OSX-bundle-rpaths-and-Qt5 topic > I just wanted to share with you how CMake looks with Qt4 vs Qt5 on Yosemite: > > https://www.dropbox.com/s/knnybhed8fahste/CMake3.1rc1-Qt4.8.6-Yosemite.png > https://www.dropbox.com/s/tm95rntexn4z6j6/CMake3.1rc1-Qt5.4-Yosemite.png Cool, thanks for testing both versions. We'd like to switch to Qt5 when we get a chance to update our binary build infrastructure for it. Thanks, -Brad From brad.king at kitware.com Wed Oct 22 11:18:55 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Oct 2014 11:18:55 -0400 Subject: [cmake-developers] ExternalProject CMAKE_ARGS and CMAKE_CACHE_ARGS arguments In-Reply-To: <5446672F.3070501@gmail.com> References: <543FE392.7020706@gmail.com> <54451383.4070809@kitware.com> <5446672F.3070501@gmail.com> Message-ID: <5447CADF.8020804@kitware.com> On 10/21/2014 10:01 AM, Daniele E. Domenichelli wrote: > I would like to be able to set some some variables (for example > CMAKE_BUILD_TYPE) for all the "external project" according to the value > in the "super-project", but the same time I would like to be able to > change them (for example change CMAKE_BUILD_TYPE to Debug if I'm > building in Release mode) for just one external project without changing > it in all of them, and having to rebuild everything. How about a new option like "CMAKE_CACHE_DEFAULT_ARGS" for that? -Brad From ono at java.pl Wed Oct 22 13:29:00 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 22 Oct 2014 19:29:00 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <5447C6F6.8060708@kitware.com> References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com> <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com> <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com> <5446610A.8020609@kitware.com> <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl> <54466DFC.4070403@kitware.com> <5520EEFC-3B8E-4487-992E-F36700486256@java.pl> <54467F83.4030309@kitware.com> <5447C6F6.8060708@kitware.com> Message-ID: > The nightly binary works again. The first working version after > this gap is now: Great! Now, do you plan code signing the CMake.app? Do you guys have Mac Developer ID? --Adam From sean at rogue-research.com Wed Oct 22 13:33:29 2014 From: sean at rogue-research.com (Sean McBride) Date: Wed, 22 Oct 2014 13:33:29 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: References: <542ACE37.1040302@kitware.com> <1628618059.342313.1412864176571.JavaMail.zimbra@elemtech.com> <54369B54.3040501@kitware.com> <4919083.hvPr6C4Ify@stryke> <5D31C146-4F11-4995-AF02-9928DB269A8E@java.pl> <5436A775.7040401@kitware.com> <5437F443.3040705@kitware.com> <544573BF.7060002@kitware.com> <251714D3-F85F-4E39-8C08-F5F5DCFF1D39@java.pl> <5446516B.9060206@kitware.com> <5446610A.8020609@kitware.com> <75A9B110-BB4D-4C5B-9017-01EDF1DED92B@java.pl> <54466DFC.4070403@kitware.com> <5520EEFC-3B8E-4487-992E-F36700486256@java.pl> <54467F83.4030309@kitware.com> <5447C6F6.8060708@kitware.com> Message-ID: <20141022173329.1241639395@mail.rogue-research.com> On Wed, 22 Oct 2014 19:29:00 +0200, Adam Strzelecki said: >> The nightly binary works again. The first working version after >> this gap is now: > >Great! Now, do you plan code signing the CMake.app? Do you guys have Mac >Developer ID? The bug for that is here BTW, created over 2 years ago now... Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From guillaume.papin at parrot.com Thu Oct 23 04:09:53 2014 From: guillaume.papin at parrot.com (Guillaume Papin) Date: Thu, 23 Oct 2014 10:09:53 +0200 Subject: [cmake-developers] FindBoost.cmake cannot find some libraries when cross-compiling In-Reply-To: References: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan> <4037EE152A73A9448DAD73C415D4D8C0873819@MBX79.aswsp.lan> Message-ID: <5448B7D1.1030604@parrot.com> Please find the patch attached to this email. Let me know if anything is wrong. Best, Guillaume On 10/16/2014 05:09 PM, Chuck Atkins wrote: > Guillaume, > > Please see CONTRIBUTING.rst in the top level of the CMake source > tree. If you can please create and post a patch against cmake master > then I'll work on getting it merged into cmake next. Thanks for the > bug fix! > > - Chuck > > On Thu, Oct 16, 2014 at 10:32 AM, Chuck Atkins > > wrote: > > This looks like a reasonable way to accomplish this right now. > The underlying prioblem is that ther's no way to specify which > path types get re-rooted and which don't. Ideally you'd want to > be able to specify in the toolchain for something like this that > all paths operate in "ONLY" mode except HINTS, which you would > want to place in NEVER mode. I'm currently working on just such a > feature but in the meantime, forcing it like this in the FindBoost > module looks reasonable. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FindBoost-fix-re-rooting.patch Type: text/x-patch Size: 1729 bytes Desc: not available URL: From konstantin at podsvirov.pro Thu Oct 23 08:45:36 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 23 Oct 2014 16:45:36 +0400 Subject: [cmake-developers] [TEST REQUEST] CPack IFW generator on OSX Message-ID: <1482491414068336@web15m.yandex.ru> Hello developers! Can anybody test IFW generator on Mac? Regards, Konstantin Podsvirov From sean at rogue-research.com Thu Oct 23 11:09:07 2014 From: sean at rogue-research.com (Sean McBride) Date: Thu, 23 Oct 2014 11:09:07 -0400 Subject: [cmake-developers] [TEST REQUEST] CPack IFW generator on OSX In-Reply-To: <1482491414068336@web15m.yandex.ru> References: <1482491414068336@web15m.yandex.ru> Message-ID: <20141023150907.2007902885@mail.rogue-research.com> On Thu, 23 Oct 2014 16:45:36 +0400, Konstantin Podsvirov said: >Can anybody test IFW generator on Mac? Probably... What is it? :) How would I test it? If you can give me clear instructions, I can update one or more of my dashboards to test it. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From brad.king at kitware.com Thu Oct 23 11:13:15 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Oct 2014 11:13:15 -0400 Subject: [cmake-developers] Support of codesign In-Reply-To: <6639644.c5E5zbx6zX@stryke> References: <543FD64A.1040907@kitware.com> <6639644.c5E5zbx6zX@stryke> Message-ID: <54491B0B.2080705@kitware.com> On 10/21/2014 11:44 AM, Clinton Stimpson wrote: > Because the design of this Bundle generator is not consistent with the rest of > the CPack generators, you don't have this same chance, and the only way to do > customization is to keep adding patches like yours. Is this something that should be refactored in CPack to address independently of the codesign changes? Thanks, -Brad From konstantin at podsvirov.pro Thu Oct 23 11:50:55 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 23 Oct 2014 19:50:55 +0400 Subject: [cmake-developers] [TEST REQUEST] CPack IFW generator on OSX In-Reply-To: <20141023150907.2007902885@mail.rogue-research.com> References: <1482491414068336@web15m.yandex.ru> <20141023150907.2007902885@mail.rogue-research.com> Message-ID: <315501414079455@web4m.yandex.ru> Hi Sean! 23.10.2014, 19:09, "Sean McBride" : > On Thu, 23 Oct 2014 16:45:36 +0400, Konstantin Podsvirov said: >> Can anybody test IFW generator on Mac? > > Probably... What is it? :) How would I test it? If you can give me clear instructions, I can update one or more of my dashboards to test it. Thanks that have responded. CPack IFW generator generates the installer with a graphical user interface. I have no ideas for automated testing. But you can try to create the installer and see how it works. On the CMake Wiki has an article "CMake:Install Component With CPack": http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack CPack IFW generator will cope with this task. Shot with a small edit to IFW generator available here: http://git.podsvirov.pro/?p=kitware/componentexample.git;a=snapshot;h=refs/heads/develop;sf=tgz You must use the latest version of CMake for developers. You can find here: http://www.cmake.org/files/dev Just need to install Qt Installer Framework from here: http://download.qt-project.org/official_releases/qt-installer-framework/1.5.0 Then initialize the project from the snapshot. Further configuration. Must be set to ON (enble) advanced variable CPACK_BINARY_IFW. Also must be set to OFF (disable) the rest CPACK_BINARY_{XXX} variables. Start the generation. Make the target "package" and get the installer in the folder Assembly. Run the installer. We should see the installer similar to what is specified in the Wiki. For Linux and Windows I got these installers: http://ifw.podsvirov.pro/cmake/old/cpackifw-componentexample-linux.png http://ifw.podsvirov.pro/cmake/old/cpackifw-componentexample-windows.png Then click "next" and check that mylibapp start. Here is an approximate algorithm. Regards, Konstantin Podsvirov From clinton at elemtech.com Thu Oct 23 12:21:31 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Thu, 23 Oct 2014 10:21:31 -0600 Subject: [cmake-developers] Support of codesign In-Reply-To: <54491B0B.2080705@kitware.com> References: <6639644.c5E5zbx6zX@stryke> <54491B0B.2080705@kitware.com> Message-ID: <235694142.S1LGzdHcBU@stryke> On Thursday, October 23, 2014 11:13:15 AM Brad King wrote: > On 10/21/2014 11:44 AM, Clinton Stimpson wrote: > > Because the design of this Bundle generator is not consistent with the > > rest of the CPack generators, you don't have this same chance, and the > > only way to do customization is to keep adding patches like yours. > > Is this something that should be refactored in CPack to address > independently of the codesign changes? Actually, the design is intentional -- that is, it has the feature of creating the application bundle for you, which involves handling for icons, Info.plist, and now the proposed code signing. Alternatively, we have handling for icons and Info.plist in add_executable(... MACOSX_BUNDLE ...). So basically, its duplicated functionality. There are 2 approaches: 1. set(INSTALL_LIB_DIR lib) set(INSTALL_BIN_DIR bin) add_library(foolib ...) install(TARGETS foolib RUNTIME DESTINATION ${INSTALL_LIB_DIR}) add_executable(foo ...) target_link_libraries(foo foolib) add_executable(foo2 ...) target_link_libraries(foo2 foolib) install(TARGETS foo foo2 RUNTIME DESTINATION ${INSTALL_BIN_DIR}) set(CPACK_GENERATOR Bundle) set(CPACK_BUNDLE_STARTUP_COMMAND "StartScript") include(CPack) The end result is a foo.app/Contents/MacOS/foo (renamed from StartScript) foo.app/Contents/MacOS/bin/foo foo.app/Contents/MacOS/bin/foo2 foo.app/Contents/MacOS/lib/libfoo.dylib If any other CPack generator is used (TGZ, DragNDrop, PackageMaker, etc...), the package layout will be bin/foo bin/foo2 lib/libfoo.dylib 2. set(INSTALL_LIB_DIR foo.app/Contents/MacOS) set(INSTALL_BIN_DIR foo.app/Contents/MacOS) add_library(foolib ...) install(TARGETS foolib RUNTIME DESTINATION ${INSTALL_LIB_DIR}) add_executable(foo MACOSX_BUNDLE ...) target_link_libraries(foo foolib) add_executable(foo2 MACOSX_BUNDLE ...) target_link_libraries(foo2 foolib) install(TARGETS foo foo2 BUNDLE DESTINATION . RUNTIME DESTINATION ${INSTALL_BIN_DIR}) include(CPack) The end result is a foo.app/Contents/MacOS/foo foo.app/Contents/MacOS/foo2 foo.app/Contents/MacOS/libfoo.dylib This gives consistent results with all CPack generators (TGZ, DragNDrop, PackageMaker, etc..) except for the Bundle generator. Similar to #2, CMake itself uses an interesting approach of modifying CMAKE_INSTALL_PREFIX to redirect the installation into the CMake.app bundle, without modifying the DESTINATION option to the install() commands. If the Bundle generator is changed to be made consistent with other cpack generators (which implies you lose the bundle making feature), you end up with what the DragNDrop generator is. And now there is code signing.... There is a chance that code signing will be introduced into CMake using another mechanism that works across platforms and across cpack generators. How that will interact with the propose patch, I do not know, so I do have some concern about adding this patch. So Brad, does this give you some idea of the situation? Do you have some thoughts on merging the patch? Clint From ono at java.pl Thu Oct 23 13:01:39 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 23 Oct 2014 19:01:39 +0200 Subject: [cmake-developers] Support of codesign In-Reply-To: <235694142.S1LGzdHcBU@stryke> References: <6639644.c5E5zbx6zX@stryke> <54491B0B.2080705@kitware.com> <235694142.S1LGzdHcBU@stryke> Message-ID: <3699002F-4034-4D0D-94B8-CD409DBA9A23@java.pl> Let me put my 2?. I have feeling that we are mixing up signing (install) packages, such as .pkg (OSX) or .msi (Windows), with signing bundles .app or whatever OSX binaries (that can keep signature inside macho). I think that CPack should be responsible of signing only what it creates. Since CPack does not create .app bundle but just packs it into .pkg, .dmg or whatever else it shouldn't touch .app. Then code signing .app bundle should be part of install (cmake_install.cmake), triggered once the .app bundle is complete (final), probably after fixup_bundle. Once may not even want to use CPack, but still want to code-sign .app when installing. But this is just my personal opinion, Also I don't see any reason we need to implement that in C++ as this can be handled with cmake scripting capabilities. --Adam From brad.king at kitware.com Thu Oct 23 13:40:58 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Oct 2014 13:40:58 -0400 Subject: [cmake-developers] Support of codesign In-Reply-To: <3699002F-4034-4D0D-94B8-CD409DBA9A23@java.pl> References: <6639644.c5E5zbx6zX@stryke> <54491B0B.2080705@kitware.com> <235694142.S1LGzdHcBU@stryke> <3699002F-4034-4D0D-94B8-CD409DBA9A23@java.pl> Message-ID: <54493DAA.1040600@kitware.com> On 10/23/2014 12:21 PM, Clinton Stimpson wrote: > Actually, the design is intentional -- that is, it has the feature of creating > the application bundle for you, which involves handling for icons, Info.plist, > and now the proposed code signing. Alternatively, we have handling for icons > and Info.plist in add_executable(... MACOSX_BUNDLE ...). So basically, its > duplicated functionality. Okay, so IIUC the CPack Bundle generator helps create .app bundles out of projects that are not aware of them. Projects that are aware and that use MACOSX_BUNDLE should probably not use the CPack Bundle generator and instead use the DragNDrop generator. > If the Bundle generator is changed to be made consistent with other cpack > generators (which implies you lose the bundle making feature), you end up with > what the DragNDrop generator is. Okay, so it does not make sense to change it. > And now there is code signing.... There is a chance that code signing will be > introduced into CMake using another mechanism that works across platforms and > across cpack generators. How that will interact with the propose patch, I do > not know, so I do have some concern about adding this patch. [snip] On 10/23/2014 01:01 PM, Adam Strzelecki wrote: > I think that CPack should be responsible of signing only what it creates. > Since CPack does not create .app bundle ... it shouldn't touch .app. > Then code signing .app bundle should be part of install (cmake_install.cmake) I think Adam's suggestion makes sense. However, in the case of the Bundle generator that the proposed patch modifies CPack *is* creating the .app bundle and so should be able to sign it. Therefore the patch will not get in the way of future CMake support for signing .app during installation, especially because it requires both explicit configuration and use of the CPack Bundle generator that according to the above recommendation should not be used for projects aware of MACOSX_BUNDLE. In order to keep it further out of the way, the related variables should be specific to the Bundle generator. Instead of: CPACK_APPLE_CERT_APP CPACK_APPLE_ENTITLEMENTS CPACK_APPLE_CODESIGN_FILES perhaps they should be called: CPACK_BUNDLE_APPLE_CERT_APP CPACK_BUNDLE_APPLE_ENTITLEMENTS CPACK_BUNDLE_APPLE_CODESIGN_FILES Thanks, -Brad From bill.hoffman at kitware.com Thu Oct 23 17:40:05 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 23 Oct 2014 17:40:05 -0400 Subject: [cmake-developers] Fwd: Re: Severe behavioural change regressions in release branch In-Reply-To: References: Message-ID: <544975B5.7070002@kitware.com> FYI, a conversation on the KDE mailing list. -------- Forwarded Message -------- Subject: Re: Severe behavioural change regressions in release branch Date: Fri, 24 Oct 2014 10:11:02 +1300 From: Ben Cooksley Reply-To: KDE build system (cmake) To: kde-frameworks-devel at kde.org CC: kde-core-devel , KDE build system (cmake) On Fri, Oct 24, 2014 at 10:05 AM, Ben Cooksley wrote: > Hi all, > > It would appear that CMake 3.0 to 3.1 introduces a colossal change in > behaviour. This change totally breaks all KDE projects which use > Extra-CMake-Modules, as necessary headers are no longer installed. > > This has become an issue following http://build.kde.org/job/cmake/160/ > which has led to a significant number of our projects failing to build > from source as can be seen here - > http://build.kde.org/view/Frameworks/ > > Someone needs to investigate this before CMake 3.1.0 goes out the door > and fix it. I've no idea what the policy is in the CMake world, but in > the KDE world this sort of compatibility breakage would be a release > blocker. And it would seem that the CMake developers prefer to live in their own closed off little bubble. My post was automatically rejected. Someone who is subscribed there will have to take this up with them. I'm extremely displeased. If they release CMake 3.1.0 with this regression, we should consider forking CMake as their developers can't be trusted to ensure our code remains buildable. > > Regards, > Ben Cooksley > KDE Sysadmin Regards, Ben _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem at kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem From ben.boeckel at kitware.com Thu Oct 23 22:34:27 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 23 Oct 2014 22:34:27 -0400 Subject: [cmake-developers] Fwd: Re: Severe behavioural change regressions in release branch In-Reply-To: <544975B5.7070002@kitware.com> References: <544975B5.7070002@kitware.com> Message-ID: <20141024023427.GA11952@bronto-burt.dev.benboeckel.net> [ Adding Ben Cooksley to the CC list; feel free to reply privately and I'll forward to the list if you keep getting rejected from it. ] Hi, > > It would appear that CMake 3.0 to 3.1 introduces a colossal change in > > behaviour. This change totally breaks all KDE projects which use > > Extra-CMake-Modules, as necessary headers are no longer installed. This is indeed true (between the new variable expansion code (CMP0053) and 'if()' variable expansion rules (CMP0054), there's a lot of changes otherwise); however, all you should get are warnings about the change, not the actual behavior change without actually bumping your minimum version or enabling the policy explicitly. > > This has become an issue following http://build.kde.org/job/cmake/160/ > > which has led to a significant number of our projects failing to build > > from source as can be seen here - > > http://build.kde.org/view/Frameworks/ So looking at kdelibs4support, I see lots of CMP0053 warnings (due to the @var@ expansion in normal CMakeLists.txt processing which was obscure and undocumented) and CMP0048 warnings (I'm not familiar with it, but it's about project() offering version variables). In kdelibs, I see CMP0022 and CMP0046 warnings (both related to target_link_libraries and things which are likely bugs anyways such as depending on non-existent targets or a mismatch between INTERFACE_LINK_LIBRARIES and LINK_INTERFACE_LIBRARIES). However, I do see: 04:35:39 -- Installing: /srv/jenkins/workspace/kdelibs_master/local-inst/srv/jenkins/install/linux/x86_64/g++/latest-qt4/kde/kdelibs/inst/include/kpluginfactory.h in kdelibs' logs, so it makes me think that: /srv/jenkins/workspace/kdelibs4support_master_qt5/src/kssl/kcm/kcmssl.cpp:27:28: fatal error: kpluginfactory.h: No such file or directory implies the build isn't getting the include directories plumbed through properly. I'll try a build tomorrow (or if it'd be possible to run a Jenkins build of kdelibs4support with make VERBOSE=1, that'd be great too since the environment would be consistent then). My gut feeling is some CMP0054 corner case isn't caught and falls through to the new behavior without a warning (or the old behavior was subtly changed in the process), but that's just a shot in the dark. > > Someone needs to investigate this before CMake 3.1.0 goes out the door > > and fix it. I've no idea what the policy is in the CMake world, but in > > the KDE world this sort of compatibility breakage would be a release > > blocker. Thanks for testing the rc; it should be a blocker on our side too. It would indeed be bad for 3.1.0 to release with such breaking changes. We try really hard for backwards compatibility. Obviously our test coverage is lacking somewhere. > And it would seem that the CMake developers prefer to live in their > own closed off little bubble. My post was automatically rejected. > Someone who is subscribed there will have to take this up with them. > I'm extremely displeased. > > If they release CMake 3.1.0 with this regression, we should consider > forking CMake as their developers can't be trusted to ensure our code > remains buildable. For preventing this in the future, would it be possible to set up Jenkins build to submit builds for kdelibs and a few other libraries which would test CMake master and submit to CMake's dashboard some results nightly so we can catch these problems more quickly? There are examples in: https://github.com/Kitware/CMake/tree/master/Tests/Contracts for how this is done for other projects already. The instance would then just to set something like CMAKE_CONTRACT_PROJECTS=kdelibs and run CMake's test suite and submit to the dashboard. Thanks, --Ben From mantis at public.kitware.com Fri Oct 24 02:50:59 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 24 Oct 2014 02:50:59 -0400 Subject: [cmake-developers] [CMake 0015217]: CPack make wrong dependencies between components Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15217 ====================================================================== Reported By: sudakov_ivan Assigned To: ====================================================================== Project: CMake Issue ID: 15217 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-24 02:50 EDT Last Modified: 2014-10-24 02:50 EDT ====================================================================== Summary: CPack make wrong dependencies between components Description: I have three components: a,b,c and code: install(FILES ${CMAKE_CURRENT_LIST_FILE} DESTINATION /tmp COMPONENT a) install(FILES ${CMAKE_CURRENT_LIST_FILE} DESTINATION /tmp COMPONENT b) install(FILES ${CMAKE_CURRENT_LIST_FILE} DESTINATION /tmp COMPONENT c) SET(CPACK_RPM_a_PACKAGE_REQUIRES "d") SET(CPACK_RPM_c_PACKAGE_REQUIRES "e") In result: a requires d - ok b requires d - wrong c requires e - ok There is the same situation with PROVIDES Additional Information: If I set REQUIRES for ALL components it's work fine: SET(CPACK_RPM_a_PACKAGE_REQUIRES "d") SET(CPACK_RPM_c_PACKAGE_REQUIRES "e") SET(CPACK_RPM_b_PACKAGE_REQUIRES "") ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-24 02:50 sudakov_ivan New Issue ====================================================================== From pascal.bach at siemens.com Fri Oct 24 09:21:11 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Fri, 24 Oct 2014 15:21:11 +0200 Subject: [cmake-developers] [PATCHv2] Tests: Run Tutorial steps 1-4 as tests for Windows CE In-Reply-To: <5446586D.6010107@kitware.com> References: <5446586D.6010107@kitware.com> Message-ID: <1414156871-28308-1-git-send-email-pascal.bach@siemens.com> --- Tests/CMakeLists.txt | 46 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 45 insertions(+), 1 deletion(-) diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt index 25cc846..2ac13c2 100644 --- a/Tests/CMakeLists.txt +++ b/Tests/CMakeLists.txt @@ -1781,6 +1781,20 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release endif() if(WIN32) + # Macro to search for available Windows CE SDKs in the windows Registry + macro(select_wince_sdk selected_sdk) + if(CMAKE_HOST_WIN32) + execute_process(COMMAND reg QUERY "HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows CE Tools\\SDKs" + OUTPUT_VARIABLE sdk_reg + ERROR_VARIABLE my_err) + string(REGEX REPLACE "HKEY_LOCAL_MACHINE\\\\SOFTWARE\\\\Wow6432Node\\\\Microsoft\\\\Windows CE Tools\\\\SDKs\\\\" ";" sdk_list "${sdk_reg}") + list(LENGTH sdk_list sdk_list_len) + if (${sdk_list_len} GREATER 1) + list(GET sdk_list 1 ${selected_sdk}) # The first entry is always empty due to the regex replace above + endif() + endif(CMAKE_HOST_WIN32) + endmacro(select_wince_sdk) + set(reg_vs10 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\10.0;InstallDir]") set(reg_vs11 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\11.0;InstallDir]") set(reg_vs12 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\12.0;InstallDir]") @@ -1788,8 +1802,9 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release set(reg_ws81 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v8.1;InstallationFolder]") set(reg_wp80 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\WindowsPhone\\v8.0;InstallationFolder]") set(reg_wp81 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\WindowsPhone\\v8.1;InstallationFolder]") + select_wince_sdk(reg_wince) set(reg_tegra "[HKEY_LOCAL_MACHINE\\SOFTWARE\\NVIDIA Corporation\\Nsight Tegra;sdkRoot]") - foreach(reg vs10 vs11 vs12 ws80 ws81 wp80 wp81 tegra) + foreach(reg vs10 vs11 vs12 ws80 ws81 wp80 wp81 wince tegra) get_filename_component(r "${reg_${reg}}" ABSOLUTE) if(IS_DIRECTORY "${r}") set(${reg} 1) @@ -1835,6 +1850,35 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release endif() endif() + if(WIN32 AND reg_wince) + macro(add_test_VSWinCE name generator systemName systemVersion generatorPlatform) + # TODO: Fix the tutorial to make it work in cross compile + # currently the MakeTable is build for target and can not be used on the host + # This happens in part 5 so we build only part 1-4 of the tutorial + foreach(STP RANGE 1 4) + add_test(NAME "TutorialStep${STP}.${name}" COMMAND ${CMAKE_CTEST_COMMAND} + --build-and-test + "${CMake_SOURCE_DIR}/Tests/Tutorial/Step${STP}" + "${CMake_BINARY_DIR}/Tests/Tutorial/Step${STP}_${name}" + --build-generator "${generator}" + --build-project Tutorial + --build-config $ + --build-options -DCMAKE_SYSTEM_NAME=${systemName} + -DCMAKE_SYSTEM_VERSION=${systemVersion} + -DCMAKE_GENERATOR_PLATFORM=${generatorPlatform}) + list(APPEND TEST_BUILD_DIRS "${CMake_BINARY_DIR}/Tests/Tutorial/Step${STP}_${name}") + endforeach() + endmacro() + + if(vs11) + add_test_VSWinCE(vs11-ce80-ARM "Visual Studio 11 2012" WindowsCE 8.0 ${reg_wince}) + endif() + + if(vs12) + add_test_VSWinCE(vs12-ce80-ARM "Visual Studio 12 2013" WindowsCE 8.0 ${reg_wince}) + endif() + endif() + if(tegra AND NOT "${CMake_SOURCE_DIR};${CMake_BINARY_DIR}" MATCHES " ") macro(add_test_VSNsightTegra name generator) add_test(NAME VSNsightTegra.${name} COMMAND ${CMAKE_CTEST_COMMAND} -- 1.7.10.4 From brad.king at kitware.com Fri Oct 24 09:50:17 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 24 Oct 2014 09:50:17 -0400 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: <20141024023427.GA11952@bronto-burt.dev.benboeckel.net> References: <544975B5.7070002@kitware.com> <20141024023427.GA11952@bronto-burt.dev.benboeckel.net> Message-ID: <544A5919.6000804@kitware.com> On 10/23/2014 10:34 PM, Ben Boeckel wrote: > implies the build isn't getting the include directories plumbed through > properly. I reproduced it locally far enough to find that kcoreaddons is not installing headers like include/KF5/KCoreAddons/kpluginfactory.h when built with 3.1 but is with 3.0. I narrowed it down to a test case using just ECM: ------------------------------------------------------------------- $ cat CMakeLists.txt cmake_minimum_required(VERSION 3.0) project(Minimal NONE) file(WRITE "${CMAKE_CURRENT_SOURCE_DIR}/header.h" "header") find_package(ECM 1.3.0 REQUIRED NO_MODULE) set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH}) include(ECMGenerateHeaders) ecm_generate_headers(headers HEADER_NAMES header REQUIRED_HEADERS headers ) message(WARNING " headers=[${headers}]") ecm_generate_headers(headers HEADER_NAMES header REQUIRED_HEADERS headers ) message(FATAL_ERROR " headers=[${headers}]") ------------------------------------------------------------------- With 3.0 we see the list of headers accumulate. With 3.1 just the first one works and the rest do not. -Brad From brad.king at kitware.com Fri Oct 24 10:02:31 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 24 Oct 2014 10:02:31 -0400 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: <544A5919.6000804@kitware.com> References: <544975B5.7070002@kitware.com> <20141024023427.GA11952@bronto-burt.dev.benboeckel.net> <544A5919.6000804@kitware.com> Message-ID: <544A5BF7.2000800@kitware.com> On 10/24/2014 09:50 AM, Brad King wrote: > With 3.0 we see the list of headers accumulate. With 3.1 just the > first one works and the rest do not. I bisected it down to: commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49 Author: Ben Boeckel Date: Wed Mar 12 14:01:45 2014 -0400 cmDefinitions: Don't store parent lookups When looking up scopes, it is faster to not store the lookup locally to keep the maps smaller and avoid extra allocations and rebalancing. -Brad From brad.king at kitware.com Fri Oct 24 10:20:42 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 24 Oct 2014 10:20:42 -0400 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: <544A5BF7.2000800@kitware.com> References: <544975B5.7070002@kitware.com> <20141024023427.GA11952@bronto-burt.dev.benboeckel.net> <544A5919.6000804@kitware.com> <544A5BF7.2000800@kitware.com> Message-ID: <544A603A.4030505@kitware.com> On 10/24/2014 10:02 AM, Brad King wrote: > I bisected it down to: > > commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49 > Author: Ben Boeckel > Date: Wed Mar 12 14:01:45 2014 -0400 > > cmDefinitions: Don't store parent lookups > > When looking up scopes, it is faster to not store the lookup locally to > keep the maps smaller and avoid extra allocations and rebalancing. Here is a minimal standalone example: $ cat regression.cmake function(func var_name) list(APPEND ${var_name} value) set(${var_name} ${${var_name}} PARENT_SCOPE) set(${var_name} ${${var_name}} PARENT_SCOPE) endfunction() func(var) message(STATUS " var=[${var}]") func(var) message(STATUS " var=[${var}]") $ cmake-3.0 -P regression.cmake -- var=[value] -- var=[value;value] $ cmake-3.1 -P regression.cmake -- var=[value] -- var=[value] -Brad From ben.boeckel at kitware.com Fri Oct 24 10:22:49 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 24 Oct 2014 10:22:49 -0400 Subject: [cmake-developers] [bcooksley@kde.org: Re: Fwd: Re: Severe behavioural change regressions in release branch] Message-ID: <20141024142249.GA6450@megas.kitwarein.com> [ Forward from Ben Cooksley. ] ----- Forwarded message from Ben Cooksley ----- Date: Fri, 24 Oct 2014 19:55:23 +1300 From: Ben Cooksley To: ben.boeckel at kitware.com Cc: Bill Hoffman , "cmake-developers at cmake.org" Subject: Re: [cmake-developers] Fwd: Re: Severe behavioural change regressions in release branch On Fri, Oct 24, 2014 at 3:34 PM, Ben Boeckel wrote: > [ Adding Ben Cooksley to the CC list; feel free to reply privately and > I'll forward to the list if you keep getting rejected from it. ] Duly noted, will do. > > Hi, Hi, > >> > It would appear that CMake 3.0 to 3.1 introduces a colossal change in >> > behaviour. This change totally breaks all KDE projects which use >> > Extra-CMake-Modules, as necessary headers are no longer installed. > > This is indeed true (between the new variable expansion code (CMP0053) > and 'if()' variable expansion rules (CMP0054), there's a lot of > changes otherwise); however, all you should get are warnings about the > change, not the actual behavior change without actually bumping your > minimum version or enabling the policy explicitly. Oki, that sounds about right. > >> > This has become an issue following http://build.kde.org/job/cmake/160/ >> > which has led to a significant number of our projects failing to build >> > from source as can be seen here - >> > http://build.kde.org/view/Frameworks/ > > So looking at kdelibs4support, I see lots of CMP0053 warnings (due to > the @var@ expansion in normal CMakeLists.txt processing which was > obscure and undocumented) and CMP0048 warnings (I'm not familiar with > it, but it's about project() offering version variables). In kdelibs, I > see CMP0022 and CMP0046 warnings (both related to target_link_libraries > and things which are likely bugs anyways such as depending on > non-existent targets or a mismatch between INTERFACE_LINK_LIBRARIES and > LINK_INTERFACE_LIBRARIES). > > However, I do see: > > 04:35:39 -- Installing: /srv/jenkins/workspace/kdelibs_master/local-inst/srv/jenkins/install/linux/x86_64/g++/latest-qt4/kde/kdelibs/inst/include/kpluginfactory.h > > in kdelibs' logs, so it makes me think that: > > /srv/jenkins/workspace/kdelibs4support_master_qt5/src/kssl/kcm/kcmssl.cpp:27:28: fatal error: kpluginfactory.h: No such file or directory > > implies the build isn't getting the include directories plumbed through > properly. I'll try a build tomorrow (or if it'd be possible to run a > Jenkins build of kdelibs4support with make VERBOSE=1, that'd be great > too since the environment would be consistent then). My gut feeling is > some CMP0054 corner case isn't caught and falls through to the new > behavior without a warning (or the old behavior was subtly changed in > the process), but that's just a shot in the dark. Slight bit of confusion here, sorry about that. kdelibs_master is for the KDE 4 (Qt 4 based) series of software. kdelibs4support_master_qt5 is for the Frameworks 5 (Qt 5 based) series of software. In this case, kpluginfactory.h should come from kcoreaddons. It's build log can be found here - http://build.kde.org/job/kcoreaddons_master_qt5/153/consoleText I can't see a sign of kpluginfactory.h being installed there unfortunately. Others have done a bit of digging already it seems as to what might be the cause. Please see https://mail.kde.org/pipermail/kde-frameworks-devel/2014-October/019906.html for that. If you're still interested in a VERBOSE=1 build of some of our projects, i'll be more than happy to supply such a log. > >> > Someone needs to investigate this before CMake 3.1.0 goes out the door >> > and fix it. I've no idea what the policy is in the CMake world, but in >> > the KDE world this sort of compatibility breakage would be a release >> > blocker. > > Thanks for testing the rc; it should be a blocker on our side too. It > would indeed be bad for 3.1.0 to release with such breaking changes. > We try really hard for backwards compatibility. Obviously our test > coverage is lacking somewhere. That is a relief to know. > >> And it would seem that the CMake developers prefer to live in their >> own closed off little bubble. My post was automatically rejected. >> Someone who is subscribed there will have to take this up with them. >> I'm extremely displeased. >> >> If they release CMake 3.1.0 with this regression, we should consider >> forking CMake as their developers can't be trusted to ensure our code >> remains buildable. Sorry for that - I got a bit caught up in the heat of the moment. > > For preventing this in the future, would it be possible to set up > Jenkins build to submit builds for kdelibs and a few other libraries > which would test CMake master and submit to CMake's dashboard some > results nightly so we can catch these problems more quickly? There are > examples in: > > https://github.com/Kitware/CMake/tree/master/Tests/Contracts > > for how this is done for other projects already. The instance would > then just to set something like CMAKE_CONTRACT_PROJECTS=kdelibs and run > CMake's test suite and submit to the dashboard. Theoretically that is possible, although a little complicated. We would have to chain two or more Frameworks builds (each one relying on the results of the prior build) in this case in order to detect the regression which tripped us up here. It is something which would need some adjustments to how our CI scripts work, but is certainly feasible. Just to be sure, such a job would: 1) Build the latest CMake (branch next) 2) Use the newly built CMake to compile all of the Frameworks, run their unit tests and submit each one to CDash. 3) Execute the CMake unit tests and submit this to CDash as well. For each submission to CDash, would the same CMAKE_CONTRACT_PROJECTS variable apply? ie. they would all be kde-frameworks or similar, even though we're making multiple submissions? > > Thanks, > > --Ben Thanks, Ben ----- End forwarded message ----- From alex.merry at kde.org Fri Oct 24 10:15:35 2014 From: alex.merry at kde.org (Alex Merry) Date: Fri, 24 Oct 2014 15:15:35 +0100 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: <544A5BF7.2000800@kitware.com> References: <544A5919.6000804@kitware.com> <544A5BF7.2000800@kitware.com> Message-ID: <9204499.9BDeAiUES7@kyoshi> On Friday 24 October 2014 10:02:31 Brad King wrote: > On 10/24/2014 09:50 AM, Brad King wrote: > > With 3.0 we see the list of headers accumulate. With 3.1 just the > > first one works and the rest do not. > > I bisected it down to: > > commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49 > Author: Ben Boeckel > Date: Wed Mar 12 14:01:45 2014 -0400 > > cmDefinitions: Don't store parent lookups > > When looking up scopes, it is faster to not store the lookup locally to > keep the maps smaller and avoid extra allocations and rebalancing. > > -Brad Which matches my trimmed-down testcase: ----------------------------------------------------------------- cmake_minimum_required(VERSION 3.0) project(Minimal NONE) function(test_append varname entry) list(APPEND ${varname} "${entry}") set(${varname} ${${varname}} PARENT_SCOPE) set(${varname} ${${varname}} PARENT_SCOPE) endfunction() test_append(blah entry1) message(STATUS "blah=${blah}") test_append(blah entry2) message(FATAL_ERROR "blah=${blah}") ----------------------------------------------------------------- It's that double-setting of the variable in the parent scope that seems to be the killer. Alex From alex.merry at kde.org Fri Oct 24 10:24:57 2014 From: alex.merry at kde.org (Alex Merry) Date: Fri, 24 Oct 2014 15:24:57 +0100 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: <544A603A.4030505@kitware.com> References: <544A5BF7.2000800@kitware.com> <544A603A.4030505@kitware.com> Message-ID: <2355239.vjbPdPHlH4@kyoshi> On Friday 24 October 2014 10:20:42 Brad King wrote: > On 10/24/2014 10:02 AM, Brad King wrote: > > I bisected it down to: > > > > commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49 > > Author: Ben Boeckel > > Date: Wed Mar 12 14:01:45 2014 -0400 > > > > cmDefinitions: Don't store parent lookups > > > > When looking up scopes, it is faster to not store the lookup locally > > to > > keep the maps smaller and avoid extra allocations and rebalancing. > > Here is a minimal standalone example: > > $ cat regression.cmake > function(func var_name) > list(APPEND ${var_name} value) > set(${var_name} ${${var_name}} PARENT_SCOPE) > set(${var_name} ${${var_name}} PARENT_SCOPE) > endfunction() > func(var) > message(STATUS " var=[${var}]") > func(var) > message(STATUS " var=[${var}]") > > $ cmake-3.0 -P regression.cmake > -- var=[value] > -- var=[value;value] > > $ cmake-3.1 -P regression.cmake > -- var=[value] > -- var=[value] > > -Brad Even simpler: ------------------------------------------- cmake_minimum_required(VERSION 3.0) project(Minimal NONE) function(test_set) set(blah "value2") message(STATUS "before PARENT_SCOPE blah=${blah}") set(blah ${blah} PARENT_SCOPE) message(STATUS "after PARENT_SCOPE blah=${blah}") endfunction() set(blah value1) test_set() message(FATAL_ERROR "in parent scope, blah=${blah}") ------------------------------------------ With CMake master: -- before PARENT_SCOPE blah=value2 -- after PARENT_SCOPE blah=value1 CMake Error at CMakeLists.txt:13 (message): in parent scope, blah=value2 With CMake 3.0.2: -- before PARENT_SCOPE blah=value2 -- after PARENT_SCOPE blah=value2 CMake Error at CMakeLists.txt:13 (message): in parent scope, blah=value2 From ben.boeckel at kitware.com Fri Oct 24 10:54:17 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 24 Oct 2014 10:54:17 -0400 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: <2355239.vjbPdPHlH4@kyoshi> References: <544A5BF7.2000800@kitware.com> <544A603A.4030505@kitware.com> <2355239.vjbPdPHlH4@kyoshi> Message-ID: <20141024145417.GB6450@megas.kitwarein.com> On Fri, Oct 24, 2014 at 15:24:57 +0100, Alex Merry wrote: > On Friday 24 October 2014 10:20:42 Brad King wrote: > > On 10/24/2014 10:02 AM, Brad King wrote: > > > commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49 > > > Author: Ben Boeckel > > > Date: Wed Mar 12 14:01:45 2014 -0400 > > > > > > cmDefinitions: Don't store parent lookups > > > > > > When looking up scopes, it is faster to not store the lookup locally > > > to > > > keep the maps smaller and avoid extra allocations and rebalancing. So the problem was that when redoing the "pull" logic for PARENT_SCOPE, it was unconditional when it should be skipped if the variable is already local. Pushed to stage as: variable-pull-failure > ------------------------------------------- > cmake_minimum_required(VERSION 3.0) > project(Minimal NONE) > > function(test_set) > set(blah "value2") > message(STATUS "before PARENT_SCOPE blah=${blah}") > set(blah ${blah} PARENT_SCOPE) > message(STATUS "after PARENT_SCOPE blah=${blah}") > endfunction() > > set(blah value1) > test_set() > message(FATAL_ERROR "in parent scope, blah=${blah}") > ------------------------------------------ Now added as a test in CMake (with minor changes). Thanks, --Ben From ben.boeckel at kitware.com Fri Oct 24 11:36:40 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 24 Oct 2014 11:36:40 -0400 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: <20141024145417.GB6450@megas.kitwarein.com> References: <544A5BF7.2000800@kitware.com> <544A603A.4030505@kitware.com> <2355239.vjbPdPHlH4@kyoshi> <20141024145417.GB6450@megas.kitwarein.com> Message-ID: <20141024153640.GA6124@megas.kitwarein.com> On Fri, Oct 24, 2014 at 10:54:17 -0400, Ben Boeckel wrote: > On Fri, Oct 24, 2014 at 15:24:57 +0100, Alex Merry wrote: > > On Friday 24 October 2014 10:20:42 Brad King wrote: > > > On 10/24/2014 10:02 AM, Brad King wrote: > > > > commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49 > > > > Author: Ben Boeckel > > > > Date: Wed Mar 12 14:01:45 2014 -0400 > > > > > > > > cmDefinitions: Don't store parent lookups > > > > > > > > When looking up scopes, it is faster to not store the lookup locally > > > > to > > > > keep the maps smaller and avoid extra allocations and rebalancing. > > So the problem was that when redoing the "pull" logic for PARENT_SCOPE, > it was unconditional when it should be skipped if the variable is > already local. So after discussion with Brad, this commit breaks other subtle behaviors as well, so the plan is to just revert it instead and defer its optimizations until after 3.1 once proper tests are in place (more under development now). --Ben From ben.boeckel at kitware.com Fri Oct 24 13:09:01 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 24 Oct 2014 13:09:01 -0400 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: <20141024153640.GA6124@megas.kitwarein.com> References: <544A5BF7.2000800@kitware.com> <544A603A.4030505@kitware.com> <2355239.vjbPdPHlH4@kyoshi> <20141024145417.GB6450@megas.kitwarein.com> <20141024153640.GA6124@megas.kitwarein.com> Message-ID: <20141024170901.GA30288@megas.kitwarein.com> On Fri, Oct 24, 2014 at 11:36:40 -0400, Ben Boeckel wrote: > So after discussion with Brad, this commit breaks other subtle behaviors > as well, so the plan is to just revert it instead and defer its > optimizations until after 3.1 once proper tests are in place (more under > development now). There are two branches on stage now (the previously mentioned branch has been reverted): - parent-scope-tests Based on v3.0.0~ to test that it worked on the release. This includes the more complex testing of PARENT_SCOPE's behaviors. - revert-definition-map-lookup Based on the bad commit, this reverts it with a description of what it is happening and then merges in parent-scope-tests to ensure that it works there. --Ben From ydginster at gmail.com Fri Oct 24 17:46:52 2014 From: ydginster at gmail.com (Evgeny Kalishenko) Date: Sat, 25 Oct 2014 01:46:52 +0400 Subject: [cmake-developers] [PATCH] Preinstall requirements support for CPack RPM generator In-Reply-To: <54465680.9060003@kitware.com> References: <543695B3.5010201@kitware.com> <5443A04E.7030806@gmail.com> <54465680.9060003@kitware.com> Message-ID: Documentation added, authorship fixed, a couple of commits squashed. 2014-10-21 16:50 GMT+04:00 Brad King : > On 10/20/2014 12:53 PM, Evgeny Kalishenko wrote: > > The final patch version with erroneous spelling fixes. > > Thanks. Please configure your git 'user.name' so that proper > authorship is recorded with your Real Name. Also please squash > the spelling fixup changes back in the commit that they fixup. > > >> Here, /X/ can be one of *pre*, *post*, *preun*, or *postun* > > The PREUN and POSTUN patch does not add documentation of any > corresponding CPackRPM variables. Should it? > > Thanks, > -Brad > > -- Regards, Evgeny Kalishenko -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pre_post_rpm_install.patch Type: text/x-patch Size: 7464 bytes Desc: not available URL: From ben.boeckel at kitware.com Fri Oct 24 19:23:42 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 24 Oct 2014 19:23:42 -0400 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: References: Message-ID: <20141024232342.GB999@bronto-burt.dev.benboeckel.net> On Sat, Oct 25, 2014 at 08:50:12 +1300, Ben Cooksley wrote: > On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly wrote: > > Is build.kde.org now using the release branch of cmake.git instead of the > > next branch? When/why did that change? > > This was changed around about > http://mail.kde.org/pipermail/kde-frameworks-devel/2014-June/016670.html > The motivation behind the change was to get the CI system to have the > same setup as developers I think, and to avoid regressions in 3.1 > which had been causing some build problems at the time. Those same > regressions are the ones causing us issues now. > > Interestingly, the commit which was identified as causing the issue > occurred back in March, yet this thread was in June. So perhaps there > may be other commits interacting here (or that was the time when the > commit previously identified was merged into the next branch). Earlier this year, I was working on lots of performance metrics of CMake and this was part of it. There ended up being more than a dozen branches resulting from that work (some of them still unmerged). Doing some digging shows that this is where the commit finally hit master: commit bd20dd6b8a925a421167602027fff9b904fd0822 Merge: b041fc1 e17a69b Author: Brad King Date: Thu Jun 12 11:28:44 2014 -0400 so June looks right. --Ben From mantis at public.kitware.com Fri Oct 24 20:09:15 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 24 Oct 2014 20:09:15 -0400 Subject: [cmake-developers] [CMake 0015218]: Option to forward signals to running test subprocesses Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15218 ====================================================================== Reported By: Zach Mullen Assigned To: ====================================================================== Project: CMake Issue ID: 15218 Category: CTest Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-24 20:09 EDT Last Modified: 2014-10-24 20:09 EDT ====================================================================== Summary: Option to forward signals to running test subprocesses Description: It would be great to have an option when running ctest that would forward signals (or a subset of signals) down to the running test processes. My main use case for this is that I would like for my test processes to cleanly shut down when the outer ctest process gets a SIGINT from being ctrl+c'd by the user. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-24 20:09 Zach Mullen New Issue ====================================================================== From steveire at gmail.com Sat Oct 25 02:14:46 2014 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 25 Oct 2014 08:14:46 +0200 Subject: [cmake-developers] Severe behavioural change regressions in release branch References: Message-ID: Ben Cooksley wrote: > On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly wrote: >> Is build.kde.org now using the release branch of cmake.git instead of the >> next branch? When/why did that change? > > This was changed around about > http://mail.kde.org/pipermail/kde-frameworks-devel/2014-June/016670.html That thread is... unsettling. No participant suggested reporting the issue. Four months later bigger waves are made. KDE and CMake are the same in that both rely on people hitting problems to report them. This could have been fixed mere days after it hit master. Something for KDE to learn from I hope. Thanks, Steve. From ben.boeckel at kitware.com Sat Oct 25 10:02:44 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Sat, 25 Oct 2014 10:02:44 -0400 Subject: [cmake-developers] [bcooksley@kde.org: Re: Fwd: Re: Severe behavioural change regressions in release branch] In-Reply-To: <20141024142249.GA6450@megas.kitwarein.com> References: <20141024142249.GA6450@megas.kitwarein.com> Message-ID: <20141025140244.GA19943@bronto-burt.dev.benboeckel.net> On Fri, Oct 24, 2014 at 10:22:49 -0400, Ben Boeckel wrote: > > For preventing this in the future, would it be possible to set up > > Jenkins build to submit builds for kdelibs and a few other libraries > > which would test CMake master and submit to CMake's dashboard some > > results nightly so we can catch these problems more quickly? There are > > examples in: > > > > https://github.com/Kitware/CMake/tree/master/Tests/Contracts > > > > for how this is done for other projects already. The instance would > > then just to set something like CMAKE_CONTRACT_PROJECTS=kdelibs and run > > CMake's test suite and submit to the dashboard. > > Theoretically that is possible, although a little complicated. We > would have to chain two or more Frameworks builds (each one relying on > the results of the prior build) in this case in order to detect the > regression which tripped us up here. It is something which would need > some adjustments to how our CI scripts work, but is certainly > feasible. > > Just to be sure, such a job would: > > 1) Build the latest CMake (branch next) > 2) Use the newly built CMake to compile all of the Frameworks, run > their unit tests and submit each one to CDash. > 3) Execute the CMake unit tests and submit this to CDash as well. > > For each submission to CDash, would the same CMAKE_CONTRACT_PROJECTS > variable apply? ie. they would all be kde-frameworks or similar, even > though we're making multiple submissions? So the way it works is that the contract build actually happens during CMake's ctest run. So to do this, you could add two libraries which depend on each other into the contract test. Basically all that needs to be done is to set up externalproject_add calls for the two with proper dependencies between them. There shouldn't be a need for building cmake then chaining it out to some other build instance. --Ben From chuck.atkins at kitware.com Sun Oct 26 00:18:10 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Sun, 26 Oct 2014 00:18:10 -0400 Subject: [cmake-developers] FindBoost.cmake cannot find some libraries when cross-compiling In-Reply-To: <5448B7D1.1030604@parrot.com> References: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan> <4037EE152A73A9448DAD73C415D4D8C0873819@MBX79.aswsp.lan> <5448B7D1.1030604@parrot.com> Message-ID: Guillaume, Nice patch! Good detail in the commit message. I make a few minor tweaks for typos and tense, but other than that, it's good. Pushed to stage as 'find-boost-no-reroot' and merged to next for testing. We'll keep an eye on the dashboards and fix as needed but I don't anticipate any issues. Thanks for the patch! - Chuck On Thu, Oct 23, 2014 at 4:09 AM, Guillaume Papin wrote: > Please find the patch attached to this email. > Let me know if anything is wrong. > > Best, > Guillaume > > > On 10/16/2014 05:09 PM, Chuck Atkins wrote: > > Guillaume, > > Please see CONTRIBUTING.rst in the top level of the CMake source tree. > If you can please create and post a patch against cmake master then I'll > work on getting it merged into cmake next. Thanks for the bug fix! > > - Chuck > > On Thu, Oct 16, 2014 at 10:32 AM, Chuck Atkins > wrote: > >> This looks like a reasonable way to accomplish this right now. The >> underlying prioblem is that ther's no way to specify which path types get >> re-rooted and which don't. Ideally you'd want to be able to specify in the >> toolchain for something like this that all paths operate in "ONLY" mode >> except HINTS, which you would want to place in NEVER mode. I'm currently >> working on just such a feature but in the meantime, forcing it like this in >> the FindBoost module looks reasonable. >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sun Oct 26 03:27:11 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 26 Oct 2014 03:27:11 -0400 Subject: [cmake-developers] [CMake 0015219]: cmake does not compile any more since 3.0.0 Message-ID: <6520a05f8eec83d5e29fe79a7f56ff7e@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15219 ====================================================================== Reported By: rupert Assigned To: ====================================================================== Project: CMake Issue ID: 15219 Category: Development Reproducibility: always Severity: block Priority: low Status: new ====================================================================== Date Submitted: 2014-10-26 03:27 EDT Last Modified: 2014-10-26 03:27 EDT ====================================================================== Summary: cmake does not compile any more since 3.0.0 Description: hi, i am trying to package cmake for opencsw, and i am unsure what got changed in 3.0.0 to not make it compile any more. maybe also our buildsystem is guilty. "/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.h", line 394: syntax error before or at: data_ahead "/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.h", line 394: warning: old-style declaration or incorrect type for: data_ahead "/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.h", line 395: warning: old-style declaration or incorrect type for: data_behind "/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 124: warning: no explicit type given "/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 124: syntax error before or at: _nc_Copy_Type "/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 124: warning: old-style declaration or incorrect type for: _nc_Copy_Type "/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 132: warning: no explicit type given "/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 132: syntax error before or at: _nc_Internal_Validation "/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 132: warning: old-style declaration or incorrect type for: _nc_Internal_Validation "/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 71: improper member use: status "/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 72: improper member use: makearg "/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 73: improper member use: copyarg "/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 74: improper member use: freearg cc: acomp failed for /home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c Source/CursesDialog/form/CMakeFiles/cmForm.dir/build.make:54: recipe for target 'Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o' failed gmake[2]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o] Error 2 gmake[2]: Leaving directory '/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2' CMakeFiles/Makefile2:1665: recipe for target 'Source/CursesDialog/form/CMakeFiles/cmForm.dir/all' failed gmake[1]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/all] Error 2 gmake[1]: Leaving directory '/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2' Makefile:147: recipe for target 'all' failed gmake: *** [all] Error 2 gmake: Leaving directory '/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2' /home/rupert/opencsw/.buildsys/v2/gar//gar.lib.mk:874: recipe for target 'build-work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Makefile' failed gmake[1]: *** [build-work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.2/Makefile] Error 2 gmake[1]: Leaving directory '/home/rupert/opencsw/cmake/trunk' gar/gar.mk:198: recipe for target 'merge-isa-pentium_pro' failed gmake: *** [merge-isa-pentium_pro] Error 2 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-26 03:27 rupert New Issue ====================================================================== From ben.boeckel at kitware.com Mon Oct 27 08:30:07 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 27 Oct 2014 08:30:07 -0400 Subject: [cmake-developers] [bcooksley@kde.org: Re: [bcooksley@kde.org: Re: Fwd: Re: Severe behavioural change regressions in release branch]] Message-ID: <20141027123007.GA10310@megas.kitwarein.com> ----- Forwarded message from Ben Cooksley ----- Date: Sun, 26 Oct 2014 11:50:45 +1300 From: Ben Cooksley To: Ben Boeckel Subject: Re: [bcooksley at kde.org: Re: [cmake-developers] Fwd: Re: Severe behavioural change regressions in release branch] On Sun, Oct 26, 2014 at 3:02 AM, Ben Boeckel wrote: > On Fri, Oct 24, 2014 at 10:22:49 -0400, Ben Boeckel wrote: >> > For preventing this in the future, would it be possible to set up >> > Jenkins build to submit builds for kdelibs and a few other libraries >> > which would test CMake master and submit to CMake's dashboard some >> > results nightly so we can catch these problems more quickly? There are >> > examples in: >> > >> > https://github.com/Kitware/CMake/tree/master/Tests/Contracts >> > >> > for how this is done for other projects already. The instance would >> > then just to set something like CMAKE_CONTRACT_PROJECTS=kdelibs and run >> > CMake's test suite and submit to the dashboard. >> >> Theoretically that is possible, although a little complicated. We >> would have to chain two or more Frameworks builds (each one relying on >> the results of the prior build) in this case in order to detect the >> regression which tripped us up here. It is something which would need >> some adjustments to how our CI scripts work, but is certainly >> feasible. >> >> Just to be sure, such a job would: >> >> 1) Build the latest CMake (branch next) >> 2) Use the newly built CMake to compile all of the Frameworks, run >> their unit tests and submit each one to CDash. >> 3) Execute the CMake unit tests and submit this to CDash as well. >> >> For each submission to CDash, would the same CMAKE_CONTRACT_PROJECTS >> variable apply? ie. they would all be kde-frameworks or similar, even >> though we're making multiple submissions? > > So the way it works is that the contract build actually happens during > CMake's ctest run. So to do this, you could add two libraries which > depend on each other into the contract test. Basically all that needs to > be done is to set up externalproject_add calls for the two with proper > dependencies between them. > > There shouldn't be a need for building cmake then chaining it out to > some other build instance. Okay, that sort of simplifies things a bit. I'll need to look into this further and probably talk with someone who is more familiar with CMake than I am to help to get it sorted out, but it should be possible to get this arranged with our setup. (The list still has me blocked, so this will need to be forwarded as well) > > --Ben Thanks, Ben ----- End forwarded message ----- From brad.king at kitware.com Mon Oct 27 09:11:45 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Oct 2014 09:11:45 -0400 Subject: [cmake-developers] [PATCHv2] Tests: Run Tutorial steps 1-4 as tests for Windows CE In-Reply-To: <1414156871-28308-1-git-send-email-pascal.bach@siemens.com> References: <5446586D.6010107@kitware.com> <1414156871-28308-1-git-send-email-pascal.bach@siemens.com> Message-ID: <544E4491.7080002@kitware.com> On 10/24/2014 09:21 AM, Pascal Bach wrote: > --- > Tests/CMakeLists.txt | 46 +++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 45 insertions(+), 1 deletion(-) Thanks, applied: Tests: Run Tutorial steps 1-4 as tests for Windows CE http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e690d0db -Brad From brad.king at kitware.com Mon Oct 27 09:27:52 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Oct 2014 09:27:52 -0400 Subject: [cmake-developers] [PATCH] Preinstall requirements support for CPack RPM generator In-Reply-To: References: <543695B3.5010201@kitware.com> <5443A04E.7030806@gmail.com> <54465680.9060003@kitware.com> Message-ID: <544E4858.5070105@kitware.com> On 10/24/2014 05:46 PM, Evgeny Kalishenko wrote: > Documentation added, authorship fixed, a couple of commits squashed. Great. Applied and merged for testing: CPackRPM: Support pre(post) install scripts http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7d049e7c CPackRPM: Support PREUN and POSTUN requirements http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=04801c2e Thanks, -Brad From brad.king at kitware.com Mon Oct 27 09:46:07 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Oct 2014 09:46:07 -0400 Subject: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <0b5b33c4d1f0472782e260f9e5bce980@CO1PR07MB208.namprd07.prod.outlook.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <543D2BBC.1010306@kitware.com> <0b5b33c4d1f0472782e260f9e5bce980@CO1PR07MB208.namprd07.prod.outlook.com> Message-ID: <544E4C9F.3050408@kitware.com> On 10/14/2014 12:48 PM, Geoffrey Viola wrote: > Green Hills MULTI is an IDE for embedded real-time systems. > http://www.ghs.com/products/MULTI_IDE.html. > http://www.ghs.com/products/rtos/integrity.html. Thanks for the explanation. > I took a look at CMAKE_OSX_SYSROOT. It is similar to GHS_OS_DIR. > There may be a simpler way to represent these customizations, > but I don't know if there are any guarantees on standard folder > structures or names. [snip] > It seems there needs to be some development to use the find boost > module, because "CMAKE_FIND_LIBRARY_PREFIXES" is not set. Both of these should be addressed by creating the corresponding Modules/Platform/*.cmake files associated with the target platform. -Brad From eike at sf-mail.de Mon Oct 27 10:41:37 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 27 Oct 2014 15:41:37 +0100 Subject: [cmake-developers] [PATCH] Preinstall requirements support for CPack RPM generator In-Reply-To: <544E4858.5070105@kitware.com> References: "\" <543695B3.5010201@kitware.com> <5443A04E.7030806@gmail.com>" " <54465680.9060003@kitware.com> <544E4858.5070105@kitware.com> Message-ID: Am 27.10.2014 14:27, schrieb Brad King: > On 10/24/2014 05:46 PM, Evgeny Kalishenko wrote: >> Documentation added, authorship fixed, a couple of commits squashed. > > Great. Applied and merged for testing: > > CPackRPM: Support pre(post) install scripts > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7d049e7c > if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE" OR > "${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST") This should really be using STREQUAL and not using dereferences on the left hand side. Eike From brad.king at kitware.com Mon Oct 27 10:55:50 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Oct 2014 10:55:50 -0400 Subject: [cmake-developers] [PATCH] Preinstall requirements support for CPack RPM generator In-Reply-To: References: "\" <543695B3.5010201@kitware.com> <5443A04E.7030806@gmail.com>" " <54465680.9060003@kitware.com> <544E4858.5070105@kitware.com> Message-ID: <544E5CF6.6050608@kitware.com> On 10/27/2014 10:41 AM, Rolf Eike Beer wrote: >> if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE" OR >> "${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST") > > This should really be using STREQUAL and not using dereferences on the > left hand side. Thanks. Actually I mentioned that in my first review in this thread but forgot to check that it had been resolved in updated patches. It doesn't matter though because the second commit replaces that line with different logic anyway. -Brad From mantis at public.kitware.com Mon Oct 27 12:10:27 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 27 Oct 2014 12:10:27 -0400 Subject: [cmake-developers] [CMake 0015220]: Find_package(Curses) failed for QNX 6.5 and QNX 6.6 Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15220 ====================================================================== Reported By: Anton Indrawan Assigned To: ====================================================================== Project: CMake Issue ID: 15220 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-27 12:10 EDT Last Modified: 2014-10-27 12:10 EDT ====================================================================== Summary: Find_package(Curses) failed for QNX 6.5 and QNX 6.6 Description: When using find_package(Curses) for a cmake project compiled with the QNX 6.5 or QNX 6.6 toolchain, cmake threw the following error: CMake Error at /usr/local/share/cmake-3.0/Modules/FindCurses.cmake:139 (CHECK_LIBRARY_EXISTS): Unknown CMake command "CHECK_LIBRARY_EXISTS". Call Stack (most recent call first): TestProgram/curses/CMakeLists.txt:3 (find_package) The same error is reproducible on cmake 3.0.2. Steps to Reproduce: To reproduce the issue, you have to have a QNX 6.5 or QNX 6.6 toolchain installed. 1. Please create a simple cmake project which calls "find_package(Curses)" project(test.curses) find_package(Curses) add_executable(${PROJECT_NAME} main.cpp) 2. In the main.cpp, it can just be an empty int main. Additional Information: The toolchains I am using are standard QNX 6.5 and QNX 6.6 toolchains downloaded from www.qnx.com. The host OS is Ubuntu 12.04 64-bit. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-27 12:10 Anton Indrawan New Issue ====================================================================== From ydginster at gmail.com Mon Oct 27 12:22:53 2014 From: ydginster at gmail.com (Evgeny Kalishenko) Date: Mon, 27 Oct 2014 20:22:53 +0400 Subject: [cmake-developers] [PATCH] Preinstall requirements support for CPack RPM generator In-Reply-To: <544E5CF6.6050608@kitware.com> References: <543695B3.5010201@kitware.com> <5443A04E.7030806@gmail.com> <54465680.9060003@kitware.com> <544E4858.5070105@kitware.com> <544E5CF6.6050608@kitware.com> Message-ID: Little correction: the first comment "CPackRPM: Support pre(post) install scripts" differs from mine "Requires for pre(post) install scripts are implemented" and can cause misunderstanding. Because "pre(post) install scripts" are already implemented. 2014-10-27 17:55 GMT+03:00 Brad King : > On 10/27/2014 10:41 AM, Rolf Eike Beer wrote: > >> if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE" OR > >> "${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST") > > > > This should really be using STREQUAL and not using dereferences on the > > left hand side. > > Thanks. Actually I mentioned that in my first review in this thread > but forgot to check that it had been resolved in updated patches. > > It doesn't matter though because the second commit replaces that > line with different logic anyway. > > -Brad > > -- Regards, Evgeny Kalishenko -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Oct 27 12:37:25 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Oct 2014 12:37:25 -0400 Subject: [cmake-developers] [PATCH] Preinstall requirements support for CPack RPM generator In-Reply-To: References: <543695B3.5010201@kitware.com> <5443A04E.7030806@gmail.com> <54465680.9060003@kitware.com> <544E4858.5070105@kitware.com> <544E5CF6.6050608@kitware.com> Message-ID: <544E74C5.7020903@kitware.com> On 10/27/2014 12:22 PM, Evgeny Kalishenko wrote: > Little correction: Revised: CPackRPM: Support pre(post) install script requirements http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=add4e50d CPackRPM: Support PREUN and POSTUN requirements http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9ed546ff Thanks, -Brad From eike at sf-mail.de Mon Oct 27 13:34:18 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 27 Oct 2014 18:34:18 +0100 Subject: [cmake-developers] [PATCH] Preinstall requirements support for CPack RPM generator In-Reply-To: <544E5CF6.6050608@kitware.com> References: <544E5CF6.6050608@kitware.com> Message-ID: <4982937.QGZPQ7vsBa@caliban.sf-tec.de> Am Montag, 27. Oktober 2014, 10:55:50 schrieb Brad King: > On 10/27/2014 10:41 AM, Rolf Eike Beer wrote: > >> if("${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_PRE" OR > >> "${_RPM_SPEC_HEADER}" MATCHES "REQUIRES_POST") > > > > This should really be using STREQUAL and not using dereferences on the > > left hand side. > > Thanks. Actually I mentioned that in my first review in this thread > but forgot to check that it had been resolved in updated patches. > > It doesn't matter though because the second commit replaces that > line with different logic anyway. Why not use that logic from the beginning then? Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From orion at cora.nwra.com Mon Oct 27 13:59:09 2014 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 27 Oct 2014 11:59:09 -0600 Subject: [cmake-developers] cmake-gui icons Message-ID: <544E87ED.4080208@cora.nwra.com> Trying to bring a bit more attention to this: Fedora is pushing to have higher resolution icons for the applications. There already is CMakeSetup128.png, but these would need to get installed into the proper /usr/share/icons/ hierarchy and named appropriately for the correct size to be automatically found and used. It would be good to have cmake-gui be conformant to the current desktop standards. Related - http://www.cmake.org/Bug/view.php?id=13504 http://www.cmake.org/Bug/view.php?id=14315 Also might want to consider shipping AppData information. http://people.freedesktop.org/~hughsient/appdata/ -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From ben.boeckel at kitware.com Mon Oct 27 16:33:20 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 27 Oct 2014 16:33:20 -0400 Subject: [cmake-developers] cmake-gui icons In-Reply-To: <544E87ED.4080208@cora.nwra.com> References: <544E87ED.4080208@cora.nwra.com> Message-ID: <20141027203320.GA32588@megas.kitwarein.com> On Mon, Oct 27, 2014 at 11:59:09 -0600, Orion Poplawski wrote: > Trying to bring a bit more attention to this: > > Fedora is pushing to have higher resolution icons for the applications. There > already is CMakeSetup128.png, but these would need to get installed into the > proper /usr/share/icons/ hierarchy and named appropriately for the correct > size to be automatically found and used. It would be good to have cmake-gui be > conformant to the current desktop standards. > > Related - > > http://www.cmake.org/Bug/view.php?id=13504 > http://www.cmake.org/Bug/view.php?id=14315 > > Also might want to consider shipping AppData information. > > http://people.freedesktop.org/~hughsient/appdata/ I think there's a bug about this too (or at least for appdata). My question is: does it really make sense to have appdata for CMake's GUI? It isn't an "end user" application and I feel that developers "know" about CMake's Qt UI (or at least wouldn't look for it in the application tool thing). (I'm not against AppData overall; just wondering whether it makes sense for development tools such as cmake-gui.) Others' thoughts? --Ben From bcooksley at kde.org Mon Oct 27 16:58:58 2014 From: bcooksley at kde.org (Ben Cooksley) Date: Tue, 28 Oct 2014 09:58:58 +1300 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: References: Message-ID: On Sat, Oct 25, 2014 at 7:14 PM, Stephen Kelly wrote: > Ben Cooksley wrote: > >> On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly wrote: >>> Is build.kde.org now using the release branch of cmake.git instead of the >>> next branch? When/why did that change? >> >> This was changed around about >> http://mail.kde.org/pipermail/kde-frameworks-devel/2014-June/016670.html > > That thread is... unsettling. No participant suggested reporting the issue. > Four months later bigger waves are made. Yes. > > KDE and CMake are the same in that both rely on people hitting problems to > report them. > > This could have been fixed mere days after it hit master. > > Something for KDE to learn from I hope. If anyone is interested, help would be appreciated to get a Contracts style build up and running. In particular, pointers to documentation on how to perform such builds would be appreciated - we'll need to run "make install" for parts of it which doesn't seem to happen in any of the existing examples as far as I can see. > > Thanks, > > Steve. > Thanks, Ben > > _______________________________________________ > Kde-buildsystem mailing list > Kde-buildsystem at kde.org > https://mail.kde.org/mailman/listinfo/kde-buildsystem From ben.boeckel at kitware.com Mon Oct 27 17:22:45 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 27 Oct 2014 17:22:45 -0400 Subject: [cmake-developers] Severe behavioural change regressions in release branch In-Reply-To: References: Message-ID: <20141027212245.GA9878@megas.kitwarein.com> On Tue, Oct 28, 2014 at 09:58:58 +1300, Ben Cooksley wrote: > If anyone is interested, help would be appreciated to get a Contracts > style build up and running. > In particular, pointers to documentation on how to perform such builds > would be appreciated - we'll need to run "make install" for parts of > it which doesn't seem to happen in any of the existing examples as far > as I can see. Since it's a CMake build, ExternalProject should make it fairly straightforward. A quick sketch of the non-boilerplate code I see in the current contracts tests: externalproject_add(kdelibs GIT_REPOSITORY [...] GIT_TAG [...] # The oldest supported release. CMAKE_ARGS [...] INSTALL_DIR "${CMAKE_CURRENT_BINARY_DIR}/install") externalproject_add(someotherkdelib DEPENDS kdelibs GIT_REPOSITORY [...] GIT_TAG [...] # The oldest supported release. CMAKE_ARGS # Might not be necessary. "-DCMAKE_MODULE_PATH={$CMAKE_CURRENT_BINARY_DIR}/install/lib/cmake" [...] INSTALL_DIR "${CMAKE_CURRENT_BINARY_DIR}/install") The rationale for using the oldest supported release is so that we make sure whatever was written *then* still works today. --Ben From mantis at public.kitware.com Mon Oct 27 18:32:49 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 27 Oct 2014 18:32:49 -0400 Subject: [cmake-developers] [CMake 0015221]: Allow a user to set project-wide attributes in Xcode Message-ID: <48e0cb3bad85b17ded6275c48b95d732@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15221 ====================================================================== Reported By: Ilya Assigned To: ====================================================================== Project: CMake Issue ID: 15221 Category: CMake Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-27 18:32 EDT Last Modified: 2014-10-27 18:32 EDT ====================================================================== Summary: Allow a user to set project-wide attributes in Xcode Description: Some options are very often used project-wide, e.g. LLVM_LTO or DEBUG_INFORMATION_FORMAT. CMake should allow to set them globally e.g. via set_propert(GLOBAL?) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-27 18:32 Ilya New Issue ====================================================================== From daniel at pfeifer-mail.de Tue Oct 28 03:27:16 2014 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Tue, 28 Oct 2014 08:27:16 +0100 Subject: [cmake-developers] cmake-gui icons In-Reply-To: <20141027203320.GA32588@megas.kitwarein.com> References: <544E87ED.4080208@cora.nwra.com> <20141027203320.GA32588@megas.kitwarein.com> Message-ID: 2014-10-27 21:33 GMT+01:00 Ben Boeckel : > On Mon, Oct 27, 2014 at 11:59:09 -0600, Orion Poplawski wrote: > > Trying to bring a bit more attention to this: > > > > Fedora is pushing to have higher resolution icons for the applications. > There > > already is CMakeSetup128.png, but these would need to get installed into > the > > proper /usr/share/icons/ hierarchy and named appropriately for the > correct > > size to be automatically found and used. It would be good to have > cmake-gui be > > conformant to the current desktop standards. > > > > Related - > > > > http://www.cmake.org/Bug/view.php?id=13504 > > http://www.cmake.org/Bug/view.php?id=14315 > > > > Also might want to consider shipping AppData information. > > > > http://people.freedesktop.org/~hughsient/appdata/ > > I think there's a bug about this too (or at least for appdata). My > question is: does it really make sense to have appdata for CMake's GUI? > It isn't an "end user" application and I feel that developers "know" > about CMake's Qt UI (or at least wouldn't look for it in the application > tool thing). > > (I'm not against AppData overall; just wondering whether it makes sense > for development tools such as cmake-gui.) > > Others' thoughts? I wouds say: Yes, it makes sense. There is AppData for Anjuta, Eclipse, KDevelop, QtCreator and the like. Those too are tools for developers rather than "end users". cmake-gui would perfectly fit into that crowd. -- Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniele.domenichelli at gmail.com Tue Oct 28 06:48:23 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Tue, 28 Oct 2014 11:48:23 +0100 Subject: [cmake-developers] ExternalProject CMAKE_ARGS and CMAKE_CACHE_ARGS arguments In-Reply-To: <5447CADF.8020804@kitware.com> References: <543FE392.7020706@gmail.com> <54451383.4070809@kitware.com> <5446672F.3070501@gmail.com> <5447CADF.8020804@kitware.com> Message-ID: <544F7477.1060700@gmail.com> Hello Brad, Sorry for the delay. On 22/10/14 17:18, Brad King wrote: > How about a new option like "CMAKE_CACHE_DEFAULT_ARGS" for that? I just pushed a new ExternalProject_CMAKE_CACHE_DEFAULT_ARGS topic, can you please review it? Cheers, Daniele From DLRdave at aol.com Tue Oct 28 07:56:31 2014 From: DLRdave at aol.com (David Cole) Date: Tue, 28 Oct 2014 07:56:31 -0400 Subject: [cmake-developers] cmake-gui icons In-Reply-To: References: <544E87ED.4080208@cora.nwra.com> <20141027203320.GA32588@megas.kitwarein.com> Message-ID: I would say yes, too. On Tue, Oct 28, 2014 at 3:27 AM, Daniel Pfeifer wrote: > 2014-10-27 21:33 GMT+01:00 Ben Boeckel : > >> On Mon, Oct 27, 2014 at 11:59:09 -0600, Orion Poplawski wrote: >> > Trying to bring a bit more attention to this: >> > >> > Fedora is pushing to have higher resolution icons for the applications. >> There >> > already is CMakeSetup128.png, but these would need to get installed >> into the >> > proper /usr/share/icons/ hierarchy and named appropriately for the >> correct >> > size to be automatically found and used. It would be good to have >> cmake-gui be >> > conformant to the current desktop standards. >> > >> > Related - >> > >> > http://www.cmake.org/Bug/view.php?id=13504 >> > http://www.cmake.org/Bug/view.php?id=14315 >> > >> > Also might want to consider shipping AppData information. >> > >> > http://people.freedesktop.org/~hughsient/appdata/ >> >> I think there's a bug about this too (or at least for appdata). My >> question is: does it really make sense to have appdata for CMake's GUI? >> It isn't an "end user" application and I feel that developers "know" >> about CMake's Qt UI (or at least wouldn't look for it in the application >> tool thing). >> >> (I'm not against AppData overall; just wondering whether it makes sense >> for development tools such as cmake-gui.) >> >> Others' thoughts? > > > I wouds say: Yes, it makes sense. > > There is AppData for Anjuta, Eclipse, KDevelop, QtCreator and the like. > Those too are tools for developers rather than "end users". cmake-gui would > perfectly fit into that crowd. > > -- 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Tue Oct 28 08:08:50 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 28 Oct 2014 08:08:50 -0400 Subject: [cmake-developers] [CMake 0015222]: Need a way to determine when features were introduced into cmake Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15222 ====================================================================== Reported By: Charles Karney Assigned To: ====================================================================== Project: CMake Issue ID: 15222 Category: CMake Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-28 08:08 EDT Last Modified: 2014-10-28 08:08 EDT ====================================================================== Summary: Need a way to determine when features were introduced into cmake Description: Authors of cmake scripts face a challenge ensuring that their scripts are portable. This is exacerbated by * cmake is constantly evolving (which is good!); * their cmake scripts are run by a diverse set of users (also good!); * authors have little control over the version of cmake that end-users have installed; * the relationship with end-users is even more tenuous with the package-config scripts (which are not read by the builder of the package but by a developer using the package). There is cmake_minimum_required, but authors would normally not want to set this to too recent a version. The problem is that it's difficult to know when a particular feature appeared in cmake. There's no single changelog (and the format of the changelog doesn't make it easy to search in). Frequently I'm left doing a binary search in the documentation! Sometimes I need install old versions to check their behavior. For example I just noticed that install (TARGET ...) also an INCLUDES DESTINATION option. This seemed like a feature I should be using until I noticed that it only appeared in 2.8.12 (or thereabouts). Suggestions: * Have a developer mode where cmake behaves as though it were at the version given by cmake_minimum_required. (Probably this is unfeasible?) * In the documentation, specify when each command, command option, variable, etc., was introduced. (Might junk up the documentation.) * Split this information off into a separate document. (My favored solution.) Steps to Reproduce: N/A Additional Information: N/A ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-28 08:08 Charles Karney New Issue ====================================================================== From brad.king at kitware.com Tue Oct 28 10:18:05 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 28 Oct 2014 10:18:05 -0400 Subject: [cmake-developers] cmake-gui icons In-Reply-To: <544E87ED.4080208@cora.nwra.com> References: <544E87ED.4080208@cora.nwra.com> Message-ID: <544FA59D.6090701@kitware.com> On 10/27/2014 01:59 PM, Orion Poplawski wrote: > Fedora is pushing to have higher resolution icons for the applications. There > already is CMakeSetup128.png, but these would need to get installed into the > proper /usr/share/icons/ hierarchy and named appropriately for the correct > size to be automatically found and used. It would be good to have cmake-gui be > conformant to the current desktop standards. Where should it go and what should it be called? > http://www.cmake.org/Bug/view.php?id=13504 > http://www.cmake.org/Bug/view.php?id=14315 These were fixed in 3.0. I've updated the issue tracker entries. Thanks, -Brad From brad.king at kitware.com Tue Oct 28 10:20:31 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 28 Oct 2014 10:20:31 -0400 Subject: [cmake-developers] [PATCHv2] Tests: Run Tutorial steps 1-4 as tests for Windows CE In-Reply-To: <544E4491.7080002@kitware.com> References: <5446586D.6010107@kitware.com> <1414156871-28308-1-git-send-email-pascal.bach@siemens.com> <544E4491.7080002@kitware.com> Message-ID: <544FA62F.2050608@kitware.com> On 10/27/2014 09:11 AM, Brad King wrote: > Tests: Run Tutorial steps 1-4 as tests for Windows CE > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e690d0db Please take a look at the test failures on your dashboard submission for these tests. Thanks, -Brad From pascal.bach at siemens.com Tue Oct 28 10:23:15 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 28 Oct 2014 14:23:15 +0000 Subject: [cmake-developers] [PATCHv2] Tests: Run Tutorial steps 1-4 as tests for Windows CE In-Reply-To: <544FA62F.2050608@kitware.com> References: <5446586D.6010107@kitware.com> <1414156871-28308-1-git-send-email-pascal.bach@siemens.com> <544E4491.7080002@kitware.com> <544FA62F.2050608@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616AF4D2A@DEFTHW99EH4MSX.ww902.siemens.net> > On 10/27/2014 09:11 AM, Brad King wrote: > > Tests: Run Tutorial steps 1-4 as tests for Windows CE > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e690d0db > > Please take a look at the test failures on your dashboard submission > for these tests. > I'm already on it. I will let you know if I have found the problem. Pascal From mantis at public.kitware.com Tue Oct 28 12:07:52 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 28 Oct 2014 17:07:52 +0100 Subject: [cmake-developers] [CMake 0015223]: Object OUTPUT_EXTENSIONs selection is hard - if ever possible - to manage with cross compilation Message-ID: <8c30f1451ce30451166901d3d15db3ae@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15223 ====================================================================== Reported By: Emmanuel Blot Assigned To: ====================================================================== Project: CMake Issue ID: 15223 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-28 17:07 CET Last Modified: 2014-10-28 17:07 CET ====================================================================== Summary: Object OUTPUT_EXTENSIONs selection is hard - if ever possible - to manage with cross compilation Description: For some (historical?) reasons, CMake considers the default object extension tas ".obj", which is quite unusual but on Windows. CMake "Modules" files define: IF (UNIX) set(CMAKE__OUTPUT_EXTENSION .o) ELSE () set(CMAKE__OUTPUT_EXTENSION .obj) ENDIF () which makes the Unix style the exception, and Windows style the default rule. However, when cmake is used to cross compile, many (if not most) OSes use the Unix style, even if they are not Unix-based. The trouble is that UNIX variable seems to be mostly defined from the host environment, not from the target environment. The net result is that ".obj" extension is enforced for non-Windows targets, which in turn rapidly becomes a nightmare to manage. Forcing UNIX to 1 from a CMakeLists.txt sometimes helps for C source files - although it is definitely a hack - but does not with ASM files for example. Setting CMAKE__OUTPUT_EXTENSION from a CMakeLists.txt does not seem to be recommended - from previous CMake ML posts - and does not work anyway. Although I would personally favour .o to be the default extension and Windows the exception, I guess that for at least compatibility with previous CMake version this cannot be changed. However, being able to easily define the extension for a non Unix project, or for a cross compiled one is definitely a real need. Additional Information: I've failed - up to know - to find a way to choose the proper extension, which forced me to write ugly workaround in CMakeLists.txt files. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-28 17:07 Emmanuel Blot New Issue ====================================================================== From orion at cora.nwra.com Tue Oct 28 12:27:40 2014 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 28 Oct 2014 10:27:40 -0600 Subject: [cmake-developers] cmake-gui icons In-Reply-To: <544FA59D.6090701@kitware.com> References: <544E87ED.4080208@cora.nwra.com> <544FA59D.6090701@kitware.com> Message-ID: <544FC3FC.3020201@cora.nwra.com> On 10/28/2014 08:18 AM, Brad King wrote: > On 10/27/2014 01:59 PM, Orion Poplawski wrote: >> Fedora is pushing to have higher resolution icons for the applications. There >> already is CMakeSetup128.png, but these would need to get installed into the >> proper /usr/share/icons/ hierarchy and named appropriately for the correct >> size to be automatically found and used. It would be good to have cmake-gui be >> conformant to the current desktop standards. > > Where should it go and what should it be called? > There should be a series in: /usr/share/icons/hicolor/XxX/apps/CMakeSetup.png Where XxX is the resolution, eg: 32x32, 48x48,... : ls /usr/share/icons/hicolor 128x128 192x192 22x22 256x256 36x36 512x512 72x72 16x16 20x20 24x24 32x32 48x48 64x64 96x96 You don't need all of them, but a selection is nice. SVG/svgz is nice too, and that goes in "scalable". Then the icon name in the .desktop file is simply "CMakeSetup". http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From hobbes1069 at gmail.com Tue Oct 28 12:45:50 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Tue, 28 Oct 2014 11:45:50 -0500 Subject: [cmake-developers] cmake-gui icons In-Reply-To: <544FC3FC.3020201@cora.nwra.com> References: <544E87ED.4080208@cora.nwra.com> <544FA59D.6090701@kitware.com> <544FC3FC.3020201@cora.nwra.com> Message-ID: On Tue, Oct 28, 2014 at 11:27 AM, Orion Poplawski wrote: > There should be a series in: > > /usr/share/icons/hicolor/XxX/apps/CMakeSetup.png > > Where XxX is the resolution, eg: 32x32, 48x48,... : > > ls /usr/share/icons/hicolor > 128x128 192x192 22x22 256x256 36x36 512x512 72x72 > 16x16 20x20 24x24 32x32 48x48 64x64 96x96 > > You don't need all of them, but a selection is nice. > > SVG/svgz is nice too, and that goes in "scalable". > I do this within the RPM spec file for packages I maintain which don't do this for me but the idea should work the same for CMake, something like: if(UNIX) # Or any other qualifiers/tests needed... include(GNUInstallDirs) set(ICON_INSTALL_PREFIX} "${CMAKE_INSTALL_DATADIR}/icons/hicolor") set(ICON_SIZES "32x32;64x64;128x128") foreach(_size ICON_SIZES) install(FILES CMakeSetup${_size}.png DESTINATION ${ICON_INSTALL_PREFIX}/${_size}/apps RENAME CMakeSetup.png) endforeach() install(FILES CMakeSetup.svg DESTINATION ${ICON_INSTALL_PREFIX}/scalable/apps) endif() This assumes the icon size is appended to the base name. I haven't tested this and it may well have typos but I would think this would work. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Oct 28 13:01:28 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 28 Oct 2014 13:01:28 -0400 Subject: [cmake-developers] ExternalProject CMAKE_ARGS and CMAKE_CACHE_ARGS arguments In-Reply-To: <544F7477.1060700@gmail.com> References: <543FE392.7020706@gmail.com> <54451383.4070809@kitware.com> <5446672F.3070501@gmail.com> <5447CADF.8020804@kitware.com> <544F7477.1060700@gmail.com> Message-ID: <544FCBE8.4060600@kitware.com> On 10/28/2014 06:48 AM, Daniele E. Domenichelli wrote: > I just pushed a new ExternalProject_CMAKE_CACHE_DEFAULT_ARGS topic, can > you please review it? Good. After seeing the lack of a clean place to document the differences among these options I decided it is time to revise the documentation layout. I've done that here: ExternalProject: Convert docs to a bracket comment http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=98936ae3 ExternalProject: Use explicit markup and definition lists in docs http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9c2c17b Please rebase on those. You should find it much easier to add more detail to the documentation of each option. Thanks, -Brad From mantis at public.kitware.com Tue Oct 28 13:29:26 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 28 Oct 2014 13:29:26 -0400 Subject: [cmake-developers] [CMake 0015224]: CMake unconditionally sets WARNING_CFLAGS for each targets overriding project-level option. Message-ID: <7a6b23f3a2aa8314626f11df49a3bcb3@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15224 ====================================================================== Reported By: Ilya Assigned To: ====================================================================== Project: CMake Issue ID: 15224 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-28 13:29 EDT Last Modified: 2014-10-28 13:29 EDT ====================================================================== Summary: CMake unconditionally sets WARNING_CFLAGS for each targets overriding project-level option. Description: CMake not just sets WARNING_CFLAGS to the following: -Wmost -Wno-four-char-constants -Wno-unknown-pragmas but also overrides higher-level options e.g. set via CMAKE_XCODE_ATTRIBUTE. It should remove these 3 definitions, replace them with appropriate Xcode attributes or prepand WARNINGS_CFLAGS with "$(inherited)" so top-level attributes will be respected. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-28 13:29 Ilya New Issue ====================================================================== From mantis at public.kitware.com Tue Oct 28 13:42:14 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 28 Oct 2014 13:42:14 -0400 Subject: [cmake-developers] [CMake 0015225]: Xcode generator ignores the add_compile_options command Message-ID: <8e67b54aa56f9af2ee6c7e13436f1e2d@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15225 ====================================================================== Reported By: Ilya Assigned To: ====================================================================== Project: CMake Issue ID: 15225 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-28 13:42 EDT Last Modified: 2014-10-28 13:42 EDT ====================================================================== Summary: Xcode generator ignores the add_compile_options command Description: The flags specified via add_compile_options do not appear anywhere in generated Xcode project (I use Xcode 6) In other hand, options specified via the add_definitions command will be properly placed under the OTHER_CFLAGS Xcode attribute. Moreover, generator seems to categorize these flags and put them under appropriate Xcode attributes. E.g. add_definitions( -DHAVE_PTHREADS -Wduplicate-method-match ) -DHAVE_PTHREADS will be added to the GCC_PREPROCESSOR_DEFINITIONS Xcode attribute while -Wduplicate-method-match will be added to the OTHER_CFLAGS Xcode attribute. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-28 13:42 Ilya New Issue ====================================================================== From robert.maynard at kitware.com Tue Oct 28 14:16:58 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 28 Oct 2014 14:16:58 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing! Message-ID: I am proud to announce that CMake 3.1 has entered the release candidate stage. Sources and binaries are available at: http://www.cmake.org/files/v3.1/?C=M;O=D Documentation is available at: http://www.cmake.org/cmake/help/v3.1 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.1/release/3.1.0.html Some of the more significant features of CMake 3.1 are: * Windows Phone and Windows Store support has been added to Visual Studio 11 (2012) and above Generators. * NVIDIA Nsight Tegra support has been added to Visual Studio 10 (2010) and above Generators. * New "target_compile_features" command allows populating target based compile features. CMake uses this information to ensure that the compiler in use is capable of building the target, and to add any necessary compile flags such as -std=gnu++11 to support language features. More information on this is found at: - http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html * The syntax for *Variable References* and *Escape Sequences* was simplified in order to allow a much faster implementation. See policy "CMP0053". * The "if" command no longer automatically dereferences variables named in quoted or bracket arguments. See policy "CMP0054". * The target property "SOURCES" now generally supports "Generator Expressions". The generator expressions may be used in the "add_library" and "add_executable" commands. * It is now possible to write and append to the target property "SOURCES". The variable "CMAKE_DEBUG_TARGET_PROPERTIES" can be used to trace the origin of sources. * CPack gained "7Z" and "TXZ" generators supporting lzma-compressed archives. * The ExternalProject module has learned to support lzma-compressed source tarballs with ".7z", ".tar.xz", and ".txz" extensions. * The ExternalProject module ExternalProject_Add command learned a new BUILD_ALWAYS option to cause the external project build step to run every time the host project is built. * The ctest_coverage command learned to support Intel coverage files with the "codecov" tool. * The ctest_memcheck command learned to support sanitizer modes, including "AddressSanitizer", "MemorySanitizer", "ThreadSanitizer", and "UndefinedBehaviorSanitizer". Deprecated and Removed Features: * In CMake 3.0 the "target_link_libraries" command accidentally began allowing unquoted arguments to use Generator Expressions containing a semicolon separated list within them. For example: set(libs B C) target_link_libraries(A PUBLIC $) This is equivalent to writing: target_link_libraries(A PUBLIC $) and was never intended to work. It did not work in CMake 2.8.12. Such generator expressions should be in quoted arguments: set(libs B C) target_link_libraries(A PUBLIC "$") CMake 3.1 again requires the quotes for this to work correctly. CMake 3.1.0 Release Notes ************************* Changes made since CMake 3.0.0 include the following. Documentation Changes ===================== * A new "cmake-compile-features(7)" manual was added. New Features ============ Generators ---------- * A "Visual Studio 14" generator was added. Windows Phone and Windows Store ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Generators for Visual Studio 11 (2012) and above learned to generate projects for Windows Phone and Windows Store. One may set the "CMAKE_SYSTEM_NAME" variable to "WindowsPhone" or "WindowsStore" on the "cmake(1)" command-line or in a "CMAKE_TOOLCHAIN_FILE" to activate these platforms. Also set "CMAKE_SYSTEM_VERSION" to "8.0" or "8.1" to specify the version of Windows to be targeted. NVIDIA Nsight Tegra ~~~~~~~~~~~~~~~~~~~ * Generators for Visual Studio 10 (2010) and above learned to generate projects for NVIDIA Nsight Tegra Visual Studio Edition. One may set the "CMAKE_SYSTEM_NAME" variable to "Android" on the "cmake(1)" command-line or in a "CMAKE_TOOLCHAIN_FILE" to activate this platform. Syntax ------ * The "cmake-language(7)" syntax for *Variable References* and *Escape Sequences* was simplified in order to allow a much faster implementation. See policy "CMP0053". * The "if()" command no longer automatically dereferences variables named in quoted or bracket arguments. See policy "CMP0054". Commands -------- * The "add_custom_command()" command learned to interpret "cmake- generator-expressions(7)" in arguments to "DEPENDS". * The "export(PACKAGE)" command learned to check the "CMAKE_EXPORT_NO_PACKAGE_REGISTRY" variable to skip exporting the package. * The "file(STRINGS)" command gained a new "ENCODING" option to enable extraction of "UTF-8" strings. * The "find_package()" command learned to check the "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" and "CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY" variables to skip searching the package registries. * The "install()" command learned a "MESSAGE_NEVER" option to avoid output during installation. * The "string()" command learned a new "GENEX_STRIP" subcommand which removes "generator expression". * The "string()" command learned a new "UUID" subcommand to generate a univerally unique identifier. * New "target_compile_features()" command allows populating the "COMPILE_FEATURES" target property, just like any other build variable. * The "target_sources()" command was added to add to the "SOURCES" target property. Variables --------- * The Visual Studio generators for versions 8 (2005) and above learned to read the target platform name from a new "CMAKE_GENERATOR_PLATFORM" variable when it is not specified as part of the generator name. The platform name may be specified on the "cmake(1)" command line with the "-A" option, e.g. "-G "Visual Studio 12 2013" -A x64". * The "CMAKE_GENERATOR_TOOLSET" variable may now be initialized in a toolchain file specified by the "CMAKE_TOOLCHAIN_FILE" variable. This is useful when cross-compiling with the Xcode or Visual Studio generators. * The "CMAKE_INSTALL_MESSAGE" variable was introduced to optionally reduce output installation. Properties ---------- * New "CXX_STANDARD" and "CXX_EXTENSIONS" target properties may specify values which CMake uses to compute required compile options such as "-std=c++11" or "-std=gnu++11". The "CMAKE_CXX_STANDARD" and "CMAKE_CXX_EXTENSIONS" variables may be set to initialize the target properties. * New "C_STANDARD" and "C_EXTENSIONS" target properties may specify values which CMake uses to compute required compile options such as "-std=c11" or "-std=gnu11". The "CMAKE_C_STANDARD" and "CMAKE_C_EXTENSIONS" variables may be set to initialize the target properties. * New "COMPILE_FEATURES" target property may contain a list of features required to compile a target. CMake uses this information to ensure that the compiler in use is capable of building the target, and to add any necessary compile flags to support language features. * New "COMPILE_PDB_NAME" and "COMPILE_PDB_OUTPUT_DIRECTORY" target properties were introduced to specify the MSVC compiler program database file location ("cl /Fd"). This complements the existing "PDB_NAME" and "PDB_OUTPUT_DIRECTORY" target properties that specify the linker program database file location ("link /pdb"). * The "INTERFACE_LINK_LIBRARIES" target property now supports a "$" "generator expression". * A new "INTERFACE_SOURCES" target property was introduced. This is consumed by dependent targets, which compile and link the listed sources. * The "SOURCES" target property now contains "generator expression" such as "TARGET_OBJECTS" when read at configure time, if policy "CMP0051" is "NEW". * The "SOURCES" target property now generally supports "generator expression". The generator expressions may be used in the "add_library()" and "add_executable()" commands. * It is now possible to write and append to the "SOURCES" target property. The "CMAKE_DEBUG_TARGET_PROPERTIES" variable may be used to trace the origin of sources. * A "VS_DEPLOYMENT_CONTENT" source file property was added to tell the Visual Studio generators to mark content for deployment in Windows Phone and Windows Store projects. * The "VS_WINRT_COMPONENT" target property was created to tell Visual Studio generators to compile a shared library as a Windows Runtime (WinRT) component. * The "Xcode" generator learned to check source file properties "XCODE_EXPLICIT_FILE_TYPE" and "XCODE_LAST_KNOWN_FILE_TYPE" for a custom Xcode file reference type. Modules ------- * The "BundleUtilities" module learned to resolve and replace "@rpath" placeholders on OS X to correctly bundle applications using them. * The "CMakePackageConfigHelpers" module "configure_package_config_file()" command learned a new "INSTALL_PREFIX" option to generate package configuration files meant for a prefix other than "CMAKE_INSTALL_PREFIX". * The "CheckFortranSourceCompiles" module was added to provide a "CHECK_Fortran_SOURCE_COMPILES" macro. * The "ExternalData" module learned to tolerate a "DATA{}" reference to a missing source file with a warning instead of rejecting it with an error. This helps developers write new "DATA{}" references to test reference outputs that have not yet been created. * The "ExternalProject" module learned to support lzma-compressed source tarballs with ".7z", ".tar.xz", and ".txz" extensions. * The "ExternalProject" module "ExternalProject_Add" command learned a new "BUILD_ALWAYS" option to cause the external project build step to run every time the host project is built. * The "ExternalProject" module "ExternalProject_Add" command learned a new "EXCLUDE_FROM_ALL" option to cause the external project target to have the "EXCLUDE_FROM_ALL" target property set. * The "ExternalProject" module "ExternalProject_Add_Step" command learned a new "EXCLUDE_FROM_MAIN" option to cause the step to not be a direct dependency of the main external project target. * The "ExternalProject" module "ExternalProject_Add" command learned a new "DOWNLOAD_NO_PROGRESS" option to disable progress output while downloading the source tarball. * The "FeatureSummary" module "feature_summary" API learned to accept multiple values for the "WHAT" option and combine them appropriately. * The "FindCUDA" module learned to support "fatbin" and "cubin" modules. * The "FindGTest" module "gtest_add_tests" macro learned a new "AUTO" option to automatically read the "SOURCES" target property of the test executable and scan the source files for tests to be added. * The "FindGLEW" module now provides imported targets. * The "FindGLUT" module now provides imported targets. * The "FindHg" module gained a new "Hg_WC_INFO" macro to help run "hg" to extract information about a Mercurial work copy. * The "FindOpenCL" module was introduced. * The "FindOpenGL" module now provides imported targets "OpenGL::GL" and "OpenGL::GLU" when the libraries are found. * The "FindOpenMP" module learned to support Fortran. * The "FindPkgConfig" module learned to use the "PKG_CONFIG" environment variable value as the "pkg-config" executable, if set. * The "FindVTK" module dropped support for finding VTK 4.0. It is now a thin-wrapper around "find_package(VTK ... NO_MODULE)". This produces much clearer error messages when VTK is not found. * The "FindZLIB" module now provides imported targets. * The "GenerateExportHeader" module "generate_export_header" function learned to allow use with *Object Libraries*. * The "InstallRequiredSystemLibraries" module gained a new "CMAKE_INSTALL_OPENMP_LIBRARIES" option to install MSVC OpenMP runtime libraries. * The "UseSWIG" module learned to detect the module name from ".i" source files if possible to avoid the need to set the "SWIG_MODULE_NAME" source file property explicitly. * The "WriteCompilerDetectionHeader" module was added to allow creation of a portable header file for compiler optional feature detection. Generator Expressions --------------------- * New "COMPILE_FEATURES" "generator expression" allows setting build properties based on available compiler features. CTest ----- * The "ctest_coverage()" command learned to read variable "CTEST_COVERAGE_EXTRA_FLAGS" to set "CoverageExtraFlags". * The "ctest_coverage()" command learned to support Intel coverage files with the "codecov" tool. * The "ctest_memcheck()" command learned to support sanitizer modes, including "AddressSanitizer", "MemorySanitizer", "ThreadSanitizer", and "UndefinedBehaviorSanitizer". Options may be set using the new "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable. CPack ----- * "cpack(1)" gained an "IFW" generator to package using Qt Framework Installer tools. See the "CPackIFW" module. * "cpack(1)" gained "7Z" and "TXZ" generators supporting lzma- compressed archives. * The "CPackDeb" module learned a new "CPACK_DEBIAN_COMPRESSION_TYPE" variable to set the tarball compression type. * The "cpack(1)" "WiX" generator learned to support a "CPACK_WIX_ACL" installed file property to specify an Access Control List. Other ----- * The "cmake(1)" "-E" option learned a new "env" command. * The "cmake(1)" "-E tar" command learned to support lzma-compressed files. * *Object Libraries* may now have extra sources that do not compile to object files so long as they would not affect linking of a normal library (e.g. ".dat" is okay but not ".def"). * Visual Studio generators for VS 8 and later learned to support the "ASM_MASM" language. * The Visual Studio generators learned to treat ".hlsl" source files as High Level Shading Language sources (using "FXCompile" in ".vcxproj" files). A "VS_SHADER_TYPE" source file property was added to specify the Shader Type. New Diagnostics =============== * Policy "CMP0052" introduced to control directories in the "INTERFACE_INCLUDE_DIRECTORIES" of exported targets. Deprecated and Removed Features =============================== * In CMake 3.0 the "target_link_libraries()" command accidentally began allowing unquoted arguments to use "generator expressions" containing a (";" separated) list within them. For example: set(libs B C) target_link_libraries(A PUBLIC $) This is equivalent to writing: target_link_libraries(A PUBLIC $) and was never intended to work. It did not work in CMake 2.8.12. Such generator expressions should be in quoted arguments: set(libs B C) target_link_libraries(A PUBLIC "$") CMake 3.1 again requires the quotes for this to work correctly. * Callbacks established by the "variable_watch()" command will no longer receive the "ALLOWED_UNKNOWN_READ_ACCESS" access type when the undocumented "CMAKE_ALLOW_UNKNOWN_VARIABLE_READ_ACCESS" variable is set. Uninitialized variable accesses will always be reported as "UNKNOWN_READ_ACCESS". * The "CMakeDetermineVSServicePack" module now warns that it is deprecated and should not longer be used. Use the "CMAKE__COMPILER_VERSION" variable instead. Other Changes ============= * The "cmake-gui(1)" learned to capture output from child processes started by the "execute_process()" command and display it in the output window. * The "cmake-language(7)" internal implementation of generator expression and list expansion parsers have been optimized and shows non-trivial speedup on large projects. * The Makefile generators learned to use response files with GNU tools on Windows to pass library directories and names to the linker. * When generating linker command-lines, CMake now avoids repeating items corresponding to SHARED library targets. * Support for the Open Watcom compiler has been overhauled. The "CMAKE__COMPILER_ID" is now "OpenWatcom", and the "CMAKE__COMPILER_VERSION" now uses the Open Watcom external version numbering. The external version numbers are lower than the internal version number by 11. From aklitzing at gmail.com Tue Oct 28 14:18:34 2014 From: aklitzing at gmail.com (A. Klitzing) Date: Tue, 28 Oct 2014 18:18:34 +0000 Subject: [cmake-developers] Support of codesign References: <543FD64A.1040907@kitware.com> <15229978.cqkd4WDHtU@stryke> Message-ID: Hi there! As requested... I renamed the 3 APPLE variables to BUNDLE_APPLE in attached patch. Thanks Andr? Klitzing Clinton Stimpson schrieb am Mon Oct 27 2014 at 17:42:50: > Hi Andr?, > > I can help you get this patch into the git repo. But before doing that, > Brad > requested one more change. > > Can you please rename 3 of the CMake variables to > CPACK_BUNDLE_APPLE_CERT_APP > CPACK_BUNDLE_APPLE_ENTITLEMENTS > CPACK_BUNDLE_APPLE_CODESIGN_FILES > > Thanks, > Clint > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CPack-Add-support-for-code-signing-of-bundles-on-Mac.patch Type: text/x-patch Size: 7391 bytes Desc: not available URL: From clinton at elemtech.com Tue Oct 28 14:22:34 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Tue, 28 Oct 2014 12:22:34 -0600 Subject: [cmake-developers] Support of codesign In-Reply-To: References: <15229978.cqkd4WDHtU@stryke> Message-ID: <1678645.2J7lYulytt@stryke> Thanks for the patch. Its in the repository now. Clint On Tuesday, October 28, 2014 06:18:34 PM A. Klitzing wrote: > Hi there! > > As requested... I renamed the 3 APPLE variables to BUNDLE_APPLE in attached > patch. > > Thanks > Andr? Klitzing > > > Clinton Stimpson schrieb am Mon Oct 27 2014 at > > 17:42:50: > > Hi Andr?, > > > > I can help you get this patch into the git repo. But before doing that, > > Brad > > requested one more change. > > > > Can you please rename 3 of the CMake variables to > > > > CPACK_BUNDLE_APPLE_CERT_APP > > CPACK_BUNDLE_APPLE_ENTITLEMENTS > > CPACK_BUNDLE_APPLE_CODESIGN_FILES > > > > Thanks, > > Clint From daniele.domenichelli at gmail.com Tue Oct 28 15:20:17 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Tue, 28 Oct 2014 20:20:17 +0100 Subject: [cmake-developers] ExternalProject CMAKE_ARGS and CMAKE_CACHE_ARGS arguments In-Reply-To: <544FCBE8.4060600@kitware.com> References: <543FE392.7020706@gmail.com> <54451383.4070809@kitware.com> <5446672F.3070501@gmail.com> <5447CADF.8020804@kitware.com> <544F7477.1060700@gmail.com> <544FCBE8.4060600@kitware.com> Message-ID: <544FEC71.7040900@gmail.com> On 28/10/14 18:01, Brad King wrote: > Please rebase on those. You should find it much easier to add > more detail to the documentation of each option. Done, thanks. Daniele From ruslan_baratov at yahoo.com Tue Oct 28 16:28:51 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Tue, 28 Oct 2014 23:28:51 +0300 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <543BE40C.4000404@kitware.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> <543BE40C.4000404@kitware.com> Message-ID: <544FFC83.4090107@yahoo.com> On 13-Oct-14 18:39, Brad King wrote: > With all the above in mind, please brainstorm and propose a more complete > signature set. You can use the keyword/value pairing common in other > commands to avoid needing a positional argument for every value. What do you think about this: file( LOCK [DIRECTORY] # if present locked file will be /cmake.lock (instead of ) [RELEASE] # do explicit unlock [GUARD ] # if not present - set to `GUARD PROCESS` (not used if RELEASE) [RESULT_VARIABLE ] # 0 on success, error message otherwise; if not present - any error is FATAL_ERROR [TIMEOUT ] # 0 - return immediately if operation failed (try_lock), otherwise timeout (timed_lock); # if not present - lock until success (or error); # not used if RELEASE; ) ? On 13-Oct-14 18:39, Brad King wrote: > Also, please post a summary of how the implementation will work on each > platform. Boost implementation of file locking mechanism use LockFileEx/UnlockFileEx for windows and fcntl for unix-like platforms. These functions lock file only for current process. When process crashes lock removed by OS automatically. In terms of boost documentation `file(LOCK ...)` locks are exclusive and advisory. boost.interprocess: http://www.boost.org/doc/libs/1_56_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.file_lock LockFileEx: http://msdn.microsoft.com/library/windows/desktop/aa365203%28v=vs.85%29.aspx UnlockFileEx: http://msdn.microsoft.com/library/windows/desktop/aa365716%28v=vs.85%29.aspx fcntl (linux): http://linux.die.net/man/2/fcntl fcntl (mac): https://developer.apple.com/library/Mac/documentation/Darwin/Reference/ManPages/man2/fcntl.2.html I've tried (Un)LockFileEx/fcntl on windows (including mingw and cygwin), linux and mac - works fine for me with one exception: cygwin's lock is not visible by win32's lock. I.e. you can synchronize multiple cygwin processes and multiple windows "normal" processes, but you can't mix them. On 13-Oct-14 18:34, Ben Boeckel wrote: > Maybe we need something like the 'trap' shell builtin which runs code on > various triggers rather than something like file/directory locks... Note that you can't set trap for SIGKILL. So if somebody will terminate your CMake instance by `kill -9 ` probably you will have a problem. From mantis at public.kitware.com Tue Oct 28 18:00:16 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 28 Oct 2014 23:00:16 +0100 Subject: [cmake-developers] [CMake 0015226]: Allow TARGET_OBJECTS generator expression in non-target contexts Message-ID: <493cc563368a10c936aba1b7e0a76ddf@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15226 ====================================================================== Reported By: Stephen Kelly Assigned To: ====================================================================== Project: CMake Issue ID: 15226 Category: CMake Reproducibility: have not tried Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-28 23:00 CET Last Modified: 2014-10-28 23:00 CET ====================================================================== Summary: Allow TARGET_OBJECTS generator expression in non-target contexts Description: The limitation on use of TARGET_OBJECTS in add_custom_{target,command} and file(GENERATE) was added to avoid macro replacement problems from IDEs http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9705 http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5de63265 With some additional design work, the problems could be solvable and the generator expression could be allowed. See also http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/50872 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-28 23:00 Stephen Kelly New Issue ====================================================================== From mantis at public.kitware.com Wed Oct 29 04:02:29 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 29 Oct 2014 04:02:29 -0400 Subject: [cmake-developers] [CMake 0015227]: Add Search path for AUTOUIC Message-ID: <2ebfdeae84787049d32a4ae27bd69e21@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15227 ====================================================================== Reported By: Christian Ehrlicher Assigned To: ====================================================================== Project: CMake Issue ID: 15227 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-29 04:02 EDT Last Modified: 2014-10-29 04:02 EDT ====================================================================== Summary: Add Search path for AUTOUIC Description: In our project structure the ui-files are inside a subfolder of the current source directory. --> It would be nice to be able to add something like AUTOUIC_SEARCH_PATH where we can specifiy relative search paths for the ui-files: SET(AUTOUIC_SEARCH_PATH ui) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-29 04:02 Christian EhrlicherNew Issue ====================================================================== From chuck.atkins at kitware.com Wed Oct 29 08:39:56 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 29 Oct 2014 08:39:56 -0400 Subject: [cmake-developers] FindBoost.cmake cannot find some libraries when cross-compiling In-Reply-To: References: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan> <4037EE152A73A9448DAD73C415D4D8C0873819@MBX79.aswsp.lan> <5448B7D1.1030604@parrot.com> Message-ID: Merged: c752f8f165e9b8db7bc645cc55301277cd7773be Merge topic 'find-boost-no-reroot' - Chuck On Sun, Oct 26, 2014 at 12:18 AM, Chuck Atkins wrote: > Guillaume, > > Nice patch! Good detail in the commit message. I make a few minor tweaks > for typos and tense, but other than that, it's good. Pushed to stage as > 'find-boost-no-reroot' and merged to next for testing. We'll keep an eye > on the dashboards and fix as needed but I don't anticipate any issues. > > Thanks for the patch! > - Chuck > > On Thu, Oct 23, 2014 at 4:09 AM, Guillaume Papin < > guillaume.papin at parrot.com> wrote: > >> Please find the patch attached to this email. >> Let me know if anything is wrong. >> >> Best, >> Guillaume >> >> >> On 10/16/2014 05:09 PM, Chuck Atkins wrote: >> >> Guillaume, >> >> Please see CONTRIBUTING.rst in the top level of the CMake source tree. >> If you can please create and post a patch against cmake master then I'll >> work on getting it merged into cmake next. Thanks for the bug fix! >> >> - Chuck >> >> On Thu, Oct 16, 2014 at 10:32 AM, Chuck Atkins >> wrote: >> >>> This looks like a reasonable way to accomplish this right now. The >>> underlying prioblem is that ther's no way to specify which path types get >>> re-rooted and which don't. Ideally you'd want to be able to specify in the >>> toolchain for something like this that all paths operate in "ONLY" mode >>> except HINTS, which you would want to place in NEVER mode. I'm currently >>> working on just such a feature but in the meantime, forcing it like this in >>> the FindBoost module looks reasonable. >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume.papin at parrot.com Wed Oct 29 09:09:51 2014 From: guillaume.papin at parrot.com (Guillaume Papin) Date: Wed, 29 Oct 2014 13:09:51 +0000 Subject: [cmake-developers] FindBoost.cmake cannot find some libraries when cross-compiling In-Reply-To: References: <4037EE152A73A9448DAD73C415D4D8C08737A2@MBX79.aswsp.lan> <4037EE152A73A9448DAD73C415D4D8C0873819@MBX79.aswsp.lan> <5448B7D1.1030604@parrot.com>, Message-ID: <4037EE152A73A9448DAD73C415D4D8C0875366@MBX79.aswsp.lan> Great, Happy to contribute to CMake. - Guillaume ________________________________ From: Chuck Atkins [chuck.atkins at kitware.com] Sent: 26 October 2014 05:18 To: Guillaume Papin Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] FindBoost.cmake cannot find some libraries when cross-compiling Guillaume, Nice patch! Good detail in the commit message. I make a few minor tweaks for typos and tense, but other than that, it's good. Pushed to stage as 'find-boost-no-reroot' and merged to next for testing. We'll keep an eye on the dashboards and fix as needed but I don't anticipate any issues. Thanks for the patch! - Chuck On Thu, Oct 23, 2014 at 4:09 AM, Guillaume Papin > wrote: Please find the patch attached to this email. Let me know if anything is wrong. Best, Guillaume On 10/16/2014 05:09 PM, Chuck Atkins wrote: Guillaume, Please see CONTRIBUTING.rst in the top level of the CMake source tree. If you can please create and post a patch against cmake master then I'll work on getting it merged into cmake next. Thanks for the bug fix! - Chuck On Thu, Oct 16, 2014 at 10:32 AM, Chuck Atkins > wrote: This looks like a reasonable way to accomplish this right now. The underlying prioblem is that ther's no way to specify which path types get re-rooted and which don't. Ideally you'd want to be able to specify in the toolchain for something like this that all paths operate in "ONLY" mode except HINTS, which you would want to place in NEVER mode. I'm currently working on just such a feature but in the meantime, forcing it like this in the FindBoost module looks reasonable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascal.bach at siemens.com Wed Oct 29 09:27:11 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Wed, 29 Oct 2014 14:27:11 +0100 Subject: [cmake-developers] [PATCHv3] Tests: Run Tutorial steps 1-4 as tests for Windows CE In-Reply-To: <544FA62F.2050608@kitware.com> References: <544FA62F.2050608@kitware.com> Message-ID: <1414589231-8307-1-git-send-email-pascal.bach@siemens.com> --- Tests/CMakeLists.txt | 53 +++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 52 insertions(+), 1 deletion(-) diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt index e1e90a1..60b50f8 100644 --- a/Tests/CMakeLists.txt +++ b/Tests/CMakeLists.txt @@ -1781,6 +1781,27 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release endif() if(WIN32) + # Macro to search for available Windows CE SDKs in the windows Registry + macro(select_wince_sdk selected_reg selected_sdk) + if(CMAKE_HOST_WIN32) + execute_process(COMMAND reg QUERY "HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows CE Tools\\SDKs" + OUTPUT_VARIABLE sdk_reg + ERROR_VARIABLE my_err) + string(REGEX REPLACE "HKEY_LOCAL_MACHINE\\\\SOFTWARE\\\\Wow6432Node\\\\Microsoft\\\\Windows CE Tools\\\\SDKs\\\\" ";" sdk_list "${sdk_reg}") + list(LENGTH sdk_list sdk_list_len) + if (${sdk_list_len} GREATER 1) + list(GET sdk_list 1 _sdk) # The first entry is always empty due to the regex replace above + string(STRIP ${_sdk} _sdk) # Make sure there is no newline in the SDK name + endif() + # Build a key to be used by get_filename_component that is pointing to the SDK directory + set(_reg "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows CE Tools\\SDKs\\${_sdk}]") + + # Set return values + set(${selected_reg} ${_reg}) + set(${selected_sdk} ${_sdk}) + endif(CMAKE_HOST_WIN32) + endmacro(select_wince_sdk) + set(reg_vs10 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\10.0;InstallDir]") set(reg_vs11 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\11.0;InstallDir]") set(reg_vs12 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\12.0;InstallDir]") @@ -1788,8 +1809,9 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release set(reg_ws81 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v8.1;InstallationFolder]") set(reg_wp80 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\WindowsPhone\\v8.0;InstallationFolder]") set(reg_wp81 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\WindowsPhone\\v8.1;InstallationFolder]") + select_wince_sdk(reg_wince wince_sdk) set(reg_tegra "[HKEY_LOCAL_MACHINE\\SOFTWARE\\NVIDIA Corporation\\Nsight Tegra;sdkRoot]") - foreach(reg vs10 vs11 vs12 ws80 ws81 wp80 wp81 tegra) + foreach(reg vs10 vs11 vs12 ws80 ws81 wp80 wp81 wince tegra) get_filename_component(r "${reg_${reg}}" ABSOLUTE) if(IS_DIRECTORY "${r}") set(${reg} 1) @@ -1835,6 +1857,35 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release endif() endif() + if(WIN32 AND wince) + macro(add_test_VSWinCE name generator systemName systemVersion generatorPlatform) + # TODO: Fix the tutorial to make it work in cross compile + # currently the MakeTable is build for target and can not be used on the host + # This happens in part 5 so we build only part 1-4 of the tutorial + foreach(STP RANGE 1 4) + add_test(NAME "TutorialStep${STP}.${name}" COMMAND ${CMAKE_CTEST_COMMAND} + --build-and-test + "${CMake_SOURCE_DIR}/Tests/Tutorial/Step${STP}" + "${CMake_BINARY_DIR}/Tests/Tutorial/Step${STP}_${name}" + --build-generator "${generator}" + --build-project Tutorial + --build-config $ + --build-options -DCMAKE_SYSTEM_NAME=${systemName} + -DCMAKE_SYSTEM_VERSION=${systemVersion} + -DCMAKE_GENERATOR_PLATFORM=${generatorPlatform}) + list(APPEND TEST_BUILD_DIRS "${CMake_BINARY_DIR}/Tests/Tutorial/Step${STP}_${name}") + endforeach() + endmacro() + + if(vs11) + add_test_VSWinCE(vs11-ce80-ARM "Visual Studio 11 2012" WindowsCE 8.0 ${wince_sdk}) + endif() + + if(vs12) + add_test_VSWinCE(vs12-ce80-ARM "Visual Studio 12 2013" WindowsCE 8.0 ${wince_sdk}) + endif() + endif() + if(tegra AND NOT "${CMake_SOURCE_DIR};${CMake_BINARY_DIR}" MATCHES " ") macro(add_test_VSNsightTegra name generator) add_test(NAME VSNsightTegra.${name} COMMAND ${CMAKE_CTEST_COMMAND} -- 1.7.10.4 From brad.king at kitware.com Wed Oct 29 09:38:26 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 29 Oct 2014 09:38:26 -0400 Subject: [cmake-developers] ExternalProject CMAKE_ARGS and CMAKE_CACHE_ARGS arguments In-Reply-To: <544FEC71.7040900@gmail.com> References: <543FE392.7020706@gmail.com> <54451383.4070809@kitware.com> <5446672F.3070501@gmail.com> <5447CADF.8020804@kitware.com> <544F7477.1060700@gmail.com> <544FCBE8.4060600@kitware.com> <544FEC71.7040900@gmail.com> Message-ID: <5450EDD2.8060700@kitware.com> On 10/28/2014 03:20 PM, Daniele E. Domenichelli wrote: > Done, thanks. Good. In the updated docs for CMAKE_ARGS, CMAKE_CACHE_ARGS, and CMAKE_CACHE_DEFAULT_ARGS, the intro line now needs a period. The new RunCMake.ExternalProject test looks good. However, it does not verify that the external project actually builds with the new options. Please extend one of the main ExternalProject tests to cover this too. Thanks, -Brad From brad.king at kitware.com Wed Oct 29 09:42:21 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 29 Oct 2014 09:42:21 -0400 Subject: [cmake-developers] [PATCHv3] Tests: Run Tutorial steps 1-4 as tests for Windows CE In-Reply-To: <1414589231-8307-1-git-send-email-pascal.bach@siemens.com> References: <544FA62F.2050608@kitware.com> <1414589231-8307-1-git-send-email-pascal.bach@siemens.com> Message-ID: <5450EEBD.9030405@kitware.com> On 10/29/2014 09:27 AM, Pascal Bach wrote: > --- > Tests/CMakeLists.txt | 53 +++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 52 insertions(+), 1 deletion(-) Applied, thanks: Tests: Run Tutorial steps 1-4 as tests for Windows CE http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5bd29b88 -Brad From brad.king at kitware.com Wed Oct 29 09:48:47 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 29 Oct 2014 09:48:47 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <544FFC83.4090107@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> <543BE40C.4000404@kitware.com> <544FFC83.4090107@yahoo.com> Message-ID: <5450F03F.2040500@kitware.com> On 10/28/2014 04:28 PM, Ruslan Baratov wrote: > What do you think about this: Thanks for drafting the signature. > file( > LOCK > [DIRECTORY] # if present locked file will be /cmake.lock > (instead of ) > [RELEASE] # do explicit unlock > [GUARD ] # if not present - set to `GUARD > PROCESS` (not used if RELEASE) > [RESULT_VARIABLE ] # 0 on success, error message > otherwise; if not present - any error is FATAL_ERROR > [TIMEOUT ] > # 0 - return immediately if operation failed (try_lock), > otherwise timeout (timed_lock); > # if not present - lock until success (or error); > # not used if RELEASE; > ) That looks good. The TIMEOUT unit can be 'seconds' but it should accept a floating point value to get shorter times if possible. > Boost implementation of file locking mechanism use > LockFileEx/UnlockFileEx for windows and fcntl for unix-like platforms. > These functions lock file only for current process. When process crashes > lock removed by OS automatically. Great! > I've tried (Un)LockFileEx/fcntl on windows (including mingw and cygwin), > linux and mac - works fine for me with one exception: cygwin's lock is > not visible by win32's lock. I.e. you can synchronize multiple cygwin > processes and multiple windows "normal" processes, but you can't mix them. Thanks for testing. The windows/cygwin mixing limitation is acceptable IMO. Thanks, -Brad From ben.boeckel at kitware.com Wed Oct 29 11:50:32 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 29 Oct 2014 11:50:32 -0400 Subject: [cmake-developers] cmake-gui icons In-Reply-To: <544E87ED.4080208@cora.nwra.com> References: <544E87ED.4080208@cora.nwra.com> Message-ID: <20141029155032.GA9654@megas.kitwarein.com> On Mon, Oct 27, 2014 at 11:59:09 -0600, Orion Poplawski wrote: > Fedora is pushing to have higher resolution icons for the applications. There > already is CMakeSetup128.png, but these would need to get installed into the > proper /usr/share/icons/ hierarchy and named appropriately for the correct > size to be automatically found and used. It would be good to have cmake-gui be > conformant to the current desktop standards. The 128x128 is now installed with the branch currently on stage (and next): unix-icon-install This also stops installing the files on Apple where, at least AFAIK, the .desktop and other freedesktop.org files are never actually used. If these files are important on Apple, please chime in (MacPorts and/or homebrew? KDE or GNOME on OS X?). --Ben From jmerkow at gmail.com Wed Oct 29 16:27:09 2014 From: jmerkow at gmail.com (Jameson Merkow) Date: Wed, 29 Oct 2014 13:27:09 -0700 Subject: [cmake-developers] Help enabling libssh2 in cmake Message-ID: Hello, I am working on adding libssh2 support into cmake (specifically the curl code). Most of the ground work was previously done so most of what I had to use was add cmake support. I'm having some issues still. So, I've added the option for libssh2, its find_package call, and defined the options in Utilities/cmcurl/config.h.in for libssh2. When try a simple test (cmake -P) file(WRITE upload.txt "testing upload") file(UPLOAD upload.txt "sftp://username:pw at url:path/to/home/" STATUS status SHOW_PROGRESS) message(STATUS "STATUS ${status}") I get: -- STATUS 6;"couldn't resolve host name" or (If I drop the path): -- STATUS 2;"failed init" I cannot be sure if this is a parsing problem or some other problem. Using --debug-output doesn't give me anything additional and I don't know where this error is being thrown. Is there an easy way to get more info than this? I've tried adding some printfs to print the hostname, but they don't seem to be displayed (or maybe I haven't found the correct location of where its thrown). The only non cmake change I made was a function name change for libssh2_free to libssh2_free2 in ssh.c. The current code defines this function for the LIBSSH2_FREE_FUNC callback but this function is already defined in libssh2.h (I am using version 1.4.3). I renamed this function in the cmake code to libssh2_free2 so the symbols would not clash. Anyway, I attached the git patch so people can take a look. There may be a few debug messages in there which would be removed before submission. -Jameson -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: use_libssh2.patch Type: text/x-patch Size: 5381 bytes Desc: not available URL: From mantis at public.kitware.com Wed Oct 29 17:32:53 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 29 Oct 2014 17:32:53 -0400 Subject: [cmake-developers] [CMake 0015228]: Compiler identification fails with -DCMAKE_SYSTEM_NAME=WindowsStore Message-ID: <4ea176155bc428b93a21fbcd5e1918b8@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15228 ====================================================================== Reported By: Remi Assigned To: ====================================================================== Project: CMake Issue ID: 15228 Category: CMake Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-29 17:32 EDT Last Modified: 2014-10-29 17:32 EDT ====================================================================== Summary: Compiler identification fails with -DCMAKE_SYSTEM_NAME=WindowsStore Description: cmake version 3.1.0-rc1 I tried to generate a project with the command line below: cmake -G "Visual Studio 12 2013" -DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION=8.0 and it fails with: -- The C compiler identification is unknown -- The CXX compiler identification is unknown CMake Error at CMakeLists.txt:3 (project): No CMAKE_C_COMPILER could be found. CMake Error at CMakeLists.txt:3 (project): No CMAKE_CXX_COMPILER could be found. -- Configuring incomplete, errors occurred! See also "[censored]/CMakeFiles/CMakeOutput.log". See also "[censored]/CMakeFiles/CMakeError.log". I checked the files to understand the error. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.Cpp.Platform.targets(64,5): error MSB8020: The build tools for Visual Studio 2012 (Platform Toolset = 'v110') cannot be found. To build using the v110 build tools, please install Visual Studio 2012 build tools. Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Upgrade Solution...". I believe the error is that 'v110' in the project file should be 'v120'. Steps to Reproduce: cmake -G "Visual Studio 12 2013" -DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION=8.0 Installed on my machine: VS Express 2013 for Desktop VS Express 2013 for Windows ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-29 17:32 Remi New Issue ====================================================================== From daniele.domenichelli at gmail.com Thu Oct 30 10:21:34 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Thu, 30 Oct 2014 15:21:34 +0100 Subject: [cmake-developers] ExternalProject CMAKE_ARGS and CMAKE_CACHE_ARGS arguments In-Reply-To: <5450EDD2.8060700@kitware.com> References: <543FE392.7020706@gmail.com> <54451383.4070809@kitware.com> <5446672F.3070501@gmail.com> <5447CADF.8020804@kitware.com> <544F7477.1060700@gmail.com> <544FCBE8.4060600@kitware.com> <544FEC71.7040900@gmail.com> <5450EDD2.8060700@kitware.com> Message-ID: <5452496E.1060604@gmail.com> Hello Brad, On 29/10/14 14:38, Brad King wrote: > In the updated docs for CMAKE_ARGS, CMAKE_CACHE_ARGS, and > CMAKE_CACHE_DEFAULT_ARGS, the intro line now needs a period. > > The new RunCMake.ExternalProject test looks good. However, it > does not verify that the external project actually builds with > the new options. Please extend one of the main ExternalProject > tests to cover this too. I updated the topic and modified one of the tests in ExternalProjectLocal to use the new CMAKE_CACHE_DEFAULT_ARGS argument. Unfortunately this triggered a hidden bug in the external projects, so I fixed it with an extra commit, see: http://www.cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=2c3b9a91 Cheers, Daniele From brad.king at kitware.com Thu Oct 30 10:30:31 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Oct 2014 10:30:31 -0400 Subject: [cmake-developers] Help enabling libssh2 in cmake In-Reply-To: References: Message-ID: <54524B87.1010309@kitware.com> On 10/29/2014 04:27 PM, Jameson Merkow wrote: > I am working on adding libssh2 support into cmake Great! > change for libssh2_free to libssh2_free2 in ssh.c Try building against a system-installed curl by enabling CMAKE_USE_SYSTEM_CURL. That should be much more recent than the version that comes in CMake and may have fixed some problems. I have been working slowly toward updating the version of curl that comes in our source tree but it is not ready yet. -Brad From kgt at lanl.gov Thu Oct 30 10:41:31 2014 From: kgt at lanl.gov (Thompson, KT) Date: Thu, 30 Oct 2014 14:41:31 +0000 Subject: [cmake-developers] Proposed patch for FindMPI.cmake (Intel MPI) Message-ID: <0458DF31F610EF42BFC78C497E806C7B3B520473@ECS-EXG-P-MB03.win.lanl.gov> Please find below a proposed patch that addresses this bug: http://public.kitware.com/Bug/view.php?id=15182 (FindMPI.cmake fails to properly detect Intel MPI 5.0.1). Because the return code is unreliable for the Intel MPI compile wrappers (e.g.: 'mpiicpc -showme:compile'), the output text must be interrogated for possible issues. My choice of "undefined reference" may not be the best choice, but it works for all of my test cases. I have tested this patch with OpenMPI, MPICH2 and Intel MPI on RHEL 6.4 and RHEL 6.4. I have also tested it on Win7 with VS2013 using Microsoft HPC Pack 2008 R2 MPI. Would anyone like to provide feedback or test this modification? What do I need to do to get this into release code? -kt Kelly Thompson ====================================================================================== --- a/Modules/FindMPI.cmake +++ b/Modules/FindMPI.cmake @@ -226,6 +226,13 @@ function (interrogate_mpi_compiler lang try_libs) ERROR_VARIABLE MPI_COMPILE_CMDLINE ERROR_STRIP_TRAILING_WHITESPACE RESULT_VARIABLE MPI_COMPILER_RETURN) + # Intel MPI will return a zero return code even when the + # argument to the MPI compiler wrapper is unknown. Attempt to + # catch this case. + if( "${MPI_COMPILE_CMDLINE}" MATCHES "undefined reference" ) + set( MPI_COMPILER_RETURN 255 ) + endif() + if (MPI_COMPILER_RETURN EQUAL 0) # If we appear to have -showme:compile, then we should # also have -showme:link. Try it. @@ -264,7 +271,15 @@ function (interrogate_mpi_compiler lang try_libs) RESULT_VARIABLE MPI_COMPILER_RETURN) endif() + # Intel MPI will return a zero return code even when the + # argument to the MPI compiler wrapper is unknown. Attempt to + # catch this case. + if( "${MPI_COMPILE_CMDLINE}" MATCHES "undefined reference" ) + set( MPI_COMPILER_RETURN 255 ) + endif() + # MVAPICH uses -compile-info and -link-info. Try them. + # Intel and Cray MPICH2 flavors will likely follow this path. if (NOT MPI_COMPILER_RETURN EQUAL 0) execute_process( COMMAND ${MPI_${lang}_COMPILER} -compile-info @@ -378,7 +393,6 @@ function (interrogate_mpi_compiler lang try_libs) # Extract the set of libraries to link against from the link command # line string(REGEX MATCHALL "(^| )-l([^\" ]+|\"[^\"]+\")" MPI_LIBNAMES "${MPI_LINK_CMDLINE}") - # add the compiler implicit directories because some compilers # such as the intel compiler have libraries that show up # in the showme list that can only be found in the implicit @@ -588,6 +602,7 @@ foreach (lang C CXX Fortran) HINTS ${_MPI_BASE_DIR}/bin PATHS ${_MPI_PREFIX_PATH} ) + interrogate_mpi_compiler(${lang} ${try_libs}) mark_as_advanced(MPI_${lang}_COMPILER) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Oct 30 11:45:40 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Oct 2014 11:45:40 -0400 Subject: [cmake-developers] ExternalProject CMAKE_ARGS and CMAKE_CACHE_ARGS arguments In-Reply-To: <5452496E.1060604@gmail.com> References: <543FE392.7020706@gmail.com> <54451383.4070809@kitware.com> <5446672F.3070501@gmail.com> <5447CADF.8020804@kitware.com> <544F7477.1060700@gmail.com> <544FCBE8.4060600@kitware.com> <544FEC71.7040900@gmail.com> <5450EDD2.8060700@kitware.com> <5452496E.1060604@gmail.com> Message-ID: <54525D24.7070406@kitware.com> On 10/30/2014 10:21 AM, Daniele E. Domenichelli wrote: > I updated the topic and modified one of the tests in > ExternalProjectLocal to use the new CMAKE_CACHE_DEFAULT_ARGS argument. Thanks. > Unfortunately this triggered a hidden bug in the external projects, so I > fixed it with an extra commit, see: > > http://www.cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=2c3b9a91 Instead of allowing a possible fault and then needing 'isnan', please fix the examples to check for a value >= 0 before calling sqrt. Then please merge the topic to 'next' for testing when ready. Thanks, -Brad From brad.king at kitware.com Thu Oct 30 12:28:51 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Oct 2014 12:28:51 -0400 Subject: [cmake-developers] Proposed patch for FindMPI.cmake (Intel MPI) In-Reply-To: <0458DF31F610EF42BFC78C497E806C7B3B520473@ECS-EXG-P-MB03.win.lanl.gov> References: <0458DF31F610EF42BFC78C497E806C7B3B520473@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <54526743.3000705@kitware.com> On 10/30/2014 10:41 AM, Thompson, KT wrote: > Please find below a proposed patch that addresses this bug: > http://public.kitware.com/Bug/view.php?id=15182 > (FindMPI.cmake fails to properly detect Intel MPI 5.0.1). Thanks. I've linked this thread from the issue. There are many invocations of the mpi compiler in the module, but the patch only deals with two of them. We may need to instead refactor the module to put calls to execute_process inside a helper macro. Then the macro could add this extra check for the workaround. -Brad From hobbes1069 at gmail.com Thu Oct 30 13:55:03 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Thu, 30 Oct 2014 12:55:03 -0500 Subject: [cmake-developers] Expected difference in execute_process between MSYS / UNIX Message-ID: I'm working on a big update to the FindFLTK module and I'm testing it on all platforms I have access to. One problem that took me quite a while to figure out was that on *nix systems, execute_process works with shell scripts but on my MSYS2 install it does not, I have to prefix the command with "sh" to make sure it executes in a shell. Is this known/expected? Should I prefix shell scripts with "sh" in all cases and not count on it to work? Or should I test for MSYS and only prefix the command with "sh" there? Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Oct 30 15:25:27 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Oct 2014 15:25:27 -0400 Subject: [cmake-developers] Expected difference in execute_process between MSYS / UNIX In-Reply-To: References: Message-ID: <545290A7.2040503@kitware.com> On 10/30/2014 01:55 PM, Richard Shaw wrote: > I'm working on a big update to the FindFLTK module and I'm > testing it on all platforms I have access to. > > One problem that took me quite a while to figure out was that > on *nix systems, execute_process works with shell scripts but > on my MSYS2 install it does not, I have to prefix the command > with "sh" to make sure it executes in a shell. > > Is this known/expected? Yes. It is not execute_process, but the underlying operating system process launching rules. A shell script starts in a "shebang" (#!) line that the OS knows how to interpret to decide what program to run to launch the script. Windows does not know how to do this so we have to specify a shell explicitly. MSYS is Windows, not POSIX/Cygwin. > Should I prefix shell scripts with "sh" in all cases and not > count on it to work? Or should I test for MSYS and only prefix > the command with "sh" there? Using 'sh' should be safe. -Brad From brad.king at kitware.com Thu Oct 30 15:29:31 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Oct 2014 15:29:31 -0400 Subject: [cmake-developers] Expected difference in execute_process between MSYS / UNIX In-Reply-To: <545290A7.2040503@kitware.com> References: <545290A7.2040503@kitware.com> Message-ID: <5452919B.9080709@kitware.com> On 10/30/2014 03:25 PM, Brad King wrote: > MSYS is Windows, not POSIX/Cygwin. More specifically, CMake is a normal Windows process even when generating for MSYS Makefiles. -Brad From ewmailing at gmail.com Thu Oct 30 19:19:11 2014 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 30 Oct 2014 16:19:11 -0700 Subject: [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing! In-Reply-To: References: Message-ID: Just curious, are the new WinRT changes the same exact changes from CMakeMS? And if the CMakeMS people are listening, I just want to say you guys did a terrific job! Thanks, Eric From hobbes1069 at gmail.com Fri Oct 31 09:06:45 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Fri, 31 Oct 2014 08:06:45 -0500 Subject: [cmake-developers] Expected difference in execute_process between MSYS / UNIX In-Reply-To: <545290A7.2040503@kitware.com> References: <545290A7.2040503@kitware.com> Message-ID: On Thu, Oct 30, 2014 at 2:25 PM, Brad King wrote: > On 10/30/2014 01:55 PM, Richard Shaw wrote: > > I'm working on a big update to the FindFLTK module and I'm > > testing it on all platforms I have access to. > > > > One problem that took me quite a while to figure out was that > > on *nix systems, execute_process works with shell scripts but > > on my MSYS2 install it does not, I have to prefix the command > > with "sh" to make sure it executes in a shell. > > > > Is this known/expected? > > Yes. It is not execute_process, but the underlying operating > system process launching rules. A shell script starts in a > "shebang" (#!) line that the OS knows how to interpret to > decide what program to run to launch the script. Windows does > not know how to do this so we have to specify a shell explicitly. > MSYS is Windows, not POSIX/Cygwin. > I figured as much but wanted to verify. > Should I prefix shell scripts with "sh" in all cases and not > > count on it to work? Or should I test for MSYS and only prefix > > the command with "sh" there? > > Using 'sh' should be safe. Good to know. Thanks! Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Fri Oct 31 09:07:02 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 31 Oct 2014 16:07:02 +0300 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <5450F03F.2040500@kitware.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> <543BE40C.4000404@kitware.com> <544FFC83.4090107@yahoo.com> <5450F03F.2040500@kitware.com> Message-ID: <54538976.5050007@yahoo.com> Does anybody ready to implement it or you want me to send the patches? Ruslo On 29-Oct-14 16:48, Brad King wrote: > On 10/28/2014 04:28 PM, Ruslan Baratov wrote: >> What do you think about this: > Thanks for drafting the signature. > >> file( >> LOCK >> [DIRECTORY] # if present locked file will be /cmake.lock >> (instead of ) >> [RELEASE] # do explicit unlock >> [GUARD ] # if not present - set to `GUARD >> PROCESS` (not used if RELEASE) >> [RESULT_VARIABLE ] # 0 on success, error message >> otherwise; if not present - any error is FATAL_ERROR >> [TIMEOUT ] >> # 0 - return immediately if operation failed (try_lock), >> otherwise timeout (timed_lock); >> # if not present - lock until success (or error); >> # not used if RELEASE; >> ) > That looks good. The TIMEOUT unit can be 'seconds' but it should > accept a floating point value to get shorter times if possible. > >> Boost implementation of file locking mechanism use >> LockFileEx/UnlockFileEx for windows and fcntl for unix-like platforms. >> These functions lock file only for current process. When process crashes >> lock removed by OS automatically. > Great! > >> I've tried (Un)LockFileEx/fcntl on windows (including mingw and cygwin), >> linux and mac - works fine for me with one exception: cygwin's lock is >> not visible by win32's lock. I.e. you can synchronize multiple cygwin >> processes and multiple windows "normal" processes, but you can't mix them. > Thanks for testing. The windows/cygwin mixing limitation is acceptable > IMO. > > Thanks, > -Brad > From brad.king at kitware.com Fri Oct 31 09:39:59 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 31 Oct 2014 09:39:59 -0400 Subject: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)' In-Reply-To: <54538976.5050007@yahoo.com> References: <5431B11C.3010209@yahoo.com> <54329100.8020502@kitware.com> <54338CF1.3070304@yahoo.com> <5433DBC1.5080800@kitware.com> <5435257B.80201@yahoo.com> <543531CC.7090103@kitware.com> <5437C6CA.3030201@yahoo.com> <543BE40C.4000404@kitware.com> <544FFC83.4090107@yahoo.com> <5450F03F.2040500@kitware.com> <54538976.5050007@yahoo.com> Message-ID: <5453912F.6000305@kitware.com> On 10/31/2014 09:07 AM, Ruslan Baratov wrote: > Does anybody ready to implement it or you want me to send the patches? Please work on the patches. You can use "git format-patch" to format them and post here either inline or as attachments. Thanks, -Brad From brad.king at kitware.com Fri Oct 31 11:25:59 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 31 Oct 2014 11:25:59 -0400 Subject: [cmake-developers] [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing! In-Reply-To: References: Message-ID: <5453AA07.1000104@kitware.com> On 10/30/2014 07:19 PM, Eric Wing wrote: > Just curious, are the new WinRT changes the same exact changes from CMakeMS? Yes. After prototyping the changes in CMakeMS they worked with us to contribute the functionality upstream. -Brad From mantis at public.kitware.com Fri Oct 31 12:06:25 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 31 Oct 2014 12:06:25 -0400 Subject: [cmake-developers] [CMake 0015230]: Behavior of relative paths of target properties Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15230 ====================================================================== Reported By: Lekensteyn Assigned To: ====================================================================== Project: CMake Issue ID: 15230 Category: Documentation Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-31 12:06 EDT Last Modified: 2014-10-31 12:06 EDT ====================================================================== Summary: Behavior of relative paths of target properties Description: I was wondering whether relative paths can be used in the LIBRARY_OUTPUT_DIRECTORY property, but this is not documented. @ngladitz confirmed on IRC that paths are resolved against the binary directory, referring to the code[1]. Affected documentation: http://www.cmake.org/cmake/help/v3.0/command/add_library.html http://www.cmake.org/cmake/help/v3.0/prop_tgt/LIBRARY_OUTPUT_DIRECTORY.html ... [1]: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;h=ee62f060607c8fa95da2118784e089bcd70a23fe;hb=HEAD#l4554 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-31 12:06 Lekensteyn New Issue ====================================================================== From Gilles.Khouzam at microsoft.com Fri Oct 31 11:53:59 2014 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Fri, 31 Oct 2014 15:53:59 +0000 Subject: [cmake-developers] [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing! In-Reply-To: <5453AA07.1000104@kitware.com> References: , <5453AA07.1000104@kitware.com> Message-ID: We actually have a couple if extra changes that are not fully ready to be pushed upstream yet. ~Gilles Sent from my Windows Phone ________________________________ From: Brad King Sent: ?10/?31/?2014 8:26 To: Eric Wing Cc: Robert Maynard; CMake Developers; CMake MailingList; Gilles Khouzam Subject: Re: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing! On 10/30/2014 07:19 PM, Eric Wing wrote: > Just curious, are the new WinRT changes the same exact changes from CMakeMS? Yes. After prototyping the changes in CMakeMS they worked with us to contribute the functionality upstream. -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Fri Oct 31 12:31:05 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 31 Oct 2014 12:31:05 -0400 Subject: [cmake-developers] [CMake 0015231]: find_package: should be a simple way to alter the order of the config/module lookups Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15231 ====================================================================== Reported By: Charles Karney Assigned To: ====================================================================== Project: CMake Issue ID: 15231 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-10-31 12:31 EDT Last Modified: 2014-10-31 12:31 EDT ====================================================================== Summary: find_package: should be a simple way to alter the order of the config/module lookups Description: As we are integrating cmake more and more into our environment, it is clear how much superior the config-mode for find_package is compared to the module-mode. As a result, our top-level CMakeLists.txt contains several occurrences of the following pattern find_package (PROJ4 CONFIG QUIET) if (NOT PROJ4_FOUND) find_package (PROJ4 MODULE REQUIRED) endif () Request 1: Add MODULE_FIRST CONFIG_FIRST options to find_package, meaning do the module lookup first (the default but see next) or the config lookup first. (These options complement the MODULE and CONFIG options.) So the find_package invocation above becomes find_package (PROJ4 CONFIG_FIRST REQUIRED) Request 2: Add a global variable, e.g., CMAKE_FIND_PACKAGE_PREFER_CONFIG (default OFF) to specify the default lookup order. Thus if I've worked to get all my dependent packages with config-mode support, I can invoke cmake with cmake -DCMAKE_FIND_PACKAGE_PREFER_CONFIG=ON .. without having to edit the CMakeLists.txt file. Finally a comment: the advice (not sure where from) that our current pattern can be shortened to find_package (PROJ4 NO_MODULE QUIET) find_package (PROJ4 MODULE) seems not to hold in all cases. If you think this should work, let me know and I will look for a counter-example. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-10-31 12:31 Charles Karney New Issue ====================================================================== From jmerkow at gmail.com Fri Oct 31 13:25:01 2014 From: jmerkow at gmail.com (Jameson Merkow) Date: Fri, 31 Oct 2014 10:25:01 -0700 Subject: [cmake-developers] Help enabling libssh2 in cmake In-Reply-To: <54524B87.1010309@kitware.com> References: <54524B87.1010309@kitware.com> Message-ID: Thanks Brad! Its working with my system curl! Here is the curl version I am using. curl 7.38.1-DEV (Linux) libcurl/7.38.1-DEV OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 libssh2/1.4.3 Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Features: IDN IPv6 NTLM SSL libz What are the next steps? Shall I wait till you complete re-adding curl into the cmake build to submit? I could prevent users from using CMAKE_USE_LIBSSH2=1 and CMAKE_USE_SYSTEM_CURL=0. Or I could submit it as is (after I clean out the debug messages). I had been talking to Bill Hoffman (on the users mailing list) about adding libssh2 support for upcoming binaries, so I guess it depends on your build settings for the binaries too... -Jameson On Thu, Oct 30, 2014 at 7:30 AM, Brad King wrote: > On 10/29/2014 04:27 PM, Jameson Merkow wrote: > > I am working on adding libssh2 support into cmake > > Great! > > > change for libssh2_free to libssh2_free2 in ssh.c > > Try building against a system-installed curl by enabling > CMAKE_USE_SYSTEM_CURL. That should be much more recent > than the version that comes in CMake and may have fixed > some problems. > > I have been working slowly toward updating the version > of curl that comes in our source tree but it is not ready > yet. > > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Oct 31 13:33:29 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 31 Oct 2014 13:33:29 -0400 Subject: [cmake-developers] Help enabling libssh2 in cmake In-Reply-To: References: <54524B87.1010309@kitware.com> Message-ID: <5453C7E9.1050002@kitware.com> On 10/31/2014 01:25 PM, Jameson Merkow wrote: > Thanks Brad! Its working with my system curl! Great! > Shall I wait till you complete re-adding curl into the cmake build to submit? If you don't mind, yes. I'd prefer not to make further modifications to the current version of curl in CMake because they will just be more conflicts for updating it. If it doesn't happen in the next few weeks please ping again. Thanks, -Brad From gjasny at googlemail.com Fri Oct 31 16:00:11 2014 From: gjasny at googlemail.com (Gregor Jasny) Date: Fri, 31 Oct 2014 21:00:11 +0100 Subject: [cmake-developers] Please review patch for 'continue' keyword Message-ID: <5453EA4B.5090804@googlemail.com> Hello, I use CMake extensively for cross platform and sometimes I write really complex functions. Sometimes I wish we had a 'continue' keyword to keep loops readable. There is a wishlist report about that and Doug Barbieri even added a patch: http://www.cmake.org/Bug/view.php?id=14013 I re-applied the patch to master, fixed some bit-rot and formatted it via git format-patch (also attached). Could you please take a look? It would be great if the 'continue' keyword support would be part of CMake 3.2. Thanks, Gregor PS: I'm unable to see Doug Barbieri email address in Mantis, so I cannot properly attribute him as original patch author. -------------- next part -------------- From 55dd89a8105e5576b1f6a3c0fde7ed7ffc8418ed Mon Sep 17 00:00:00 2001 From: Gregor Jasny Date: Thu, 23 Oct 2014 09:28:55 +0200 Subject: [PATCH] Add continue keyword (#14013) Original patch by Doug Barbieri. Signed-off-by: Gregor Jasny --- Help/command/continue.rst | 7 ++++++ Source/cmBootstrapCommands1.cxx | 2 ++ Source/cmContinueCommand.cxx | 21 ++++++++++++++++ Source/cmContinueCommand.h | 55 +++++++++++++++++++++++++++++++++++++++++ Source/cmExecutionStatus.h | 7 ++++++ Source/cmForEachCommand.cxx | 4 +++ Source/cmIfCommand.cxx | 5 ++++ Source/cmWhileCommand.cxx | 4 +++ 8 files changed, 105 insertions(+) create mode 100644 Help/command/continue.rst create mode 100644 Source/cmContinueCommand.cxx create mode 100644 Source/cmContinueCommand.h diff --git a/Help/command/continue.rst b/Help/command/continue.rst new file mode 100644 index 0000000..d377542 --- /dev/null +++ b/Help/command/continue.rst @@ -0,0 +1,7 @@ +continue +-------- + +Continue to the top of enclosing foreach or while loop. + +Continue allows the cmake script to abort the rest of a block in a foreach +or while loop, and start at the top of the next iteration. See also break(). diff --git a/Source/cmBootstrapCommands1.cxx b/Source/cmBootstrapCommands1.cxx index 9093579..d129aef 100644 --- a/Source/cmBootstrapCommands1.cxx +++ b/Source/cmBootstrapCommands1.cxx @@ -28,6 +28,7 @@ #include "cmCMakePolicyCommand.cxx" #include "cmCommandArgumentsHelper.cxx" #include "cmConfigureFileCommand.cxx" +#include "cmContinueCommand.cxx" #include "cmCoreTryCompile.cxx" #include "cmCreateTestSourceList.cxx" #include "cmDefinePropertyCommand.cxx" @@ -68,6 +69,7 @@ void GetBootstrapCommands1(std::list& commands) commands.push_back(new cmCMakeMinimumRequired); commands.push_back(new cmCMakePolicyCommand); commands.push_back(new cmConfigureFileCommand); + commands.push_back(new cmContinueCommand); commands.push_back(new cmCreateTestSourceList); commands.push_back(new cmDefinePropertyCommand); commands.push_back(new cmElseCommand); diff --git a/Source/cmContinueCommand.cxx b/Source/cmContinueCommand.cxx new file mode 100644 index 0000000..ecb894b --- /dev/null +++ b/Source/cmContinueCommand.cxx @@ -0,0 +1,21 @@ +/*============================================================================ + CMake - Cross Platform Makefile Generator + Copyright 2000-2009 Kitware, Inc., Insight Software Consortium + + Distributed under the OSI-approved BSD License (the "License"); + see accompanying file Copyright.txt for details. + + This software is distributed WITHOUT ANY WARRANTY; without even the + implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + See the License for more information. +============================================================================*/ +#include "cmContinueCommand.h" + +// cmContinueCommand +bool cmContinueCommand::InitialPass(std::vector const&, + cmExecutionStatus &status) +{ + status.SetContinueInvoked(true); + return true; +} + diff --git a/Source/cmContinueCommand.h b/Source/cmContinueCommand.h new file mode 100644 index 0000000..2107637 --- /dev/null +++ b/Source/cmContinueCommand.h @@ -0,0 +1,55 @@ +/*============================================================================ + CMake - Cross Platform Makefile Generator + Copyright 2000-2009 Kitware, Inc., Insight Software Consortium + + Distributed under the OSI-approved BSD License (the "License"); + see accompanying file Copyright.txt for details. + + This software is distributed WITHOUT ANY WARRANTY; without even the + implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + See the License for more information. +============================================================================*/ +#ifndef cmContinueCommand_h +#define cmContinueCommand_h + +#include "cmCommand.h" + +/** \class cmContinueCommand + * \brief Continue from an enclosing foreach or while loop + * + * cmContinueCommand returns from an enclosing foreach or while loop + */ +class cmContinueCommand : public cmCommand +{ +public: + /** + * This is a virtual constructor for the command. + */ + virtual cmCommand* Clone() + { + return new cmContinueCommand; + } + + /** + * This is called when the command is first encountered in + * the CMakeLists.txt file. + */ + virtual bool InitialPass(std::vector const& args, + cmExecutionStatus &status); + + /** + * This determines if the command is invoked when in script mode. + */ + virtual bool IsScriptable() const { return true; } + + /** + * The name of the command as specified in CMakeList.txt. + */ + virtual std::string GetName() const { return "continue"; } + + cmTypeMacro(cmContinueCommand, cmCommand); +}; + + + +#endif diff --git a/Source/cmExecutionStatus.h b/Source/cmExecutionStatus.h index 5c94a97..d4da5a4 100644 --- a/Source/cmExecutionStatus.h +++ b/Source/cmExecutionStatus.h @@ -36,10 +36,16 @@ public: virtual bool GetBreakInvoked() { return this->BreakInvoked; } + virtual void SetContinueInvoked(bool val) + { this->ContinueInvoked = val; } + virtual bool GetContinueInvoked() + { return this->ContinueInvoked; } + virtual void Clear() { this->ReturnInvoked = false; this->BreakInvoked = false; + this->ContinueInvoked = false; this->NestedError = false; } virtual void SetNestedError(bool val) { this->NestedError = val; } @@ -49,6 +55,7 @@ public: protected: bool ReturnInvoked; bool BreakInvoked; + bool ContinueInvoked; bool NestedError; }; diff --git a/Source/cmForEachCommand.cxx b/Source/cmForEachCommand.cxx index e3f66c1..dfb9ae7 100644 --- a/Source/cmForEachCommand.cxx +++ b/Source/cmForEachCommand.cxx @@ -67,6 +67,10 @@ IsFunctionBlocked(const cmListFileFunction& lff, cmMakefile &mf, mf.AddDefinition(this->Args[0],oldDef.c_str()); return true; } + if (status.GetContinueInvoked()) + { + break; + } if(cmSystemTools::GetFatalErrorOccured() ) { return true; diff --git a/Source/cmIfCommand.cxx b/Source/cmIfCommand.cxx index f728c15..b8e30b7 100644 --- a/Source/cmIfCommand.cxx +++ b/Source/cmIfCommand.cxx @@ -151,6 +151,11 @@ IsFunctionBlocked(const cmListFileFunction& lff, inStatus.SetBreakInvoked(true); return true; } + if (status.GetContinueInvoked()) + { + inStatus.SetContinueInvoked(true); + return true; + } } } return true; diff --git a/Source/cmWhileCommand.cxx b/Source/cmWhileCommand.cxx index 851c4cb..d648a0c 100644 --- a/Source/cmWhileCommand.cxx +++ b/Source/cmWhileCommand.cxx @@ -81,6 +81,10 @@ IsFunctionBlocked(const cmListFileFunction& lff, cmMakefile &mf, { return true; } + if (status.GetContinueInvoked()) + { + break; + } if(cmSystemTools::GetFatalErrorOccured() ) { return true; -- 1.9.3 (Apple Git-50) From orion at cora.nwra.com Fri Oct 31 17:15:44 2014 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 31 Oct 2014 15:15:44 -0600 Subject: [cmake-developers] cmake-gui icons In-Reply-To: <20141029155032.GA9654@megas.kitwarein.com> References: <544E87ED.4080208@cora.nwra.com> <20141029155032.GA9654@megas.kitwarein.com> Message-ID: <5453FC00.2090902@cora.nwra.com> On 10/29/2014 09:50 AM, Ben Boeckel wrote: > On Mon, Oct 27, 2014 at 11:59:09 -0600, Orion Poplawski wrote: >> Fedora is pushing to have higher resolution icons for the applications. There >> already is CMakeSetup128.png, but these would need to get installed into the >> proper /usr/share/icons/ hierarchy and named appropriately for the correct >> size to be automatically found and used. It would be good to have cmake-gui be >> conformant to the current desktop standards. > > The 128x128 is now installed with the branch currently on stage (and > next): > > unix-icon-install > Looks good. You might want to add more resolutions, maybe a svg version too. According to https://bugzilla.redhat.com/show_bug.cgi?id=1157509, the recommended sizes are 24x24, 48x48, 64x64 and 256x256 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com