From pascal.bach at siemens.com Mon Sep 1 03:52:46 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Mon, 1 Sep 2014 07:52:46 +0000 Subject: [cmake-developers] Cross compile tests on open.cdash.org In-Reply-To: <54009DAD.7090003@kitware.com> References: <355BE46A91031048906B695426A8D8E616AC19C1@DEFTHW99EH4MSX.ww902.siemens.net> <54009DAD.7090003@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACA9B2@DEFTHW99EH4MSX.ww902.siemens.net> Hi > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] > On Behalf Of Bill Hoffman > Sent: Freitag, 29. August 2014 17:35 > To: cmake-developers at cmake.org > Subject: Re: [cmake-developers] Cross compile tests on open.cdash.org > > On 8/29/2014 9:47 AM, Bach, Pascal wrote: > > Hi Everybody > > > > I'm interested in cross compilation, and am already using it extensively for > Linux and Embedded Linux. > > But now I ran into some problems cross compiling for Windows Compact > Embedded 2013 using Visual Studio. > > After some discussion on IRC, Nils Gladitz pointed out that there are no > cross compilation tests on the public CDash > (http://open.cdash.org/index.php?project=CMake). > > > > It might be worth to start a discussion on that topic and maybe find a way > to improve that. > > > > One question is if there is already somebody working in this direction or > maybe even already has a running cross compilation test using CMake? > > What would be necessary to extend the current test for a cross compilation > scenario? > > > > With best regards, > > Pascal Bach > > > > Hi, > > This is a good idea. There has been some recent work on the windows > phone support: Tests/VSWinStorePhone/. However, I would think what you > would want would be a more comprehensive test of CMake. Most of the > tests run executables that are built. We would either have to not do > that, or run them on a simulator or have an actual device that the tests > are pushed to for running. The other option would be to create one or > more specific cross compile tests. I would for a start suggest to run the tests in a simulator. The simplest thing to set up would be to have a cross compile on linux and the run the tests using qemu. > It would require someone to setup dashboard clients as well: > http://www.cmake.org/cmake/resources/testing.html. Would you be able > to run clients like that? I'm currently clarifying if we can provide some build/test machines. I would like to be able to provide a Linux x86 -> Linux ARM and a Windows 64bit -> Windows CE ARM build including target/simulator to run the tests on. But I can't promise yet. - Pascal From eike at sf-mail.de Mon Sep 1 04:35:34 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 01 Sep 2014 10:35:34 +0200 Subject: [cmake-developers] Cross compile tests on open.cdash.org In-Reply-To: <54009DAD.7090003@kitware.com> References: <355BE46A91031048906B695426A8D8E616AC19C1@DEFTHW99EH4MSX.ww902.siemens.net> <54009DAD.7090003@kitware.com> Message-ID: <9bdf3242bf375181f7aee0d9c36fdec6@sf-mail.de> Am 29.08.2014 17:35, schrieb Bill Hoffman: > On 8/29/2014 9:47 AM, Bach, Pascal wrote: >> Hi Everybody >> >> I'm interested in cross compilation, and am already using it >> extensively for Linux and Embedded Linux. >> But now I ran into some problems cross compiling for Windows Compact >> Embedded 2013 using Visual Studio. >> After some discussion on IRC, Nils Gladitz pointed out that there are >> no cross compilation tests on the public CDash >> (http://open.cdash.org/index.php?project=CMake). >> >> It might be worth to start a discussion on that topic and maybe find a >> way to improve that. >> >> One question is if there is already somebody working in this direction >> or maybe even already has a running cross compilation test using >> CMake? >> What would be necessary to extend the current test for a cross >> compilation scenario? > This is a good idea. There has been some recent work on the windows > phone support: Tests/VSWinStorePhone/. However, I would think what > you would want would be a more comprehensive test of CMake. Most of > the tests run executables that are built. We would either have to not > do that, or run them on a simulator or have an actual device that the > tests are pushed to for running. The other option would be to create > one or more specific cross compile tests. > > It would require someone to setup dashboard clients as well: > http://www.cmake.org/cmake/resources/testing.html. Would you be able > to run clients like that? I think I will be able to provide some Linux x86_64 -> * cross-builds, likely ARM and MIPS, maybe something more. Eike From aleixpol at kde.org Mon Sep 1 09:53:26 2014 From: aleixpol at kde.org (Aleix Pol) Date: Mon, 1 Sep 2014 15:53:26 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: Message-ID: On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol wrote: > Dear cmake'rs, > I'm rewriting the KDevelop plugin from scratch to fetch the information > from the build directory. > > Now in the first implementation I'm using the compile_commands.json file > that cmake already can generate for some time. It works quite well already, > given how data just comes out ready to be consumed (almost). The problem > now is that we're lacking some information, namely information about the > targets, their location and such *. > > To that end, I wrote a little patch to be taken as a proof of concept, > that generates (some of) the needed information. I would like to know if > you think it's an approach that would be accepted in the cmake code-base or > if I need to take a different approach. > > Patch http://proli.net/meu/kdevelop/cmake-targetsdata.patch > Output: http://proli.net/meu/kdevelop/AwesomeTargets.json > > Cheers! > Aleix > > * Yes, I'm aware of generators, but I'm not comfortable with the idea of > tying a build directory to an editor (even if it's my editor). Our users > usually build the projects with different tools and asking them to > re-create their build only for being comfortable with KDevelop sometimes is > a burden. It would be for me too! > Bump? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascal.bach at siemens.com Mon Sep 1 11:25:05 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Mon, 1 Sep 2014 15:25:05 +0000 Subject: [cmake-developers] Cross compile tests on open.cdash.org In-Reply-To: <9bdf3242bf375181f7aee0d9c36fdec6@sf-mail.de> References: <355BE46A91031048906B695426A8D8E616AC19C1@DEFTHW99EH4MSX.ww902.siemens.net> <54009DAD.7090003@kitware.com> <9bdf3242bf375181f7aee0d9c36fdec6@sf-mail.de> Message-ID: <355BE46A91031048906B695426A8D8E616ACCB31@DEFTHW99EH4MSX.ww902.siemens.net> Hi Guys > > > This is a good idea. There has been some recent work on the windows > > phone support: Tests/VSWinStorePhone/. However, I would think what > > you would want would be a more comprehensive test of CMake. Most of > > the tests run executables that are built. We would either have to not > > do that, or run them on a simulator or have an actual device that the > > tests are pushed to for running. The other option would be to create > > one or more specific cross compile tests. I gave it some thought and I think it might be better to have some cross compile tests. This because it might not be possible to compile all of CMake for a given target. Does somebody already have an idea where to put this tests? I'm still digging through the code ;) > > > > It would require someone to setup dashboard clients as well: > > http://www.cmake.org/cmake/resources/testing.html. Would you be > able > > to run clients like that? > > I think I will be able to provide some Linux x86_64 -> * cross-builds, > likely ARM and MIPS, maybe something more. > That would be good Erik, I will then try to focus on providing a Windows CE machine first. Pascal From chuck.atkins at kitware.com Mon Sep 1 14:35:41 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 1 Sep 2014 14:35:41 -0400 Subject: [cmake-developers] How to get a nightly build process going. In-Reply-To: References: <1625614106.25599.1409412011499.JavaMail.vpopmail@webmail2.networksolutionsemail.com> <1442524.tQkLfgu6xA@caliban.sf-tec.de> <1568432513.23189.1409428834864.JavaMail.vpopmail@webmail2.networksolutionsemail.com> <2411065.ulDJNWIhbH@caliban.sf-tec.de> <1565610899.23232.1409429367244.JavaMail.vpopmail@webmail2.networksolutionsemail.com> <540234AB.6080306@gmail.com> <1915404470.31130.1409449872395.JavaMail.vpopmail@webmail2.networksolutionsemail.com> Message-ID: Back on topic... > Solaris 10 + SolarisStudio > http://open.cdash.org/buildSummary.php?buildid=3470493 > No build failures, 4 test failures > > Solaris 10 + GCC (from OpenCSW) > http://open.cdash.org/buildSummary.php?buildid=3470687 > No build failures, 5 test failures > I dug more into the test failures. 3 of the failures were due to a borked mercurial install on the machine, i.e. not a cmake problem but a system problem, which has since been fixed. Another was a FindGTK2 bug, which I just pushed a fix to next for. Given the _Bool fix and GTK2 fix, all tests should pass for nightly next on Solaris + suncc, and 1 failure for Solaris + GCC. So once you get your nightly submissions set up, I would expect a clean Solaris Studio build and test and a clean GCC build with 1 test failure. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Mon Sep 1 15:26:12 2014 From: dlrdave at aol.com (David Cole) Date: Mon, 1 Sep 2014 15:26:12 -0400 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: Message-ID: <8D19431B9E085CE-1284-18364@webmail-vm008.sysops.aol.com> The approach looks reasonable, but having it unconditionally spit out a file in cmGlobalGenerator regardless of generator is probably not what we want. Seems like it should be based on a variable, or be in a specific generator, or somehow have a limited scope. HTH, David C. From mantis at public.kitware.com Mon Sep 1 16:29:19 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 1 Sep 2014 16:29:19 -0400 Subject: [cmake-developers] [CMake 0015121]: OpenSceneGraph module broken Message-ID: <2f142d0b17dc7860f03f0aa462f42c24@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15121 ====================================================================== Reported By: Hartmut Seichter Assigned To: ====================================================================== Project: CMake Issue ID: 15121 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-01 16:29 EDT Last Modified: 2014-09-01 16:29 EDT ====================================================================== Summary: OpenSceneGraph module broken Description: On Arch Linux and Mac OS X 10.9.3 the find module for OpenSceneGraph stopped working. Seems the combination cmake 3.0.x and OSG 3.2.1 is having issues. Also setting OSG_DIR and CMAKE_PREFIX_PATH seem to have no effect. This is quite an issue as most OSG dependent project will use cmake as build system. An OSX example with debug on ... cmake -DOpenSceneGraph_DEBUG=ON -DCMAKE_PREFIX_PATH=/opt/local -DOSG_DIR=/opt/local ../VisionSpace -- [ FindOpenSceneGraph.cmake:128 ] Components = osg;OpenThreads -- [ FindOpenSceneGraph.cmake:200 ] Calling find_package(osg ) -- Could NOT find osg (missing: OSG_LIBRARY OSG_INCLUDE_DIR) -- [ FindOpenSceneGraph.cmake:200 ] Calling find_package(OpenThreads ) -- Could NOT find OpenThreads (missing: OPENTHREADS_LIBRARY OPENTHREADS_INCLUDE_DIR) CMake Error at /opt/local/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:136 (message): Could NOT find OpenSceneGraph (missing: OPENSCENEGRAPH_LIBRARIES OPENSCENEGRAPH_INCLUDE_DIR OSG_FOUND OPENTHREADS_FOUND) Call Stack (most recent call first): /opt/local/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:343 (_FPHSA_FAILURE_MESSAGE) /opt/local/share/cmake-3.0/Modules/FindOpenSceneGraph.cmake:230 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:11 (find_package) Steps to Reproduce: Arch Linux (x86_64, cmake-3.0.1-1, openscenegraph-3.2.1-1) Mavericks (MacPorts, CMake @3.0.0_3, OpenSceneGraph @3.2.1) Clear cache (it kept working on an install where the cache was moved over from an older CMake build). Minimal project (https://github.com/seichter/sandbox/tree/master/bugreports/cmake-osg) with find_package(OpenSceneGraph REQUIRED) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-01 16:29 Hartmut SeichterNew Issue ====================================================================== From neundorf at kde.org Mon Sep 1 17:22:06 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Mon, 01 Sep 2014 23:22:06 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <8D19431B9E085CE-1284-18364@webmail-vm008.sysops.aol.com> References: <8D19431B9E085CE-1284-18364@webmail-vm008.sysops.aol.com> Message-ID: <1616912.3Bv1RU2FhA@tuxedo.neundorf.net> On Monday, September 01, 2014 15:26:12 David Cole via cmake-developers wrote: > The approach looks reasonable, but having it unconditionally spit out a > file in cmGlobalGenerator regardless of generator is probably not what > we want. Seems like it should be based on a variable, or be in a > specific generator, or somehow have a limited scope. I agree. IMO this should be a generator, I don't see why it should work around that. Alex From aleixpol at kde.org Mon Sep 1 19:27:27 2014 From: aleixpol at kde.org (Aleix Pol) Date: Tue, 2 Sep 2014 01:27:27 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <8D19431B9E085CE-1284-18364@webmail-vm008.sysops.aol.com> References: <8D19431B9E085CE-1284-18364@webmail-vm008.sysops.aol.com> Message-ID: On Mon, Sep 1, 2014 at 9:26 PM, David Cole wrote: > The approach looks reasonable, but having it unconditionally spit out a > file in cmGlobalGenerator regardless of generator is probably not what we > want. Seems like it should be based on a variable, or be in a specific > generator, or somehow have a limited scope. > > HTH, > David C. > Ok, how does it sound if we have a variable, such as CMAKE_EXPORT_COMPILE_COMMANDS? Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Tue Sep 2 01:37:04 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 02 Sep 2014 07:37:04 +0200 Subject: [cmake-developers] How to get a nightly build process going. In-Reply-To: References: <1625614106.25599.1409412011499.JavaMail.vpopmail@webmail2.networksolutionsemail.com> Message-ID: <1966586.ILOyKsinXl@caliban.sf-tec.de> Am Montag, 1. September 2014, 14:35:41 schrieb Chuck Atkins: > Back on topic... > > > Solaris 10 + SolarisStudio > > http://open.cdash.org/buildSummary.php?buildid=3470493 > > No build failures, 4 test failures > > > > Solaris 10 + GCC (from OpenCSW) > > http://open.cdash.org/buildSummary.php?buildid=3470687 > > No build failures, 5 test failures > > I dug more into the test failures. 3 of the failures were due to a borked > mercurial install on the machine, i.e. not a cmake problem but a system > problem, which has since been fixed. Another was a FindGTK2 bug, which I > just pushed a fix to next for. Isn't "if (D)" enough there instead of the MATCHES? 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 Tue Sep 2 07:03:43 2014 From: dlrdave at aol.com (David Cole) Date: Tue, 2 Sep 2014 07:03:43 -0400 Subject: [cmake-developers] Extracting target metadata, IDE integration Message-ID: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> > Ok, how does it sound if we have a variable, such as > CMAKE_EXPORT_COMPILE_COMMANDS? > Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. I would prefer CMAKE_EXPORT_TARGETS_FILE, or some name that implies it is a filename value, with the value of the variable being the name of the file to generate. Who's the consumer of this file? Is it just one particular IDE, or is it meant to be general and possibly be used by multiple IDE generators? (I'm not sure I fully understand the context of the intent here based on the prior emails.... Can you explain it a little more?) Thanks, David C. From aleixpol at kde.org Tue Sep 2 07:28:15 2014 From: aleixpol at kde.org (Aleix Pol) Date: Tue, 2 Sep 2014 13:28:15 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> Message-ID: On Tue, Sep 2, 2014 at 1:03 PM, David Cole wrote: > > Ok, how does it sound if we have a variable, such as > > CMAKE_EXPORT_COMPILE_COMMANDS? > > Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. > > > I would prefer CMAKE_EXPORT_TARGETS_FILE, or some name that implies it > is a filename value, with the value of the variable being the name of > the file to generate. > I think it's better to do an "ON/OFF" setting, given that from an IDE point of view what we want is to be able to run cmake again and get the file. If Eclipse generated the file I will still want to open it, and then we'd have to agree on a file name or need to modify the build directory, which kind of defeats the purpose. > > Who's the consumer of this file? Is it just one particular IDE, or is > it meant to be general and possibly be used by multiple IDE generators? > (I'm not sure I fully understand the context of the intent here based > on the prior emails.... Can you explain it a little more?) > The consumer of this file is the IDE or anyone who needs to be able to figure out the project's data. We need ways to describe the targets generated by the project to let the IDE user know what targets the project has and to be able to use them. To get some context, let me define one of our use-cases, which would be a KDE user. To build a KDE Plasma 5 installation you need > 100 repositories to be built and configured. This means that all these are configured and installed to a prefix, possibly with an external tool. Our user will want to develop one of those projects. To do so, he will open the project and choose the build directory tied to it, from there we need to infer all the information he will need to develop the project. Here's where the targets file comes into place, the IDE will just need to open this file and the compile_commands.json files. If they're not created the IDE will set the cache values then generate to be able to access them. I hope it makes sense now. Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Tue Sep 2 09:25:51 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Tue, 2 Sep 2014 09:25:51 -0400 Subject: [cmake-developers] How to get a nightly build process going. In-Reply-To: <1966586.ILOyKsinXl@caliban.sf-tec.de> References: <1625614106.25599.1409412011499.JavaMail.vpopmail@webmail2.networksolutionsemail.com> <1966586.ILOyKsinXl@caliban.sf-tec.de> Message-ID: It seems so. I was thrown off by the multiple levels of indirection happening since the actual values in the OPTIONAL_INCLUDES end up as "foo1;foo2-NOTFOUND;bar". I was thinking that if(VARNAME) would only work if the value of VARNAME was actually "VARNAME-NOTFOUND" but that's not the case, it works so long as "-NOTFOUND" is a suffix. - Chuck On Tue, Sep 2, 2014 at 1:37 AM, Rolf Eike Beer wrote: > Am Montag, 1. September 2014, 14:35:41 schrieb Chuck Atkins: > > Back on topic... > > > > > Solaris 10 + SolarisStudio > > > http://open.cdash.org/buildSummary.php?buildid=3470493 > > > No build failures, 4 test failures > > > > > > Solaris 10 + GCC (from OpenCSW) > > > http://open.cdash.org/buildSummary.php?buildid=3470687 > > > No build failures, 5 test failures > > > > I dug more into the test failures. 3 of the failures were due to a > borked > > mercurial install on the machine, i.e. not a cmake problem but a system > > problem, which has since been fixed. Another was a FindGTK2 bug, which I > > just pushed a fix to next for. > > Isn't "if (D)" enough there instead of the MATCHES? > > Eike -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Tue Sep 2 09:58:37 2014 From: dlrdave at aol.com (David Cole) Date: Tue, 2 Sep 2014 09:58:37 -0400 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> Message-ID: <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> It makes sense. But what IDE are you referring to? Eclipse? Some other concrete example? Or just "any IDE and this feature should work everywhere CMake works...?" From brad.king at kitware.com Tue Sep 2 10:12:21 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Sep 2014 10:12:21 -0400 Subject: [cmake-developers] Mixing generator expressions and debug|optimized|general keywords in target_link_libraries() In-Reply-To: <54004758.7000506@gmail.com> References: <54004758.7000506@gmail.com> Message-ID: <5405D045.4030803@kitware.com> On 08/29/2014 05:26 AM, Nils Gladitz wrote: > I tried wrapping the libraries returned by FindBoost.cmake in > $ in a target_link_libraries() call and noticed that > this breaks because of the debug/optimized keywords that the find module > inserts. > > Specifically it results in CMake trying to link e.g. "optimized.lib". > > Should/could these keywords be handled at generation time (after > generator expressions expansion)? These keywords are meaningful to target_link_libraries and nothing else, just like the PRIVATE/PUBLIC/INTERFACE keywords. It is the responsibility of that command to handle them. One can put a genex in the value after the keyword: "optimized $<...>", but otherwise they are not really meant to mix. The use of generator expressions and imported targets is supposed to supersede use of the old keywords. There was recent work posted on this list to add imported targets to the FindBoost results. > There don't seem to be generator expressions that correspond to the > debug/optimized keywords exactly. Can/should there be? Steve K and I discussed this once. Since DEBUG_CONFIGURATIONS can be set differently in exporting and importing projects so there is no global meaning across all targets. See the cmTarget::GetDebugGeneratorExpressions method: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;hb=v3.0.1#l908 It constructs a $ expression of $ expressions for each entry in DEBUG_CONFIGURATIONS. This is how target_link_libraries transforms debug/optimized keywords when constructing the INTERFACE_LINK_LIBRARIES value. -Brad From nilsgladitz at gmail.com Tue Sep 2 10:40:26 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 02 Sep 2014 16:40:26 +0200 Subject: [cmake-developers] Mixing generator expressions and debug|optimized|general keywords in target_link_libraries() In-Reply-To: <5405D045.4030803@kitware.com> References: <54004758.7000506@gmail.com> <5405D045.4030803@kitware.com> Message-ID: <5405D6DA.90401@gmail.com> On 09/02/2014 04:12 PM, Brad King wrote: > On 08/29/2014 05:26 AM, Nils Gladitz wrote: > Steve K and I discussed this once. Since DEBUG_CONFIGURATIONS can be > set differently in exporting and importing projects so there is no > global meaning across all targets. See the > cmTarget::GetDebugGeneratorExpressions method: > > http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;hb=v3.0.1#l908 > > It constructs a $ expression of $ expressions > for each entry in DEBUG_CONFIGURATIONS. This is how > target_link_libraries transforms debug/optimized keywords when > constructing the INTERFACE_LINK_LIBRARIES value. For some reason I thought RelWithDebInfo was per default a debug configuration but that does not actually seem to be the case. Given that Debug is the only (default) configuration in the set that simplifies things greatly - for me at least :p I'll manually transform the library lists until FindBoost.cmake exports targets or Boost itself provides a config file. Thanks! Nils From brad.king at kitware.com Tue Sep 2 11:00:19 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Sep 2014 11:00:19 -0400 Subject: [cmake-developers] VS 2013 WindowsCE support (was: VS12: Allow specifying an installed SDK as target platform for the generator.) In-Reply-To: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> Message-ID: <5405DB83.7040605@kitware.com> On 08/28/2014 08:52 AM, Pascal Bach wrote: > This brings the behavior of Visual Studio 2013 in line with the one of Visual Studio 2012. In combination with your related issue report: WindowsCE: /SUBSYSTEM and /ENTRYPOINT does not end up in the generated Visual Studio project http://www.cmake.org/Bug/view.php?id=15115 it looks like a bit of work is needed to get Windows CE support working with VS 2013. Also, since the work was done for VS 2012, our infrastructure for cross-compiling with Visual Studio generators has improved. Rather than putting the target platform in the generator name (leading to a vs-version/platform combinatorial explosion), we should now be able to activate cross-compiling with -DCMAKE_SYSTEM_NAME=WindowsCE or -DCMAKE_TOOLCHAIN_FILE=... while still using -G "Visual Studio 12 2013" as the generator. This will be the preferred approach for new upstream support. I can help guide anyone interested in making the needed changes. -Brad From pascal.bach at siemens.com Tue Sep 2 11:27:10 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 2 Sep 2014 15:27:10 +0000 Subject: [cmake-developers] VS 2013 WindowsCE support (was: VS12: Allow specifying an installed SDK as target platform for the generator.) In-Reply-To: <5405DB83.7040605@kitware.com> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> Hi Brad > In combination with your related issue report: > > WindowsCE: /SUBSYSTEM and /ENTRYPOINT does not end up in the > generated Visual Studio project > http://www.cmake.org/Bug/view.php?id=15115 > > it looks like a bit of work is needed to get Windows CE support > working with VS 2013. Also, since the work was done for VS 2012, > our infrastructure for cross-compiling with Visual Studio generators > has improved. Rather than putting the target platform in the > generator name (leading to a vs-version/platform combinatorial > explosion), we should now be able to activate cross-compiling > with -DCMAKE_SYSTEM_NAME=WindowsCE or - > DCMAKE_TOOLCHAIN_FILE=... > while still using -G "Visual Studio 12 2013" as the generator. > This will be the preferred approach for new upstream support. I think proposal would make things cleaner. I think specifying only -DCMAKE_SYSTEM_NAME=WindowsCE wouldn't be enough or how does VS know what compiler to use? I would like it if we had a toolchain file for each SDK but then I'm not clear what it contains. In this toolchain file do we specify compiler etc like it is done for gcc for example, or would the toolchain file contain a variable like CMAKE_VS_SDK pointing to one of the installed SDKs? I'm not yet familiar with the VS build environment . > I can help guide anyone interested in making the needed changes. I might be able to invest some time into this so some guidance would be welcome ;) Pascal From brad.king at kitware.com Tue Sep 2 12:02:53 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Sep 2014 12:02:53 -0400 Subject: [cmake-developers] VS 2013 WindowsCE support In-Reply-To: <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <5405EA2D.4070801@kitware.com> On 09/02/2014 11:27 AM, Bach, Pascal wrote: >> we should now be able to activate cross-compiling >> with -DCMAKE_SYSTEM_NAME=WindowsCE or - >> DCMAKE_TOOLCHAIN_FILE=... >> while still using -G "Visual Studio 12 2013" as the generator. > > I think proposal would make things cleaner. Great. It should be able to work for VS 2010 and greater. > I think specifying only -DCMAKE_SYSTEM_NAME=WindowsCE wouldn't be > enough or how does VS know what compiler to use? Correct. We would need another variable to specify the SDK. It could be added to the command line or set in a toolchain file. > I would like it if we had a toolchain file for each SDK but > then I'm not clear what it contains. In this toolchain file do > we specify compiler etc like it is done for gcc for example, > or would the toolchain file contain a variable like CMAKE_VS_SDK > pointing to one of the installed SDKs? The following block in Modules/CMakeDetermineSystem.cmake: elseif(CMAKE_VS_WINCE_VERSION) set(CMAKE_SYSTEM_NAME "WindowsCE") set(CMAKE_SYSTEM_VERSION "${CMAKE_VS_WINCE_VERSION}") set(CMAKE_SYSTEM_PROCESSOR "${MSVC_C_ARCHITECTURE_ID}") is basically a mini toolchain file. A real toolchain file would explicitly specify the values. We would also need a new variable to tell the generator which SDK to use. Currently the info is in the internal CMAKE_VS_PLATFORM_NAME variable that corresponds to the platform component of the generator name. >> I can help guide anyone interested in making the needed changes. > > I might be able to invest some time into this so some guidance > would be welcome ;) Take a look at cmGlobalVisualStudio10Generator::InitializeSystem in recent 'master' versions. That is likely the place to hook in to recognize the "WindowsCE" name and look up the SDK variable. -Brad From neundorf at kde.org Tue Sep 2 15:45:19 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 02 Sep 2014 21:45:19 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> Message-ID: <1508558.GIL7YTuQJT@tuxedo.neundorf.net> On Tuesday, September 02, 2014 09:58:37 David Cole via cmake-developers wrote: > It makes sense. But what IDE are you referring to? Eclipse? Some other > concrete example? Or just "any IDE and this feature should work > everywhere CMake works...?" AFAIK it is kdevelop4, and the goal is that developers don't have to tell cmake to run a kdevelop4 generator, but just the normal makefile generator, and still be able to use kdevelop4 on these build trees. Alex From irwin at beluga.phys.uvic.ca Tue Sep 2 15:52:46 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 2 Sep 2014 12:52:46 -0700 (PDT) Subject: [cmake-developers] --debug-trycompile not working as documented with the results being overwritten Message-ID: Preliminaries to this topic have already been posted on the cmake list, but the only response there (from Mark Abraham) was "Raw try_compile is not a great idiom for general use (though it is unclear why it is not working well for you). Using the Modules/Check*cmake gear is a much better option, e.g. with check_symbol_exists()" which was useful in working around the issue, but not responsive about the issue itself which I now believe is a try_compile documentation bug. The (CMake-2.8.12.1) documentation says: "If you use --debug-trycompile, you can only debug one try_compile call at a time. The recommended procedure is to configure with cmake all the way through once, then delete the cache entry associated with the try_compile call of interest, and then re-run cmake again with --debug-trycompile." That implies every call to the second signature of try_compile, i.e., try_compile(RESULT_VAR [optional arguments]) is implicitly protected inside the implementation of try_compile by if(NOT DEFINED RESULT_VAR) [...] endif(NOT DEFINED RESULT_VAR) logic, but my tests show this is not the case and this second form of try_compile signature always repeated no matter if RESULT_VAR is defined or not in the cache. In fact, if you look at all the try_compile usage in Modules/Check*cmake, every such try_compile call is protected _outside_ the call by either if(NOT DEFINED VARIABLE) logic or the equivalent (using CMake logic available in 2006 (!)) if("${VARIABLE}" MATCHES "^${VARIABLE}$") logic. Which in turn implies all the different writers of the Modules/Check*cmake modules were well aware over the years that try_compile repeats (unless protected by such DEFINED logic) for each cmake invocation contrary to the above try_compile documentation. So to fix this documentation bug, I suggest This recommended procedure obviously only works if every try_compile call using the second signature in any given build system is protected by "if(NOT DEFINED RESULT_VAR)" logic. be appended to the try_compile documentation. I am willing to write this up as a bug report, but I believe this bug fix is pretty much a no-brainer which requires only checking my experimental results that the try_compile implementation is not protected internally by a DEFINED check of the variable before adding the above sentence to the documentation. So I hope to convince a CMake developer to just go ahead an fix this documentation bug without going through the normal dance of putting it on the bug tracker, watching it get ignored there because of all the noise from low-quality bug reports there, keep advocating here this really is a useful documentation fix, etc. 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 pascal.bach at siemens.com Wed Sep 3 05:23:28 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Wed, 3 Sep 2014 09:23:28 +0000 Subject: [cmake-developers] VS 2013 WindowsCE support In-Reply-To: <5405EA2D.4070801@kitware.com> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> <5405EA2D.4070801@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACE504@DEFTHW99EH4MSX.ww902.siemens.net> > On 09/02/2014 11:27 AM, Bach, Pascal wrote: > >> we should now be able to activate cross-compiling > >> with -DCMAKE_SYSTEM_NAME=WindowsCE or - > >> DCMAKE_TOOLCHAIN_FILE=... > >> while still using -G "Visual Studio 12 2013" as the generator. > > > > I think proposal would make things cleaner. > > Great. It should be able to work for VS 2010 and greater. > > > I think specifying only -DCMAKE_SYSTEM_NAME=WindowsCE wouldn't be > > enough or how does VS know what compiler to use? > > Correct. We would need another variable to specify the SDK. > It could be added to the command line or set in a toolchain file. > > > I would like it if we had a toolchain file for each SDK but > > then I'm not clear what it contains. In this toolchain file do > > we specify compiler etc like it is done for gcc for example, > > or would the toolchain file contain a variable like CMAKE_VS_SDK > > pointing to one of the installed SDKs? > > The following block in Modules/CMakeDetermineSystem.cmake: > > elseif(CMAKE_VS_WINCE_VERSION) > set(CMAKE_SYSTEM_NAME "WindowsCE") > set(CMAKE_SYSTEM_VERSION "${CMAKE_VS_WINCE_VERSION}") > set(CMAKE_SYSTEM_PROCESSOR "${MSVC_C_ARCHITECTURE_ID}") Do we need to preserve the current behavior? CMAKE_VS_WINCE_VERSION seems to be undocumented. The new way would be to set CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_VERSION in a toolchain file. > > is basically a mini toolchain file. A real toolchain file would > explicitly specify the values. We would also need a new variable > to tell the generator which SDK to use. Currently the info is > in the internal CMAKE_VS_PLATFORM_NAME variable that corresponds > to the platform component of the generator name. So do you agree that the right thing would be to add a CMAKE_VS_PLATFORM_SDK (or CMAKE_GENERATOR_SDK ?) variable that the user can set? A resulting toolchain file would look something like this: set(CMAKE_SYSTEM_NAME "WindowsCE") set(CMAKE_SYSTEM_VERSION "8.0") set(CMAKE_SYSTEM_PROCESSOR "arm" ) set(CMAKE_GENERATOR_TOOLSET "CE800") # I still don't know if this is needed ;) set(CMAKE_GENERATOR_SDK "MYSDK01") I don't understand the purpose of CMAKE_GENERATOR_TOOLSET resp. CMAKE_VS_PLATFORM_TOOLSET. As far as I understand they are independent of the SDK selected? > > >> I can help guide anyone interested in making the needed changes. > > > > I might be able to invest some time into this so some guidance > > would be welcome ;) > > Take a look at cmGlobalVisualStudio10Generator::InitializeSystem > in recent 'master' versions. That is likely the place to hook > in to recognize the "WindowsCE" name and look up the SDK variable. > Thanks I will have a look there. Pascal From mantis at public.kitware.com Wed Sep 3 06:16:52 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 3 Sep 2014 12:16:52 +0200 Subject: [cmake-developers] [CMake 0015124]: CPack doesn't package static libraries when CPACK_RPM_COMPONENT_INSTALL is on Message-ID: <4f830978b1606f3f923284001d4ca14a@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15124 ====================================================================== Reported By: Barthelemy von Haller Assigned To: ====================================================================== Project: CMake Issue ID: 15124 Category: CPack Reproducibility: have not tried Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-03 12:16 CEST Last Modified: 2014-09-03 12:16 CEST ====================================================================== Summary: CPack doesn't package static libraries when CPACK_RPM_COMPONENT_INSTALL is on Description: When I turn on CPACK_RPM_COMPONENT_INSTALL my static library is not packaged anymore. Other files such as headers or shared libraries are packed though. If I turn off CPACK_RPM_COMPONENT_INSTALL or make the library shared then it works fine. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-03 12:16 Barthelemy von HallerNew Issue ====================================================================== From aleixpol at kde.org Wed Sep 3 06:30:21 2014 From: aleixpol at kde.org (Aleix Pol) Date: Wed, 3 Sep 2014 12:30:21 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> Message-ID: On Tue, Sep 2, 2014 at 3:58 PM, David Cole wrote: > It makes sense. But what IDE are you referring to? Eclipse? Some other > concrete example? Or just "any IDE and this feature should work everywhere > CMake works...?" > > I'm working on KDevelop, I know for a fact though, that other IDEs are looking for something similar too, such as QtCreator. Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleixpol at kde.org Wed Sep 3 06:31:12 2014 From: aleixpol at kde.org (Aleix Pol) Date: Wed, 3 Sep 2014 12:31:12 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <1508558.GIL7YTuQJT@tuxedo.neundorf.net> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> <1508558.GIL7YTuQJT@tuxedo.neundorf.net> Message-ID: On Tue, Sep 2, 2014 at 9:45 PM, Alexander Neundorf wrote: > On Tuesday, September 02, 2014 09:58:37 David Cole via cmake-developers > wrote: > > It makes sense. But what IDE are you referring to? Eclipse? Some other > > concrete example? Or just "any IDE and this feature should work > > everywhere CMake works...?" > > AFAIK it is kdevelop4, and the goal is that developers don't have to tell > cmake to run a kdevelop4 generator, but just the normal makefile generator, > and still be able to use kdevelop4 on these build trees. > > Alex > Yes, essentially. Makefile, or ninja, or whatever they use on mac and Windows and any of our supported platforms. Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Wed Sep 3 08:47:24 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 3 Sep 2014 08:47:24 -0400 Subject: [cmake-developers] [CMake 0015125]: XCode generator cannot add assetcatalog assets Message-ID: <2aa9c4c360ae3f95dc209bcd912205f0@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15125 ====================================================================== Reported By: Jan R?egg Assigned To: ====================================================================== Project: CMake Issue ID: 15125 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-03 08:47 EDT Last Modified: 2014-09-03 08:47 EDT ====================================================================== Summary: XCode generator cannot add assetcatalog assets Description: When adding resources to an XCode CMake project like this: set_target_properties(foo PROPERTIES RESOURCE example/demo_app/Images.xcassets) An entry similar to this one is created in the xcode project: 1582C9DBB34F4291A1D09CA3 /* Images.xcassets */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = folder; name = Images.xcassets; path = example/demo_app/Images.xcassets; sourceTree = SOURCE_ROOT; }; This works fine for normal folders, however I would like to use this to add an assets folder. This creates a very similar entry, however to make it work with xcode the lastKnownFileType needs to be changed from "folder" to "folder.assetcatalog", like this: 1582C9DBB34F4291A1D09CA3 /* Images.xcassets */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = folder.assetcatalog; name = Images.xcassets; path = example/demo_app/Images.xcassets; sourceTree = SOURCE_ROOT; }; In CMake 3.0.1, this is generated in the file "cmGlobalXCodeGenerator.cxx", line 874: if(cmSystemTools::FileIsDirectory(fullpath.c_str())) { fileRef->AddAttribute("lastKnownFileType", this->CreateString("folder")); } In order to make it work, it would need to be changed to read something like this (pseudocode): if(cmSystemTools::FileIsDirectory(fullpath.c_str())) { if (fileEndsWith(".xcassets")) { fileRef->AddAttribute("lastKnownFileType", this->CreateString("folder.assetcatalog")); } else { fileRef->AddAttribute("lastKnownFileType", this->CreateString("folder")); } } ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-03 08:47 Jan R?egg New Issue ====================================================================== From brad.king at kitware.com Wed Sep 3 09:35:22 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 09:35:22 -0400 Subject: [cmake-developers] VS 2013 WindowsCE support In-Reply-To: <355BE46A91031048906B695426A8D8E616ACE504@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> <5405EA2D.4070801@kitware.com> <355BE46A91031048906B695426A8D8E616ACE504@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <5407191A.8070706@kitware.com> On 09/03/2014 05:23 AM, Bach, Pascal wrote: >> elseif(CMAKE_VS_WINCE_VERSION) >> set(CMAKE_SYSTEM_NAME "WindowsCE") >> set(CMAKE_SYSTEM_VERSION "${CMAKE_VS_WINCE_VERSION}") >> set(CMAKE_SYSTEM_PROCESSOR "${MSVC_C_ARCHITECTURE_ID}") > > Do we need to preserve the current behavior? Yes, but only for the existing VS 11 WinCE-specific generator names. > CMAKE_VS_WINCE_VERSION seems to be undocumented. It is an internal implementation detail of the WinCE-specific VS generators. > The new way would be to set CMAKE_SYSTEM_NAME and > CMAKE_SYSTEM_VERSION in a toolchain file. Yes. >> is basically a mini toolchain file. A real toolchain file would >> explicitly specify the values. We would also need a new variable >> to tell the generator which SDK to use. Currently the info is >> in the internal CMAKE_VS_PLATFORM_NAME variable that corresponds >> to the platform component of the generator name. > > So do you agree that the right thing would be to add a > CMAKE_VS_PLATFORM_SDK (or CMAKE_GENERATOR_SDK ?) variable that > the user can set? Let's use a name specific to WindowsCE like "CMAKE_VS_WINCE_SDK", at least for discussion and review purposes, so I can see where the variable fits in to the generator with your changes. Then we can decide if there is a more general name to be used later. > A resulting toolchain file would look something like this: > > set(CMAKE_SYSTEM_NAME "WindowsCE") > set(CMAKE_SYSTEM_VERSION "8.0") > set(CMAKE_SYSTEM_PROCESSOR "arm" ) > set(CMAKE_GENERATOR_TOOLSET "CE800") # I still don't know if this is needed ;) > set(CMAKE_GENERATOR_SDK "MYSDK01") > > I don't understand the purpose of CMAKE_GENERATOR_TOOLSET resp. > CMAKE_VS_PLATFORM_TOOLSET. The CMAKE_GENERATOR_TOOLSET is where a user-specified choice is set/saved. The CMAKE_VS_PLATFORM_TOOLSET is the actual toolset that the generator will write in to the project file, and is provided only for reference (and internal compiler id detection). The latter may be set to a default selection that CMake VS gens pick even when no explicit CMAKE_GENERATOR_TOOLSET is set. > As far as I understand they are independent of the SDK selected? I'm not familiar enough with VS+WinCE tools to know how independent they are. -Brad From brad.king at kitware.com Wed Sep 3 09:38:18 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 09:38:18 -0400 Subject: [cmake-developers] --debug-trycompile not working as documented with the results being overwritten In-Reply-To: References: Message-ID: <540719CA.4070502@kitware.com> On 09/02/2014 03:52 PM, Alan W. Irwin wrote: > just go ahead an fix this documentation bug without > going through the normal dance of putting it on the bug tracker, Please construct a proposed patch with "git format-patch" and attach it in a message here. Thanks, -Brad From hobbes1069 at gmail.com Wed Sep 3 09:48:29 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Wed, 3 Sep 2014 08:48:29 -0500 Subject: [cmake-developers] Best practice for determining if a static library was found and other issues with FindFLTK.cmake Message-ID: I'm probably going to end up taking over the module since it seems to be un-maintained but I'm hesitant to make radical changes to it. The module has several issues but a major one is that it doesn't add the required linker flags when using static libraries instead of shared. It also doesn't check for any required C flags but that's a lesser issue. These may only be a problem for the autotools based fltk build as the module uses a ConfigFLTK for CMake based builds. I have the following config to work around the issue which I'd like to ultimately get into the module and out of my cmake config: find_package(FLTK REQUIRED) if(${FLTK_FOUND}) include_directories(${FLTK_INCLUDE_DIRS}) # Set required CXX flags. execute_process(COMMAND ${FLTK_CONFIG_SCRIPT} --cxxflags OUTPUT_VARIABLE FLTK_CXXFLAGS) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${FLTK_CXXFLAGS}") # FindFLTK does not properly handle ldflags for static libraries. get_filename_component(FLTK_LIB_EXT ${FLTK_BASE_LIBRARY} EXT) if(${FLTK_LIB_EXT} STREQUAL ${CMAKE_STATIC_LIBRARY_SUFFIX}) ^^^ Is this the best way to determine if the library found was static or shared? ^^^ message(STATUS "Using static FLTK libraries.") execute_process(COMMAND ${FLTK_CONFIG_SCRIPT} --use-images --ldstaticflags OUTPUT_VARIABLE FLTK_LDFLAGS) ^^^ The module doesn't check if the library is static, and even then it only ^^^ ^^^ runs --ldflags for the fltk images library. separate_arguments(FLTK_LDFLAGS) foreach(_FLAG ${FLTK_LDFLAGS}) string(REGEX MATCH "^-l.+" _LDFLAG ${_FLAG}) string(STRIP "${_LDFLAG}" _LDFLAG) list(APPEND FLTK_LIBRARIES ${_LDFLAG}) endforeach() list(REMOVE_DUPLICATES FLTK_LIBRARIES) ^^^ This works, but is there a better way? ^^^ endif() list(APPEND FLDIGI_LINK_LIBS ${FLTK_LIBRARIES}) So a broader question... Should we trust the output of a config program, in this case, fltk-config? The writer of the module certainly doesn't. They used the fltk-config program to find the base library, strip off the path portion and then used it as a search path to find the libraries independently. I would like to update the module to use COMPONENTS, but the current default is to find everything unless a "FLTK_SKIP_..." variable is set so I assume there's a good way to keep backward compatibility. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Sep 3 10:11:15 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 10:11:15 -0400 Subject: [cmake-developers] Best practice for determining if a static library was found and other issues with FindFLTK.cmake In-Reply-To: References: Message-ID: <54072183.5090804@kitware.com> On 09/03/2014 09:48 AM, Richard Shaw wrote: > The module has several issues but a major one is that it doesn't add > the required linker flags when using static libraries instead of shared. > > It also doesn't check for any required C flags but that's a lesser issue. > > These may only be a problem for the autotools based fltk build > as the module uses a ConfigFLTK for CMake based builds. If FLTK upstream is willing to provide FTLKConfig for CMake-based builds then they may be willing to support providing one from autotools-based builds too. It is not very hard to provide one from a non-CMake build system. Qt5 and LLVM both do it. You could go work with the FLTK devs to do it there too. Then we won't even need a FindFLTK in CMake except for compatibility. > ^^^ Is this the best way to determine if the library found was > static or shared? ^^^ It is not possible in general without platform-specific knowledge. On AIX even an archive (.a) can be a shared library, for example. On Windows a .dll's import library (.lib) looks just like a static library (.lib). Ideally information provided with the FLTK package should tell us. > So a broader question... Should we trust the output of a config > program, in this case, fltk-config? The writer of the module > certainly doesn't. They used the fltk-config program to find > the base library, strip off the path portion and then used it > as a search path to find the libraries independently. Of course the output of fltk-config should be trusted to be correct, but the info still needs to be transformed into what CMake wants. That is usually more granular than strings of command-line flags for various tools, so some parsing/searching may be needed. > I would like to update the module to use COMPONENTS, but the > current default is to find everything unless a "FLTK_SKIP_..." > variable is set so I assume there's a good way to keep > backward compatibility. The FindFLTK module was added way back in the beginning of CMake and has never really been modernized. The SKIP variables may even predate the COMPONENTS support in find_package. -Brad From mantis at public.kitware.com Wed Sep 3 10:49:43 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 3 Sep 2014 16:49:43 +0200 Subject: [cmake-developers] [CMake 0015126]: cmake issues -bundle instead of -dynamiclib when creating shared modules Message-ID: <7a93fa062db74ec174641e1510483370@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15126 ====================================================================== Reported By: Ren? J.V. Bertin Assigned To: ====================================================================== Project: CMake Issue ID: 15126 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-03 16:49 CEST Last Modified: 2014-09-03 16:49 CEST ====================================================================== Summary: cmake issues -bundle instead of -dynamiclib when creating shared modules Description: While building KDE's Calligra suite, I came across a cmake-related error causing the linker to refuse to link in 'bundle' shared objects (intended to act as plugins also) in x86_64 mode. Googling, I came across ?http://www.wireshark.org/lists/wireshark-dev/201009/msg00231.html where one reads "CMake is using -bundle rather than -dylib/-dynamiclib to build the asn1 plugin, probably so that it'll work even on versions of OS X where you can't dynamically load an MH_DYLIB." AFAIK, that's a moot point since OS X 10.3 (or at least 10.4). Finding all CMAKE_SHARED_MODULE_CREATE definitions in /opt/local/lib/cmake{,-3.0} and replacing -bundle with -dynamiclib resolves the linking problem I encountered. A patchfile is included. Additional Information: Tested on OS X 10.6.8 and 10.9.x, with cmake 2.8 and cmake 3.0 . https://trac.macports.org/ticket/42840 I thought I already filed this bug "upstream" (from MacPorts) but apparently not here ... ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-03 16:49 Ren? J.V. BertinNew Issue 2014-09-03 16:49 Ren? J.V. BertinFile Added: patch-SHARED_BUNDLE_flag.diff ====================================================================== From pascal.bach at siemens.com Wed Sep 3 10:53:46 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Wed, 3 Sep 2014 14:53:46 +0000 Subject: [cmake-developers] VS 2013 WindowsCE support In-Reply-To: <5407191A.8070706@kitware.com> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> <5405EA2D.4070801@kitware.com> <355BE46A91031048906B695426A8D8E616ACE504@DEFTHW99EH4MSX.ww902.siemens.net> <5407191A.8070706@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACE698@DEFTHW99EH4MSX.ww902.siemens.net> > -----Original Message----- > From: Brad King [mailto:brad.king at kitware.com] > Sent: Mittwoch, 3. September 2014 15:35 > To: Bach, Pascal > Cc: cmake-developers at cmake.org; Patrick Roland Gansterer > Subject: Re: VS 2013 WindowsCE support > > On 09/03/2014 05:23 AM, Bach, Pascal wrote: > >> elseif(CMAKE_VS_WINCE_VERSION) > >> set(CMAKE_SYSTEM_NAME "WindowsCE") > >> set(CMAKE_SYSTEM_VERSION "${CMAKE_VS_WINCE_VERSION}") > >> set(CMAKE_SYSTEM_PROCESSOR "${MSVC_C_ARCHITECTURE_ID}") > > > > Do we need to preserve the current behavior? > > Yes, but only for the existing VS 11 WinCE-specific generator names. > > > CMAKE_VS_WINCE_VERSION seems to be undocumented. > > It is an internal implementation detail of the WinCE-specific > VS generators. > > > The new way would be to set CMAKE_SYSTEM_NAME and > > CMAKE_SYSTEM_VERSION in a toolchain file. > > Yes. > > >> is basically a mini toolchain file. A real toolchain file would > >> explicitly specify the values. We would also need a new variable > >> to tell the generator which SDK to use. Currently the info is > >> in the internal CMAKE_VS_PLATFORM_NAME variable that corresponds > >> to the platform component of the generator name. > > > > So do you agree that the right thing would be to add a > > CMAKE_VS_PLATFORM_SDK (or CMAKE_GENERATOR_SDK ?) variable that > > the user can set? > > Let's use a name specific to WindowsCE like "CMAKE_VS_WINCE_SDK", > at least for discussion and review purposes, so I can see where > the variable fits in to the generator with your changes. Then > we can decide if there is a more general name to be used later. I'm not sure this is really Windows CE specific. There is already an internal variable CMAKE_VS_PLATFORM_NAME that is set to Win32, Win64, ARM etc. This is also the variable that gets set to the SDK name. Currently this variable is set based on the Generator used, but there is also some other magic going on for example for Itanium. Would it be desirable to be able to override this value independent of the generator used? > > A resulting toolchain file would look something like this: > > > > set(CMAKE_SYSTEM_NAME "WindowsCE") > > set(CMAKE_SYSTEM_VERSION "8.0") > > set(CMAKE_SYSTEM_PROCESSOR "arm" ) > > set(CMAKE_GENERATOR_TOOLSET "CE800") # I still don't know if this is > needed ;) > > set(CMAKE_GENERATOR_SDK "MYSDK01") > > > > I don't understand the purpose of CMAKE_GENERATOR_TOOLSET resp. > > CMAKE_VS_PLATFORM_TOOLSET. > > The CMAKE_GENERATOR_TOOLSET is where a user-specified choice is > set/saved. The CMAKE_VS_PLATFORM_TOOLSET is the actual toolset > that the generator will write in to the project file, and is > provided only for reference (and internal compiler id detection). > The latter may be set to a default selection that CMake VS gens > pick even when no explicit CMAKE_GENERATOR_TOOLSET is set. Based on your explanation and my findings above, the CMAKE_VS_PLATFORM_NAME variable should behave analogues to CMAKE_VS_PLATFORM_TOOLSET but I can't come up with a good name for a variable the user should set. One way would be to just allow setting CMAKE_VS_PLATFORM_NAME and override the whole logic if it is set. Any thoughts? > > > As far as I understand they are independent of the SDK selected? > > I'm not familiar enough with VS+WinCE tools to know how independent > they are. As far as I can tell they are, at least you can change both values in visual studio independently. If the result works is another question. Pascal From irwin at beluga.phys.uvic.ca Wed Sep 3 10:52:35 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 3 Sep 2014 07:52:35 -0700 (PDT) Subject: [cmake-developers] --debug-trycompile not working as documented with the results being overwritten In-Reply-To: <540719CA.4070502@kitware.com> References: <540719CA.4070502@kitware.com> Message-ID: On 2014-09-03 09:38-0400 Brad King wrote: > On 09/02/2014 03:52 PM, Alan W. Irwin wrote: >> just go ahead an fix this documentation bug without >> going through the normal dance of putting it on the bug tracker, > > Please construct a proposed patch with "git format-patch" and > attach it in a message here. DONE. See attached 0001-Update-documentation-of-try_compile.patch The rst format seems obvious so I was pretty sure I understood what changes I had to make in the above patch, but just to be sure I checked this patch by building the patched master version and after that, cmake --help-command try_compile gave the desired corrected results. One caveat. My experimental result was try_compile always repeats so must not have any internal "if(NOT DEFINED RESULT_VAR)" logic. Which is why I updated the try_compile documentation accordingly. However, someone with more C++ skills than I have should probably double-check the try_compile code to make sure that experimental conclusion is correct. 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 __________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Update-documentation-of-try_compile.patch Type: text/x-diff Size: 1393 bytes Desc: try_compile documentation patch URL: From mantis at public.kitware.com Wed Sep 3 11:08:10 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 3 Sep 2014 17:08:10 +0200 Subject: [cmake-developers] [CMake 0015127]: command line CXX_FLAG settings overridden by settings in system-wide .cmake files Message-ID: <6d8ec4eb13827b2e1bbc4057e5b90812@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15127 ====================================================================== Reported By: Ren? J.V. Bertin Assigned To: ====================================================================== Project: CMake Issue ID: 15127 Category: CMake Reproducibility: always Severity: tweak Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-03 17:08 CEST Last Modified: 2014-09-03 17:08 CEST ====================================================================== Summary: command line CXX_FLAG settings overridden by settings in system-wide .cmake files Description: KDE defines a number of compiler options that are (supposedly) required but that include optimisation options. These settings are defined in system-wide .cmake files like FindKDE4Internal.cmake and get applied *after* user-specified settings have been applied. They even seem to override tweaks made directly in CMakeCache.txt (to CMAKE_CXX_FLAGS_RELEASE or _RELWITHDEBINFO). Even if user-specified compiler flags do make it to the list in the generated *.make files, the KDE/system-defined options are *appended* to the list, causing -O2 to override -O3 or -g -g3. Is it possible to specify the KDE/system options in such a way that they appear at the start of the options list in the *.make files? Steps to Reproduce: N/A Additional Information: Not really a bug, more a question and possibly a feature request. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-03 17:08 Ren? J.V. BertinNew Issue ====================================================================== From brad.king at kitware.com Wed Sep 3 11:16:38 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 11:16:38 -0400 Subject: [cmake-developers] VS 2013 WindowsCE support In-Reply-To: <355BE46A91031048906B695426A8D8E616ACE698@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> <5405EA2D.4070801@kitware.com> <355BE46A91031048906B695426A8D8E616ACE504@DEFTHW99EH4MSX.ww902.siemens.net> <5407191A.8070706@kitware.com> <355BE46A91031048906B695426A8D8E616ACE698@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <540730D6.80101@kitware.com> On 09/03/2014 10:53 AM, Bach, Pascal wrote: >> Let's use a name specific to WindowsCE like "CMAKE_VS_WINCE_SDK", > > I'm not sure this is really Windows CE specific. There is already > an internal variable CMAKE_VS_PLATFORM_NAME that is set to Win32, > Win64, ARM etc. This is also the variable that gets set to the SDK > name. Currently this variable is set based on the Generator used, > but there is also some other magic going on for example for Itanium. The fact that the PlatformName corresponds to an SDK is specific to WinCE tools. Other platforms may not have such correspondence. This is why I want to use a WinCE-specific name at first. We can generalize the name before merging the changes if it makes sense when its role becomes clear. > Would it be desirable to be able to override this value independent > of the generator used? I'm not sure what this would mean because the value is for a specific field in VS project files. > Based on your explanation and my findings above, the > CMAKE_VS_PLATFORM_NAME variable should behave analogues to > CMAKE_VS_PLATFORM_TOOLSET but I can't come up with a good > name for a variable the user should set. Yes. What I'm saying is the fact that a user can select this at all might be WinCE-specific. Hence a WinCE-specific name. -Brad From brad.king at kitware.com Wed Sep 3 11:22:44 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 11:22:44 -0400 Subject: [cmake-developers] --debug-trycompile not working as documented with the results being overwritten In-Reply-To: References: <540719CA.4070502@kitware.com> Message-ID: <54073244.5010605@kitware.com> On 09/03/2014 10:52 AM, Alan W. Irwin wrote: > On 2014-09-03 09:38-0400 Brad King wrote: >> Please construct a proposed patch with "git format-patch" and >> attach it in a message here. > > DONE. See attached 0001-Update-documentation-of-try_compile.patch Applied with minor tweaks, thanks: Help: Clarify --debug-trycompile usage with try_compile http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=abbe91c5 -Brad From pascal.bach at siemens.com Wed Sep 3 11:36:13 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Wed, 3 Sep 2014 15:36:13 +0000 Subject: [cmake-developers] VS 2013 WindowsCE support In-Reply-To: <540730D6.80101@kitware.com> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> <5405EA2D.4070801@kitware.com> <355BE46A91031048906B695426A8D8E616ACE504@DEFTHW99EH4MSX.ww902.siemens.net> <5407191A.8070706@kitware.com> <355BE46A91031048906B695426A8D8E616ACE698@DEFTHW99EH4MSX.ww902.siemens.net> <540730D6.80101@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACE705@DEFTHW99EH4MSX.ww902.siemens.net> > >> Let's use a name specific to WindowsCE like "CMAKE_VS_WINCE_SDK", > > > > I'm not sure this is really Windows CE specific. There is already > > an internal variable CMAKE_VS_PLATFORM_NAME that is set to Win32, > > Win64, ARM etc. This is also the variable that gets set to the SDK > > name. Currently this variable is set based on the Generator used, > > but there is also some other magic going on for example for Itanium. > > The fact that the PlatformName corresponds to an SDK is specific to > WinCE tools. Other platforms may not have such correspondence. > This is why I want to use a WinCE-specific name at first. We can > generalize the name before merging the changes if it makes sense > when its role becomes clear. Ok I understand your reasoning, makes sense. > > Would it be desirable to be able to override this value independent > > of the generator used? > > I'm not sure what this would mean because the value is for a > specific field in VS project files. What I meant is that is you use the generator "Visual Studio 12 (2013) ARM" but set the CMAKE_VS_PLATFORM_NAME="Win64" It would compile for Win64 not arm (like calling "Visual Studio 12 (2013) Win64"), so we just override it with whatever the user provides. > > Based on your explanation and my findings above, the > > CMAKE_VS_PLATFORM_NAME variable should behave analogues to > > CMAKE_VS_PLATFORM_TOOLSET but I can't come up with a good > > name for a variable the user should set. > > Yes. What I'm saying is the fact that a user can select this > at all might be WinCE-specific. Hence a WinCE-specific name. > For my first attempt I will just stick with allowing the user overriding CMAKE_VS_PLATFORM_NAME. Pascal From brad.king at kitware.com Wed Sep 3 11:47:55 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 11:47:55 -0400 Subject: [cmake-developers] VS 2013 WindowsCE support In-Reply-To: <355BE46A91031048906B695426A8D8E616ACE705@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> <5405EA2D.4070801@kitware.com> <355BE46A91031048906B695426A8D8E616ACE504@DEFTHW99EH4MSX.ww902.siemens.net> <5407191A.8070706@kitware.com> <355BE46A91031048906B695426A8D8E616ACE698@DEFTHW99EH4MSX.ww902.siemens.net> <540730D6.80101@kitware.com> <355BE46A91031048906B695426A8D8E616ACE705@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <5407382B.1090702@kitware.com> On 09/03/2014 11:36 AM, Bach, Pascal wrote: > What I meant is that is you use the generator "Visual Studio 12 (2013) ARM" but set the CMAKE_VS_PLATFORM_NAME="Win64" > It would compile for Win64 not arm (like calling "Visual Studio 12 (2013) Win64"), so we just override it with whatever the user provides. I think it should be an error in that case. We should only allow the platform to be set by a variable if it is not part of the generator name. Putting it in the generator name is a way of specifying the value, so we should not support conflicting specifications. Thanks, -Brad From neundorf at kde.org Wed Sep 3 11:48:28 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Wed, 03 Sep 2014 17:48:28 +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> Message-ID: <22742143.8V0LQmVuST@tuxedo.neundorf.net> On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote: > On Tue, Sep 2, 2014 at 3:58 PM, David Cole wrote: > > It makes sense. But what IDE are you referring to? Eclipse? Some other > > concrete example? Or just "any IDE and this feature should work everywhere > > CMake works...?" > > I'm working on KDevelop, I know for a fact though, that other IDEs are > looking for something similar too, such as QtCreator. I still don't understand why this shouldn't be an additional ExtraGenerator. It will generate a special file intended to be used by KDevelop and maybe QtCreator additionally to makefiles/ninja files. Could be called "GenericJSON" or so. Other IDEs which don't support this file type but which need their own project file obviously still need their own specific generator. Alex From aleixpol at kde.org Wed Sep 3 12:12:34 2014 From: aleixpol at kde.org (Aleix Pol) Date: Wed, 3 Sep 2014 18:12:34 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <22742143.8V0LQmVuST@tuxedo.neundorf.net> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> <22742143.8V0LQmVuST@tuxedo.neundorf.net> Message-ID: On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf wrote: > On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote: > > On Tue, Sep 2, 2014 at 3:58 PM, David Cole wrote: > > > It makes sense. But what IDE are you referring to? Eclipse? Some other > > > concrete example? Or just "any IDE and this feature should work > everywhere > > > CMake works...?" > > > > I'm working on KDevelop, I know for a fact though, that other IDEs are > > looking for something similar too, such as QtCreator. > > I still don't understand why this shouldn't be an additional > ExtraGenerator. > It will generate a special file intended to be used by KDevelop and maybe > QtCreator additionally to makefiles/ninja files. Could be called > "GenericJSON" > or so. > Other IDEs which don't support this file type but which need their own > project > file obviously still need their own specific generator. > > Alex > Because it's not possible to change the generator of a build directory once it's set up. You need to nuke it and re-create it. Also because changing the generator could potentially change the interaction the user has with the build directory, we don't want to get in the way. Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascal.bach at siemens.com Wed Sep 3 13:16:11 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Wed, 3 Sep 2014 19:16:11 +0200 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio Message-ID: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> Set CMAKE_VS_WINCE_SDK to specify the SDK. --- Source/cmGlobalVisualStudio10Generator.cxx | 48 ++++++++++++++++++++++++++++ Source/cmGlobalVisualStudio10Generator.h | 7 ++++ Source/cmGlobalVisualStudio11Generator.cxx | 12 +++++++ Source/cmGlobalVisualStudio11Generator.h | 2 ++ Source/cmGlobalVisualStudio12Generator.cxx | 12 +++++++ Source/cmGlobalVisualStudio12Generator.h | 2 ++ 6 files changed, 83 insertions(+) diff --git a/Source/cmGlobalVisualStudio10Generator.cxx b/Source/cmGlobalVisualStudio10Generator.cxx index 19aa52c..5c1fd4b 100644 --- a/Source/cmGlobalVisualStudio10Generator.cxx +++ b/Source/cmGlobalVisualStudio10Generator.cxx @@ -165,6 +165,14 @@ bool cmGlobalVisualStudio10Generator::InitializeSystem(cmMakefile* mf) return false; } } + else if (this->SystemName == "WindowsCE") + { + this->SystemIsWindowsCE = true; + if (!this->InitializeWindowsCE(mf)) + { + return false; + } + } return true; } @@ -187,6 +195,46 @@ bool cmGlobalVisualStudio10Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio10Generator::InitializeWindowsCE(cmMakefile* mf) +{ + this->DefaultPlatformToolset = this->SelectWindowsCEToolset(); + if (this->DefaultPlatformToolset.empty()) + { + cmOStringStream e; + e << this->GetName() << " supports Windows CE '8.0', but not '" + << this->SystemVersion << "'. Check CMAKE_SYSTEM_VERSION."; + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); + return false; + } + + if (const char* platformName = mf->GetDefinition("CMAKE_VS_WINCE_SDK")) + { + this->PlatformName = platformName; + } + else { + cmOStringStream e; + e << this->GetName() << " for " << this->GetSystemName() << " requires an SDK. Please set CMAKE_VS_WINCE_SDK to the name of your SDK."; + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); + return false; + } + + return true; +} + +//---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio10Generator::SelectWindowsCEToolset() const +{ + if (this->SystemVersion == "8.0") + { + return "CE800"; + } + else + { + return ""; + } +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio10Generator ::AddVSPlatformToolsetDefinition(cmMakefile* mf) const { diff --git a/Source/cmGlobalVisualStudio10Generator.h b/Source/cmGlobalVisualStudio10Generator.h index 11fa954..9bceb2c 100644 --- a/Source/cmGlobalVisualStudio10Generator.h +++ b/Source/cmGlobalVisualStudio10Generator.h @@ -75,6 +75,10 @@ public: bool TargetsWindowsStore() const { return this->SystemIsWindowsStore; } + /** Return true if building for WindowsCE */ + bool TargetsWindowsCE() const + { return this->SystemIsWindowsCE; } + /** * Where does this version of Visual Studio look for macros for the * current user? Returns the empty string if this version of Visual @@ -106,8 +110,10 @@ protected: virtual bool InitializeSystem(cmMakefile* mf); virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const { return ""; } virtual std::string SelectWindowsStoreToolset() const { return ""; } + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "10.0"; } @@ -119,6 +125,7 @@ protected: std::string SystemVersion; bool SystemIsWindowsPhone; bool SystemIsWindowsStore; + bool SystemIsWindowsCE; bool ExpressEdition; bool UseFolderProperty(); diff --git a/Source/cmGlobalVisualStudio11Generator.cxx b/Source/cmGlobalVisualStudio11Generator.cxx index 39bbdc0..a71c42e 100644 --- a/Source/cmGlobalVisualStudio11Generator.cxx +++ b/Source/cmGlobalVisualStudio11Generator.cxx @@ -159,6 +159,12 @@ bool cmGlobalVisualStudio11Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio11Generator::InitializeWindowsCE(cmMakefile* mf) +{ + return cmGlobalVisualStudio10Generator::InitializeWindowsCE(mf); +} + +//---------------------------------------------------------------------------- std::string cmGlobalVisualStudio11Generator::SelectWindowsPhoneToolset() const { if(this->SystemVersion == "8.0") @@ -179,6 +185,12 @@ std::string cmGlobalVisualStudio11Generator::SelectWindowsStoreToolset() const } //---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio11Generator::SelectWindowsCEToolset() const +{ + return this->cmGlobalVisualStudio10Generator::SelectWindowsCEToolset(); +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio11Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; diff --git a/Source/cmGlobalVisualStudio11Generator.h b/Source/cmGlobalVisualStudio11Generator.h index bbd935c..9dd3271 100644 --- a/Source/cmGlobalVisualStudio11Generator.h +++ b/Source/cmGlobalVisualStudio11Generator.h @@ -36,8 +36,10 @@ public: protected: virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const; virtual std::string SelectWindowsStoreToolset() const; + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "11.0"; } bool UseFolderProperty(); static std::set GetInstalledWindowsCESDKs(); diff --git a/Source/cmGlobalVisualStudio12Generator.cxx b/Source/cmGlobalVisualStudio12Generator.cxx index 29ecfe0..c784cae 100644 --- a/Source/cmGlobalVisualStudio12Generator.cxx +++ b/Source/cmGlobalVisualStudio12Generator.cxx @@ -139,6 +139,12 @@ bool cmGlobalVisualStudio12Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio12Generator::InitializeWindowsCE(cmMakefile* mf) +{ + return cmGlobalVisualStudio11Generator::InitializeWindowsCE(mf); +} + +//---------------------------------------------------------------------------- std::string cmGlobalVisualStudio12Generator::SelectWindowsPhoneToolset() const { if(this->SystemVersion == "8.1") @@ -159,6 +165,12 @@ std::string cmGlobalVisualStudio12Generator::SelectWindowsStoreToolset() const } //---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio12Generator::SelectWindowsCEToolset() const +{ + return this->cmGlobalVisualStudio11Generator::SelectWindowsCEToolset(); +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio12Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; diff --git a/Source/cmGlobalVisualStudio12Generator.h b/Source/cmGlobalVisualStudio12Generator.h index ec85f10..5d8c125 100644 --- a/Source/cmGlobalVisualStudio12Generator.h +++ b/Source/cmGlobalVisualStudio12Generator.h @@ -41,8 +41,10 @@ public: protected: virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const; virtual std::string SelectWindowsStoreToolset() const; + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "12.0"; } private: class Factory; -- 1.7.10.4 From pascal.bach at siemens.com Wed Sep 3 13:21:15 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Wed, 3 Sep 2014 17:21:15 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> Looks like I missed the Description :( This is only a first draft and I would like to hear if I am on the right track. The patch implements the SDK selection for Windows CE. If CMAKE_SYSTEM_NAME="WindowsCE" the user has to specify an SDK using the variable: CMAKE_VS_WINCE_SDK The implementation is inspired by WindowsPhone and WindowsStore. Current limitations: - Only works with Windows CE 8.0 Pascal > -----Original Message----- > From: Pascal Bach [mailto:pascal.bach at siemens.com] > Sent: Mittwoch, 3. September 2014 19:16 > To: cmake-developers at cmake.org > Cc: Bach, Pascal > Subject: [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on > Visual Studio > > Set CMAKE_VS_WINCE_SDK to specify the SDK. > --- > Source/cmGlobalVisualStudio10Generator.cxx | 48 > ++++++++++++++++++++++++++++ > Source/cmGlobalVisualStudio10Generator.h | 7 ++++ > Source/cmGlobalVisualStudio11Generator.cxx | 12 +++++++ > Source/cmGlobalVisualStudio11Generator.h | 2 ++ > Source/cmGlobalVisualStudio12Generator.cxx | 12 +++++++ > Source/cmGlobalVisualStudio12Generator.h | 2 ++ > 6 files changed, 83 insertions(+) > > diff --git a/Source/cmGlobalVisualStudio10Generator.cxx > b/Source/cmGlobalVisualStudio10Generator.cxx > index 19aa52c..5c1fd4b 100644 > --- a/Source/cmGlobalVisualStudio10Generator.cxx > +++ b/Source/cmGlobalVisualStudio10Generator.cxx > @@ -165,6 +165,14 @@ bool > cmGlobalVisualStudio10Generator::InitializeSystem(cmMakefile* mf) > return false; > } > } > + else if (this->SystemName == "WindowsCE") > + { > + this->SystemIsWindowsCE = true; > + if (!this->InitializeWindowsCE(mf)) > + { > + return false; > + } > + } > return true; > } > > @@ -187,6 +195,46 @@ bool > cmGlobalVisualStudio10Generator::InitializeWindowsStore(cmMakefile* mf) > } > > //---------------------------------------------------------------------------- > +bool cmGlobalVisualStudio10Generator::InitializeWindowsCE(cmMakefile* > mf) > +{ > + this->DefaultPlatformToolset = this->SelectWindowsCEToolset(); > + if (this->DefaultPlatformToolset.empty()) > + { > + cmOStringStream e; > + e << this->GetName() << " supports Windows CE '8.0', but not '" > + << this->SystemVersion << "'. Check CMAKE_SYSTEM_VERSION."; > + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); > + return false; > + } > + > + if (const char* platformName = mf- > >GetDefinition("CMAKE_VS_WINCE_SDK")) > + { > + this->PlatformName = platformName; > + } > + else { > + cmOStringStream e; > + e << this->GetName() << " for " << this->GetSystemName() << " requires > an SDK. Please set CMAKE_VS_WINCE_SDK to the name of your SDK."; > + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); > + return false; > + } > + > + return true; > +} > + > +//---------------------------------------------------------------------------- > +std::string cmGlobalVisualStudio10Generator::SelectWindowsCEToolset() > const > +{ > + if (this->SystemVersion == "8.0") > + { > + return "CE800"; > + } > + else > + { > + return ""; > + } > +} > + > +//---------------------------------------------------------------------------- > void cmGlobalVisualStudio10Generator > ::AddVSPlatformToolsetDefinition(cmMakefile* mf) const > { > diff --git a/Source/cmGlobalVisualStudio10Generator.h > b/Source/cmGlobalVisualStudio10Generator.h > index 11fa954..9bceb2c 100644 > --- a/Source/cmGlobalVisualStudio10Generator.h > +++ b/Source/cmGlobalVisualStudio10Generator.h > @@ -75,6 +75,10 @@ public: > bool TargetsWindowsStore() const > { return this->SystemIsWindowsStore; } > > + /** Return true if building for WindowsCE */ > + bool TargetsWindowsCE() const > + { return this->SystemIsWindowsCE; } > + > /** > * Where does this version of Visual Studio look for macros for the > * current user? Returns the empty string if this version of Visual > @@ -106,8 +110,10 @@ protected: > virtual bool InitializeSystem(cmMakefile* mf); > virtual bool InitializeWindowsPhone(cmMakefile* mf); > virtual bool InitializeWindowsStore(cmMakefile* mf); > + virtual bool InitializeWindowsCE(cmMakefile* mf); > virtual std::string SelectWindowsPhoneToolset() const { return ""; } > virtual std::string SelectWindowsStoreToolset() const { return ""; } > + virtual std::string SelectWindowsCEToolset() const; > > virtual const char* GetIDEVersion() { return "10.0"; } > > @@ -119,6 +125,7 @@ protected: > std::string SystemVersion; > bool SystemIsWindowsPhone; > bool SystemIsWindowsStore; > + bool SystemIsWindowsCE; > bool ExpressEdition; > > bool UseFolderProperty(); > diff --git a/Source/cmGlobalVisualStudio11Generator.cxx > b/Source/cmGlobalVisualStudio11Generator.cxx > index 39bbdc0..a71c42e 100644 > --- a/Source/cmGlobalVisualStudio11Generator.cxx > +++ b/Source/cmGlobalVisualStudio11Generator.cxx > @@ -159,6 +159,12 @@ bool > cmGlobalVisualStudio11Generator::InitializeWindowsStore(cmMakefile* mf) > } > > //---------------------------------------------------------------------------- > +bool cmGlobalVisualStudio11Generator::InitializeWindowsCE(cmMakefile* > mf) > +{ > + return cmGlobalVisualStudio10Generator::InitializeWindowsCE(mf); > +} > + > +//---------------------------------------------------------------------------- > std::string > cmGlobalVisualStudio11Generator::SelectWindowsPhoneToolset() const > { > if(this->SystemVersion == "8.0") > @@ -179,6 +185,12 @@ std::string > cmGlobalVisualStudio11Generator::SelectWindowsStoreToolset() const > } > > //---------------------------------------------------------------------------- > +std::string cmGlobalVisualStudio11Generator::SelectWindowsCEToolset() > const > +{ > + return this- > >cmGlobalVisualStudio10Generator::SelectWindowsCEToolset(); > +} > + > +//---------------------------------------------------------------------------- > void cmGlobalVisualStudio11Generator::WriteSLNHeader(std::ostream& > fout) > { > fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; > diff --git a/Source/cmGlobalVisualStudio11Generator.h > b/Source/cmGlobalVisualStudio11Generator.h > index bbd935c..9dd3271 100644 > --- a/Source/cmGlobalVisualStudio11Generator.h > +++ b/Source/cmGlobalVisualStudio11Generator.h > @@ -36,8 +36,10 @@ public: > protected: > virtual bool InitializeWindowsPhone(cmMakefile* mf); > virtual bool InitializeWindowsStore(cmMakefile* mf); > + virtual bool InitializeWindowsCE(cmMakefile* mf); > virtual std::string SelectWindowsPhoneToolset() const; > virtual std::string SelectWindowsStoreToolset() const; > + virtual std::string SelectWindowsCEToolset() const; > virtual const char* GetIDEVersion() { return "11.0"; } > bool UseFolderProperty(); > static std::set GetInstalledWindowsCESDKs(); > diff --git a/Source/cmGlobalVisualStudio12Generator.cxx > b/Source/cmGlobalVisualStudio12Generator.cxx > index 29ecfe0..c784cae 100644 > --- a/Source/cmGlobalVisualStudio12Generator.cxx > +++ b/Source/cmGlobalVisualStudio12Generator.cxx > @@ -139,6 +139,12 @@ bool > cmGlobalVisualStudio12Generator::InitializeWindowsStore(cmMakefile* mf) > } > > //---------------------------------------------------------------------------- > +bool cmGlobalVisualStudio12Generator::InitializeWindowsCE(cmMakefile* > mf) > +{ > + return cmGlobalVisualStudio11Generator::InitializeWindowsCE(mf); > +} > + > +//---------------------------------------------------------------------------- > std::string > cmGlobalVisualStudio12Generator::SelectWindowsPhoneToolset() const > { > if(this->SystemVersion == "8.1") > @@ -159,6 +165,12 @@ std::string > cmGlobalVisualStudio12Generator::SelectWindowsStoreToolset() const > } > > //---------------------------------------------------------------------------- > +std::string cmGlobalVisualStudio12Generator::SelectWindowsCEToolset() > const > +{ > + return this- > >cmGlobalVisualStudio11Generator::SelectWindowsCEToolset(); > +} > + > +//---------------------------------------------------------------------------- > void cmGlobalVisualStudio12Generator::WriteSLNHeader(std::ostream& > fout) > { > fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; > diff --git a/Source/cmGlobalVisualStudio12Generator.h > b/Source/cmGlobalVisualStudio12Generator.h > index ec85f10..5d8c125 100644 > --- a/Source/cmGlobalVisualStudio12Generator.h > +++ b/Source/cmGlobalVisualStudio12Generator.h > @@ -41,8 +41,10 @@ public: > protected: > virtual bool InitializeWindowsPhone(cmMakefile* mf); > virtual bool InitializeWindowsStore(cmMakefile* mf); > + virtual bool InitializeWindowsCE(cmMakefile* mf); > virtual std::string SelectWindowsPhoneToolset() const; > virtual std::string SelectWindowsStoreToolset() const; > + virtual std::string SelectWindowsCEToolset() const; > virtual const char* GetIDEVersion() { return "12.0"; } > private: > class Factory; > -- > 1.7.10.4 From brad.king at kitware.com Wed Sep 3 14:12:57 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 14:12:57 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <54075A29.1030002@kitware.com> On 09/03/2014 01:21 PM, Bach, Pascal wrote: > This is only a first draft and I would like to hear if I am on the right track. Yes, it looks good so far. > + else if (this->SystemName == "WindowsCE") > + { > + this->SystemIsWindowsCE = true; > + if (!this->InitializeWindowsCE(mf)) At the beginning of this block you should check/reject when the generator name specified a platform name. Something like: if(this->PlatformName != "Win32") { cmOStringStream e; e << "CMAKE_SYSTEM_NAME is 'WindowsCE' but CMAKE_GENERATOR " << "specifies a platform too: '" << this->GetName() << "'"; mf->IssueMessage(cmake::FATAL_ERROR, e.str()); return false; } Thanks, -Brad From joubert.sy at gmail.com Wed Sep 3 14:44:39 2014 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Wed, 03 Sep 2014 20:44:39 +0200 Subject: [cmake-developers] [patch] Bash completion for label options of ctest Message-ID: <54076197.8070802@gmail.com> Hi, Please find attached a patch that updates the bash completion of ctest. It will now be able to complete the -L,-LE options and their long versions. Regards, Sylvain -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-bash-completion-for-label-options-of-ctest.patch Type: text/x-patch Size: 1132 bytes Desc: not available URL: From brad.king at kitware.com Wed Sep 3 14:58:30 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 14:58:30 -0400 Subject: [cmake-developers] [patch] Bash completion for label options of ctest In-Reply-To: <54076197.8070802@gmail.com> References: <54076197.8070802@gmail.com> Message-ID: <540764D6.7080009@kitware.com> On 09/03/2014 02:44 PM, Sylvain Joubert wrote: > Please find attached a patch that updates the bash completion of ctest. Applied, thanks: bash-completion: Complete 'ctest' label names http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2603e128 -Brad From hobbes1069 at gmail.com Wed Sep 3 16:12:07 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Wed, 3 Sep 2014 15:12:07 -0500 Subject: [cmake-developers] Best practice for determining if a static library was found and other issues with FindFLTK.cmake In-Reply-To: <54072183.5090804@kitware.com> References: <54072183.5090804@kitware.com> Message-ID: On Wed, Sep 3, 2014 at 9:11 AM, Brad King wrote: > On 09/03/2014 09:48 AM, Richard Shaw wrote: > > The module has several issues but a major one is that it doesn't add > > the required linker flags when using static libraries instead of shared. > > > > It also doesn't check for any required C flags but that's a lesser issue. > > > > These may only be a problem for the autotools based fltk build > > as the module uses a ConfigFLTK for CMake based builds. > > If FLTK upstream is willing to provide FTLKConfig for CMake-based > builds then they may be willing to support providing one from > autotools-based builds too. It is not very hard to provide one > from a non-CMake build system. Qt5 and LLVM both do it. You > could go work with the FLTK devs to do it there too. Then we > won't even need a FindFLTK in CMake except for compatibility. > I did a cmake based build for cross-compiling for win32 on Fedora because the autotools was going to be WAY too much work to get working with the rpmbuild mingw macros and took a look at the generated cmake files. It looks like it uses a bunch of imported targets rather than utilizing find_library... I'm not familiar with this method so would you just use an "include(FLTKConfig)" instead of find_library/find_package? And then I would add the imported targets to target_link_libraries? > ^^^ Is this the best way to determine if the library found was > > static or shared? ^^^ > > It is not possible in general without platform-specific knowledge. > On AIX even an archive (.a) can be a shared library, for example. > On Windows a .dll's import library (.lib) looks just like a static > library (.lib). Ideally information provided with the FLTK package > should tell us. > Hmm... no good answer here. Another reason to move away from the autotools build... more below. > > > So a broader question... Should we trust the output of a config > > program, in this case, fltk-config? The writer of the module > > certainly doesn't. They used the fltk-config program to find > > the base library, strip off the path portion and then used it > > as a search path to find the libraries independently. > > Of course the output of fltk-config should be trusted to be > correct, but the info still needs to be transformed into what > CMake wants. That is usually more granular than strings of > command-line flags for various tools, so some parsing/searching > may be needed. > Well, after a bit more research I see why he didn't trust the output of fltk-config. I only have the shared libraries on my fedora system but if I run "fltk-config --libs" the output shows a static library: $ fltk-config --libs /usr/lib64/libfltk.a > I would like to update the module to use COMPONENTS, but the > > current default is to find everything unless a "FLTK_SKIP_..." > > variable is set so I assume there's a good way to keep > > backward compatibility. > > The FindFLTK module was added way back in the beginning of CMake > and has never really been modernized. The SKIP variables may > even predate the COMPONENTS support in find_package. > Ahh... Is it possible to support that now as long as if the user doesn't specify COMPONENTS that it emulates the old behavior and tries to find everything? Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Wed Sep 3 16:23:44 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 03 Sep 2014 22:23:44 +0200 Subject: [cmake-developers] Best practice for determining if a static library was found and other issues with FindFLTK.cmake In-Reply-To: References: <54072183.5090804@kitware.com> Message-ID: <540778D0.2080603@gmail.com> On 03.09.2014 22:12, Richard Shaw wrote: > > I did a cmake based build for cross-compiling for win32 on Fedora > because the autotools was going to be WAY too much work to get working > with the rpmbuild mingw macros and took a look at the generated cmake > files. > > It looks like it uses a bunch of imported targets rather than > utilizing find_library... I'm not familiar with this method so would > you just use an "include(FLTKConfig)" instead of > find_library/find_package? And then I would add the imported targets > to target_link_libraries? You would use e.g. find_package(FLTK CONFIG). Or find_package(FLTK) if there is no FindFLTK.cmake or if FindFLTK.cmake itself looks for the package in config mode as well. For reference on packages: http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html And find_package() module and config modes: http://www.cmake.org/cmake/help/v3.0/command/find_package.html Nils From chuck.atkins at kitware.com Wed Sep 3 17:20:01 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 3 Sep 2014 17:20:01 -0400 Subject: [cmake-developers] Changing the regex used for INFO strings Message-ID: stage/use-consistent-regex-for-info-strings The change seems minor enough but the impact if it breaks something is substantial so I wanted to get a second set of eyes on this. I set out to fix the non-working ABI detection for craycc and crayCC, which turned out was because the cray compiler will often generate *lots* of "INFO:" strings itself, which were getting through the strings regex. Since all binary info strings that CMake extracts for system and compiler info should have the same format, it seemed appropriate to have a consistent regex used in all the various places that INFO: strings are extracted from compiled binaries. - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Wed Sep 3 18:30:00 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 3 Sep 2014 18:30:00 -0400 Subject: [cmake-developers] [CMake 0015128]: FindProtobuf issues Message-ID: <357614e15937f285f21c90acde92a76c@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15128 ====================================================================== Reported By: Orion E. Poplawski Assigned To: ====================================================================== Project: CMake Issue ID: 15128 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-03 18:29 EDT Last Modified: 2014-09-03 18:30 EDT ====================================================================== Summary: FindProtobuf issues Description: For the Fedora package build of ParaView, we need to use system libraries. I have been patching ParaView to use the system protobuf library (see http://www.paraview.org/Bug/view.php?id=13656) for a while now and am updating to 4.2RC1. With that I am now seeing issues with the interaction with the cmake FindProtobuf module, due to the fact that it uses the optimize/debug list convention and add -lpthread to PROTOBUF_LIBRARIES. Part of the issue is the way it looks for a debug library: find_library(${name}_LIBRARY NAMES ${filename} PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/Release) mark_as_advanced(${name}_LIBRARY) find_library(${name}_LIBRARY_DEBUG NAMES ${filename} PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/Debug) mark_as_advanced(${name}_LIBRARY_DEBUG) On Linux/Unix this generally finds the same library in the same path. Changing to: find_library(${name}_LIBRARY_DEBUG NAMES ${filename} PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/Debug NO_DEFAULT_PATH) mark_as_advanced(${name}_LIBRARY_DEBUG) helps with that. I'm not sure what to do with the addition of -lphtreads. Simply removing it may be the way to go. The paraview protobuf cmake configuration seems to add it to protobuf_LIB_DEPS. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-03 18:29 Orion E. PoplawskiNew Issue 2014-09-03 18:30 Orion E. PoplawskiFile Added: cmake-FindProtobuf.patch ====================================================================== From dlrdave at aol.com Wed Sep 3 21:27:25 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 3 Sep 2014 21:27:25 -0400 Subject: [cmake-developers] Changing the regex used for INFO strings In-Reply-To: References: Message-ID: <8D195F6846C8B49-15CC-FF14@webmail-m269.sysops.aol.com> Looks good to me. Why not merge it to 'next' for testing? Worst case, you can also revert it and merge again... D From pascal.bach at siemens.com Thu Sep 4 06:42:56 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Thu, 4 Sep 2014 10:42:56 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <54075A29.1030002@kitware.com> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> > > + else if (this->SystemName == "WindowsCE") > > + { > > + this->SystemIsWindowsCE = true; > > + if (!this->InitializeWindowsCE(mf)) > > At the beginning of this block you should check/reject when > the generator name specified a platform name. Something like: > > if(this->PlatformName != "Win32") > { > cmOStringStream e; > e << "CMAKE_SYSTEM_NAME is 'WindowsCE' but CMAKE_GENERATOR " > << "specifies a platform too: '" << this->GetName() << "'"; > mf->IssueMessage(cmake::FATAL_ERROR, e.str()); > return false; > } > This won't' work as the code gets called multiple times during a project generation, but only the first time it is set to Win32. So the code will fail the second time. I need to put the code somewhere earlier in the initialization but don't know yet where. I will submit an updated version soon. Pascal From pascal.bach at siemens.com Thu Sep 4 07:40:40 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Thu, 4 Sep 2014 13:40:40 +0200 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio Message-ID: <1409830840-3288-1-git-send-email-pascal.bach@siemens.com> - Allow setting CMAKE_VS_WINCE_SDK to specify the SDK. - The user is warned if he uses a version different Windows CE different from 8.0 and not CMAKE_PLATFORM_TOOLSET is specified. - Docuentation for WINCE and CMAKE_VS_WINCE_SDK added. --- Help/variable/CMAKE_VS_WINCE_SDK.rst | 13 +++++++ Help/variable/WINCE.rst | 5 +++ Source/cmGlobalVisualStudio10Generator.cxx | 55 ++++++++++++++++++++++++++++ Source/cmGlobalVisualStudio10Generator.h | 7 ++++ Source/cmGlobalVisualStudio11Generator.cxx | 12 ++++++ Source/cmGlobalVisualStudio11Generator.h | 2 + Source/cmGlobalVisualStudio12Generator.cxx | 12 ++++++ Source/cmGlobalVisualStudio12Generator.h | 2 + 8 files changed, 108 insertions(+) create mode 100644 Help/variable/CMAKE_VS_WINCE_SDK.rst create mode 100644 Help/variable/WINCE.rst diff --git a/Help/variable/CMAKE_VS_WINCE_SDK.rst b/Help/variable/CMAKE_VS_WINCE_SDK.rst new file mode 100644 index 0000000..ef39b84 --- /dev/null +++ b/Help/variable/CMAKE_VS_WINCE_SDK.rst @@ -0,0 +1,13 @@ +CMAKE_VS_WINCE_SDK +------------------ + +Windows CE SDK to use together with the Visual Studio 10+ generators. + +If :variable:`CMAKE_SYSTEM_NAME` is set to Windows CE, this variable +allows to specify the SDK name that should be used to build the application. + +The value of this variable should never be modified by project code. +A toolchain file specified by the :variable:`CMAKE_TOOLCHAIN_FILE` +variable may initialize ``CMAKE_VS_WINCE_SDK``. Once a given +build tree has been initialized with a particular value for this +variable, changing the value has undefined behavior. diff --git a/Help/variable/WINCE.rst b/Help/variable/WINCE.rst new file mode 100644 index 0000000..54ff7de --- /dev/null +++ b/Help/variable/WINCE.rst @@ -0,0 +1,5 @@ +WINCE +----- + +True when the :variable:`CMAKE_SYSTEM_NAME` variable is set +to ``WindowsCE``. diff --git a/Source/cmGlobalVisualStudio10Generator.cxx b/Source/cmGlobalVisualStudio10Generator.cxx index 19aa52c..81a9723 100644 --- a/Source/cmGlobalVisualStudio10Generator.cxx +++ b/Source/cmGlobalVisualStudio10Generator.cxx @@ -165,6 +165,14 @@ bool cmGlobalVisualStudio10Generator::InitializeSystem(cmMakefile* mf) return false; } } + else if (this->SystemName == "WindowsCE") + { + this->SystemIsWindowsCE = true; + if (!this->InitializeWindowsCE(mf)) + { + return false; + } + } return true; } @@ -187,6 +195,53 @@ bool cmGlobalVisualStudio10Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio10Generator::InitializeWindowsCE(cmMakefile* mf) +{ + // To preserve the old behaviour just return the DefaultPlatformToolset + // for unknown Windows CE versions, in the worst case the user has to set + // CMAKE_GENERATOR_TOOLSET manually. In that case warn the user. + std::string platformToolset = this->SelectWindowsCEToolset(); + if (!platformToolset.empty()) + { + this->DefaultPlatformToolset = platformToolset; + } + else + { + cmOStringStream e; + e << this->GetName() << " Windows CE version '" << this->SystemVersion + << "' might require CMAKE_GENERATOR_TOOLSET to be set."; + mf->IssueMessage(cmake::WARNING, e.str()); + } + + if (const char* platformName = mf->GetDefinition("CMAKE_VS_WINCE_SDK")) + { + this->PlatformName = platformName; + } + else { + cmOStringStream e; + e << this->GetName() << " for " << this->GetSystemName() << " requires an " + << "SDK. Please set CMAKE_VS_WINCE_SDK to the name of your SDK."; + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); + return false; + } + + return true; +} + +//---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio10Generator::SelectWindowsCEToolset() const +{ + if (this->SystemVersion == "8.0") + { + return "CE800"; + } + else + { + return ""; + } +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio10Generator ::AddVSPlatformToolsetDefinition(cmMakefile* mf) const { diff --git a/Source/cmGlobalVisualStudio10Generator.h b/Source/cmGlobalVisualStudio10Generator.h index 11fa954..9bceb2c 100644 --- a/Source/cmGlobalVisualStudio10Generator.h +++ b/Source/cmGlobalVisualStudio10Generator.h @@ -75,6 +75,10 @@ public: bool TargetsWindowsStore() const { return this->SystemIsWindowsStore; } + /** Return true if building for WindowsCE */ + bool TargetsWindowsCE() const + { return this->SystemIsWindowsCE; } + /** * Where does this version of Visual Studio look for macros for the * current user? Returns the empty string if this version of Visual @@ -106,8 +110,10 @@ protected: virtual bool InitializeSystem(cmMakefile* mf); virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const { return ""; } virtual std::string SelectWindowsStoreToolset() const { return ""; } + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "10.0"; } @@ -119,6 +125,7 @@ protected: std::string SystemVersion; bool SystemIsWindowsPhone; bool SystemIsWindowsStore; + bool SystemIsWindowsCE; bool ExpressEdition; bool UseFolderProperty(); diff --git a/Source/cmGlobalVisualStudio11Generator.cxx b/Source/cmGlobalVisualStudio11Generator.cxx index 39bbdc0..a71c42e 100644 --- a/Source/cmGlobalVisualStudio11Generator.cxx +++ b/Source/cmGlobalVisualStudio11Generator.cxx @@ -159,6 +159,12 @@ bool cmGlobalVisualStudio11Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio11Generator::InitializeWindowsCE(cmMakefile* mf) +{ + return cmGlobalVisualStudio10Generator::InitializeWindowsCE(mf); +} + +//---------------------------------------------------------------------------- std::string cmGlobalVisualStudio11Generator::SelectWindowsPhoneToolset() const { if(this->SystemVersion == "8.0") @@ -179,6 +185,12 @@ std::string cmGlobalVisualStudio11Generator::SelectWindowsStoreToolset() const } //---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio11Generator::SelectWindowsCEToolset() const +{ + return this->cmGlobalVisualStudio10Generator::SelectWindowsCEToolset(); +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio11Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; diff --git a/Source/cmGlobalVisualStudio11Generator.h b/Source/cmGlobalVisualStudio11Generator.h index bbd935c..9dd3271 100644 --- a/Source/cmGlobalVisualStudio11Generator.h +++ b/Source/cmGlobalVisualStudio11Generator.h @@ -36,8 +36,10 @@ public: protected: virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const; virtual std::string SelectWindowsStoreToolset() const; + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "11.0"; } bool UseFolderProperty(); static std::set GetInstalledWindowsCESDKs(); diff --git a/Source/cmGlobalVisualStudio12Generator.cxx b/Source/cmGlobalVisualStudio12Generator.cxx index 29ecfe0..c784cae 100644 --- a/Source/cmGlobalVisualStudio12Generator.cxx +++ b/Source/cmGlobalVisualStudio12Generator.cxx @@ -139,6 +139,12 @@ bool cmGlobalVisualStudio12Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio12Generator::InitializeWindowsCE(cmMakefile* mf) +{ + return cmGlobalVisualStudio11Generator::InitializeWindowsCE(mf); +} + +//---------------------------------------------------------------------------- std::string cmGlobalVisualStudio12Generator::SelectWindowsPhoneToolset() const { if(this->SystemVersion == "8.1") @@ -159,6 +165,12 @@ std::string cmGlobalVisualStudio12Generator::SelectWindowsStoreToolset() const } //---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio12Generator::SelectWindowsCEToolset() const +{ + return this->cmGlobalVisualStudio11Generator::SelectWindowsCEToolset(); +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio12Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; diff --git a/Source/cmGlobalVisualStudio12Generator.h b/Source/cmGlobalVisualStudio12Generator.h index ec85f10..5d8c125 100644 --- a/Source/cmGlobalVisualStudio12Generator.h +++ b/Source/cmGlobalVisualStudio12Generator.h @@ -41,8 +41,10 @@ public: protected: virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const; virtual std::string SelectWindowsStoreToolset() const; + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "12.0"; } private: class Factory; -- 1.7.10.4 From ono at java.pl Thu Sep 4 09:11:41 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 15:11:41 +0200 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup Message-ID: <1409836306-96543-1-git-send-email-ono@java.pl> It makes whole executable process quicker on UNIX, especially for large bundles containing many files, since using find narrows results to only files having executable flags then all further tests follow. --- Modules/BundleUtilities.cmake | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 0046c97..7e2b173 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -378,7 +378,24 @@ endfunction() function(get_bundle_all_executables bundle exes_var) set(exes "") - file(GLOB_RECURSE file_list "${bundle}/*") + if(UNIX) + find_program(find_cmd "find") + mark_as_advanced(find_cmd) + endif() + + # find command is much quicker than checking every file one by one on Unix + # which can take long time for large bundles, and since anyway we expect + # executable to have execute flag set we can narrow the list much quicker. + if(find_cmd) + execute_process(COMMAND "${find_cmd}" "${bundle}" -type f -perm +0111 + OUTPUT_VARIABLE file_list + OUTPUT_STRIP_TRAILING_WHITESPACE + ) + string(REPLACE "\n" ";" file_list ${file_list}) + else() + file(GLOB_RECURSE file_list "${bundle}/*") + endif() + foreach(f ${file_list}) is_file_executable("${f}" is_executable) if(is_executable) -- 1.9.3 (Apple Git-50) From ono at java.pl Thu Sep 4 09:11:42 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 15:11:42 +0200 Subject: [cmake-developers] [PATCH 2/6] Make sure dyld placeholders are prefixes In-Reply-To: <1409836306-96543-1-git-send-email-ono@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> Message-ID: <1409836306-96543-2-git-send-email-ono@java.pl> Mac OS X dyld placeholders should be always prefixes, otherwise this can lead to some undefined behavior. --- Modules/GetPrerequisites.cmake | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 05c2edb..49443e3 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -329,7 +329,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) endif() if(NOT resolved) - if(item MATCHES "@executable_path") + if(item MATCHES "^@executable_path") # # @executable_path references are assumed relative to exepath # @@ -347,7 +347,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) endif() if(NOT resolved) - if(item MATCHES "@loader_path") + if(item MATCHES "^@loader_path") # # @loader_path references are assumed relative to the # PATH of the given "context" (presumably another library) @@ -367,7 +367,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) endif() if(NOT resolved) - if(item MATCHES "@rpath") + if(item MATCHES "^@rpath") # # @rpath references are relative to the paths built into the binaries with -rpath # We handle this case like we do for other Unixes -- 1.9.3 (Apple Git-50) From ono at java.pl Thu Sep 4 09:11:43 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 15:11:43 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <1409836306-96543-1-git-send-email-ono@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> Message-ID: <1409836306-96543-3-git-send-email-ono@java.pl> This is done by gathering LC_RPATH commands for main bundle executable and using it for @rpath lookup in dependent frameworks. To achieve this all utility functions now take path to executable rather than path to its directory. This enabled apps using @rpath to be bundled correctly, which will be necessary for upcoming Qt 5.4 that will use @rpath for all frameworks. --- Modules/BundleUtilities.cmake | 90 +++++++++++++++++++++++++++++------------- Modules/GetPrerequisites.cmake | 47 +++++++++++----------- 2 files changed, 86 insertions(+), 51 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 7e2b173..dece0d9 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -19,6 +19,7 @@ # get_bundle_and_executable # get_bundle_all_executables # get_item_key +# get_item_rpaths # clear_bundle_keys # set_bundle_key_values # get_bundle_keys @@ -123,7 +124,7 @@ # # :: # -# SET_BUNDLE_KEY_VALUES( +# SET_BUNDLE_KEY_VALUES( # ) # # Add a key to the list (if necessary) for the given item. If added, @@ -163,7 +164,7 @@ # # :: # -# FIXUP_BUNDLE_ITEM( ) +# FIXUP_BUNDLE_ITEM( ) # # Get the direct/non-system prerequisites of the resolved embedded item. # For each prerequisite, change the way it is referenced to the value of @@ -285,7 +286,7 @@ function(get_bundle_main_executable bundle result_var) endfunction() -function(get_dotapp_dir exe dotapp_dir_var) +function(get_dotapp_dir executable dotapp_dir_var) set(s "${exe}") if(s MATCHES "/.*\\.app/") @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) endfunction() +function(get_item_rpaths item rpaths_var) + if(APPLE) + find_program(otool_cmd "otool") + mark_as_advanced(otool_cmd) + endif() + + if(otool_cmd) + execute_process( + COMMAND "${otool_cmd}" -l "${item}" + OUTPUT_VARIABLE load_cmds_ov + ) + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") + string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") + string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") + if(load_cmds_ov) + gp_append_unique(${rpaths_var} "${load_cmds_ov}") + endif() + endif() + + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) +endfunction() + + function(get_item_key item key_var) get_filename_component(item_name "${item}" NAME) if(WIN32) @@ -425,12 +449,13 @@ function(clear_bundle_keys keys_var) set(${key}_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_COPYFLAG PARENT_SCOPE) + set(${key}_RPATHS PARENT_SCOPE) endforeach() set(${keys_var} PARENT_SCOPE) endfunction() -function(set_bundle_key_values keys_var context item exepath dirs copyflag) +function(set_bundle_key_values keys_var context item executable dirs copyflag) get_filename_component(item_name "${item}" NAME) get_item_key("${item}" key) @@ -440,10 +465,17 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) list(LENGTH ${keys_var} length_after) if(NOT length_before EQUAL length_after) - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item) + # Always use the exepath of the main bundle executable for @executable_path + # replacements: + # + get_filename_component(exepath "${executable}" PATH) + + gp_resolve_item("${context}" "${item}" "${executable}" "${dirs}" resolved_item) gp_item_default_embedded_path("${item}" default_embedded_path) + get_item_rpaths("${resolved_item}" rpaths) + if(item MATCHES "[^/]+\\.framework/") # For frameworks, construct the name under the embedded path from the # opening "${item_name}.framework/" to the closing "/${item_name}": @@ -479,6 +511,7 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) set(${key}_EMBEDDED_ITEM "${embedded_item}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" PARENT_SCOPE) set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) + set(${key}_RPATHS "${rpaths}" PARENT_SCOPE) else() #message("warning: item key '${key}' already in the list, subsequent references assumed identical to first") endif() @@ -490,11 +523,6 @@ function(get_bundle_keys app libs dirs keys_var) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - # Always use the exepath of the main bundle executable for @executable_path - # replacements: - # - get_filename_component(exepath "${executable}" PATH) - # But do fixups on all executables in the bundle: # get_bundle_all_executables("${bundle}" exes) @@ -505,12 +533,12 @@ function(get_bundle_keys app libs dirs keys_var) # but that do not show up in otool -L output...) # foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -521,14 +549,14 @@ function(get_bundle_keys app libs dirs keys_var) foreach(exe ${exes}) # Add the exe itself to the keys: # - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${executable}" "${dirs}" 0) # Add each prerequisite to the keys: # set(prereqs "") - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${exe}" prereqs 1 1 "${executable}" "${dirs}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -542,6 +570,7 @@ function(get_bundle_keys app libs dirs keys_var) set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) endforeach() endif() endfunction() @@ -612,7 +641,7 @@ function(copy_resolved_framework_into_bundle resolved_item resolved_embedded_ite endfunction() -function(fixup_bundle_item resolved_embedded_item exepath dirs) +function(fixup_bundle_item resolved_embedded_item executable dirs) # This item's key is "ikey": # get_item_key("${resolved_embedded_item}" ikey) @@ -622,7 +651,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) # tree, or in other varied locations around the file system, with our call to # install_name_tool. Make sure that doesn't happen here: # - get_dotapp_dir("${exepath}" exe_dotapp_dir) + get_dotapp_dir("${executable}" exe_dotapp_dir) string(LENGTH "${exe_dotapp_dir}/" exe_dotapp_dir_length) string(LENGTH "${resolved_embedded_item}" resolved_embedded_item_length) set(path_too_short 0) @@ -648,7 +677,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) endif() set(prereqs "") - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}") + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${executable}" "${dirs}") set(changes "") @@ -668,12 +697,20 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) execute_process(COMMAND chmod u+w "${resolved_embedded_item}") endif() + foreach(rpath ${${ikey}_RPATHS}) + set(changes ${changes} -delete_rpath "${rpath}") + endforeach() + + if(${ikey}_EMBEDDED_ITEM) + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") + endif() + # Change this item's id and all of its references in one call # to install_name_tool: # - execute_process(COMMAND install_name_tool - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" - ) + if(changes) + execute_process(COMMAND install_name_tool ${changes} "${resolved_embedded_item}") + endif() endfunction() @@ -685,8 +722,6 @@ function(fixup_bundle app libs dirs) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - get_filename_component(exepath "${executable}" PATH) - message(STATUS "fixup_bundle: preparing...") get_bundle_keys("${app}" "${libs}" "${dirs}" keys) @@ -732,7 +767,7 @@ function(fixup_bundle app libs dirs) math(EXPR i ${i}+1) if(APPLE) message(STATUS "${i}/${n}: fixing up '${${key}_RESOLVED_EMBEDDED_ITEM}'") - fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${exepath}" "${dirs}") + fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${executable}" "${dirs}") else() message(STATUS "${i}/${n}: fix-up not required on this platform '${${key}_RESOLVED_EMBEDDED_ITEM}'") endif() @@ -768,13 +803,12 @@ function(verify_bundle_prerequisites bundle result_var info_var) foreach(f ${file_list}) is_file_executable("${f}" is_executable) if(is_executable) - get_filename_component(exepath "${f}" PATH) math(EXPR count "${count} + 1") message(STATUS "executable file ${count}: ${f}") set(prereqs "") - get_prerequisites("${f}" prereqs 1 1 "${exepath}" "") + get_prerequisites("${f}" prereqs 1 1 "${executable}" "") # On the Mac, # "embedded" and "system" prerequisites are fine... anything else means @@ -788,7 +822,7 @@ function(verify_bundle_prerequisites bundle result_var info_var) foreach(p ${prereqs}) set(p_type "") - gp_file_type("${f}" "${p}" p_type) + gp_file_type("${f}" "${p}" "${main_bundle_exe}" p_type) if(APPLE) if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL "system") diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 49443e3..d655f96 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -41,7 +41,7 @@ # :: # # GET_PREREQUISITES( -# ) +# ) # # Get the list of shared library files required by . The list # in the variable named should be empty on first @@ -53,7 +53,7 @@ # must be 0 or 1 indicating whether to include or # exclude "system" prerequisites. If is set to 1 all # prerequisites will be found recursively, if set to 0 only direct -# prerequisites are listed. is the path to the top level +# prerequisites are listed. is the path to the top level # executable used for @executable_path replacment on the Mac. is # a list of paths where libraries might be found: these paths are # searched first when a target without any path info is given. Then @@ -113,7 +113,7 @@ # # :: # -# GP_RESOLVE_ITEM( ) +# GP_RESOLVE_ITEM( ) # # Resolve an item into an existing full path file. # @@ -122,13 +122,13 @@ # # :: # -# GP_RESOLVED_FILE_TYPE( ) +# GP_RESOLVED_FILE_TYPE( ) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named # . # -# Use and if necessary to resolve non-absolute +# Use and if necessary to resolve non-absolute # values -- but only for non-embedded items. # # Possible types are: @@ -318,10 +318,12 @@ function(gp_item_default_embedded_path item default_embedded_path_var) endfunction() -function(gp_resolve_item context item exepath dirs resolved_item_var) +function(gp_resolve_item context item executable dirs resolved_item_var) set(resolved 0) set(resolved_item "${item}") + get_filename_component(exepath "${executable}" PATH) + # Is it already resolved? # if(IS_ABSOLUTE "${resolved_item}" AND EXISTS "${resolved_item}") @@ -331,7 +333,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) if(NOT resolved) if(item MATCHES "^@executable_path") # - # @executable_path references are assumed relative to exepath + # @executable_path references are assumed relative to executable # string(REPLACE "@executable_path" "${exepath}" ri "${item}") get_filename_component(ri "${ri}" ABSOLUTE) @@ -374,10 +376,11 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) # string(REPLACE "@rpath/" "" norpath_item "${item}") + get_item_key("${executable}" key) set(ri "ri-NOTFOUND") - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) + find_file(ri "${norpath_item}" ${dirs} ${${key}_RPATHS} NO_DEFAULT_PATH) if(ri) - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") + #message(STATUS "info: 'find_file' in exepath/rpaths/dirs (${ri})") set(resolved 1) set(resolved_item "${ri}") set(ri "ri-NOTFOUND") @@ -436,7 +439,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) # by whatever logic they choose: # if(COMMAND gp_resolve_item_override) - gp_resolve_item_override("${context}" "${item}" "${exepath}" "${dirs}" resolved_item resolved) + gp_resolve_item_override("${context}" "${item}" "${executable}" "${dirs}" resolved_item resolved) endif() if(NOT resolved) @@ -459,7 +462,7 @@ warning: cannot resolve item '${item}' # # context='${context}' # item='${item}' -# exepath='${exepath}' +# executable='${executable}' # dirs='${dirs}' # resolved_item_var='${resolved_item_var}' #****************************************************************************** @@ -470,7 +473,7 @@ warning: cannot resolve item '${item}' endfunction() -function(gp_resolved_file_type original_file file exepath dirs type_var) +function(gp_resolved_file_type original_file file executable dirs type_var) #message(STATUS "**") if(NOT IS_ABSOLUTE "${original_file}") @@ -489,7 +492,7 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) if(NOT is_embedded) if(NOT IS_ABSOLUTE "${file}") - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file) + gp_resolve_item("${original_file}" "${file}" "${executable}" "${dirs}" resolved_file) endif() string(TOLOWER "${original_file}" original_lower) @@ -595,21 +598,19 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) endfunction() -function(gp_file_type original_file file type_var) +function(gp_file_type original_file file executable type_var) if(NOT IS_ABSOLUTE "${original_file}") message(STATUS "warning: gp_file_type expects absolute full path for first arg original_file") endif() - get_filename_component(exepath "${original_file}" PATH) - set(type "") - gp_resolved_file_type("${original_file}" "${file}" "${exepath}" "" type) + gp_resolved_file_type("${original_file}" "${file}" "${executable}" "" type) set(${type_var} "${type}" PARENT_SCOPE) endfunction() -function(get_prerequisites target prerequisites_var exclude_system recurse exepath dirs) +function(get_prerequisites target prerequisites_var exclude_system recurse exe dirs) set(verbose 0) set(eol_char "E") @@ -834,7 +835,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(add_item AND ${exclude_system}) set(type "") - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type) + gp_resolved_file_type("${target}" "${item}" "${executable}" "${dirs}" type) if("${type}" STREQUAL "system") set(add_item 0) @@ -855,7 +856,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa # that the analysis tools can simply accept it as input. # if(NOT list_length_before_append EQUAL list_length_after_append) - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${target}" "${item}" "${executable}" "${dirs}" resolved_item) set(unseen_prereqs ${unseen_prereqs} "${resolved_item}") endif() endif() @@ -874,7 +875,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(${recurse}) set(more_inputs ${unseen_prereqs}) foreach(input ${more_inputs}) - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}") + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${executable}" "${dirs}") endforeach() endif() @@ -911,7 +912,7 @@ function(list_prerequisites target) get_filename_component(exepath "${target}" PATH) set(prereqs "") - get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${exepath}" "") + get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${target}" "") if(print_target) message(STATUS "File '${target}' depends on:") @@ -925,7 +926,7 @@ function(list_prerequisites target) endif() if(print_prerequisite_type) - gp_file_type("${target}" "${d}" type) + gp_file_type("${target}" "${d}" "" type) set(type_str " (${type})") endif() -- 1.9.3 (Apple Git-50) From ono at java.pl Thu Sep 4 09:11:44 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 15:11:44 +0200 Subject: [cmake-developers] [PATCH 4/6] Process executables first when scanning bundle In-Reply-To: <1409836306-96543-1-git-send-email-ono@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> Message-ID: <1409836306-96543-4-git-send-email-ono@java.pl> This makes rpaths populated (if any), so libraries containing @rpath will be resolved properly. --- Modules/BundleUtilities.cmake | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index dece0d9..5823813 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -527,21 +527,6 @@ function(get_bundle_keys app libs dirs keys_var) # get_bundle_all_executables("${bundle}" exes) - # For each extra lib, accumulate a key as well and then also accumulate - # any of its prerequisites. (Extra libs are typically dynamically loaded - # plugins: libraries that are prerequisites for full runtime functionality - # but that do not show up in otool -L output...) - # - foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) - - set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") - foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) - endforeach() - endforeach() - # For each executable found in the bundle, accumulate keys as we go. # The list of keys should be complete when all prerequisites of all # binaries in the bundle have been analyzed. @@ -560,6 +545,21 @@ function(get_bundle_keys app libs dirs keys_var) endforeach() endforeach() + # For each extra lib, accumulate a key as well and then also accumulate + # any of its prerequisites. (Extra libs are typically dynamically loaded + # plugins: libraries that are prerequisites for full runtime functionality + # but that do not show up in otool -L output...) + # + foreach(lib ${libs}) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) + + set(prereqs "") + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") + foreach(pr ${prereqs}) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) + endforeach() + endforeach() + # Propagate values to caller's scope: # set(${keys_var} ${${keys_var}} PARENT_SCOPE) -- 1.9.3 (Apple Git-50) From ono at java.pl Thu Sep 4 09:11:46 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 15:11:46 +0200 Subject: [cmake-developers] [PATCH 6/6] Make sure we bundle Qt5 Cocoa platform plugin In-Reply-To: <1409836306-96543-1-git-send-email-ono@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> Message-ID: <1409836306-96543-6-git-send-email-ono@java.pl> Otherwise CMake.app bundle will not run when using Qt5. --- Source/QtDialog/CMakeLists.txt | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt index 8da88c1..03c2fb4 100644 --- a/Source/QtDialog/CMakeLists.txt +++ b/Source/QtDialog/CMakeLists.txt @@ -35,6 +35,32 @@ if (Qt5Widgets_FOUND) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${Qt5Widgets_EXECUTABLE_COMPILE_FLAGS}") + # We need to install Cocoa platform plugin and add qt.conf for Qt5 on Mac. + # FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly + # Qt5 Mac support is missing there. + if(APPLE) + macro(install_qt5_plugin _qt_plugin_name _qt_plugins_var) + get_target_property(_qt_plugin_path "${_qt_plugin_name}" LOCATION) + if(EXISTS "${_qt_plugin_path}") + get_filename_component(_qt_plugin_file "${_qt_plugin_path}" NAME) + get_filename_component(_qt_plugin_type "${_qt_plugin_path}" PATH) + get_filename_component(_qt_plugin_type "${_qt_plugin_type}" NAME) + set(_qt_plugin_dest "${CMAKE_INSTALL_PREFIX}/PlugIns/${_qt_plugin_type}") + install(FILES "${_qt_plugin_path}" + DESTINATION "${_qt_plugin_dest}") + set(${_qt_plugins_var} + "${${_qt_plugins_var}};${_qt_plugin_dest}/${_qt_plugin_file}") + else() + message(FATAL_ERROR "QT plugin ${_qt_plugin_name} not found") + endif() + endmacro() + install_qt5_plugin("Qt5::QCocoaIntegrationPlugin" QT_PLUGINS) + file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/qt.conf" + "[Paths]\nPlugins = PlugIns\n") + install(FILES "${CMAKE_CURRENT_BINARY_DIR}/qt.conf" + DESTINATION "${CMAKE_INSTALL_PREFIX}/Resources") + endif() + if(WIN32 AND TARGET Qt5::Core) get_property(_Qt5_Core_LOCATION TARGET Qt5::Core PROPERTY LOCATION) get_filename_component(Qt_BIN_DIR "${_Qt5_Core_LOCATION}" PATH) @@ -168,7 +194,7 @@ if(APPLE OR WIN32) install(CODE " include(\"${CMake_SOURCE_DIR}/Modules/BundleUtilities.cmake\") set(BU_CHMOD_BUNDLE_ITEMS ON) - fixup_bundle(\"${fixup_exe}\" \"\" \"${QT_LIBRARY_DIR};${QT_BINARY_DIR}\") + fixup_bundle(\"${fixup_exe}\" \"${QT_PLUGINS}\" \"${QT_LIBRARY_DIR};${QT_BINARY_DIR}\") ") endif() -- 1.9.3 (Apple Git-50) From ono at java.pl Thu Sep 4 09:11:45 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 15:11:45 +0200 Subject: [cmake-developers] [PATCH 5/6] Codesign needs framework's Contents/Info.plist In-Reply-To: <1409836306-96543-1-git-send-email-ono@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> Message-ID: <1409836306-96543-5-git-send-email-ono@java.pl> Therefore we need to bundle it (if present) too when fixing Mac OS X app bundle. --- Modules/BundleUtilities.cmake | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 5823813..5759e24 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -632,6 +632,14 @@ function(copy_resolved_framework_into_bundle resolved_item resolved_embedded_ite #message(STATUS "copying COMMAND ${CMAKE_COMMAND} -E copy_directory '${resolved_resources}' '${resolved_embedded_resources}'") execute_process(COMMAND ${CMAKE_COMMAND} -E copy_directory "${resolved_resources}" "${resolved_embedded_resources}") endif() + + # And Info.plist, if it exists: + string(REGEX REPLACE "^(.*)/[^/]+/[^/]+/[^/]+$" "\\1/Contents/Info.plist" resolved_info_plist "${resolved_item}") + string(REGEX REPLACE "^(.*)/[^/]+/[^/]+/[^/]+$" "\\1/Contents/Info.plist" resolved_embedded_info_plist "${resolved_embedded_item}") + if(EXISTS "${resolved_info_plist}") + #message(STATUS "copying COMMAND ${CMAKE_COMMAND} -E copy_directory '${resolved_info_plist}' '${resolved_embedded_info_plist}'") + execute_process(COMMAND ${CMAKE_COMMAND} -E copy "${resolved_info_plist}" "${resolved_embedded_info_plist}") + endif() endif() if(UNIX AND NOT APPLE) file(RPATH_REMOVE FILE "${resolved_embedded_item}") -- 1.9.3 (Apple Git-50) From brad.king at kitware.com Thu Sep 4 09:19:34 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 09:19:34 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <540866E6.7050603@kitware.com> On 09/04/2014 06:42 AM, Bach, Pascal wrote: > This won't' work as the code gets called multiple times Right, it gets called inside try_compile projects too. Actually the SDK information will have to be propagated into those too. That means it needs to go in files like CMakeSystem.cmake or CMakeCCompiler.cmake that are configured in the build tree, or be explicitly propagated by cmMakefile::TryCompile like the GeneratorToolset is. I'd like to understand the differences among WinCE SDKs (I've never done WinCE development). What are some example names? What does each mean? What processor does each one target? Thanks, -Brad From brad.king at kitware.com Thu Sep 4 09:25:21 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 09:25:21 -0400 Subject: [cmake-developers] Changing the regex used for INFO strings In-Reply-To: References: Message-ID: <54086841.7030909@kitware.com> On 09/03/2014 05:20 PM, Chuck Atkins wrote: > stage/use-consistent-regex-for-info-strings The proposed regex is now: INFO:[A-Za-z0-9_]+\\[[^]]*\\] It looks good to me. Thanks, -Brad From pascal.bach at siemens.com Thu Sep 4 09:31:52 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Thu, 4 Sep 2014 13:31:52 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <540866E6.7050603@kitware.com> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> > > This won't' work as the code gets called multiple times > > Right, it gets called inside try_compile projects too. Actually > the SDK information will have to be propagated into those too. > That means it needs to go in files like CMakeSystem.cmake or > CMakeCCompiler.cmake that are configured in the build tree, > or be explicitly propagated by cmMakefile::TryCompile like the > GeneratorToolset is. With the current implementation I sent this seems to work and the SDK ends up in The generated vxproj files for try compile. > > I'd like to understand the differences among WinCE SDKs (I've > never done WinCE development). What are some example names? > What does each mean? What processor does each one target? I'm also quite new to the whole Windows CE development but I try to explain what I figured out until now. An example for a Windows CE 2013 (aka 8.0) SDK is the one for Ti AM335x from Adeneo [1]. Once installed it can be found under: C:\Program Files (x86)\Windows CE Tools\SDKs\SDK_AM335X_SK_WEC2013 Where SDK_AM335X_SK_WEC2013 is the SDK name. The content of SDK_AM335X_SK_WEC2013\sdk subfolder is similar in structure to a folder under: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC I don't know the exact details but it looks like it contains a complete VC compiler targeted at the specific board. If I create a Project using this SDK in visual studio the following XML snippet ends up in the resulting .vxproj file: Debug SDK_AM335X_SK_WEC2013 It seems like this is the way Windows knows what compiler to use based on the entries in: HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows CE Tools\\SDKs Where all the installed Windows CE SDKs are listed with the default key pointing to their path on the filesystem. That's all I know till now ;) Pascal [1] http://www.adeneo-embedded.com/Products/Board-Support-Packages/Texas-Instruments-Sitara From brad.king at kitware.com Thu Sep 4 10:21:07 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 10:21:07 -0400 Subject: [cmake-developers] OS X packaging updates (was: [PATCH 1/6] Use find on UNIX for fast executable lookup) In-Reply-To: <1409836306-96543-1-git-send-email-ono@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> Message-ID: <54087553.2020104@kitware.com> Hi Adam, Thanks. I've applied the series and merged to 'next' for testing: BundleUtilities: Use 'find' on UNIX for fast executable lookup http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=634b4d5a GetPrerequisites: Make sure dyld placeholders are prefixes http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4f577985 BundleUtilities: Resolve and replace @rpath placeholders http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=591380da BundleUtilities: Process executables first when scanning bundle http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=32a38bbc BundleUtilities: Codesign needs framework's Contents/Info.plist http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5361697b cmake-gui: Make sure we bundle Qt5 Cocoa platform plugin http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=da78e01c For the last change, might something like that be needed on Windows too? Thanks, -Brad From nilsgladitz at gmail.com Thu Sep 4 10:25:21 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 04 Sep 2014 16:25:21 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion Message-ID: <54087651.8010909@gmail.com> This keeps coming up and there probably have been many discussions on how this might be "fixed" as well. I am wondering if we could provide an alias for the "if" command (e.g. "safe_if") that would inherit cmIfCommand but would reimplement GetVariableOrString() without the variable lookup. This would leave if() behavior intact for compatibility but would provide an alternative with less surprising semantics. I would keep else() elseif() endif() without additional aliases and leave the behavior to the initial if variant. Nils From dlrdave at aol.com Thu Sep 4 10:32:54 2014 From: dlrdave at aol.com (David Cole) Date: Thu, 4 Sep 2014 10:32:54 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion Message-ID: <8D196643FCF71AA-15CC-1366F@webmail-m269.sysops.aol.com> Another approach might be to add STRING_EQUAL and STRING_MATCHES (or similarly unambiguous names) operators that do not do the variable lookup. The documentation would start with: if( STRING_EQUAL ) if( STRING_MATCHES ) ...i.e., not mentioning anywhere for these operators. D From brad.king at kitware.com Thu Sep 4 10:40:56 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 10:40:56 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <54087651.8010909@gmail.com> References: <54087651.8010909@gmail.com> Message-ID: <540879F8.5050200@kitware.com> On 09/04/2014 10:25 AM, Nils Gladitz wrote: > This keeps coming up and there probably have been many discussions on > how this might be "fixed" as well. As I have explained every other time it has come up there is exactly one way to fix it: a policy that makes expansion happen only for unquoted arguments. Someone just has to do it. > I am wondering if we could provide an alias for the "if" command (e.g. > "safe_if") that would inherit cmIfCommand but would reimplement > GetVariableOrString() without the variable lookup. > > This would leave if() behavior intact for compatibility but would > provide an alternative with less surprising semantics. I think a new command would ("if_noexpand") would make the "correct" code less readable than the "incorrect" code. Also the implicit-bool conversion of variables is more readable IMO; consider if(${FOO_FOUND}) versus if(FOO_FOUND) On 09/04/2014 10:32 AM, David Cole via cmake-developers wrote: > Another approach might be to add STRING_EQUAL and STRING_MATCHES (or > similarly unambiguous names) operators that do not do the variable > lookup. This is a reasonable proposal but the difference to STREQUAL and MATCHES is quite subtle. Also adding more operators this late in the game is more likely to collide with variable names people already use. -Brad From nilsgladitz at gmail.com Thu Sep 4 10:51:03 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 04 Sep 2014 16:51:03 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <540879F8.5050200@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> Message-ID: <54087C57.6060500@gmail.com> On 09/04/2014 04:40 PM, Brad King wrote: > On 09/04/2014 10:25 AM, Nils Gladitz wrote: > I think a new command would ("if_noexpand") would make the "correct" > code less readable than the "incorrect" code. Also the implicit-bool > conversion of variables is more readable IMO; consider > > if(${FOO_FOUND}) > > versus > > if(FOO_FOUND) I am rather used to "if()" as well but safe_if()/if_noexpand() might still be more readable than the workarounds that people are using now to get something close to the expected behavior with regular if() [1]. You would also still be able to use regular if() in cases where you prefer the aesthetics of implicit-bool. Nils [1] http://www.cmake.org/pipermail/cmake/2014-September/058476.html From brad.king at kitware.com Thu Sep 4 11:13:59 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 11:13:59 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <54087C57.6060500@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> Message-ID: <540881B7.9090908@kitware.com> On 09/04/2014 10:51 AM, Nils Gladitz wrote: > I am rather used to "if()" as well but safe_if()/if_noexpand() might > still be more readable than the workarounds that people are using now to > get something close to the expected behavior with regular if() [1]. If "if()" is never fixed people will still run into that and be confused. Adding another command will leave people with the decision about which one to use in what cases and be even more confused. As I have explained every other time it has come up there is exactly one way to fix it: a policy that makes expansion happen only for unquoted arguments. Someone just has to do it. -Brad From eike at sf-mail.de Thu Sep 4 11:15:55 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Thu, 04 Sep 2014 17:15:55 +0200 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup In-Reply-To: <1409836306-96543-1-git-send-email-ono@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> Message-ID: <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> Am 04.09.2014 15:11, schrieb Adam Strzelecki: > It makes whole executable process quicker on UNIX, especially for large > bundles > containing many files, since using find narrows results to only files > having > executable flags then all further tests follow. > --- > Modules/BundleUtilities.cmake | 19 ++++++++++++++++++- > 1 file changed, 18 insertions(+), 1 deletion(-) > > diff --git a/Modules/BundleUtilities.cmake > b/Modules/BundleUtilities.cmake > index 0046c97..7e2b173 100644 > --- a/Modules/BundleUtilities.cmake > +++ b/Modules/BundleUtilities.cmake > @@ -378,7 +378,24 @@ endfunction() > function(get_bundle_all_executables bundle exes_var) > set(exes "") > > - file(GLOB_RECURSE file_list "${bundle}/*") > + if(UNIX) > + find_program(find_cmd "find") > + mark_as_advanced(find_cmd) > + endif() > + > + # find command is much quicker than checking every file one by one > on Unix > + # which can take long time for large bundles, and since anyway we > expect > + # executable to have execute flag set we can narrow the list much > quicker. > + if(find_cmd) > + execute_process(COMMAND "${find_cmd}" "${bundle}" -type f -perm > +0111 > + OUTPUT_VARIABLE file_list > + OUTPUT_STRIP_TRAILING_WHITESPACE > + ) > + string(REPLACE "\n" ";" file_list ${file_list}) > + else() > + file(GLOB_RECURSE file_list "${bundle}/*") > + endif() > + > foreach(f ${file_list}) > is_file_executable("${f}" is_executable) > if(is_executable) > -- I wonder if the "right" solution would instead be to add some additional flags to GLOB/GLOB_RECURSE where one could e.g. specify that the file is executable, or is a directory. Looking at GetPrerequisites.cmake, FindDoxygen.cmake, and CMakeDetermineCompilerId.cmake this could be a good idea for other places, too. Eike From brad.king at kitware.com Thu Sep 4 11:24:43 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 11:24:43 -0400 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup In-Reply-To: <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> References: <1409836306-96543-1-git-send-email-ono@java.pl> <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> Message-ID: <5408843B.3000704@kitware.com> On 09/04/2014 11:15 AM, Rolf Eike Beer wrote: > I wonder if the "right" solution would instead be to add some additional > flags to GLOB/GLOB_RECURSE where one could e.g. specify that the file is > executable, or is a directory. That would be useful functionality regardless of this application. -Brad From nilsgladitz at gmail.com Thu Sep 4 11:41:23 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 04 Sep 2014 17:41:23 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <540881B7.9090908@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> Message-ID: <54088823.3000309@gmail.com> On 09/04/2014 05:13 PM, Brad King wrote: > As I have explained every other time it has come up there is exactly > one way to fix it: a policy that makes expansion happen only for > unquoted arguments. Someone just has to do it. > The fact that this behaviour has persisted this long and that no one has volunteered to fix it is a bit intimidating. How large scale would the required changes be? I assume the fact that arguments were quoted would have to be preserved and the implementation of all existing commands touched so that they can actually make use of that information (even if only if() would currently make use of it). Are there any major pitfalls to look out for? Nils From brad.king at kitware.com Thu Sep 4 11:53:51 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 11:53:51 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <54088823.3000309@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> Message-ID: <54088B0F.7030405@kitware.com> On 09/04/2014 11:41 AM, Nils Gladitz wrote: > I assume the fact that arguments were quoted would have to be preserved > and the implementation of all existing commands touched so that they can > actually make use of that information (even if only if() would currently > make use of it). Most commands just implement InitialPass, which gets the expanded arguments. Some implement InvokeInitialPass which gets the args before expansion. The cmIfCommand does this already, and its call to cmMakefile::ExpandArguments could be updated to request the additional information. Other commands should not need to be modified. The cmMakefile::ExpandArguments method's output will have to provide the information. I'm not sure whether all call sites need it or not, but it could simply be implemented as a second argument of type "vector* = 0" to be populated with the same number of entries as the original argument. Or, a second signature of vector could be created to pair each output argument string with its delimiter type. Then cmIfCommand could use that internally. -Brad From nilsgladitz at gmail.com Thu Sep 4 11:58:08 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 04 Sep 2014 17:58:08 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <54088B0F.7030405@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> Message-ID: <54088C10.50601@gmail.com> On 09/04/2014 05:53 PM, Brad King wrote: > Most commands just implement InitialPass, which gets the expanded > arguments. Some implement InvokeInitialPass which gets the args > before expansion. The cmIfCommand does this already, and its > call to cmMakefile::ExpandArguments could be updated to request > the additional information. Other commands should not need to > be modified. > > The cmMakefile::ExpandArguments method's output will have to provide > the information. I'm not sure whether all call sites need it or not, > but it could simply be implemented as a second argument of type > "vector* = 0" to be populated with > the same number of entries as the original argument. Or, a second > signature of vector could be created to pair each output > argument string with its delimiter type. Then cmIfCommand could use > that internally. Thanks, that actually sounds doable. I'll give it a try. Nils From brad.king at kitware.com Thu Sep 4 12:03:36 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 12:03:36 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <54088D58.70408@kitware.com> On 09/04/2014 09:31 AM, Bach, Pascal wrote: > With the current implementation I sent this seems to work and the SDK ends up in > The generated vxproj files for try compile. I don't see anything in the patch that could do that. CMakeDetermineCompilerId generates a test .vcxproj file that gets the value from CMAKE_VS_PLATFORM_NAME. That one is in the CompilerId directory. Is that the one you checked? It is not from a try_compile. -Brad From ono at java.pl Thu Sep 4 12:43:57 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 18:43:57 +0200 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup In-Reply-To: <5408843B.3000704@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> <5408843B.3000704@kitware.com> Message-ID: <5D044E05-087E-4DAE-8234-C562AD7723A6@java.pl> > On 09/04/2014 11:15 AM, Rolf Eike Beer wrote: >> I wonder if the "right" solution would instead be to add some additional >> flags to GLOB/GLOB_RECURSE where one could e.g. specify that the file is >> executable, or is a directory. > > That would be useful functionality regardless of this application. I was thinking about that. And yes it would be useful. Generally specifying UNIX mask for present/missing bits would be useful. Yet this requires changes in C++ code that's why I used "find" instead. --Adam From ono at java.pl Thu Sep 4 12:45:42 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 18:45:42 +0200 Subject: [cmake-developers] OS X packaging updates (was: [PATCH 1/6] Use find on UNIX for fast executable lookup) In-Reply-To: <54087553.2020104@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> Message-ID: > Thanks. I've applied the series and merged to 'next' for testing: Thanks! > For the last change, might something like that be needed on > Windows too? Yes, this is very likely. I can investigate that how it looks for Windows apps. --Adam From brad.king at kitware.com Thu Sep 4 12:49:01 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 12:49:01 -0400 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup In-Reply-To: <5D044E05-087E-4DAE-8234-C562AD7723A6@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> <5408843B.3000704@kitware.com> <5D044E05-087E-4DAE-8234-C562AD7723A6@java.pl> Message-ID: <540897FD.6000207@kitware.com> On 09/04/2014 12:43 PM, Adam Strzelecki wrote: > Generally specifying UNIX mask for present/missing bits Rather than trying to do this with file(GLOB), perhaps we should consider a file(FIND) command for this purpose. It could have more options, including pattern matching, and eventually supersede file(GLOB) with a better signature. > Yet this requires changes in C++ code that's why I used "find" instead. That's fine. If someone adds the functionality later then this use case can be ported to it. -Brad From bill.hoffman at kitware.com Thu Sep 4 13:26:30 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 04 Sep 2014 13:26:30 -0400 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup In-Reply-To: <540897FD.6000207@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> <5408843B.3000704@kitware.com> <5D044E05-087E-4DAE-8234-C562AD7723A6@java.pl> <540897FD.6000207@kitware.com> Message-ID: <5408A0C6.3080205@kitware.com> On 9/4/2014 12:49 PM, Brad King wrote: > On 09/04/2014 12:43 PM, Adam Strzelecki wrote: >> Generally specifying UNIX mask for present/missing bits > > Rather than trying to do this with file(GLOB), perhaps we should > consider a file(FIND) command for this purpose. It could have > more options, including pattern matching, and eventually > supersede file(GLOB) with a better signature. > >> Yet this requires changes in C++ code that's why I used "find" instead. > > That's fine. If someone adds the functionality later then this > use case can be ported to it. > > -Brad > I would be concerned with the portability of the arguments to find. How much faster is this? How hard would it be to change the c++? I have not looked into this myself at all, but the use of an external program raises some red flags for me. -Bill From ono at java.pl Thu Sep 4 13:43:16 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 19:43:16 +0200 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup In-Reply-To: <5408A0C6.3080205@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> <5408843B.3000704@kitware.com> <5D044E05-087E-4DAE-8234-C562AD7723A6@java.pl> <540897FD.6000207@kitware.com> <5408A0C6.3080205@kitware.com> Message-ID: <7D383996-160E-4E34-88BE-A51E60385A5B@java.pl> > I would be concerned with the portability of the arguments to find. find DIR -perm +FLAGS is part of POSIX/SUS http://pubs.opengroup.org/onlinepubs/007904875/utilities/find.html I guess it exists on systems dated 199x. > How much faster is this? With CMake.app build, about 50x. Really going through all files in the bundle including html docs, cmake scripts takes almost a minute. > How hard would it be to change the c++? I guess it wouldn't be hard, but we need to agree on naming. > I have not looked into this myself at all, but the use of an external program raises some red flags for me. First of all, it looks if "find" exists on system, otherwise it falls back to old (slow) behavior. So "find" is optional dependency. --Adam From bill.hoffman at kitware.com Thu Sep 4 14:36:53 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 04 Sep 2014 14:36:53 -0400 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup In-Reply-To: <7D383996-160E-4E34-88BE-A51E60385A5B@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> <5408843B.3000704@kitware.com> <5D044E05-087E-4DAE-8234-C562AD7723A6@java.pl> <540897FD.6000207@kitware.com> <5408A0C6.3080205@kitware.com> <7D383996-160E-4E34-88BE-A51E60385A5B@java.pl> Message-ID: <5408B145.6040402@kitware.com> On 9/4/2014 1:43 PM, Adam Strzelecki wrote: > First of all, it looks if "find" exists on system, otherwise it falls back to old (slow) behavior. So "find" is optional dependency. My main concern is that it finds a "find" that does not work as you expect. Also, if it were done in C++ it would automatically benefit all platforms not just the ones that have find. -Bill From brad.king at kitware.com Thu Sep 4 14:42:00 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 14:42:00 -0400 Subject: [cmake-developers] OS X packaging updates In-Reply-To: References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> Message-ID: <5408B278.2070400@kitware.com> On 09/04/2014 12:45 PM, Adam Strzelecki wrote: >> Thanks. I've applied the series and merged to 'next' for testing: > > Thanks! I had to revert the topic because it fails the BundleUtilities test on Linux and Windows on our continuous builds: http://open.cdash.org/testDetails.php?test=278873429&build=3476297 http://open.cdash.org/testDetails.php?test=278879098&build=3476366 Please run the CMake test: ctest -C Debug -R BundleUtilities -V locally on these platforms and revise accordingly. Thanks, -Brad From mantis at public.kitware.com Thu Sep 4 14:46:09 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 4 Sep 2014 14:46:09 -0400 Subject: [cmake-developers] [CMake 0015129]: My macros are written into codeblocks project file but they can'be shown in codebloks IDE Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15129 ====================================================================== Reported By: yaoyansi Assigned To: ====================================================================== Project: CMake Issue ID: 15129 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-04 14:46 EDT Last Modified: 2014-09-04 14:46 EDT ====================================================================== Summary: My macros are written into codeblocks project file but they can'be shown in codebloks IDE Description: CodeBlocks doesn't privide binary packages for CentOS 7 x64 now. But you can get the pre-build package from this page:http://rpm.jenslody.de/, and here is my installation guide: http://www.cnblogs.com/yaoyansi/p/3946600.html I defined some macro: REQUIRE_IOSTREAM _BOOL LINUX _LINUX LINUX_6 These macros are written into the codeblocks project file. But when I open the project file with codeblocks, and open the project build option window, I can't see these macros at all. In fact, I also defined some include directories and link directories, but these directories disappeared in project build option window either. Steps to Reproduce: My cmake files and the generated codeblocks project file is attached. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-04 14:46 yaoyansi New Issue 2014-09-04 14:46 yaoyansi File Added: my_cmake.zip ====================================================================== From ono at java.pl Thu Sep 4 15:01:17 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 21:01:17 +0200 Subject: [cmake-developers] OS X packaging updates In-Reply-To: <5408B278.2070400@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> <5408B278.2070400@kitware.com> Message-ID: <952D2C19-AD78-4E46-BAE0-B2F0F4DF7C2E@java.pl> > Please run the CMake test: > ctest -C Debug -R BundleUtilities -V > locally on these platforms and revise accordingly. Okay, will do tommorow. Thanks for follow up. --Adam From mantis at public.kitware.com Fri Sep 5 02:38:02 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 5 Sep 2014 02:38:02 -0400 Subject: [cmake-developers] [CMake 0015130]: support for generator expressions in OUTPUT_DIRECTORY Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15130 ====================================================================== Reported By: tim blechmann Assigned To: ====================================================================== Project: CMake Issue ID: 15130 Category: CMake Reproducibility: N/A Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-05 02:38 EDT Last Modified: 2014-09-05 02:38 EDT ====================================================================== Summary: support for generator expressions in OUTPUT_DIRECTORY Description: atm generator expressions in *_OUTPUT_DIRECTORY properties are not resolved. it would be great if this could be implemented. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-05 02:38 tim blechmann New Issue ====================================================================== From ono at java.pl Fri Sep 5 07:50:41 2014 From: ono at java.pl (Adam Strzelecki) Date: Fri, 5 Sep 2014 13:50:41 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <952D2C19-AD78-4E46-BAE0-B2F0F4DF7C2E@java.pl> References: <952D2C19-AD78-4E46-BAE0-B2F0F4DF7C2E@java.pl> Message-ID: <1409917844-28297-3-git-send-email-ono@java.pl> This is done by gathering LC_RPATH commands for main bundle executable and using it for @rpath lookup in dependent frameworks. To achieve this all utility functions now take path to executable rather than path to its directory. This enabled apps using @rpath to be bundled correctly, which will be necessary for upcoming Qt 5.4 that will use @rpath for all frameworks. --- Modules/BundleUtilities.cmake | 169 ++++++++++++++++++++++++----------------- Modules/GetPrerequisites.cmake | 48 ++++++------ 2 files changed, 124 insertions(+), 93 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 7e2b173..9733bc9 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -19,6 +19,7 @@ # get_bundle_and_executable # get_bundle_all_executables # get_item_key +# get_item_rpaths # clear_bundle_keys # set_bundle_key_values # get_bundle_keys @@ -75,7 +76,7 @@ # # :: # -# GET_DOTAPP_DIR( ) +# GET_DOTAPP_DIR( ) # # Returns the nearest parent dir whose name ends with ".app" given the # full path to an executable. If there is no such parent dir, then @@ -123,7 +124,7 @@ # # :: # -# SET_BUNDLE_KEY_VALUES( +# SET_BUNDLE_KEY_VALUES( # ) # # Add a key to the list (if necessary) for the given item. If added, @@ -163,7 +164,7 @@ # # :: # -# FIXUP_BUNDLE_ITEM( ) +# FIXUP_BUNDLE_ITEM( ) # # Get the direct/non-system prerequisites of the resolved embedded item. # For each prerequisite, change the way it is referenced to the value of @@ -189,11 +190,11 @@ # # :: # -# VERIFY_BUNDLE_PREREQUISITES( ) +# VERIFY_BUNDLE_PREREQUISITES( ) # # Verifies that the sum of all prerequisites of all files inside the -# bundle are contained within the bundle or are "system" libraries, -# presumed to exist everywhere. +# bundle with given main executable are contained within the bundle or are +# "system" libraries, presumed to exist everywhere. # # :: # @@ -285,8 +286,8 @@ function(get_bundle_main_executable bundle result_var) endfunction() -function(get_dotapp_dir exe dotapp_dir_var) - set(s "${exe}") +function(get_dotapp_dir executable dotapp_dir_var) + set(s "${executable}") if(s MATCHES "/.*\\.app/") # If there is a ".app" parent directory, @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) endfunction() +function(get_item_rpaths item rpaths_var) + if(APPLE) + find_program(otool_cmd "otool") + mark_as_advanced(otool_cmd) + endif() + + if(otool_cmd) + execute_process( + COMMAND "${otool_cmd}" -l "${item}" + OUTPUT_VARIABLE load_cmds_ov + ) + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") + string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") + string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") + if(load_cmds_ov) + gp_append_unique(${rpaths_var} "${load_cmds_ov}") + endif() + endif() + + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) +endfunction() + + function(get_item_key item key_var) get_filename_component(item_name "${item}" NAME) if(WIN32) @@ -425,12 +449,13 @@ function(clear_bundle_keys keys_var) set(${key}_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_COPYFLAG PARENT_SCOPE) + set(${key}_RPATHS PARENT_SCOPE) endforeach() set(${keys_var} PARENT_SCOPE) endfunction() -function(set_bundle_key_values keys_var context item exepath dirs copyflag) +function(set_bundle_key_values keys_var context item executable dirs copyflag) get_filename_component(item_name "${item}" NAME) get_item_key("${item}" key) @@ -440,10 +465,17 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) list(LENGTH ${keys_var} length_after) if(NOT length_before EQUAL length_after) - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item) + # Always use the exepath of the main bundle executable for @executable_path + # replacements: + # + get_filename_component(exepath "${executable}" PATH) + + gp_resolve_item("${context}" "${item}" "${executable}" "${dirs}" resolved_item) gp_item_default_embedded_path("${item}" default_embedded_path) + get_item_rpaths("${resolved_item}" rpaths) + if(item MATCHES "[^/]+\\.framework/") # For frameworks, construct the name under the embedded path from the # opening "${item_name}.framework/" to the closing "/${item_name}": @@ -479,6 +511,7 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) set(${key}_EMBEDDED_ITEM "${embedded_item}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" PARENT_SCOPE) set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) + set(${key}_RPATHS "${rpaths}" PARENT_SCOPE) else() #message("warning: item key '${key}' already in the list, subsequent references assumed identical to first") endif() @@ -490,14 +523,9 @@ function(get_bundle_keys app libs dirs keys_var) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - # Always use the exepath of the main bundle executable for @executable_path - # replacements: - # - get_filename_component(exepath "${executable}" PATH) - # But do fixups on all executables in the bundle: # - get_bundle_all_executables("${bundle}" exes) + get_bundle_all_executables("${bundle}" file_list) # For each extra lib, accumulate a key as well and then also accumulate # any of its prerequisites. (Extra libs are typically dynamically loaded @@ -505,12 +533,12 @@ function(get_bundle_keys app libs dirs keys_var) # but that do not show up in otool -L output...) # foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -518,17 +546,17 @@ function(get_bundle_keys app libs dirs keys_var) # The list of keys should be complete when all prerequisites of all # binaries in the bundle have been analyzed. # - foreach(exe ${exes}) + foreach(f ${file_list}) # Add the exe itself to the keys: # - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${f}" "${f}" "${executable}" "${dirs}" 0) # Add each prerequisite to the keys: # set(prereqs "") - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${f}" prereqs 1 1 "${executable}" "${dirs}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${f}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -542,6 +570,7 @@ function(get_bundle_keys app libs dirs keys_var) set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) endforeach() endif() endfunction() @@ -612,7 +641,7 @@ function(copy_resolved_framework_into_bundle resolved_item resolved_embedded_ite endfunction() -function(fixup_bundle_item resolved_embedded_item exepath dirs) +function(fixup_bundle_item resolved_embedded_item executable dirs) # This item's key is "ikey": # get_item_key("${resolved_embedded_item}" ikey) @@ -622,7 +651,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) # tree, or in other varied locations around the file system, with our call to # install_name_tool. Make sure that doesn't happen here: # - get_dotapp_dir("${exepath}" exe_dotapp_dir) + get_dotapp_dir("${executable}" exe_dotapp_dir) string(LENGTH "${exe_dotapp_dir}/" exe_dotapp_dir_length) string(LENGTH "${resolved_embedded_item}" resolved_embedded_item_length) set(path_too_short 0) @@ -648,7 +677,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) endif() set(prereqs "") - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}") + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${executable}" "${dirs}") set(changes "") @@ -668,12 +697,20 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) execute_process(COMMAND chmod u+w "${resolved_embedded_item}") endif() + foreach(rpath ${${ikey}_RPATHS}) + set(changes ${changes} -delete_rpath "${rpath}") + endforeach() + + if(${ikey}_EMBEDDED_ITEM) + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") + endif() + # Change this item's id and all of its references in one call # to install_name_tool: # - execute_process(COMMAND install_name_tool - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" - ) + if(changes) + execute_process(COMMAND install_name_tool ${changes} "${resolved_embedded_item}") + endif() endfunction() @@ -685,8 +722,6 @@ function(fixup_bundle app libs dirs) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - get_filename_component(exepath "${executable}" PATH) - message(STATUS "fixup_bundle: preparing...") get_bundle_keys("${app}" "${libs}" "${dirs}" keys) @@ -732,7 +767,7 @@ function(fixup_bundle app libs dirs) math(EXPR i ${i}+1) if(APPLE) message(STATUS "${i}/${n}: fixing up '${${key}_RESOLVED_EMBEDDED_ITEM}'") - fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${exepath}" "${dirs}") + fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${executable}" "${dirs}") else() message(STATUS "${i}/${n}: fix-up not required on this platform '${${key}_RESOLVED_EMBEDDED_ITEM}'") endif() @@ -757,55 +792,49 @@ function(copy_and_fixup_bundle src dst libs dirs) endfunction() -function(verify_bundle_prerequisites bundle result_var info_var) +function(verify_bundle_prerequisites bundle executable result_var info_var) set(result 1) set(info "") set(count 0) - get_bundle_main_executable("${bundle}" main_bundle_exe) - - file(GLOB_RECURSE file_list "${bundle}/*") + get_bundle_all_executables("${bundle}" file_list) foreach(f ${file_list}) - is_file_executable("${f}" is_executable) - if(is_executable) - get_filename_component(exepath "${f}" PATH) - math(EXPR count "${count} + 1") + math(EXPR count "${count} + 1") - message(STATUS "executable file ${count}: ${f}") + message(STATUS "executable file ${count}: ${f}") - set(prereqs "") - get_prerequisites("${f}" prereqs 1 1 "${exepath}" "") + set(prereqs "") + get_prerequisites("${f}" prereqs 1 1 "${executable}" "") - # On the Mac, - # "embedded" and "system" prerequisites are fine... anything else means - # the bundle's prerequisites are not verified (i.e., the bundle is not - # really "standalone") - # - # On Windows (and others? Linux/Unix/...?) - # "local" and "system" prereqs are fine... - # - set(external_prereqs "") + # On the Mac, + # "embedded" and "system" prerequisites are fine... anything else means + # the bundle's prerequisites are not verified (i.e., the bundle is not + # really "standalone") + # + # On Windows (and others? Linux/Unix/...?) + # "local" and "system" prereqs are fine... + # + set(external_prereqs "") - foreach(p ${prereqs}) - set(p_type "") - gp_file_type("${f}" "${p}" p_type) + foreach(p ${prereqs}) + set(p_type "") + gp_file_type("${f}" "${p}" "${executable}" p_type) - if(APPLE) - if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL "system") - set(external_prereqs ${external_prereqs} "${p}") - endif() - else() - if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL "system") - set(external_prereqs ${external_prereqs} "${p}") - endif() + if(APPLE) + if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL "system") + set(external_prereqs ${external_prereqs} "${p}") + endif() + else() + if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL "system") + set(external_prereqs ${external_prereqs} "${p}") endif() - endforeach() - - if(external_prereqs) - # Found non-system/somehow-unacceptable prerequisites: - set(result 0) - set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() + endforeach() + + if(external_prereqs) + # Found non-system/somehow-unacceptable prerequisites: + set(result 0) + set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() endforeach() @@ -845,7 +874,7 @@ function(verify_app app) # Verify that the bundle does not have any "external" prerequisites: # - verify_bundle_prerequisites("${bundle}" verified info) + verify_bundle_prerequisites("${bundle}" "${executable}" verified info) message(STATUS "verified='${verified}'") message(STATUS "info='${info}'") message(STATUS "") diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 49443e3..29a8470 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -41,7 +41,7 @@ # :: # # GET_PREREQUISITES( -# ) +# ) # # Get the list of shared library files required by . The list # in the variable named should be empty on first @@ -53,7 +53,7 @@ # must be 0 or 1 indicating whether to include or # exclude "system" prerequisites. If is set to 1 all # prerequisites will be found recursively, if set to 0 only direct -# prerequisites are listed. is the path to the top level +# prerequisites are listed. is the path to the top level # executable used for @executable_path replacment on the Mac. is # a list of paths where libraries might be found: these paths are # searched first when a target without any path info is given. Then @@ -113,7 +113,7 @@ # # :: # -# GP_RESOLVE_ITEM( ) +# GP_RESOLVE_ITEM( ) # # Resolve an item into an existing full path file. # @@ -122,13 +122,13 @@ # # :: # -# GP_RESOLVED_FILE_TYPE( ) +# GP_RESOLVED_FILE_TYPE( ) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named # . # -# Use and if necessary to resolve non-absolute +# Use and if necessary to resolve non-absolute # values -- but only for non-embedded items. # # Possible types are: @@ -318,10 +318,12 @@ function(gp_item_default_embedded_path item default_embedded_path_var) endfunction() -function(gp_resolve_item context item exepath dirs resolved_item_var) +function(gp_resolve_item context item executable dirs resolved_item_var) set(resolved 0) set(resolved_item "${item}") + get_filename_component(exepath "${executable}" PATH) + # Is it already resolved? # if(IS_ABSOLUTE "${resolved_item}" AND EXISTS "${resolved_item}") @@ -331,7 +333,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) if(NOT resolved) if(item MATCHES "^@executable_path") # - # @executable_path references are assumed relative to exepath + # @executable_path references are assumed relative to executable # string(REPLACE "@executable_path" "${exepath}" ri "${item}") get_filename_component(ri "${ri}" ABSOLUTE) @@ -374,10 +376,11 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) # string(REPLACE "@rpath/" "" norpath_item "${item}") + get_item_key("${executable}" key) set(ri "ri-NOTFOUND") - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) + find_file(ri "${norpath_item}" ${dirs} ${${key}_RPATHS} NO_DEFAULT_PATH) if(ri) - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") + #message(STATUS "info: 'find_file' in exepath/rpaths/dirs (${ri})") set(resolved 1) set(resolved_item "${ri}") set(ri "ri-NOTFOUND") @@ -436,7 +439,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) # by whatever logic they choose: # if(COMMAND gp_resolve_item_override) - gp_resolve_item_override("${context}" "${item}" "${exepath}" "${dirs}" resolved_item resolved) + gp_resolve_item_override("${context}" "${item}" "${executable}" "${dirs}" resolved_item resolved) endif() if(NOT resolved) @@ -459,7 +462,7 @@ warning: cannot resolve item '${item}' # # context='${context}' # item='${item}' -# exepath='${exepath}' +# executable='${executable}' # dirs='${dirs}' # resolved_item_var='${resolved_item_var}' #****************************************************************************** @@ -470,7 +473,7 @@ warning: cannot resolve item '${item}' endfunction() -function(gp_resolved_file_type original_file file exepath dirs type_var) +function(gp_resolved_file_type original_file file executable dirs type_var) #message(STATUS "**") if(NOT IS_ABSOLUTE "${original_file}") @@ -489,7 +492,7 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) if(NOT is_embedded) if(NOT IS_ABSOLUTE "${file}") - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file) + gp_resolve_item("${original_file}" "${file}" "${executable}" "${dirs}" resolved_file) endif() string(TOLOWER "${original_file}" original_lower) @@ -595,21 +598,19 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) endfunction() -function(gp_file_type original_file file type_var) +function(gp_file_type original_file file executable type_var) if(NOT IS_ABSOLUTE "${original_file}") message(STATUS "warning: gp_file_type expects absolute full path for first arg original_file") endif() - get_filename_component(exepath "${original_file}" PATH) - set(type "") - gp_resolved_file_type("${original_file}" "${file}" "${exepath}" "" type) + gp_resolved_file_type("${original_file}" "${file}" "${executable}" "" type) set(${type_var} "${type}" PARENT_SCOPE) endfunction() -function(get_prerequisites target prerequisites_var exclude_system recurse exepath dirs) +function(get_prerequisites target prerequisites_var exclude_system recurse executable dirs) set(verbose 0) set(eol_char "E") @@ -738,6 +739,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if("${gp_tool}" STREQUAL "ldd") set(old_ld_env "$ENV{LD_LIBRARY_PATH}") + get_filename_component(exepath "${executable}" PATH) set(new_ld_env "${exepath}") foreach(dir ${dirs}) set(new_ld_env "${new_ld_env}:${dir}") @@ -834,7 +836,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(add_item AND ${exclude_system}) set(type "") - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type) + gp_resolved_file_type("${target}" "${item}" "${executable}" "${dirs}" type) if("${type}" STREQUAL "system") set(add_item 0) @@ -855,7 +857,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa # that the analysis tools can simply accept it as input. # if(NOT list_length_before_append EQUAL list_length_after_append) - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${target}" "${item}" "${executable}" "${dirs}" resolved_item) set(unseen_prereqs ${unseen_prereqs} "${resolved_item}") endif() endif() @@ -874,7 +876,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(${recurse}) set(more_inputs ${unseen_prereqs}) foreach(input ${more_inputs}) - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}") + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${executable}" "${dirs}") endforeach() endif() @@ -911,7 +913,7 @@ function(list_prerequisites target) get_filename_component(exepath "${target}" PATH) set(prereqs "") - get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${exepath}" "") + get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${target}" "") if(print_target) message(STATUS "File '${target}' depends on:") @@ -925,7 +927,7 @@ function(list_prerequisites target) endif() if(print_prerequisite_type) - gp_file_type("${target}" "${d}" type) + gp_file_type("${target}" "${d}" "" type) set(type_str " (${type})") endif() -- 1.9.3 (Apple Git-50) From ono at java.pl Fri Sep 5 07:50:42 2014 From: ono at java.pl (Adam Strzelecki) Date: Fri, 5 Sep 2014 13:50:42 +0200 Subject: [cmake-developers] [PATCH 4/6] Process executables first when scanning bundle In-Reply-To: <952D2C19-AD78-4E46-BAE0-B2F0F4DF7C2E@java.pl> References: <952D2C19-AD78-4E46-BAE0-B2F0F4DF7C2E@java.pl> Message-ID: <1409917844-28297-4-git-send-email-ono@java.pl> This makes rpaths populated (if any), so libraries containing @rpath will be resolved properly. --- Modules/BundleUtilities.cmake | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 9733bc9..e99da9b 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -527,21 +527,6 @@ function(get_bundle_keys app libs dirs keys_var) # get_bundle_all_executables("${bundle}" file_list) - # For each extra lib, accumulate a key as well and then also accumulate - # any of its prerequisites. (Extra libs are typically dynamically loaded - # plugins: libraries that are prerequisites for full runtime functionality - # but that do not show up in otool -L output...) - # - foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) - - set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") - foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) - endforeach() - endforeach() - # For each executable found in the bundle, accumulate keys as we go. # The list of keys should be complete when all prerequisites of all # binaries in the bundle have been analyzed. @@ -560,6 +545,21 @@ function(get_bundle_keys app libs dirs keys_var) endforeach() endforeach() + # For each extra lib, accumulate a key as well and then also accumulate + # any of its prerequisites. (Extra libs are typically dynamically loaded + # plugins: libraries that are prerequisites for full runtime functionality + # but that do not show up in otool -L output...) + # + foreach(lib ${libs}) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) + + set(prereqs "") + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") + foreach(pr ${prereqs}) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) + endforeach() + endforeach() + # Propagate values to caller's scope: # set(${keys_var} ${${keys_var}} PARENT_SCOPE) -- 1.9.3 (Apple Git-50) From ono at java.pl Fri Sep 5 07:53:26 2014 From: ono at java.pl (Adam Strzelecki) Date: Fri, 5 Sep 2014 13:53:26 +0200 Subject: [cmake-developers] OS X packaging updates In-Reply-To: <5408B278.2070400@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> <5408B278.2070400@kitware.com> Message-ID: <4C094659-30A8-4304-ADBD-C62A1788C2A0@java.pl> I have sent updated 3/6 & 4/6. Rest of patches remain the same. I've tested on all 3 platforms: OSX, Windows & Linux. Tests are now running fine. Regards -- Adam From brad.king at kitware.com Fri Sep 5 08:33:04 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Sep 2014 08:33:04 -0400 Subject: [cmake-developers] OS X packaging updates In-Reply-To: <4C094659-30A8-4304-ADBD-C62A1788C2A0@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> <5408B278.2070400@kitware.com> <4C094659-30A8-4304-ADBD-C62A1788C2A0@java.pl> Message-ID: <5409AD80.2000303@kitware.com> On 09/05/2014 07:53 AM, Adam Strzelecki wrote: > I have sent updated 3/6 & 4/6. Rest of patches remain the same. > I've tested on all 3 platforms: OSX, Windows & Linux. Thanks. I've re-built the topic with those locally. I will merge again for testing next week when some issues caused by other topics have been resolved. -Brad From brad.king at kitware.com Fri Sep 5 08:50:06 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Sep 2014 08:50:06 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <54088C10.50601@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> Message-ID: <5409B17E.4050503@kitware.com> On 09/04/2014 11:58 AM, Nils Gladitz wrote: > Thanks, that actually sounds doable. > > I'll give it a try. Good work on the topic so far. I have a few more thoughts: - The dashboard submissions that bootstrap got many CMP0054 warnings. Most of them are the same warning repeated due to presence in a macro or loop. Please update the warning to not warn on the same line more than once. A set<> of already-emitted warning lines can be kept somewhere. - I think we can generalize the policy a bit further. Consider: set(x EXISTS) if("${x}" STREQUAL "EXISTS") Currently that will get an error because the evaluated variable spells "EXISTS" which is treated as a keyword. The policy could also make if() honor such keywords only when they are unquoted. - The new cmExpandedCommandArgument class interface could be simplified by making it derive from std::string and then just add the boolean as an extra member. - In the documentation we need to be precise about when the expansion is still allowed. The cmake-language(7) manual defines unquoted, "quoted", and [[bracket]] arguments as distinct argument types. We should use the same terminology here. You can even link back to the manual with cross-reference syntax: :ref:`Bracket Argument` :ref:`Quoted Argument` :ref:`Unquoted Argument` Also please extend the test cases for this policy to cover: - All if() command conditions that do variable-or-string. - if() inside a macro() and a function(), covering each combination of policy settings when the macro/function is recorded and when it is invoked. The policy value should be that when the macro/function was recorded. Thanks, -Brad From pascal.bach at siemens.com Fri Sep 5 09:16:53 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Fri, 5 Sep 2014 13:16:53 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <54088D58.70408@kitware.com> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> >> Right, it gets called inside try_compile projects too. Actually >> the SDK information will have to be propagated into those too. >> That means it needs to go in files like CMakeSystem.cmake or >> CMakeCCompiler.cmake that are configured in the build tree, >> or be explicitly propagated by cmMakefile::TryCompile like the >> GeneratorToolset is. > > With the current implementation I sent this seems to work and the SDK > ends up in > > The generated vxproj files for try compile. > > I don't see anything in the patch that could do that. > > CMakeDetermineCompilerId generates a test .vcxproj file that > gets the value from CMAKE_VS_PLATFORM_NAME. That one is in > the CompilerId directory. Is that the one you checked? > It is not from a try_compile. > I'm not clear what you mean. As far as I understand the solution files that do try compile are generated using the same generator that generates the final solution file. So if I change it I it also gets into try compile. Maybe I'm missing something. Pascal From pascal.bach at siemens.com Fri Sep 5 09:18:45 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Fri, 5 Sep 2014 13:18:45 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <355BE46A91031048906B695426A8D8E616ACEC1E@DEFTHW99EH4MSX.ww902.siemens.net> Here is an update version of my patchset: It also works with older versions of Windows CE but it tells the user that he might to manually se the CMAKE_PLATFORM_TOOLSET (I hope the resubmission is OK like this) >From 145c3189abf84aca046f555c5452396f0e5936eb Mon Sep 17 00:00:00 2001 From: Pascal Bach Date: Thu, 4 Sep 2014 13:32:30 +0200 Subject: [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio - Allow setting CMAKE_VS_WINCE_SDK to specify the SDK. - The user is warned if he uses a version different Windows CE different from 8.0 and not CMAKE_PLATFORM_TOOLSET is specified. - Docuentation for WINCE and CMAKE_VS_WINCE_SDK added. --- Help/variable/CMAKE_VS_WINCE_SDK.rst | 13 +++++++ Help/variable/WINCE.rst | 5 +++ Source/cmGlobalVisualStudio10Generator.cxx | 55 ++++++++++++++++++++++++++++ Source/cmGlobalVisualStudio10Generator.h | 7 ++++ Source/cmGlobalVisualStudio11Generator.cxx | 12 ++++++ Source/cmGlobalVisualStudio11Generator.h | 2 + Source/cmGlobalVisualStudio12Generator.cxx | 12 ++++++ Source/cmGlobalVisualStudio12Generator.h | 2 + 8 files changed, 108 insertions(+) create mode 100644 Help/variable/CMAKE_VS_WINCE_SDK.rst create mode 100644 Help/variable/WINCE.rst diff --git a/Help/variable/CMAKE_VS_WINCE_SDK.rst b/Help/variable/CMAKE_VS_WINCE_SDK.rst new file mode 100644 index 0000000..ef39b84 --- /dev/null +++ b/Help/variable/CMAKE_VS_WINCE_SDK.rst @@ -0,0 +1,13 @@ +CMAKE_VS_WINCE_SDK +------------------ + +Windows CE SDK to use together with the Visual Studio 10+ generators. + +If :variable:`CMAKE_SYSTEM_NAME` is set to Windows CE, this variable +allows to specify the SDK name that should be used to build the application. + +The value of this variable should never be modified by project code. +A toolchain file specified by the :variable:`CMAKE_TOOLCHAIN_FILE` +variable may initialize ``CMAKE_VS_WINCE_SDK``. Once a given +build tree has been initialized with a particular value for this +variable, changing the value has undefined behavior. diff --git a/Help/variable/WINCE.rst b/Help/variable/WINCE.rst new file mode 100644 index 0000000..54ff7de --- /dev/null +++ b/Help/variable/WINCE.rst @@ -0,0 +1,5 @@ +WINCE +----- + +True when the :variable:`CMAKE_SYSTEM_NAME` variable is set +to ``WindowsCE``. diff --git a/Source/cmGlobalVisualStudio10Generator.cxx b/Source/cmGlobalVisualStudio10Generator.cxx index 19aa52c..81a9723 100644 --- a/Source/cmGlobalVisualStudio10Generator.cxx +++ b/Source/cmGlobalVisualStudio10Generator.cxx @@ -165,6 +165,14 @@ bool cmGlobalVisualStudio10Generator::InitializeSystem(cmMakefile* mf) return false; } } + else if (this->SystemName == "WindowsCE") + { + this->SystemIsWindowsCE = true; + if (!this->InitializeWindowsCE(mf)) + { + return false; + } + } return true; } @@ -187,6 +195,53 @@ bool cmGlobalVisualStudio10Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio10Generator::InitializeWindowsCE(cmMakefile* mf) +{ + // To preserve the old behaviour just return the DefaultPlatformToolset + // for unknown Windows CE versions, in the worst case the user has to set + // CMAKE_GENERATOR_TOOLSET manually. In that case warn the user. + std::string platformToolset = this->SelectWindowsCEToolset(); + if (!platformToolset.empty()) + { + this->DefaultPlatformToolset = platformToolset; + } + else + { + cmOStringStream e; + e << this->GetName() << " Windows CE version '" << this->SystemVersion + << "' might require CMAKE_GENERATOR_TOOLSET to be set."; + mf->IssueMessage(cmake::WARNING, e.str()); + } + + if (const char* platformName = mf->GetDefinition("CMAKE_VS_WINCE_SDK")) + { + this->PlatformName = platformName; + } + else { + cmOStringStream e; + e << this->GetName() << " for " << this->GetSystemName() << " requires an " + << "SDK. Please set CMAKE_VS_WINCE_SDK to the name of your SDK."; + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); + return false; + } + + return true; +} + +//---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio10Generator::SelectWindowsCEToolset() const +{ + if (this->SystemVersion == "8.0") + { + return "CE800"; + } + else + { + return ""; + } +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio10Generator ::AddVSPlatformToolsetDefinition(cmMakefile* mf) const { diff --git a/Source/cmGlobalVisualStudio10Generator.h b/Source/cmGlobalVisualStudio10Generator.h index 11fa954..9bceb2c 100644 --- a/Source/cmGlobalVisualStudio10Generator.h +++ b/Source/cmGlobalVisualStudio10Generator.h @@ -75,6 +75,10 @@ public: bool TargetsWindowsStore() const { return this->SystemIsWindowsStore; } + /** Return true if building for WindowsCE */ + bool TargetsWindowsCE() const + { return this->SystemIsWindowsCE; } + /** * Where does this version of Visual Studio look for macros for the * current user? Returns the empty string if this version of Visual @@ -106,8 +110,10 @@ protected: virtual bool InitializeSystem(cmMakefile* mf); virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const { return ""; } virtual std::string SelectWindowsStoreToolset() const { return ""; } + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "10.0"; } @@ -119,6 +125,7 @@ protected: std::string SystemVersion; bool SystemIsWindowsPhone; bool SystemIsWindowsStore; + bool SystemIsWindowsCE; bool ExpressEdition; bool UseFolderProperty(); diff --git a/Source/cmGlobalVisualStudio11Generator.cxx b/Source/cmGlobalVisualStudio11Generator.cxx index 39bbdc0..a71c42e 100644 --- a/Source/cmGlobalVisualStudio11Generator.cxx +++ b/Source/cmGlobalVisualStudio11Generator.cxx @@ -159,6 +159,12 @@ bool cmGlobalVisualStudio11Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio11Generator::InitializeWindowsCE(cmMakefile* mf) +{ + return cmGlobalVisualStudio10Generator::InitializeWindowsCE(mf); +} + +//---------------------------------------------------------------------------- std::string cmGlobalVisualStudio11Generator::SelectWindowsPhoneToolset() const { if(this->SystemVersion == "8.0") @@ -179,6 +185,12 @@ std::string cmGlobalVisualStudio11Generator::SelectWindowsStoreToolset() const } //---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio11Generator::SelectWindowsCEToolset() const +{ + return this->cmGlobalVisualStudio10Generator::SelectWindowsCEToolset(); +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio11Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; diff --git a/Source/cmGlobalVisualStudio11Generator.h b/Source/cmGlobalVisualStudio11Generator.h index bbd935c..9dd3271 100644 --- a/Source/cmGlobalVisualStudio11Generator.h +++ b/Source/cmGlobalVisualStudio11Generator.h @@ -36,8 +36,10 @@ public: protected: virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const; virtual std::string SelectWindowsStoreToolset() const; + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "11.0"; } bool UseFolderProperty(); static std::set GetInstalledWindowsCESDKs(); diff --git a/Source/cmGlobalVisualStudio12Generator.cxx b/Source/cmGlobalVisualStudio12Generator.cxx index 29ecfe0..c784cae 100644 --- a/Source/cmGlobalVisualStudio12Generator.cxx +++ b/Source/cmGlobalVisualStudio12Generator.cxx @@ -139,6 +139,12 @@ bool cmGlobalVisualStudio12Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio12Generator::InitializeWindowsCE(cmMakefile* mf) +{ + return cmGlobalVisualStudio11Generator::InitializeWindowsCE(mf); +} + +//---------------------------------------------------------------------------- std::string cmGlobalVisualStudio12Generator::SelectWindowsPhoneToolset() const { if(this->SystemVersion == "8.1") @@ -159,6 +165,12 @@ std::string cmGlobalVisualStudio12Generator::SelectWindowsStoreToolset() const } //---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio12Generator::SelectWindowsCEToolset() const +{ + return this->cmGlobalVisualStudio11Generator::SelectWindowsCEToolset(); +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio12Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; diff --git a/Source/cmGlobalVisualStudio12Generator.h b/Source/cmGlobalVisualStudio12Generator.h index ec85f10..5d8c125 100644 --- a/Source/cmGlobalVisualStudio12Generator.h +++ b/Source/cmGlobalVisualStudio12Generator.h @@ -41,8 +41,10 @@ public: protected: virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const; virtual std::string SelectWindowsStoreToolset() const; + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "12.0"; } private: class Factory; -- 1.7.10.4 From nilsgladitz at gmail.com Fri Sep 5 09:19:48 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 05 Sep 2014 15:19:48 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5409B17E.4050503@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> Message-ID: <5409B874.2060607@gmail.com> On 09/05/2014 02:50 PM, Brad King wrote: > On 09/04/2014 11:58 AM, Nils Gladitz wrote: > - The dashboard submissions that bootstrap got many CMP0054 > warnings. Most of them are the same warning repeated due > to presence in a macro or loop. Please update the warning > to not warn on the same line more than once. A set<> of > already-emitted warning lines can be kept somewhere. I'll look into it. Would it be ok to set the policy for cmcurl to OLD? I assume that makes it easier to pull changes from upstream than when I fix the code to comply with the new policy; also it isn't always clear what the intention was with the given conditionals and I am more likely to break something. > > - I think we can generalize the policy a bit further. Consider: > > set(x EXISTS) > if("${x}" STREQUAL "EXISTS") > > Currently that will get an error because the evaluated > variable spells "EXISTS" which is treated as a keyword. > The policy could also make if() honor such keywords only > when they are unquoted. > I'll look into it. > - The new cmExpandedCommandArgument class interface could > be simplified by making it derive from std::string and > then just add the boolean as an extra member. I think composition is cleaner and more future proof in this case though; I'd like to keep it unless you insist it should be changed. > - In the documentation we need to be precise about when > the expansion is still allowed. The cmake-language(7) > manual defines unquoted, "quoted", and [[bracket]] > arguments as distinct argument types. We should use the > same terminology here. You can even link back to the > manual with cross-reference syntax: > > :ref:`Bracket Argument` > :ref:`Quoted Argument` > :ref:`Unquoted Argument` I kept the distinction in cmExpandedCommandArgument at first but then generalized it so that bracketed, quoted and C++ side "0", "1" constant arguments would be subsumed. This could be expanded again if there are future use cases where they need to be distinguished. I'll document the current behavior for if(). > Also please extend the test cases for this policy to cover: > > - All if() command conditions that do variable-or-string. Will do. I was also thinking about setting up an alternative testing infrastructure parallel to RunCMake which runs cmake in script mode rather than performing configuration/generation. It would be nice to have something less granular which would allow multiple related test cases, expected outputs and exit statuses in a single file (which I think could be nicely done with the new bracket syntax). Not for this topic obviously but would this make sense in general? e.g. something similar to expect_failure( [[ if( ]], [[Parse error. Function missing ending ")". End of file reached. ]]) > - if() inside a macro() and a function(), covering each > combination of policy settings when the macro/function > is recorded and when it is invoked. The policy value > should be that when the macro/function was recorded. Is that behavior command specific? Isn't it covered by policy testing in general? Nils From brad.king at kitware.com Fri Sep 5 09:31:51 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Sep 2014 09:31:51 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5409B874.2060607@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> Message-ID: <5409BB47.3000309@kitware.com> On 09/05/2014 09:19 AM, Nils Gladitz wrote: > Would it be ok to set the policy for cmcurl to OLD? No, but the code could be fixed to not trigger the warning. See similar changes here: Check*: Allow result variables to contain regex special characters http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4f2fcce4 Alternatively, just let the warnings go for now so we can see how they look. Then we can fix the code in a follow-up change. > I kept the distinction in cmExpandedCommandArgument at first but then > generalized it so that bracketed, quoted and C++ side "0", "1" constant > arguments would be subsumed. This could be expanded again if there are > future use cases where they need to be distinguished. That's fine. I'm just talking about the documentation. Right now it says "quoted" arguments do not expand in the NEW behavior. It should say something more like "only unquoted arguments expand" since both "quoted" and [[bracket]] arguments are left alone now. > I was also thinking about setting up an alternative testing > infrastructure parallel to RunCMake which runs cmake in script mode > rather than performing configuration/generation. You can use "run_cmake_command" to run arbitrary cmake command-line signatures and still use the rest of the infrastructure. > It would be nice to have something less granular which would allow > multiple related test cases, expected outputs and exit statuses in a > single file (which I think could be nicely done with the new bracket > syntax). > > Not for this topic obviously but would this make sense in general? Yes. The existing RunCMake infrastructure could be extended with more commands that take the expected pieces directly as arguments. Then the current infrastructure could be ported to use it after reading info from the files. >> - if() inside a macro() and a function(), covering each >> combination of policy settings when the macro/function >> is recorded and when it is invoked. The policy value >> should be that when the macro/function was recorded. > > Is that behavior command specific? > Isn't it covered by policy testing in general? The policy scope is general behavior, but we need to know that the forwarding of arguments into commands when replayed from macro/function works correctly to implement this policy. Thanks, -Brad From dlrdave at aol.com Fri Sep 5 09:33:29 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 5 Sep 2014 09:33:29 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion Message-ID: <8D197251CDF9BB9-15CC-1A84C@webmail-m269.sysops.aol.com> > I was also thinking about setting up an alternative testing > infrastructure parallel to RunCMake which runs cmake in script mode > rather than performing configuration/generation. This already exists in a form in the Tests/CMakeTests/*TestScript* tests. An example: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/CMakeTests/StringTestScript.cmake;h=a562e71d38ff7db040e567f0ef9b899c2101bc9f;hb=ff1fddb0bf40b8a7170d54ccdc9420c2d7190472 Any *TestScript* file also requires a "driving" *Test.cmake.in file and an entry in Tests/CMakeTests/CMakeLists.txt, but the infrastructure is there already. Actually, there are two infrastructures in that folder, but this one is similar to the one you're proposing. HTH, David C. From nilsgladitz at gmail.com Fri Sep 5 09:50:40 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 05 Sep 2014 15:50:40 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5409BB47.3000309@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <5409BB47.3000309@kitware.com> Message-ID: <5409BFB0.1060408@gmail.com> On 09/05/2014 03:31 PM, Brad King wrote: > You can use "run_cmake_command" to run arbitrary cmake command-line > signatures and still use the rest of the infrastructure. Ok. I just thought it would be nice to distinguish tests that don't configure a project. (Headline for RunCMake is "This directory contains tests that run CMake to configure a project but do not actually build anything.") E.g. have a well defined set of tests which are generator independent as well. Nils From brad.king at kitware.com Fri Sep 5 09:59:42 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Sep 2014 09:59:42 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <5409C1CE.1010501@kitware.com> On 09/05/2014 09:16 AM, Bach, Pascal wrote: > I'm not clear what you mean. > As far as I understand the solution files that do try compile > are generated using the same generator that generates the > final solution file. A generator with the same name is used but it is not the same instance of cmGlobalGenerator. See cmMakefile::TryCompile: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmMakefile.cxx;hb=v3.0.1#l3080 It creates a new generator, but also does cm.SetIsInTryCompile(true) on the temporary try_compile cmake instance. That tells the generator's EnableLanguage method to load settings for languages from the existing files created by the outer generator. The try_compile generator is explicitly given the toolset: cm.SetGeneratorToolset(this->GetCMakeInstance()->GetGeneratorToolset()); but the rest of the information (e.g. CMAKE_SYSTEM_NAME) gets loaded from CMakeFiles//CMakeSystem.cmake and a few per-language files. The CMAKE_VS_WINCE_SDK value (or whatever more general name we choose) will have to go through here too. Since CMakeSystem.cmake loads the CMAKE_TOOLCHAIN_FILE, try_compile should use CMAKE_VS_WINCE_SDK when the value is set in the toolchain file. Is this the case when you test the changes locally? On 09/05/2014 09:18 AM, Bach, Pascal wrote: > (I hope the resubmission is OK like this) Yes, revised patch resubmissions are just right. Thanks, -Brad From nilsgladitz at gmail.com Fri Sep 5 09:59:18 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 05 Sep 2014 15:59:18 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <8D197251CDF9BB9-15CC-1A84C@webmail-m269.sysops.aol.com> References: <8D197251CDF9BB9-15CC-1A84C@webmail-m269.sysops.aol.com> Message-ID: <5409C1B6.6020102@gmail.com> On 09/05/2014 03:33 PM, David Cole wrote: >> I was also thinking about setting up an alternative testing >> infrastructure parallel to RunCMake which runs cmake in script mode >> rather than performing configuration/generation. > > This already exists in a form in the Tests/CMakeTests/*TestScript* > tests. > > An example: > http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/CMakeTests/StringTestScript.cmake;h=a562e71d38ff7db040e567f0ef9b899c2101bc9f;hb=ff1fddb0bf40b8a7170d54ccdc9420c2d7190472 > > > Any *TestScript* file also requires a "driving" *Test.cmake.in file and > an entry in Tests/CMakeTests/CMakeLists.txt, but the infrastructure is > there already. Actually, there are two infrastructures in that folder, > but this one is similar to the one you're proposing. I used the second infrastructure for the TIMESTAMP tests apparently. Those feel similar to the tests in RunCMake e.g. lots of files that I would prefer to combine into something more compact. The other infrastructure I don't think I have touched but optically it looks very noisy. Having something that takes away repetitive tasks, more compact and easier on the eye would be nice. Nils From pascal.bach at siemens.com Fri Sep 5 10:02:58 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Fri, 5 Sep 2014 14:02:58 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <5409C1CE.1010501@kitware.com> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> <5409C1CE.1010501@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACEC74@DEFTHW99EH4MSX.ww902.siemens.net> > On 09/05/2014 09:16 AM, Bach, Pascal wrote: > > I'm not clear what you mean. > > As far as I understand the solution files that do try compile > > are generated using the same generator that generates the > > final solution file. > > A generator with the same name is used but it is not the same > instance of cmGlobalGenerator. See cmMakefile::TryCompile: > > > http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmMakefile.c > xx;hb=v3.0.1#l3080 > > It creates a new generator, but also does cm.SetIsInTryCompile(true) > on the temporary try_compile cmake instance. That tells the > generator's EnableLanguage method to load settings for languages > from the existing files created by the outer generator. > > The try_compile generator is explicitly given the toolset: > > cm.SetGeneratorToolset(this->GetCMakeInstance()- > >GetGeneratorToolset()); > > but the rest of the information (e.g. CMAKE_SYSTEM_NAME) gets > loaded from CMakeFiles//CMakeSystem.cmake and a few > per-language files. The CMAKE_VS_WINCE_SDK value (or whatever more > general name we choose) will have to go through here too. Ok now I understand. > Since CMakeSystem.cmake loads the CMAKE_TOOLCHAIN_FILE, try_compile > should use CMAKE_VS_WINCE_SDK when the value is set in the toolchain > file. Is this the case when you test the changes locally? > The case I was testing was indeed with the CMAKE_VS_WINCE_SDK set inside the toolchain file. I guess to support this variable only in the toolchain file is not an option? Pascal From brad.king at kitware.com Fri Sep 5 10:04:41 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Sep 2014 10:04:41 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5409BFB0.1060408@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <5409BB47.3000309@kitware.com> <5409BFB0.1060408@gmail.com> Message-ID: <5409C2F9.30600@kitware.com> On 09/05/2014 09:50 AM, Nils Gladitz wrote: > On 09/05/2014 03:31 PM, Brad King wrote: >> You can use "run_cmake_command" to run arbitrary cmake command-line >> signatures and still use the rest of the infrastructure. > > Ok. I just thought it would be nice to distinguish tests that don't > configure a project. (Headline for RunCMake is "This directory contains > tests that run CMake to configure a project but do not actually build > anything.") > > E.g. have a well defined set of tests which are generator independent as > well. I think the description of RunCMake can just be updated. All of its tests are about running "cmake" command lines. -Brad From nilsgladitz at gmail.com Fri Sep 5 10:17:52 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 05 Sep 2014 16:17:52 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5409C2F9.30600@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <5409BB47.3000309@kitware.com> <5409BFB0.1060408@gmail.com> <5409C2F9.30600@kitware.com> Message-ID: <5409C610.8030203@gmail.com> >> On 09/05/2014 03:31 PM, Brad King wrote: > > I think the description of RunCMake can just be updated. > All of its tests are about running "cmake" command lines. So you see no advantage to having the distinction? E.g. if you consider testing a set of generators (or variants of the same generator) possibly non-native and distinct from the generator being used to build cmake itself it might make sense to run tests which perform configuration once for each of those but script mode tests would only have to be run once. Nils From clinton at elemtech.com Fri Sep 5 08:29:34 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Fri, 5 Sep 2014 06:29:34 -0600 (MDT) Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <1409917844-28297-3-git-send-email-ono@java.pl> References: <952D2C19-AD78-4E46-BAE0-B2F0F4DF7C2E@java.pl> <1409917844-28297-3-git-send-email-ono@java.pl> Message-ID: <43520581.222701.1409920174530.JavaMail.zimbra@elemtech.com> I think it would be nice to move get_item_rpaths() from BundleUtilities.cmake to gp_item_get_rpaths() in GetPrerequisites.cmake. And how does your patch or patch set handle @loader_path being used in the rpath? Also, I think the function signature should include the rpath vs runpath distinction. I realize OS X doesn't have the runpath concept, but if one were to add support for Linux, one may need that where the runpath affects only finding immediate dependencies. Below is what I have for Linux and OS X. It include rpath vs. runpath, and expands out the @loader_path variable. Does it help, or did you have something else in mind? # Get rpaths for a binary. function(get_rpaths binary rpaths run_paths) get_filename_component(binary_dir "${binary}" PATH) unset(myrpaths) unset(myrunpaths) if(APPLE) execute_process(COMMAND otool -l "${binary}" COMMAND grep -A2 LC_RPATH COMMAND grep path OUTPUT_VARIABLE paths) string(REPLACE "\n" ";" paths "${paths}") foreach(str ${paths}) string(REGEX REPLACE " path (.*) \\(offset.*" "\\1" rpath "${str}") string(STRIP "${rpath}" rpath) string(REPLACE "@loader_path" "${binary_dir}" rpath "${rpath}") list(APPEND myrpaths "${rpath}") endforeach() else() execute_process(COMMAND objdump -p "${binary}" COMMAND grep RPATH OUTPUT_VARIABLE paths) execute_process(COMMAND objdump -p "${binary}" COMMAND grep RUNPATH OUTPUT_VARIABLE paths2) string(REPLACE "\n" ";" paths "${paths}") string(REPLACE "\n" ";" paths2 "${paths2}") foreach(str ${paths}) string(REGEX REPLACE " RPATH[ ]*(.*)" "\\1" rpath "${str}") string(STRIP "${rpath}" rpath) string(REPLACE "\$ORIGIN" "${binary_dir}" rpath "${rpath}") list(APPEND myrpaths "${rpath}") endforeach() foreach(str ${paths2}) string(REGEX REPLACE " RUNPATH[ ]*(.*)" "\\1" rpath "${str}") string(STRIP "${rpath}" rpath) string(REPLACE "\$ORIGIN" "${binary_dir}" rpath "${rpath}") list(APPEND myrunpaths "${rpath}") endforeach() endif() string(REPLACE ":" ";" myrpaths "${myrpaths}") string(REPLACE ":" ";" myrunpaths "${myrunpaths}") set(${rpaths} ${myrpaths} PARENT_SCOPE) set(${run_paths} ${myrunpaths} PARENT_SCOPE) endfunction() Clint ----- Original Message ----- > This is done by gathering LC_RPATH commands for main bundle executable and > using it for @rpath lookup in dependent frameworks. > > To achieve this all utility functions now take path to executable rather than > path to its directory. > > This enabled apps using @rpath to be bundled correctly, which will be > necessary > for upcoming Qt 5.4 that will use @rpath for all frameworks. > --- > Modules/BundleUtilities.cmake | 169 > ++++++++++++++++++++++++----------------- > Modules/GetPrerequisites.cmake | 48 ++++++------ > 2 files changed, 124 insertions(+), 93 deletions(-) > > diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake > index 7e2b173..9733bc9 100644 > --- a/Modules/BundleUtilities.cmake > +++ b/Modules/BundleUtilities.cmake > @@ -19,6 +19,7 @@ > # get_bundle_and_executable > # get_bundle_all_executables > # get_item_key > +# get_item_rpaths > # clear_bundle_keys > # set_bundle_key_values > # get_bundle_keys > @@ -75,7 +76,7 @@ > # > # :: > # > -# GET_DOTAPP_DIR( ) > +# GET_DOTAPP_DIR( ) > # > # Returns the nearest parent dir whose name ends with ".app" given the > # full path to an executable. If there is no such parent dir, then > @@ -123,7 +124,7 @@ > # > # :: > # > -# SET_BUNDLE_KEY_VALUES( > +# SET_BUNDLE_KEY_VALUES( > # ) > # > # Add a key to the list (if necessary) for the given item. If added, > @@ -163,7 +164,7 @@ > # > # :: > # > -# FIXUP_BUNDLE_ITEM( ) > +# FIXUP_BUNDLE_ITEM( ) > # > # Get the direct/non-system prerequisites of the resolved embedded item. > # For each prerequisite, change the way it is referenced to the value of > @@ -189,11 +190,11 @@ > # > # :: > # > -# VERIFY_BUNDLE_PREREQUISITES( ) > +# VERIFY_BUNDLE_PREREQUISITES( > ) > # > # Verifies that the sum of all prerequisites of all files inside the > -# bundle are contained within the bundle or are "system" libraries, > -# presumed to exist everywhere. > +# bundle with given main executable are contained within the bundle or are > +# "system" libraries, presumed to exist everywhere. > # > # :: > # > @@ -285,8 +286,8 @@ function(get_bundle_main_executable bundle result_var) > endfunction() > > > -function(get_dotapp_dir exe dotapp_dir_var) > - set(s "${exe}") > +function(get_dotapp_dir executable dotapp_dir_var) > + set(s "${executable}") > > if(s MATCHES "/.*\\.app/") > # If there is a ".app" parent directory, > @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) > endfunction() > > > +function(get_item_rpaths item rpaths_var) > + if(APPLE) > + find_program(otool_cmd "otool") > + mark_as_advanced(otool_cmd) > + endif() > + > + if(otool_cmd) > + execute_process( > + COMMAND "${otool_cmd}" -l "${item}" > + OUTPUT_VARIABLE load_cmds_ov > + ) > + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) > \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") > + string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") > + string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") > + if(load_cmds_ov) > + gp_append_unique(${rpaths_var} "${load_cmds_ov}") > + endif() > + endif() > + > + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) > +endfunction() > + > + > function(get_item_key item key_var) > get_filename_component(item_name "${item}" NAME) > if(WIN32) > @@ -425,12 +449,13 @@ function(clear_bundle_keys keys_var) > set(${key}_EMBEDDED_ITEM PARENT_SCOPE) > set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) > set(${key}_COPYFLAG PARENT_SCOPE) > + set(${key}_RPATHS PARENT_SCOPE) > endforeach() > set(${keys_var} PARENT_SCOPE) > endfunction() > > > -function(set_bundle_key_values keys_var context item exepath dirs copyflag) > +function(set_bundle_key_values keys_var context item executable dirs > copyflag) > get_filename_component(item_name "${item}" NAME) > > get_item_key("${item}" key) > @@ -440,10 +465,17 @@ function(set_bundle_key_values keys_var context item > exepath dirs copyflag) > list(LENGTH ${keys_var} length_after) > > if(NOT length_before EQUAL length_after) > - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" > resolved_item) > + # Always use the exepath of the main bundle executable for > @executable_path > + # replacements: > + # > + get_filename_component(exepath "${executable}" PATH) > + > + gp_resolve_item("${context}" "${item}" "${executable}" "${dirs}" > resolved_item) > > gp_item_default_embedded_path("${item}" default_embedded_path) > > + get_item_rpaths("${resolved_item}" rpaths) > + > if(item MATCHES "[^/]+\\.framework/") > # For frameworks, construct the name under the embedded path from the > # opening "${item_name}.framework/" to the closing "/${item_name}": > @@ -479,6 +511,7 @@ function(set_bundle_key_values keys_var context item > exepath dirs copyflag) > set(${key}_EMBEDDED_ITEM "${embedded_item}" PARENT_SCOPE) > set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" > PARENT_SCOPE) > set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) > + set(${key}_RPATHS "${rpaths}" PARENT_SCOPE) > else() > #message("warning: item key '${key}' already in the list, subsequent > references assumed identical to first") > endif() > @@ -490,14 +523,9 @@ function(get_bundle_keys app libs dirs keys_var) > > get_bundle_and_executable("${app}" bundle executable valid) > if(valid) > - # Always use the exepath of the main bundle executable for > @executable_path > - # replacements: > - # > - get_filename_component(exepath "${executable}" PATH) > - > # But do fixups on all executables in the bundle: > # > - get_bundle_all_executables("${bundle}" exes) > + get_bundle_all_executables("${bundle}" file_list) > > # For each extra lib, accumulate a key as well and then also accumulate > # any of its prerequisites. (Extra libs are typically dynamically loaded > @@ -505,12 +533,12 @@ function(get_bundle_keys app libs dirs keys_var) > # but that do not show up in otool -L output...) > # > foreach(lib ${libs}) > - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" > "${dirs}" 0) > + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" > "${dirs}" 0) > > set(prereqs "") > - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") > + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") > foreach(pr ${prereqs}) > - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" > "${dirs}" 1) > + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" > "${dirs}" 1) > endforeach() > endforeach() > > @@ -518,17 +546,17 @@ function(get_bundle_keys app libs dirs keys_var) > # The list of keys should be complete when all prerequisites of all > # binaries in the bundle have been analyzed. > # > - foreach(exe ${exes}) > + foreach(f ${file_list}) > # Add the exe itself to the keys: > # > - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" > "${dirs}" 0) > + set_bundle_key_values(${keys_var} "${f}" "${f}" "${executable}" > "${dirs}" 0) > > # Add each prerequisite to the keys: > # > set(prereqs "") > - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") > + get_prerequisites("${f}" prereqs 1 1 "${executable}" "${dirs}") > foreach(pr ${prereqs}) > - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" > "${dirs}" 1) > + set_bundle_key_values(${keys_var} "${f}" "${pr}" "${executable}" > "${dirs}" 1) > endforeach() > endforeach() > > @@ -542,6 +570,7 @@ function(get_bundle_keys app libs dirs keys_var) > set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) > set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" > PARENT_SCOPE) > set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) > + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) > endforeach() > endif() > endfunction() > @@ -612,7 +641,7 @@ function(copy_resolved_framework_into_bundle > resolved_item resolved_embedded_ite > endfunction() > > > -function(fixup_bundle_item resolved_embedded_item exepath dirs) > +function(fixup_bundle_item resolved_embedded_item executable dirs) > # This item's key is "ikey": > # > get_item_key("${resolved_embedded_item}" ikey) > @@ -622,7 +651,7 @@ function(fixup_bundle_item resolved_embedded_item exepath > dirs) > # tree, or in other varied locations around the file system, with our call > to > # install_name_tool. Make sure that doesn't happen here: > # > - get_dotapp_dir("${exepath}" exe_dotapp_dir) > + get_dotapp_dir("${executable}" exe_dotapp_dir) > string(LENGTH "${exe_dotapp_dir}/" exe_dotapp_dir_length) > string(LENGTH "${resolved_embedded_item}" resolved_embedded_item_length) > set(path_too_short 0) > @@ -648,7 +677,7 @@ function(fixup_bundle_item resolved_embedded_item exepath > dirs) > endif() > > set(prereqs "") > - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" > "${dirs}") > + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${executable}" > "${dirs}") > > set(changes "") > > @@ -668,12 +697,20 @@ function(fixup_bundle_item resolved_embedded_item > exepath dirs) > execute_process(COMMAND chmod u+w "${resolved_embedded_item}") > endif() > > + foreach(rpath ${${ikey}_RPATHS}) > + set(changes ${changes} -delete_rpath "${rpath}") > + endforeach() > + > + if(${ikey}_EMBEDDED_ITEM) > + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") > + endif() > + > # Change this item's id and all of its references in one call > # to install_name_tool: > # > - execute_process(COMMAND install_name_tool > - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" > - ) > + if(changes) > + execute_process(COMMAND install_name_tool ${changes} > "${resolved_embedded_item}") > + endif() > endfunction() > > > @@ -685,8 +722,6 @@ function(fixup_bundle app libs dirs) > > get_bundle_and_executable("${app}" bundle executable valid) > if(valid) > - get_filename_component(exepath "${executable}" PATH) > - > message(STATUS "fixup_bundle: preparing...") > get_bundle_keys("${app}" "${libs}" "${dirs}" keys) > > @@ -732,7 +767,7 @@ function(fixup_bundle app libs dirs) > math(EXPR i ${i}+1) > if(APPLE) > message(STATUS "${i}/${n}: fixing up > '${${key}_RESOLVED_EMBEDDED_ITEM}'") > - fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${exepath}" > "${dirs}") > + fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${executable}" > "${dirs}") > else() > message(STATUS "${i}/${n}: fix-up not required on this platform > '${${key}_RESOLVED_EMBEDDED_ITEM}'") > endif() > @@ -757,55 +792,49 @@ function(copy_and_fixup_bundle src dst libs dirs) > endfunction() > > > -function(verify_bundle_prerequisites bundle result_var info_var) > +function(verify_bundle_prerequisites bundle executable result_var info_var) > set(result 1) > set(info "") > set(count 0) > > - get_bundle_main_executable("${bundle}" main_bundle_exe) > - > - file(GLOB_RECURSE file_list "${bundle}/*") > + get_bundle_all_executables("${bundle}" file_list) > foreach(f ${file_list}) > - is_file_executable("${f}" is_executable) > - if(is_executable) > - get_filename_component(exepath "${f}" PATH) > - math(EXPR count "${count} + 1") > + math(EXPR count "${count} + 1") > > - message(STATUS "executable file ${count}: ${f}") > + message(STATUS "executable file ${count}: ${f}") > > - set(prereqs "") > - get_prerequisites("${f}" prereqs 1 1 "${exepath}" "") > + set(prereqs "") > + get_prerequisites("${f}" prereqs 1 1 "${executable}" "") > > - # On the Mac, > - # "embedded" and "system" prerequisites are fine... anything else > means > - # the bundle's prerequisites are not verified (i.e., the bundle is not > - # really "standalone") > - # > - # On Windows (and others? Linux/Unix/...?) > - # "local" and "system" prereqs are fine... > - # > - set(external_prereqs "") > + # On the Mac, > + # "embedded" and "system" prerequisites are fine... anything else means > + # the bundle's prerequisites are not verified (i.e., the bundle is not > + # really "standalone") > + # > + # On Windows (and others? Linux/Unix/...?) > + # "local" and "system" prereqs are fine... > + # > + set(external_prereqs "") > > - foreach(p ${prereqs}) > - set(p_type "") > - gp_file_type("${f}" "${p}" p_type) > + foreach(p ${prereqs}) > + set(p_type "") > + gp_file_type("${f}" "${p}" "${executable}" p_type) > > - if(APPLE) > - if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" > STREQUAL "system") > - set(external_prereqs ${external_prereqs} "${p}") > - endif() > - else() > - if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL > "system") > - set(external_prereqs ${external_prereqs} "${p}") > - endif() > + if(APPLE) > + if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL > "system") > + set(external_prereqs ${external_prereqs} "${p}") > + endif() > + else() > + if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL > "system") > + set(external_prereqs ${external_prereqs} "${p}") > endif() > - endforeach() > - > - if(external_prereqs) > - # Found non-system/somehow-unacceptable prerequisites: > - set(result 0) > - set(info ${info} "external prerequisites > found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") > endif() > + endforeach() > + > + if(external_prereqs) > + # Found non-system/somehow-unacceptable prerequisites: > + set(result 0) > + set(info ${info} "external prerequisites > found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") > endif() > endforeach() > > @@ -845,7 +874,7 @@ function(verify_app app) > > # Verify that the bundle does not have any "external" prerequisites: > # > - verify_bundle_prerequisites("${bundle}" verified info) > + verify_bundle_prerequisites("${bundle}" "${executable}" verified info) > message(STATUS "verified='${verified}'") > message(STATUS "info='${info}'") > message(STATUS "") > diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake > index 49443e3..29a8470 100644 > --- a/Modules/GetPrerequisites.cmake > +++ b/Modules/GetPrerequisites.cmake > @@ -41,7 +41,7 @@ > # :: > # > # GET_PREREQUISITES( > > -# ) > +# ) > # > # Get the list of shared library files required by . The list > # in the variable named should be empty on first > @@ -53,7 +53,7 @@ > # must be 0 or 1 indicating whether to include or > # exclude "system" prerequisites. If is set to 1 all > # prerequisites will be found recursively, if set to 0 only direct > -# prerequisites are listed. is the path to the top level > +# prerequisites are listed. is the path to the top level > # executable used for @executable_path replacment on the Mac. is > # a list of paths where libraries might be found: these paths are > # searched first when a target without any path info is given. Then > @@ -113,7 +113,7 @@ > # > # :: > # > -# GP_RESOLVE_ITEM( ) > +# GP_RESOLVE_ITEM( > ) > # > # Resolve an item into an existing full path file. > # > @@ -122,13 +122,13 @@ > # > # :: > # > -# GP_RESOLVED_FILE_TYPE( > ) > +# GP_RESOLVED_FILE_TYPE( > ) > # > # Return the type of with respect to . String > # describing type of prerequisite is returned in variable named > # . > # > -# Use and if necessary to resolve non-absolute > +# Use and if necessary to resolve non-absolute > # values -- but only for non-embedded items. > # > # Possible types are: > @@ -318,10 +318,12 @@ function(gp_item_default_embedded_path item > default_embedded_path_var) > endfunction() > > > -function(gp_resolve_item context item exepath dirs resolved_item_var) > +function(gp_resolve_item context item executable dirs resolved_item_var) > set(resolved 0) > set(resolved_item "${item}") > > + get_filename_component(exepath "${executable}" PATH) > + > # Is it already resolved? > # > if(IS_ABSOLUTE "${resolved_item}" AND EXISTS "${resolved_item}") > @@ -331,7 +333,7 @@ function(gp_resolve_item context item exepath dirs > resolved_item_var) > if(NOT resolved) > if(item MATCHES "^@executable_path") > # > - # @executable_path references are assumed relative to exepath > + # @executable_path references are assumed relative to executable > # > string(REPLACE "@executable_path" "${exepath}" ri "${item}") > get_filename_component(ri "${ri}" ABSOLUTE) > @@ -374,10 +376,11 @@ function(gp_resolve_item context item exepath dirs > resolved_item_var) > # > string(REPLACE "@rpath/" "" norpath_item "${item}") > > + get_item_key("${executable}" key) > set(ri "ri-NOTFOUND") > - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) > + find_file(ri "${norpath_item}" ${dirs} ${${key}_RPATHS} > NO_DEFAULT_PATH) > if(ri) > - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") > + #message(STATUS "info: 'find_file' in exepath/rpaths/dirs (${ri})") > set(resolved 1) > set(resolved_item "${ri}") > set(ri "ri-NOTFOUND") > @@ -436,7 +439,7 @@ function(gp_resolve_item context item exepath dirs > resolved_item_var) > # by whatever logic they choose: > # > if(COMMAND gp_resolve_item_override) > - gp_resolve_item_override("${context}" "${item}" "${exepath}" "${dirs}" > resolved_item resolved) > + gp_resolve_item_override("${context}" "${item}" "${executable}" > "${dirs}" resolved_item resolved) > endif() > > if(NOT resolved) > @@ -459,7 +462,7 @@ warning: cannot resolve item '${item}' > # > # context='${context}' > # item='${item}' > -# exepath='${exepath}' > +# executable='${executable}' > # dirs='${dirs}' > # resolved_item_var='${resolved_item_var}' > #****************************************************************************** > @@ -470,7 +473,7 @@ warning: cannot resolve item '${item}' > endfunction() > > > -function(gp_resolved_file_type original_file file exepath dirs type_var) > +function(gp_resolved_file_type original_file file executable dirs type_var) > #message(STATUS "**") > > if(NOT IS_ABSOLUTE "${original_file}") > @@ -489,7 +492,7 @@ function(gp_resolved_file_type original_file file exepath > dirs type_var) > > if(NOT is_embedded) > if(NOT IS_ABSOLUTE "${file}") > - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" > resolved_file) > + gp_resolve_item("${original_file}" "${file}" "${executable}" "${dirs}" > resolved_file) > endif() > > string(TOLOWER "${original_file}" original_lower) > @@ -595,21 +598,19 @@ function(gp_resolved_file_type original_file file > exepath dirs type_var) > endfunction() > > > -function(gp_file_type original_file file type_var) > +function(gp_file_type original_file file executable type_var) > if(NOT IS_ABSOLUTE "${original_file}") > message(STATUS "warning: gp_file_type expects absolute full path for > first arg original_file") > endif() > > - get_filename_component(exepath "${original_file}" PATH) > - > set(type "") > - gp_resolved_file_type("${original_file}" "${file}" "${exepath}" "" type) > + gp_resolved_file_type("${original_file}" "${file}" "${executable}" "" > type) > > set(${type_var} "${type}" PARENT_SCOPE) > endfunction() > > > -function(get_prerequisites target prerequisites_var exclude_system recurse > exepath dirs) > +function(get_prerequisites target prerequisites_var exclude_system recurse > executable dirs) > set(verbose 0) > set(eol_char "E") > > @@ -738,6 +739,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa > > if("${gp_tool}" STREQUAL "ldd") > set(old_ld_env "$ENV{LD_LIBRARY_PATH}") > + get_filename_component(exepath "${executable}" PATH) > set(new_ld_env "${exepath}") > foreach(dir ${dirs}) > set(new_ld_env "${new_ld_env}:${dir}") > @@ -834,7 +836,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa > > if(add_item AND ${exclude_system}) > set(type "") > - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" > type) > + gp_resolved_file_type("${target}" "${item}" "${executable}" "${dirs}" > type) > > if("${type}" STREQUAL "system") > set(add_item 0) > @@ -855,7 +857,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa > # that the analysis tools can simply accept it as input. > # > if(NOT list_length_before_append EQUAL list_length_after_append) > - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" > resolved_item) > + gp_resolve_item("${target}" "${item}" "${executable}" "${dirs}" > resolved_item) > set(unseen_prereqs ${unseen_prereqs} "${resolved_item}") > endif() > endif() > @@ -874,7 +876,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa > if(${recurse}) > set(more_inputs ${unseen_prereqs}) > foreach(input ${more_inputs}) > - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} > ${recurse} "${exepath}" "${dirs}") > + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} > ${recurse} "${executable}" "${dirs}") > endforeach() > endif() > > @@ -911,7 +913,7 @@ function(list_prerequisites target) > get_filename_component(exepath "${target}" PATH) > > set(prereqs "") > - get_prerequisites("${target}" prereqs ${exclude_system} ${all} > "${exepath}" "") > + get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${target}" > "") > > if(print_target) > message(STATUS "File '${target}' depends on:") > @@ -925,7 +927,7 @@ function(list_prerequisites target) > endif() > > if(print_prerequisite_type) > - gp_file_type("${target}" "${d}" type) > + gp_file_type("${target}" "${d}" "" type) > set(type_str " (${type})") > endif() > > -- > 1.9.3 (Apple Git-50) > > -- > > 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 dlrdave at aol.com Fri Sep 5 11:00:14 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 5 Sep 2014 11:00:14 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion Message-ID: <8D197313BC70D02-15CC-1B293@webmail-m269.sysops.aol.com> > ...I would prefer to combine into something more compact.The other > infrastructure I don't think I have touched but optically it looks > very noisy.Having something that takes away repetitive tasks, more > compact and easier on the eye would be nice. I agree. That would be nice. Feel free to reinvent and re-factor. The ones I put in there were added in a flurry of increasing coverage a few years ago. I was just pointing it out in case you wanted to take advantage of an existing run-this-script pattern we already use. Cheers, D From brad.king at kitware.com Fri Sep 5 11:28:51 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Sep 2014 11:28:51 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5409C610.8030203@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <5409BB47.3000309@kitware.com> <5409BFB0.1060408@gmail.com> <5409C2F9.30600@kitware.com> <5409C610.8030203@gmail.com> Message-ID: <5409D6B3.8090602@kitware.com> On 09/05/2014 10:17 AM, Nils Gladitz wrote: >>> On 09/05/2014 03:31 PM, Brad King wrote: >> >> I think the description of RunCMake can just be updated. >> All of its tests are about running "cmake" command lines. > > So you see no advantage to having the distinction? > > E.g. if you consider testing a set of generators (or variants of the > same generator) possibly non-native and distinct from the generator > being used to build cmake itself it might make sense to run tests which > perform configuration once for each of those but script mode tests would > only have to be run once. RunCMake already has tests of both types, so if we want to make such a distinction then a lot more work is needed. Using CMake_TEST_EXTERNAL_CMAKE we already have a few dashboards that run the CMake test suite using a different generator/compiler than was used to build CMake. The tests that are independent of the compiler/generator tend to be very small and very fast so it does not hurt to run them again. -Brad From ono at java.pl Fri Sep 5 13:23:20 2014 From: ono at java.pl (Adam Strzelecki) Date: Fri, 5 Sep 2014 19:23:20 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <43520581.222701.1409920174530.JavaMail.zimbra@elemtech.com> References: <952D2C19-AD78-4E46-BAE0-B2F0F4DF7C2E@java.pl> <1409917844-28297-3-git-send-email-ono@java.pl> <43520581.222701.1409920174530.JavaMail.zimbra@elemtech.com> Message-ID: <83FCBB60-ECFC-4C9F-8D9A-BBB5321A096E@java.pl> > I think it would be nice to move > get_item_rpaths() from BundleUtilities.cmake to gp_item_get_rpaths() in GetPrerequisites.cmake. Well, this function is generic enough to (possible) serve other routines or even in CMakeLists.txt, so I'd leave it as it is. > And how does your patch or patch set handle @loader_path being used in the rpath? My patch doesn't change anything in this regard, this is handles as it was done previously via ${context} which is expected to be the referencing library/executable. > Also, I think the function signature should include the rpath vs runpath distinction. I realize OS X doesn't have the runpath concept, but if one were to add support for Linux, one may need that where the runpath affects only finding immediate dependencies. Well, this is fine. Can you please submit your patches once my code gets merged. It would be best to do it step by step. WDYT? > Below is what I have for Linux and OS X. > It include rpath vs. runpath, and expands out the @loader_path variable. Well I think this is incorrect, because @loader_path gets expanded to image containing LC_RPATH not image that is actually loading image, which may be different binary (library), e.g.: bin/MyApp -> @rpath/libsome.so lib/libsome.so -> @rpath/libsomeplugin.so lib/plugins/libsomeplugin.so Now let's assume bin/MyApp has following LC_RPATHs: @loader_path/plugins @loader_path/../lib Then with your script plugins/ would be resolved to be bin/plugins/ but in fact dyld will resolve it to lib/plugins/ because it is lib/libsome.so which is loader of @rpath/libsomeplugin.so. > (...) > if(APPLE) > execute_process(COMMAND otool -l "${binary}" > COMMAND grep -A2 LC_RPATH > COMMAND grep path > OUTPUT_VARIABLE paths) > string(REPLACE "\n" ";" paths "${paths}") > foreach(str ${paths}) > string(REGEX REPLACE " path (.*) \\(offset.*" "\\1" rpath "${str}") > string(STRIP "${rpath}" rpath) > string(REPLACE "@loader_path" "${binary_dir}" rpath "${rpath}") > list(APPEND myrpaths "${rpath}") > endforeach() > (...) Current implementation with my patches doesn't do @loader|executable_path substitution in LC_RPATH because of simple reason. If your binary has LC_RPATHs with these then in 99% cases the dependencies are already in the bundle. So only LC_RPATH with absolute paths will cause copy. --Adam From brad.king at kitware.com Fri Sep 5 15:53:06 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Sep 2014 15:53:06 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <355BE46A91031048906B695426A8D8E616ACEC74@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> <5409C1CE.1010501@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC74@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <540A14A2.30904@kitware.com> On 09/05/2014 10:02 AM, Bach, Pascal wrote: >> On 09/05/2014 09:16 AM, Bach, Pascal wrote: >> Since CMakeSystem.cmake loads the CMAKE_TOOLCHAIN_FILE, try_compile >> should use CMAKE_VS_WINCE_SDK when the value is set in the toolchain >> file. Is this the case when you test the changes locally? > > The case I was testing was indeed with the CMAKE_VS_WINCE_SDK set inside the toolchain file. > I guess to support this variable only in the toolchain file is not an option? It would be acceptable for purposes of the initial contribution. How this is best done in the long run may depend on how we choose to generalize (or not) the CMAKE_VS_WINCE_SDK value. Therefore we need to choose that now. If one were compiling for WinCE using a Makefile or Ninja generator, then one would need to have the current environment configured for the proper SDK already. Then the CMake generator would not need to be aware of the SDK or even its name. This is why there are "Win64" and "ARM" variants of the VS generators but not of other generators. This setting is specific to Visual Studio generators, just as the setting for CMAKE_GENERATOR_TOOLSET is generator-specific (though that one is meaningful to the Xcode generator too). Although WinCE uses it to choose the SDK, from the VS generator point of view it is just the value. The value does for exactly what CMAKE_GENERATOR_TOOLSET does for . I think "CMAKE_GENERATOR_PLATFORM" may be a suitable name. Ideally this setting should be added as a general-purpose replacement for putting "ARM" or "Win64" in the generator name. The changes for that are more sweeping than I'd like to ask of you just for WinCE support, so I drafted them myself. Please fetch as: git fetch https://github.com/bradking/CMake vs-generator-platform and rebase your topic on that to try it out. Of course there is no need to send my part as patches, just your revised patch(es). Thanks, -Brad From aleixpol at kde.org Sat Sep 6 09:38:09 2014 From: aleixpol at kde.org (Aleix Pol) Date: Sat, 6 Sep 2014 15:38: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> Message-ID: On Wed, Sep 3, 2014 at 6:12 PM, Aleix Pol wrote: > On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf > wrote: > >> On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote: >> > On Tue, Sep 2, 2014 at 3:58 PM, David Cole wrote: >> > > It makes sense. But what IDE are you referring to? Eclipse? Some other >> > > concrete example? Or just "any IDE and this feature should work >> everywhere >> > > CMake works...?" >> > >> > I'm working on KDevelop, I know for a fact though, that other IDEs are >> > looking for something similar too, such as QtCreator. >> >> I still don't understand why this shouldn't be an additional >> ExtraGenerator. >> It will generate a special file intended to be used by KDevelop and maybe >> QtCreator additionally to makefiles/ninja files. Could be called >> "GenericJSON" >> or so. >> Other IDEs which don't support this file type but which need their own >> project >> file obviously still need their own specific generator. >> >> Alex >> > > Because it's not possible to change the generator of a build directory > once it's set up. You need to nuke it and re-create it. > Also because changing the generator could potentially change the > interaction the user has with the build directory, we don't want to get in > the way. > > Aleix > Bump! Can I get some pointers about how to proceed? Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sat Sep 6 15:19:44 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 6 Sep 2014 15:19:44 -0400 Subject: [cmake-developers] [CMake 0015131]: "trace.c", line 219: error: identifier redeclared: trace_strbuf Message-ID: <942d07000c38acb3b147babc14f976de@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15131 ====================================================================== Reported By: dev Assigned To: ====================================================================== Project: CMake Issue ID: 15131 Category: CMake Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-06 15:19 EDT Last Modified: 2014-09-06 15:19 EDT ====================================================================== Summary: "trace.c", line 219: error: identifier redeclared: trace_strbuf Description: Build on Solaris 10 fails thus : CC tag.o CC trace.o "trace.c", line 219: error: identifier redeclared: trace_strbuf current : function(pointer to const char, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void previous: function(pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1}, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void : "trace.h", line 33 "trace.c", line 221: warning: argument http://public.kitware.com/Bug/view.php?id=3 is incompatible with prototype: prototype: pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1} : "trace.c", line 160 argument : pointer to const char "trace.c", line 390: error: reference to static identifier "offset" in extern inline function "trace.c", line 392: error: reference to static identifier "offset" in extern inline function "trace.c", line 393: error: reference to static identifier "offset" in extern inline function "trace.c", line 401: error: reference to static identifier "offset" in extern inline function "trace.c", line 403: error: reference to static identifier "offset" in extern inline function cc: acomp failed for trace.c gmake: *** [trace.o] Error 2 Steps to Reproduce: extracted the tarball and did the following : $ gmake CFLAGS="$CFLAGS" LDFLAGS="$LD_OPTIONS" NEEDS_LIBICONV=Yes \ > SHELL_PATH=/usr/local/bin/bash \ > SANE_TOOL_PATH=/usr/local/bin \ > USE_LIBPCRE=1 LIBPCREDIR=/usr/local CURLDIR=/usr/local \ > EXPATDIR=/usr/local NEEDS_LIBINTL_BEFORE_LIBICONV=1 \ > NEEDS_SOCKET=1 NEEDS_RESOLV=1 USE_NSEC=1 \ > PERL_PATH=/usr/local/bin/perl \ > TAR=/usr/bin/tar \ > NO_PYTHON=1 DEFAULT_PAGER=/usr/xpg4/bin/more \ > DEFAULT_EDITOR=/usr/local/bin/vim DEFAULT_HELP_FORMAT=man \ > prefix=/usr/local GIT_VERSION = 2.1.0 * new build flags CC credential-store.o * new link flags CC abspath.o CC advice.o CC alias.o CC alloc.o CC archive.o CC archive-tar.o CC archive-zip.o CC argv-array.o * new prefix flags CC attr.o CC base85.o CC bisect.o CC blob.o CC branch.o CC bulk-checkin.o CC bundle.o CC cache-tree.o CC color.o CC column.o CC combine-diff.o CC commit.o CC compat/obstack.o CC compat/terminal.o CC config.o CC connect.o CC connected.o CC convert.o CC copy.o CC credential.o CC csum-file.o CC ctype.o "ctype.c", line 50: warning: initializer does not fit or is out of range: 128 "ctype.c", line 50: warning: initializer does not fit or is out of range: 129 "ctype.c", line 50: warning: initializer does not fit or is out of range: 130 "ctype.c", line 50: warning: initializer does not fit or is out of range: 131 "ctype.c", line 50: warning: initializer does not fit or is out of range: 132 "ctype.c", line 50: warning: initializer does not fit or is out of range: 133 "ctype.c", line 50: warning: initializer does not fit or is out of range: 134 "ctype.c", line 50: warning: initializer does not fit or is out of range: 135 "ctype.c", line 51: warning: initializer does not fit or is out of range: 136 "ctype.c", line 51: warning: initializer does not fit or is out of range: 137 "ctype.c", line 51: warning: initializer does not fit or is out of range: 138 "ctype.c", line 51: warning: initializer does not fit or is out of range: 139 "ctype.c", line 51: warning: initializer does not fit or is out of range: 140 "ctype.c", line 51: warning: initializer does not fit or is out of range: 141 "ctype.c", line 51: warning: initializer does not fit or is out of range: 142 "ctype.c", line 51: warning: initializer does not fit or is out of range: 143 "ctype.c", line 52: warning: initializer does not fit or is out of range: 144 "ctype.c", line 52: warning: initializer does not fit or is out of range: 145 "ctype.c", line 52: warning: initializer does not fit or is out of range: 146 "ctype.c", line 52: warning: initializer does not fit or is out of range: 147 "ctype.c", line 52: warning: initializer does not fit or is out of range: 148 "ctype.c", line 52: warning: initializer does not fit or is out of range: 149 "ctype.c", line 52: warning: initializer does not fit or is out of range: 150 "ctype.c", line 52: warning: initializer does not fit or is out of range: 151 "ctype.c", line 53: warning: initializer does not fit or is out of range: 152 "ctype.c", line 53: warning: initializer does not fit or is out of range: 153 "ctype.c", line 53: warning: initializer does not fit or is out of range: 154 "ctype.c", line 53: warning: initializer does not fit or is out of range: 155 "ctype.c", line 53: warning: initializer does not fit or is out of range: 156 "ctype.c", line 53: warning: initializer does not fit or is out of range: 157 "ctype.c", line 53: warning: initializer does not fit or is out of range: 158 "ctype.c", line 53: warning: initializer does not fit or is out of range: 159 "ctype.c", line 54: warning: initializer does not fit or is out of range: 160 "ctype.c", line 54: warning: initializer does not fit or is out of range: 161 "ctype.c", line 54: warning: initializer does not fit or is out of range: 162 "ctype.c", line 54: warning: initializer does not fit or is out of range: 163 "ctype.c", line 54: warning: initializer does not fit or is out of range: 164 "ctype.c", line 54: warning: initializer does not fit or is out of range: 165 "ctype.c", line 54: warning: initializer does not fit or is out of range: 166 "ctype.c", line 54: warning: initializer does not fit or is out of range: 167 "ctype.c", line 55: warning: initializer does not fit or is out of range: 168 "ctype.c", line 55: warning: initializer does not fit or is out of range: 169 "ctype.c", line 55: warning: initializer does not fit or is out of range: 170 "ctype.c", line 55: warning: initializer does not fit or is out of range: 171 "ctype.c", line 55: warning: initializer does not fit or is out of range: 172 "ctype.c", line 55: warning: initializer does not fit or is out of range: 173 "ctype.c", line 55: warning: initializer does not fit or is out of range: 174 "ctype.c", line 55: warning: initializer does not fit or is out of range: 175 "ctype.c", line 56: warning: initializer does not fit or is out of range: 176 "ctype.c", line 56: warning: initializer does not fit or is out of range: 177 "ctype.c", line 56: warning: initializer does not fit or is out of range: 178 "ctype.c", line 56: warning: initializer does not fit or is out of range: 179 "ctype.c", line 56: warning: initializer does not fit or is out of range: 180 "ctype.c", line 56: warning: initializer does not fit or is out of range: 181 "ctype.c", line 56: warning: initializer does not fit or is out of range: 182 "ctype.c", line 56: warning: initializer does not fit or is out of range: 183 "ctype.c", line 57: warning: initializer does not fit or is out of range: 184 "ctype.c", line 57: warning: initializer does not fit or is out of range: 185 "ctype.c", line 57: warning: initializer does not fit or is out of range: 186 "ctype.c", line 57: warning: initializer does not fit or is out of range: 187 "ctype.c", line 57: warning: initializer does not fit or is out of range: 188 "ctype.c", line 57: warning: initializer does not fit or is out of range: 189 "ctype.c", line 57: warning: initializer does not fit or is out of range: 190 "ctype.c", line 57: warning: initializer does not fit or is out of range: 191 "ctype.c", line 58: warning: initializer does not fit or is out of range: 192 "ctype.c", line 58: warning: initializer does not fit or is out of range: 193 "ctype.c", line 58: warning: initializer does not fit or is out of range: 194 "ctype.c", line 58: warning: initializer does not fit or is out of range: 195 "ctype.c", line 58: warning: initializer does not fit or is out of range: 196 "ctype.c", line 58: warning: initializer does not fit or is out of range: 197 "ctype.c", line 58: warning: initializer does not fit or is out of range: 198 "ctype.c", line 58: warning: initializer does not fit or is out of range: 199 "ctype.c", line 59: warning: initializer does not fit or is out of range: 200 "ctype.c", line 59: warning: initializer does not fit or is out of range: 201 "ctype.c", line 59: warning: initializer does not fit or is out of range: 202 "ctype.c", line 59: warning: initializer does not fit or is out of range: 203 "ctype.c", line 59: warning: initializer does not fit or is out of range: 204 "ctype.c", line 59: warning: initializer does not fit or is out of range: 205 "ctype.c", line 59: warning: initializer does not fit or is out of range: 206 "ctype.c", line 59: warning: initializer does not fit or is out of range: 207 "ctype.c", line 60: warning: initializer does not fit or is out of range: 208 "ctype.c", line 60: warning: initializer does not fit or is out of range: 209 "ctype.c", line 60: warning: initializer does not fit or is out of range: 210 "ctype.c", line 60: warning: initializer does not fit or is out of range: 211 "ctype.c", line 60: warning: initializer does not fit or is out of range: 212 "ctype.c", line 60: warning: initializer does not fit or is out of range: 213 "ctype.c", line 60: warning: initializer does not fit or is out of range: 214 "ctype.c", line 60: warning: initializer does not fit or is out of range: 215 "ctype.c", line 61: warning: initializer does not fit or is out of range: 216 "ctype.c", line 61: warning: initializer does not fit or is out of range: 217 "ctype.c", line 61: warning: initializer does not fit or is out of range: 218 "ctype.c", line 61: warning: initializer does not fit or is out of range: 219 "ctype.c", line 61: warning: initializer does not fit or is out of range: 220 "ctype.c", line 61: warning: initializer does not fit or is out of range: 221 "ctype.c", line 61: warning: initializer does not fit or is out of range: 222 "ctype.c", line 61: warning: initializer does not fit or is out of range: 223 "ctype.c", line 62: warning: initializer does not fit or is out of range: 224 "ctype.c", line 62: warning: initializer does not fit or is out of range: 225 "ctype.c", line 62: warning: initializer does not fit or is out of range: 226 "ctype.c", line 62: warning: initializer does not fit or is out of range: 227 "ctype.c", line 62: warning: initializer does not fit or is out of range: 228 "ctype.c", line 62: warning: initializer does not fit or is out of range: 229 "ctype.c", line 62: warning: initializer does not fit or is out of range: 230 "ctype.c", line 62: warning: initializer does not fit or is out of range: 231 "ctype.c", line 63: warning: initializer does not fit or is out of range: 232 "ctype.c", line 63: warning: initializer does not fit or is out of range: 233 "ctype.c", line 63: warning: initializer does not fit or is out of range: 234 "ctype.c", line 63: warning: initializer does not fit or is out of range: 235 "ctype.c", line 63: warning: initializer does not fit or is out of range: 236 "ctype.c", line 63: warning: initializer does not fit or is out of range: 237 "ctype.c", line 63: warning: initializer does not fit or is out of range: 238 "ctype.c", line 63: warning: initializer does not fit or is out of range: 239 "ctype.c", line 64: warning: initializer does not fit or is out of range: 240 "ctype.c", line 64: warning: initializer does not fit or is out of range: 241 "ctype.c", line 64: warning: initializer does not fit or is out of range: 242 "ctype.c", line 64: warning: initializer does not fit or is out of range: 243 "ctype.c", line 64: warning: initializer does not fit or is out of range: 244 "ctype.c", line 64: warning: initializer does not fit or is out of range: 245 "ctype.c", line 64: warning: initializer does not fit or is out of range: 246 "ctype.c", line 64: warning: initializer does not fit or is out of range: 247 "ctype.c", line 65: warning: initializer does not fit or is out of range: 248 "ctype.c", line 65: warning: initializer does not fit or is out of range: 249 "ctype.c", line 65: warning: initializer does not fit or is out of range: 250 "ctype.c", line 65: warning: initializer does not fit or is out of range: 251 "ctype.c", line 65: warning: initializer does not fit or is out of range: 252 "ctype.c", line 65: warning: initializer does not fit or is out of range: 253 "ctype.c", line 65: warning: initializer does not fit or is out of range: 254 "ctype.c", line 65: warning: initializer does not fit or is out of range: 255 CC date.o CC decorate.o CC diffcore-break.o CC diffcore-delta.o CC diffcore-order.o CC diffcore-pickaxe.o CC diffcore-rename.o CC diff-delta.o CC diff-lib.o CC diff-no-index.o CC diff.o CC dir.o CC editor.o CC entry.o CC environment.o CC ewah/bitmap.o CC ewah/ewah_bitmap.o CC ewah/ewah_io.o CC ewah/ewah_rlw.o CC exec_cmd.o CC fetch-pack.o CC fsck.o CC gettext.o CC gpg-interface.o CC graph.o CC grep.o CC hashmap.o GEN common-cmds.h CC help.o CC hex.o CC ident.o CC kwset.o CC levenshtein.o CC line-log.o CC line-range.o CC list-objects.o CC ll-merge.o CC lockfile.o CC log-tree.o CC mailmap.o CC match-trees.o CC merge.o CC merge-blobs.o CC merge-recursive.o CC mergesort.o CC name-hash.o CC notes.o CC notes-cache.o CC notes-merge.o CC notes-utils.o CC object.o CC pack-bitmap.o CC pack-bitmap-write.o CC pack-check.o CC pack-objects.o CC pack-revindex.o CC pack-write.o CC pager.o CC parse-options.o CC parse-options-cb.o CC patch-delta.o CC patch-ids.o CC path.o CC pathspec.o CC pkt-line.o CC preload-index.o CC pretty.o CC prio-queue.o CC progress.o CC prompt.o CC quote.o CC reachable.o CC read-cache.o "read-cache.c", line 799: warning: statement not reached CC reflog-walk.o CC refs.o CC remote.o CC replace_object.o CC rerere.o CC resolve-undo.o CC revision.o CC run-command.o CC send-pack.o CC sequencer.o CC server-info.o CC setup.o CC sha1-array.o CC sha1-lookup.o CC sha1_file.o CC sha1_name.o CC shallow.o CC sideband.o CC sigchain.o CC split-index.o CC strbuf.o CC streaming.o CC string-list.o CC submodule.o CC symlinks.o CC tag.o CC trace.o "trace.c", line 219: error: identifier redeclared: trace_strbuf current : function(pointer to const char, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void previous: function(pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1}, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void : "trace.h", line 33 "trace.c", line 221: warning: argument http://public.kitware.com/Bug/view.php?id=3 is incompatible with prototype: prototype: pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1} : "trace.c", line 160 argument : pointer to const char "trace.c", line 390: error: reference to static identifier "offset" in extern inline function "trace.c", line 392: error: reference to static identifier "offset" in extern inline function "trace.c", line 393: error: reference to static identifier "offset" in extern inline function "trace.c", line 401: error: reference to static identifier "offset" in extern inline function "trace.c", line 403: error: reference to static identifier "offset" in extern inline function cc: acomp failed for trace.c gmake: *** [trace.o] Error 2 Additional Information: Solaris 10 with Oracle Studio 12.3 compiler tools. A lengthy maillist discussion last week sorted out the previous release of git just fine however this release fails to build. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-06 15:19 dev New Issue ====================================================================== From dev at cor0.com Sat Sep 6 15:21:48 2014 From: dev at cor0.com (dev) Date: Sat, 6 Sep 2014 15:21:48 -0400 (EDT) Subject: [cmake-developers] [CMake 0015131]: "trace.c", line 219: error: identifier redeclared: trace_strbuf In-Reply-To: <942d07000c38acb3b147babc14f976de@public.kitware.com> References: <942d07000c38acb3b147babc14f976de@public.kitware.com> Message-ID: <1768689012.24006.1410031308041.JavaMail.vpopmail@webmail2.networksolutionsemail.com> well this is a new one on me ... totally wrong mantis site .. nice bug report however. someone delete this and taser me :-( -------------------------------------------- On September 6, 2014 at 3:19 PM Mantis Bug Tracker wrote: > > The following issue has been SUBMITTED. > ====================================================================== > http://public.kitware.com/Bug/view.php?id=15131 > ====================================================================== From mantis at public.kitware.com Sat Sep 6 15:26:04 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 6 Sep 2014 15:26:04 -0400 Subject: [cmake-developers] [CMake 0015132]: find_library retrieves libraries from $PATH even when they can be found in the proper locations. Message-ID: <4590972ae35b81079cbb00e02ee9d99a@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15132 ====================================================================== Reported By: Greg Jung Assigned To: ====================================================================== Project: CMake Issue ID: 15132 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-06 15:26 EDT Last Modified: 2014-09-06 15:26 EDT ====================================================================== Summary: find_library retrieves libraries from $PATH even when they can be found in the proper locations. Description: Contrary to documentation, find_library usurps my intention when it has an apparent match from $ENV{PATH}. This also occurs if I specify the preference explicitly via CMAKE_PREFIX_PATH: if the library is found in program path, it picks those up for linkage instead of the specified preference. In the folowing example, I happen to have only one of the libraries fftw3, fftw3f in my /local32/lib. So the FFTWDIR is set to pick up libraries as in FindFFTW.cmake: CMakeLists.txt: set(CMAKE_PREFIX_PATH ${FFTWDIR}) find_package(FFTW QUIET) FindFFTW.cmake: find_library(FFTW_LIBRARY NAMES fftw3) message(STATUS " FFTW_LIBRARY: ${FFTW_LIBRARY}") find_library(FFTWF_LIBRARY NAMES fftw3f) message(STATUS " FFTWF_LIBRARY: ${FFTWF_LIBRARY}") set(FFTW_LIBRARIES ${FFTW_LIBRARY} ${FFTWF_LIBRARY}) find_path(FFTW_INCLUDE_DIR NAMES fftw3.h) result: CMakeCache.txt //GDL: Specifiy the FFTW directory tree FFTWDIR:PATH=D:/programs/win32libs //Path to a library. FFTWF_LIBRARY:FILEPATH=D:/programs/win32libs/lib/libfftw3f.a //Path to a file. FFTW_INCLUDE_DIR:PATH=E:/mingw/local32/include //Path to a library. FFTW_LIBRARY:FILEPATH=E:/mingw/local32/lib/libfftw3.a Steps to Reproduce: put an acceptable library file in your %PATH%, run cmake: SET(CMAKE_PREFIX_PATH "c:/proper/lib") find_library(WRONG libname) Additional Information: In cygwin, I set LDFLAGS="-L/opt/local/lib -L/usr/local/lib" which are ingested, with my modified Platform/UnixPaths.cmake, into CMAKE_SYSTEM_LIBRARY_PATH and into CMAKE_SYSTEM_INCLUDE_PATH. inspecting LDFLAGS: -L/opt/local/lib -L/usr/local/lib adding system library path: /opt/local/lib adding system library path: /usr/local/lib so according to the docs, CMAKE_SYSTEM_LIBRARY_PATH and CMAKE_SYSTEM_INCLUDE_PATH will be utilized in find_library and in find_path, respectively. Instead I get Junk from the mingw side bleeding into it because I have an application directory in %PATH%: PLPLOT_LIBRARY: /cygdrive/d/programs/libplplotd.dll.a FindPlplot> PLPLOT_LIBRARY_DIR: /cygdrive/d/programs PLPLOT_INCLUDE=? /cygdrive/d/programs/../include Found PLPLOT: /cygdrive/d/programs/libplplotd.dll.a;/cygdrive/d/programs/libplplotcxxd.dll.a (errors due to bad linkage) Looking for c_plslabelfunc in /cygdrive/d/programs/libplplotd.dll.a;/cygdrive/d/programs/libplplotcxxd.dll.a Looking for c_plslabelfunc in /cygdrive/d/programs/libplplotd.dll.a;/cygdrive/d/programs/libplplotcxxd.dll.a - not found Of course, I reset my $PATH for the cygwin to run right, but the find_library behavior is wrong. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-06 15:26 Greg Jung New Issue 2014-09-06 15:26 Greg Jung File Added: cmakebug ====================================================================== From mantis at public.kitware.com Sat Sep 6 16:12:22 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 6 Sep 2014 16:12:22 -0400 Subject: [cmake-developers] [CMake 0015131]: "trace.c", line 219: error: identifier redeclared: trace_strbuf In-Reply-To: <942d07000c38acb3b147babc14f976de@public.kitware.com> Message-ID: The following issue has been DELETED. ====================================================================== Reported By: dev Assigned To: ====================================================================== Project: CMake Issue ID: 15131 Category: CMake Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-06 15:19 EDT Last Modified: 2014-09-06 15:22 EDT ====================================================================== Summary: "trace.c", line 219: error: identifier redeclared: trace_strbuf Description: Build on Solaris 10 fails thus : CC tag.o CC trace.o "trace.c", line 219: error: identifier redeclared: trace_strbuf current : function(pointer to const char, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void previous: function(pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1}, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void : "trace.h", line 33 "trace.c", line 221: warning: argument http://public.kitware.com/Bug/view.php?id=3 is incompatible with prototype: prototype: pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1} : "trace.c", line 160 argument : pointer to const char "trace.c", line 390: error: reference to static identifier "offset" in extern inline function "trace.c", line 392: error: reference to static identifier "offset" in extern inline function "trace.c", line 393: error: reference to static identifier "offset" in extern inline function "trace.c", line 401: error: reference to static identifier "offset" in extern inline function "trace.c", line 403: error: reference to static identifier "offset" in extern inline function cc: acomp failed for trace.c gmake: *** [trace.o] Error 2 Steps to Reproduce: extracted the tarball and did the following : $ gmake CFLAGS="$CFLAGS" LDFLAGS="$LD_OPTIONS" NEEDS_LIBICONV=Yes \ > SHELL_PATH=/usr/local/bin/bash \ > SANE_TOOL_PATH=/usr/local/bin \ > USE_LIBPCRE=1 LIBPCREDIR=/usr/local CURLDIR=/usr/local \ > EXPATDIR=/usr/local NEEDS_LIBINTL_BEFORE_LIBICONV=1 \ > NEEDS_SOCKET=1 NEEDS_RESOLV=1 USE_NSEC=1 \ > PERL_PATH=/usr/local/bin/perl \ > TAR=/usr/bin/tar \ > NO_PYTHON=1 DEFAULT_PAGER=/usr/xpg4/bin/more \ > DEFAULT_EDITOR=/usr/local/bin/vim DEFAULT_HELP_FORMAT=man \ > prefix=/usr/local GIT_VERSION = 2.1.0 * new build flags CC credential-store.o * new link flags CC abspath.o CC advice.o CC alias.o CC alloc.o CC archive.o CC archive-tar.o CC archive-zip.o CC argv-array.o * new prefix flags CC attr.o CC base85.o CC bisect.o CC blob.o CC branch.o CC bulk-checkin.o CC bundle.o CC cache-tree.o CC color.o CC column.o CC combine-diff.o CC commit.o CC compat/obstack.o CC compat/terminal.o CC config.o CC connect.o CC connected.o CC convert.o CC copy.o CC credential.o CC csum-file.o CC ctype.o "ctype.c", line 50: warning: initializer does not fit or is out of range: 128 "ctype.c", line 50: warning: initializer does not fit or is out of range: 129 "ctype.c", line 50: warning: initializer does not fit or is out of range: 130 "ctype.c", line 50: warning: initializer does not fit or is out of range: 131 "ctype.c", line 50: warning: initializer does not fit or is out of range: 132 "ctype.c", line 50: warning: initializer does not fit or is out of range: 133 "ctype.c", line 50: warning: initializer does not fit or is out of range: 134 "ctype.c", line 50: warning: initializer does not fit or is out of range: 135 "ctype.c", line 51: warning: initializer does not fit or is out of range: 136 "ctype.c", line 51: warning: initializer does not fit or is out of range: 137 "ctype.c", line 51: warning: initializer does not fit or is out of range: 138 "ctype.c", line 51: warning: initializer does not fit or is out of range: 139 "ctype.c", line 51: warning: initializer does not fit or is out of range: 140 "ctype.c", line 51: warning: initializer does not fit or is out of range: 141 "ctype.c", line 51: warning: initializer does not fit or is out of range: 142 "ctype.c", line 51: warning: initializer does not fit or is out of range: 143 "ctype.c", line 52: warning: initializer does not fit or is out of range: 144 "ctype.c", line 52: warning: initializer does not fit or is out of range: 145 "ctype.c", line 52: warning: initializer does not fit or is out of range: 146 "ctype.c", line 52: warning: initializer does not fit or is out of range: 147 "ctype.c", line 52: warning: initializer does not fit or is out of range: 148 "ctype.c", line 52: warning: initializer does not fit or is out of range: 149 "ctype.c", line 52: warning: initializer does not fit or is out of range: 150 "ctype.c", line 52: warning: initializer does not fit or is out of range: 151 "ctype.c", line 53: warning: initializer does not fit or is out of range: 152 "ctype.c", line 53: warning: initializer does not fit or is out of range: 153 "ctype.c", line 53: warning: initializer does not fit or is out of range: 154 "ctype.c", line 53: warning: initializer does not fit or is out of range: 155 "ctype.c", line 53: warning: initializer does not fit or is out of range: 156 "ctype.c", line 53: warning: initializer does not fit or is out of range: 157 "ctype.c", line 53: warning: initializer does not fit or is out of range: 158 "ctype.c", line 53: warning: initializer does not fit or is out of range: 159 "ctype.c", line 54: warning: initializer does not fit or is out of range: 160 "ctype.c", line 54: warning: initializer does not fit or is out of range: 161 "ctype.c", line 54: warning: initializer does not fit or is out of range: 162 "ctype.c", line 54: warning: initializer does not fit or is out of range: 163 "ctype.c", line 54: warning: initializer does not fit or is out of range: 164 "ctype.c", line 54: warning: initializer does not fit or is out of range: 165 "ctype.c", line 54: warning: initializer does not fit or is out of range: 166 "ctype.c", line 54: warning: initializer does not fit or is out of range: 167 "ctype.c", line 55: warning: initializer does not fit or is out of range: 168 "ctype.c", line 55: warning: initializer does not fit or is out of range: 169 "ctype.c", line 55: warning: initializer does not fit or is out of range: 170 "ctype.c", line 55: warning: initializer does not fit or is out of range: 171 "ctype.c", line 55: warning: initializer does not fit or is out of range: 172 "ctype.c", line 55: warning: initializer does not fit or is out of range: 173 "ctype.c", line 55: warning: initializer does not fit or is out of range: 174 "ctype.c", line 55: warning: initializer does not fit or is out of range: 175 "ctype.c", line 56: warning: initializer does not fit or is out of range: 176 "ctype.c", line 56: warning: initializer does not fit or is out of range: 177 "ctype.c", line 56: warning: initializer does not fit or is out of range: 178 "ctype.c", line 56: warning: initializer does not fit or is out of range: 179 "ctype.c", line 56: warning: initializer does not fit or is out of range: 180 "ctype.c", line 56: warning: initializer does not fit or is out of range: 181 "ctype.c", line 56: warning: initializer does not fit or is out of range: 182 "ctype.c", line 56: warning: initializer does not fit or is out of range: 183 "ctype.c", line 57: warning: initializer does not fit or is out of range: 184 "ctype.c", line 57: warning: initializer does not fit or is out of range: 185 "ctype.c", line 57: warning: initializer does not fit or is out of range: 186 "ctype.c", line 57: warning: initializer does not fit or is out of range: 187 "ctype.c", line 57: warning: initializer does not fit or is out of range: 188 "ctype.c", line 57: warning: initializer does not fit or is out of range: 189 "ctype.c", line 57: warning: initializer does not fit or is out of range: 190 "ctype.c", line 57: warning: initializer does not fit or is out of range: 191 "ctype.c", line 58: warning: initializer does not fit or is out of range: 192 "ctype.c", line 58: warning: initializer does not fit or is out of range: 193 "ctype.c", line 58: warning: initializer does not fit or is out of range: 194 "ctype.c", line 58: warning: initializer does not fit or is out of range: 195 "ctype.c", line 58: warning: initializer does not fit or is out of range: 196 "ctype.c", line 58: warning: initializer does not fit or is out of range: 197 "ctype.c", line 58: warning: initializer does not fit or is out of range: 198 "ctype.c", line 58: warning: initializer does not fit or is out of range: 199 "ctype.c", line 59: warning: initializer does not fit or is out of range: 200 "ctype.c", line 59: warning: initializer does not fit or is out of range: 201 "ctype.c", line 59: warning: initializer does not fit or is out of range: 202 "ctype.c", line 59: warning: initializer does not fit or is out of range: 203 "ctype.c", line 59: warning: initializer does not fit or is out of range: 204 "ctype.c", line 59: warning: initializer does not fit or is out of range: 205 "ctype.c", line 59: warning: initializer does not fit or is out of range: 206 "ctype.c", line 59: warning: initializer does not fit or is out of range: 207 "ctype.c", line 60: warning: initializer does not fit or is out of range: 208 "ctype.c", line 60: warning: initializer does not fit or is out of range: 209 "ctype.c", line 60: warning: initializer does not fit or is out of range: 210 "ctype.c", line 60: warning: initializer does not fit or is out of range: 211 "ctype.c", line 60: warning: initializer does not fit or is out of range: 212 "ctype.c", line 60: warning: initializer does not fit or is out of range: 213 "ctype.c", line 60: warning: initializer does not fit or is out of range: 214 "ctype.c", line 60: warning: initializer does not fit or is out of range: 215 "ctype.c", line 61: warning: initializer does not fit or is out of range: 216 "ctype.c", line 61: warning: initializer does not fit or is out of range: 217 "ctype.c", line 61: warning: initializer does not fit or is out of range: 218 "ctype.c", line 61: warning: initializer does not fit or is out of range: 219 "ctype.c", line 61: warning: initializer does not fit or is out of range: 220 "ctype.c", line 61: warning: initializer does not fit or is out of range: 221 "ctype.c", line 61: warning: initializer does not fit or is out of range: 222 "ctype.c", line 61: warning: initializer does not fit or is out of range: 223 "ctype.c", line 62: warning: initializer does not fit or is out of range: 224 "ctype.c", line 62: warning: initializer does not fit or is out of range: 225 "ctype.c", line 62: warning: initializer does not fit or is out of range: 226 "ctype.c", line 62: warning: initializer does not fit or is out of range: 227 "ctype.c", line 62: warning: initializer does not fit or is out of range: 228 "ctype.c", line 62: warning: initializer does not fit or is out of range: 229 "ctype.c", line 62: warning: initializer does not fit or is out of range: 230 "ctype.c", line 62: warning: initializer does not fit or is out of range: 231 "ctype.c", line 63: warning: initializer does not fit or is out of range: 232 "ctype.c", line 63: warning: initializer does not fit or is out of range: 233 "ctype.c", line 63: warning: initializer does not fit or is out of range: 234 "ctype.c", line 63: warning: initializer does not fit or is out of range: 235 "ctype.c", line 63: warning: initializer does not fit or is out of range: 236 "ctype.c", line 63: warning: initializer does not fit or is out of range: 237 "ctype.c", line 63: warning: initializer does not fit or is out of range: 238 "ctype.c", line 63: warning: initializer does not fit or is out of range: 239 "ctype.c", line 64: warning: initializer does not fit or is out of range: 240 "ctype.c", line 64: warning: initializer does not fit or is out of range: 241 "ctype.c", line 64: warning: initializer does not fit or is out of range: 242 "ctype.c", line 64: warning: initializer does not fit or is out of range: 243 "ctype.c", line 64: warning: initializer does not fit or is out of range: 244 "ctype.c", line 64: warning: initializer does not fit or is out of range: 245 "ctype.c", line 64: warning: initializer does not fit or is out of range: 246 "ctype.c", line 64: warning: initializer does not fit or is out of range: 247 "ctype.c", line 65: warning: initializer does not fit or is out of range: 248 "ctype.c", line 65: warning: initializer does not fit or is out of range: 249 "ctype.c", line 65: warning: initializer does not fit or is out of range: 250 "ctype.c", line 65: warning: initializer does not fit or is out of range: 251 "ctype.c", line 65: warning: initializer does not fit or is out of range: 252 "ctype.c", line 65: warning: initializer does not fit or is out of range: 253 "ctype.c", line 65: warning: initializer does not fit or is out of range: 254 "ctype.c", line 65: warning: initializer does not fit or is out of range: 255 CC date.o CC decorate.o CC diffcore-break.o CC diffcore-delta.o CC diffcore-order.o CC diffcore-pickaxe.o CC diffcore-rename.o CC diff-delta.o CC diff-lib.o CC diff-no-index.o CC diff.o CC dir.o CC editor.o CC entry.o CC environment.o CC ewah/bitmap.o CC ewah/ewah_bitmap.o CC ewah/ewah_io.o CC ewah/ewah_rlw.o CC exec_cmd.o CC fetch-pack.o CC fsck.o CC gettext.o CC gpg-interface.o CC graph.o CC grep.o CC hashmap.o GEN common-cmds.h CC help.o CC hex.o CC ident.o CC kwset.o CC levenshtein.o CC line-log.o CC line-range.o CC list-objects.o CC ll-merge.o CC lockfile.o CC log-tree.o CC mailmap.o CC match-trees.o CC merge.o CC merge-blobs.o CC merge-recursive.o CC mergesort.o CC name-hash.o CC notes.o CC notes-cache.o CC notes-merge.o CC notes-utils.o CC object.o CC pack-bitmap.o CC pack-bitmap-write.o CC pack-check.o CC pack-objects.o CC pack-revindex.o CC pack-write.o CC pager.o CC parse-options.o CC parse-options-cb.o CC patch-delta.o CC patch-ids.o CC path.o CC pathspec.o CC pkt-line.o CC preload-index.o CC pretty.o CC prio-queue.o CC progress.o CC prompt.o CC quote.o CC reachable.o CC read-cache.o "read-cache.c", line 799: warning: statement not reached CC reflog-walk.o CC refs.o CC remote.o CC replace_object.o CC rerere.o CC resolve-undo.o CC revision.o CC run-command.o CC send-pack.o CC sequencer.o CC server-info.o CC setup.o CC sha1-array.o CC sha1-lookup.o CC sha1_file.o CC sha1_name.o CC shallow.o CC sideband.o CC sigchain.o CC split-index.o CC strbuf.o CC streaming.o CC string-list.o CC submodule.o CC symlinks.o CC tag.o CC trace.o "trace.c", line 219: error: identifier redeclared: trace_strbuf current : function(pointer to const char, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void previous: function(pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1}, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void : "trace.h", line 33 "trace.c", line 221: warning: argument http://public.kitware.com/Bug/view.php?id=3 is incompatible with prototype: prototype: pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1} : "trace.c", line 160 argument : pointer to const char "trace.c", line 390: error: reference to static identifier "offset" in extern inline function "trace.c", line 392: error: reference to static identifier "offset" in extern inline function "trace.c", line 393: error: reference to static identifier "offset" in extern inline function "trace.c", line 401: error: reference to static identifier "offset" in extern inline function "trace.c", line 403: error: reference to static identifier "offset" in extern inline function cc: acomp failed for trace.c gmake: *** [trace.o] Error 2 Additional Information: Solaris 10 with Oracle Studio 12.3 compiler tools. A lengthy maillist discussion last week sorted out the previous release of git just fine however this release fails to build. ====================================================================== ---------------------------------------------------------------------- (0036735) dev (reporter) - 2014-09-06 15:22 http://public.kitware.com/Bug/view.php?id=15131#c36735 ---------------------------------------------------------------------- Someone delete this before it grows legs and tasers me. Wrong mantis site entirely. Issue History Date Modified Username Field Change ====================================================================== 2014-09-06 15:19 dev New Issue 2014-09-06 15:22 dev Note Added: 0036735 2014-09-06 16:12 Rolf Eike Beer Issue Deleted: 0015131 ====================================================================== From dev at cor0.com Sat Sep 6 16:16:52 2014 From: dev at cor0.com (dev) Date: Sat, 6 Sep 2014 16:16:52 -0400 (EDT) Subject: [cmake-developers] [CMake 0015131] DELETED. Message-ID: <570885624.24704.1410034612900.JavaMail.vpopmail@webmail2.networksolutionsemail.com> thank you ... I clearly have too many software tasks going on here ---------- Original Message ---------- From: Mantis Bug Tracker To: cmake-developers at cmake.org Date: September 6, 2014 at 4:12 PM Subject: [cmake-developers] [CMake 0015131]: "trace.c", line 219: error: identifier redeclared: trace_strbuf The following issue has been DELETED. From mantis at public.kitware.com Sat Sep 6 21:27:36 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 6 Sep 2014 21:27:36 -0400 Subject: [cmake-developers] [CMake 0015133]: CMake 3.0.1 shows Segmentation Fault after installation under Cygwin64 on Windows7 Message-ID: <687f02c370ed272c92e83707620355c2@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15133 ====================================================================== Reported By: N. Thompson Assigned To: ====================================================================== Project: CMake Issue ID: 15133 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-06 21:27 EDT Last Modified: 2014-09-06 21:27 EDT ====================================================================== Summary: CMake 3.0.1 shows Segmentation Fault after installation under Cygwin64 on Windows7 Description: The CMake 3.0.1 source was downloaded (cmake-3.0.1.tar.gz with LF line endings), compiled and installed following the instructions on the CMake web site. Everything worked normally as the attached log file shows. When CMake was subsequently run to show the version number using cmake -version, a segmentation fault occurred (see log file). Steps to Reproduce: 1, Delete all previous remnants of cygwin from system 2. Download and run http://cygwin.com/setup-x86_64.exe to install 64-bit cygwin 3. When asked, selected the option to install everything 4. From cygwin terminal window run "cmake -version" to confirm version is 2.8 5. Download and decompress cmake-3.0.1.tar.gz (version with LF line endings) 6. Run "tar -xzvf cmake-3.0.1.tar.gz" to decompress and extract cmake 7. Change to cmake-3.0.1 directory created by previous step. 8. Run "./configure" 9. Run "make" 10. Run "make install" 11. Reboot system 12. Run "cmake -version" from a cywgin terminal window 13. The segmentation fault will occur Additional Information: The system is running Windows X64 Ultimate. Since a 64-bit version of cygwin was needed, the 32-bit version of cygwin that was originally installed on this system was removed. All remnants of cygwin were deleted from the system including the directories and desktop icons and start-menu entries. A new 64-bit was installed successfully without any failures. Every application in the cygwin package was installed. After cygwin64 was installed, cmake was run to show the version of cmake that came with the cygwin installer. It ran successfully and showed something like 2.8.11. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-06 21:27 N. Thompson New Issue 2014-09-06 21:27 N. Thompson File Added: cmake-3.0.1-cygwin64-failed-install-log-20140906.log ====================================================================== From mantis at public.kitware.com Mon Sep 8 02:47:25 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 8 Sep 2014 02:47:25 -0400 Subject: [cmake-developers] [CMake 0015134]: add_subdirectory() fails when CMakeLists.txt in drive root Message-ID: <4a1f8d8ec76a951efdc0128041cb830f@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15134 ====================================================================== Reported By: Mattes D Assigned To: ====================================================================== Project: CMake Issue ID: 15134 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-08 02:47 EDT Last Modified: 2014-09-08 02:47 EDT ====================================================================== Summary: add_subdirectory() fails when CMakeLists.txt in drive root Description: I'm using the "subst" command on windows to make my build folder the root of a separate drive. Thus, the cmake file being processed is called "N:\CMakeLists.txt". CMake then fails to process the file, with several errors, all following the pattern: CMake Error at N://CMakeLists.txt:66 (add_subdirectory): add_subdirectory not given a binary directory but the given source directory "N:/lib/jsoncpp" is not a subdirectory of "N:/". When specifying an out-of-tree source a binary directory must be explicitly specified. CMake Error at N://CMakeLists.txt:76 (get_property): get_property DIRECTORY scope provided but requested directory was not found. This could be because the directory argument was invalid or, it is valid but has not been processed yet. The very same cmake file, when used in a subfolder, works without a problem. For your reference, the CMakeLists.txt file being used is this one: https://github.com/mc-server/MCServer/blob/562b2d1d1de7438bc763d778b56b0743affd1b5b/CMakeLists.txt Cmake is being called as: cmake -G "Visual Studio 9 2008" . Steps to Reproduce: Use subst to map a folder containing a project to a separate drive letter. Then use CMake in that drive's root to configure the project. CMake fails with the specified error. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-08 02:47 Mattes D New Issue ====================================================================== From pascal.bach at siemens.com Mon Sep 8 05:35:02 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Mon, 8 Sep 2014 11:35:02 +0200 Subject: [cmake-developers] [PATCH 1/3] WINCE: Document the WINCE variable In-Reply-To: <540A14A2.30904@kitware.com> References: <540A14A2.30904@kitware.com> Message-ID: <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> From: Pascal Bach --- Help/manual/cmake-variables.7.rst | 1 + Help/variable/WINCE.rst | 5 +++++ 2 files changed, 6 insertions(+) create mode 100644 Help/variable/WINCE.rst diff --git a/Help/manual/cmake-variables.7.rst b/Help/manual/cmake-variables.7.rst index 149e4ac..b00c16e 100644 --- a/Help/manual/cmake-variables.7.rst +++ b/Help/manual/cmake-variables.7.rst @@ -192,6 +192,7 @@ Variables that Describe the System /variable/MSVC_VERSION /variable/UNIX /variable/WIN32 + /variable/WINCE /variable/WINDOWS_PHONE /variable/WINDOWS_STORE /variable/XCODE_VERSION diff --git a/Help/variable/WINCE.rst b/Help/variable/WINCE.rst new file mode 100644 index 0000000..54ff7de --- /dev/null +++ b/Help/variable/WINCE.rst @@ -0,0 +1,5 @@ +WINCE +----- + +True when the :variable:`CMAKE_SYSTEM_NAME` variable is set +to ``WindowsCE``. -- 1.7.10.4 From pascal.bach at siemens.com Mon Sep 8 05:35:04 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Mon, 8 Sep 2014 11:35:04 +0200 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> Message-ID: <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> Currently the mapping from flags to XML elements in the Visual Studio generator is case sensitive. It only handles upper case flags so we should pass them as upper case. Even better would be to make the search case insensitive. --- Modules/Platform/Windows-MSVC.cmake | 36 +++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/Modules/Platform/Windows-MSVC.cmake b/Modules/Platform/Windows-MSVC.cmake index a72f946..236328e 100644 --- a/Modules/Platform/Windows-MSVC.cmake +++ b/Modules/Platform/Windows-MSVC.cmake @@ -33,16 +33,16 @@ endif() if(CMAKE_VERBOSE_MAKEFILE) set(CMAKE_CL_NOLOGO) else() - set(CMAKE_CL_NOLOGO "/nologo") + set(CMAKE_CL_NOLOGO "/NOLOGO") endif() if(CMAKE_SYSTEM_NAME STREQUAL "WindowsCE") - set(CMAKE_CREATE_WIN32_EXE "/entry:WinMainCRTStartup") - set(CMAKE_CREATE_CONSOLE_EXE "/entry:mainACRTStartup") - set(_PLATFORM_LINK_FLAGS " /subsystem:windowsce") + set(CMAKE_CREATE_WIN32_EXE "/SUBSYSTEM:WINDOWSCE /ENTRY:WinMainCRTStartup") + set(CMAKE_CREATE_CONSOLE_EXE "/SUBSYSTEM:WINDOWSCE /ENTRY:mainACRTStartup") + set(_PLATFORM_LINK_FLAGS "") else() - set(CMAKE_CREATE_WIN32_EXE "/subsystem:windows") - set(CMAKE_CREATE_CONSOLE_EXE "/subsystem:console") + set(CMAKE_CREATE_WIN32_EXE "/SUBSYSTEM:WINDOWS") + set(CMAKE_CREATE_CONSOLE_EXE "/SUBSYSTEM:CONSOLE") set(_PLATFORM_LINK_FLAGS "") endif() @@ -55,7 +55,7 @@ endif() # make sure to enable languages after setting configuration types enable_language(RC) -set(CMAKE_COMPILE_RESOURCE "rc /fo ") +set(CMAKE_COMPILE_RESOURCE "rc /Fo ") if("${CMAKE_GENERATOR}" MATCHES "Visual Studio") set(MSVC_IDE 1) @@ -200,16 +200,16 @@ set(CMAKE_CXX_STANDARD_LIBRARIES_INIT "${CMAKE_C_STANDARD_LIBRARIES_INIT}") set (CMAKE_LINK_DEF_FILE_FLAG "/DEF:") # set the machine type if(MSVC_C_ARCHITECTURE_ID) - set(_MACHINE_ARCH_FLAG "/machine:${MSVC_C_ARCHITECTURE_ID}") + set(_MACHINE_ARCH_FLAG "/MACHINE:${MSVC_C_ARCHITECTURE_ID}") elseif(MSVC_CXX_ARCHITECTURE_ID) - set(_MACHINE_ARCH_FLAG "/machine:${MSVC_CXX_ARCHITECTURE_ID}") + set(_MACHINE_ARCH_FLAG "/MACHINE:${MSVC_CXX_ARCHITECTURE_ID}") elseif(MSVC_Fortran_ARCHITECTURE_ID) - set(_MACHINE_ARCH_FLAG "/machine:${MSVC_Fortran_ARCHITECTURE_ID}") + set(_MACHINE_ARCH_FLAG "/MACHINE:${MSVC_Fortran_ARCHITECTURE_ID}") endif() set(CMAKE_EXE_LINKER_FLAGS_INIT "${CMAKE_EXE_LINKER_FLAGS_INIT} ${_MACHINE_ARCH_FLAG}") unset(_MACHINE_ARCH_FLAG) -# add /debug and /INCREMENTAL:YES to DEBUG and RELWITHDEBINFO also add pdbtype +# add /DEBUG and /INCREMENTAL:YES to DEBUG and RELWITHDEBINFO also add PDBTYPE # on versions that support it set( MSVC_INCREMENTAL_YES_FLAG "") if(NOT WINDOWS_PHONE AND NOT WINDOWS_STORE) @@ -221,11 +221,11 @@ if(NOT WINDOWS_PHONE AND NOT WINDOWS_STORE) endif() if (CMAKE_COMPILER_SUPPORTS_PDBTYPE) - set (CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "/debug /pdbtype:sept ${MSVC_INCREMENTAL_YES_FLAG}") - set (CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO_INIT "/debug /pdbtype:sept ${MSVC_INCREMENTAL_YES_FLAG}") + set (CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "/DEBUG /PDBTYPE:sept ${MSVC_INCREMENTAL_YES_FLAG}") + set (CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO_INIT "/DEBUG /PDBTYPE:sept ${MSVC_INCREMENTAL_YES_FLAG}") else () - set (CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "/debug ${MSVC_INCREMENTAL_YES_FLAG}") - set (CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO_INIT "/debug ${MSVC_INCREMENTAL_YES_FLAG}") + set (CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "/DEBUG ${MSVC_INCREMENTAL_YES_FLAG}") + set (CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO_INIT "/DEBUG ${MSVC_INCREMENTAL_YES_FLAG}") endif () # for release and minsize release default to no incremental linking set(CMAKE_EXE_LINKER_FLAGS_MINSIZEREL_INIT "/INCREMENTAL:NO") @@ -252,10 +252,10 @@ macro(__windows_compiler_msvc lang) set(_CMAKE_VS_LINK_EXE " -E vs_link_exe ") endif() set(CMAKE_${lang}_CREATE_SHARED_LIBRARY - "${_CMAKE_VS_LINK_DLL} ${CMAKE_CL_NOLOGO} ${CMAKE_START_TEMP_FILE} /out: /implib: /pdb: /dll /version:.${_PLATFORM_LINK_FLAGS} ${CMAKE_END_TEMP_FILE}") + "${_CMAKE_VS_LINK_DLL} ${CMAKE_CL_NOLOGO} ${CMAKE_START_TEMP_FILE} /OUT: /IMPLIB: /PDB: /DLL /VERSION:.${_PLATFORM_LINK_FLAGS} ${CMAKE_END_TEMP_FILE}") set(CMAKE_${lang}_CREATE_SHARED_MODULE ${CMAKE_${lang}_CREATE_SHARED_LIBRARY}) - set(CMAKE_${lang}_CREATE_STATIC_LIBRARY " /lib ${CMAKE_CL_NOLOGO} /out: ") + set(CMAKE_${lang}_CREATE_STATIC_LIBRARY " /LIB ${CMAKE_CL_NOLOGO} /OUT: ") set(CMAKE_${lang}_COMPILE_OBJECT " ${CMAKE_START_TEMP_FILE} ${CMAKE_CL_NOLOGO}${_COMPILE_${lang}} /Fo /Fd${_FS_${lang}} -c ${CMAKE_END_TEMP_FILE}") @@ -266,7 +266,7 @@ macro(__windows_compiler_msvc lang) set(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_OBJECTS 1) set(CMAKE_${lang}_LINK_EXECUTABLE - "${_CMAKE_VS_LINK_EXE} ${CMAKE_CL_NOLOGO} ${CMAKE_START_TEMP_FILE} /out: /implib: /pdb: /version:.${_PLATFORM_LINK_FLAGS} ${CMAKE_END_TEMP_FILE}") + "${_CMAKE_VS_LINK_EXE} ${CMAKE_CL_NOLOGO} ${CMAKE_START_TEMP_FILE} /OUT: /implib: /PDB: /version:.${_PLATFORM_LINK_FLAGS} ${CMAKE_END_TEMP_FILE}") set(CMAKE_${lang}_FLAGS_INIT "${_PLATFORM_DEFINES}${_PLATFORM_DEFINES_${lang}} /D_WINDOWS /W3${_FLAGS_${lang}}") set(CMAKE_${lang}_FLAGS_DEBUG_INIT "/D_DEBUG /MDd /Zi /Ob0 /Od ${_RTC1}") -- 1.7.10.4 From pascal.bach at siemens.com Mon Sep 8 05:35:03 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Mon, 8 Sep 2014 11:35:03 +0200 Subject: [cmake-developers] [PATCH 2/3] WINCE, VS: Propagate Subsystem and Entry point to generated solution In-Reply-To: <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> Message-ID: <1410168904-7228-2-git-send-email-pascal.bach@siemens.com> The flags /SUBSYSTEM and /ENTRY are set by Windows-MSVC.cmake depending on the system. Howver these values never ended up in the resulting VS solution. This is fixed by reading the values of CMAKE_CREATE_WIN32_EXE and CMAKE_CREATE_CONSOLE_EXE and propagates theses to the resulting XML. --- Source/cmVS11LinkFlagTable.h | 2 ++ Source/cmVS12LinkFlagTable.h | 2 ++ Source/cmVS14LinkFlagTable.h | 2 ++ Source/cmVisualStudio10TargetGenerator.cxx | 19 ++++++++++--------- 4 files changed, 16 insertions(+), 9 deletions(-) diff --git a/Source/cmVS11LinkFlagTable.h b/Source/cmVS11LinkFlagTable.h index 0f641e4..765dbcf 100644 --- a/Source/cmVS11LinkFlagTable.h +++ b/Source/cmVS11LinkFlagTable.h @@ -56,6 +56,8 @@ static cmVS7FlagTable cmVS11LinkFlagTable[] = "EFI ROM", "EFI ROM", 0}, {"SubSystem", "SUBSYSTEM:EFI_RUNTIME_DRIVER", "EFI Runtime", "EFI Runtime", 0}, + {"SubSystem", "SUBSYSTEM:WINDOWSCE", + "WindowsCE", "WindowsCE", 0}, {"SubSystem", "SUBSYSTEM:POSIX", "POSIX", "POSIX", 0}, diff --git a/Source/cmVS12LinkFlagTable.h b/Source/cmVS12LinkFlagTable.h index e5a570e..ca68c7e 100644 --- a/Source/cmVS12LinkFlagTable.h +++ b/Source/cmVS12LinkFlagTable.h @@ -56,6 +56,8 @@ static cmVS7FlagTable cmVS12LinkFlagTable[] = "EFI ROM", "EFI ROM", 0}, {"SubSystem", "SUBSYSTEM:EFI_RUNTIME_DRIVER", "EFI Runtime", "EFI Runtime", 0}, + {"SubSystem", "SUBSYSTEM:WINDOWSCE", + "WindowsCE", "WindowsCE", 0}, {"SubSystem", "SUBSYSTEM:POSIX", "POSIX", "POSIX", 0}, diff --git a/Source/cmVS14LinkFlagTable.h b/Source/cmVS14LinkFlagTable.h index 6d81d12..67ddbe3 100644 --- a/Source/cmVS14LinkFlagTable.h +++ b/Source/cmVS14LinkFlagTable.h @@ -56,6 +56,8 @@ static cmVS7FlagTable cmVS14LinkFlagTable[] = "EFI ROM", "EFI ROM", 0}, {"SubSystem", "SUBSYSTEM:EFI_RUNTIME_DRIVER", "EFI Runtime", "EFI Runtime", 0}, + {"SubSystem", "SUBSYSTEM:WINDOWSCE", + "WindowsCE", "WindowsCE", 0}, {"SubSystem", "SUBSYSTEM:POSIX", "POSIX", "POSIX", 0}, diff --git a/Source/cmVisualStudio10TargetGenerator.cxx b/Source/cmVisualStudio10TargetGenerator.cxx index c525b7c..1c2a7be 100644 --- a/Source/cmVisualStudio10TargetGenerator.cxx +++ b/Source/cmVisualStudio10TargetGenerator.cxx @@ -2041,6 +2041,16 @@ cmVisualStudio10TargetGenerator::ComputeLinkOptions(std::string const& config) flags += " "; flags += flagsConfig; } + if (this->Target->GetPropertyAsBool("WIN32_EXECUTABLE")) + { + flags += " "; + flags += this->Target->GetMakefile()->GetSafeDefinition("CMAKE_CREATE_WIN32_EXE"); + } + else + { + flags += " "; + flags += this->Target->GetMakefile()->GetSafeDefinition("CMAKE_CREATE_CONSOLE_EXE"); + } std::string standardLibsVar = "CMAKE_"; standardLibsVar += linkLanguage; standardLibsVar += "_STANDARD_LIBRARIES"; @@ -2113,15 +2123,6 @@ cmVisualStudio10TargetGenerator::ComputeLinkOptions(std::string const& config) { linkOptions.AddFlag("Version", ""); - if ( this->Target->GetPropertyAsBool("WIN32_EXECUTABLE") ) - { - linkOptions.AddFlag("SubSystem", "Windows"); - } - else - { - linkOptions.AddFlag("SubSystem", "Console"); - } - if(const char* stackVal = this->Makefile->GetDefinition("CMAKE_"+linkLanguage+"_STACK_SIZE")) { -- 1.7.10.4 From mantis at public.kitware.com Mon Sep 8 05:45:46 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 8 Sep 2014 05:45:46 -0400 Subject: [cmake-developers] [CMake 0015135]: Allow properties on installed directories Message-ID: <9e6914bc9cfabd7ad51fdd375d7943e9@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15135 ====================================================================== Reported By: Richard Ulrich Assigned To: ====================================================================== Project: CMake Issue ID: 15135 Category: CPack Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-08 05:45 EDT Last Modified: 2014-09-08 05:45 EDT ====================================================================== Summary: Allow properties on installed directories Description: Since cmake 3 (I think) we can set properties on installed files. This is great, but it would be even better, if we could also set these properties on installed directories. Steps to Reproduce: INSTALL(DIRECTORY source/ DESTINATION "/" COMPONENT app PATTERN "Database/*.zip" EXCLUDE ) SET_PROPERTY(INSTALL "/" PROPERTY CPACK_WIX_ACL "Everyone=GenericAll" ) Additional Information: Since the install properties are part of cmInstalledFile, it's not just a WiX issue. WiX in turn supports these properties on directories. http://wixtoolset.org/documentation/manual/v3/xsd/wix/createfolder.html At the moment I sole it with a custom action, but it would be really great if I didn't have to do that. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-08 05:45 Richard Ulrich New Issue ====================================================================== From brad.king at kitware.com Mon Sep 8 08:51:43 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 08 Sep 2014 08:51:43 -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> Message-ID: <540DA65F.4030501@kitware.com> On 09/03/2014 12:12 PM, Aleix Pol wrote: > On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf wrote: >> I still don't understand why this shouldn't be an additional ExtraGenerator. > > Because it's not possible to change the generator of a build directory > once it's set up. You need to nuke it and re-create it. [snip] On 09/01/2014 07:27 PM, Aleix Pol wrote: > Ok, how does it sound if we have a variable, such as CMAKE_EXPORT_COMPILE_COMMANDS? > Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. A control variable like that sounds good to me. The purpose looks very similar to CMAKE_EXPORT_COMPILE_COMMANDS, but is distinct enough to have its own control. Thanks, -Brad From mantis at public.kitware.com Mon Sep 8 10:11:38 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 8 Sep 2014 10:11:38 -0400 Subject: [cmake-developers] [CMake 0015137]: find_package(LAPACK) reports incorrect syntax in FindLAPACK.cmake Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15137 ====================================================================== Reported By: Eugene Shalygin Assigned To: ====================================================================== Project: CMake Issue ID: 15137 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-08 10:11 EDT Last Modified: 2014-09-08 10:11 EDT ====================================================================== Summary: find_package(LAPACK) reports incorrect syntax in FindLAPACK.cmake Description: Part of the cmake output log: -- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") -- checking for module 'blas' -- found blas, version 3.2.1 -- Found BLAS: /usr/lib64/libeigen_blas.so -- checking for module 'lapack' -- found lapack, version 3.4.2 CMake Error at /usr/share/cmake/Modules/FindLAPACK.cmake:190 (check_lapack_libraries): A logical block opening on the line /usr/share/cmake/Modules/FindLAPACK.cmake:84 (if) is not closed. Steps to Reproduce: $ cat << EOF > CMakeLists.txt project(test) find_package(LAPACK) EOF $ mkdir -p build & cd build & cmake .. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-08 10:11 Eugene ShalyginNew Issue ====================================================================== From brad.king at kitware.com Mon Sep 8 10:44:42 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 08 Sep 2014 10:44:42 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5409B874.2060607@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> Message-ID: <540DC0DA.5010409@kitware.com> On 09/05/2014 09:19 AM, Nils Gladitz wrote: > On 09/05/2014 02:50 PM, Brad King wrote: >> On 09/04/2014 11:58 AM, Nils Gladitz wrote: >> - The dashboard submissions that bootstrap got many CMP0054 >> warnings. Most of them are the same warning repeated due >> to presence in a macro or loop. Please update the warning >> to not warn on the same line more than once. A set<> of >> already-emitted warning lines can be kept somewhere. > > I'll look into it. Good work on the revisions. In the warning message: Quoted variables like 'SOME_VAR' are no longer dereferenced. I think the 'single quoting' may be confusing since it looks like an example of the quoting that is no longer dereferenced. Instead use double-quotes: Quoted variables like "SOME_VAR" are no longer dereferenced. I tested this on a few projects and found that the warning is repeated in cases like: macro(foo VAR) if("${VAR}" MATCHES "^${VAR}$") endmacro() because each call has a different quoted variable name after macro expansion. Since if() does not even get the arguments until after the macro execution has substituted for ${VAR}, it is hard to eliminate this unless we take out the variable name from the dedup set key. I think perhaps we should do that even though it could suppress cases with multiple separate problems in a single if() command. The goal of dedup is to reduce the number of warnings that show up. Once a developer sits down to resolve the warnings, s/he will repeat running CMake until all the warnings are gone anyway. Thanks, -Brad From nilsgladitz at gmail.com Mon Sep 8 11:35:27 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 08 Sep 2014 17:35:27 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <540DC0DA.5010409@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> Message-ID: <540DCCBF.6010002@gmail.com> On 09/08/2014 04:44 PM, Brad King wrote: > Good work on the revisions. Thanks. I updated the topic, squished and merged. Nils From brad.king at kitware.com Mon Sep 8 13:07:55 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 08 Sep 2014 13:07:55 -0400 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> Message-ID: <540DE26B.20005@kitware.com> On 09/08/2014 05:35 AM, Pascal Bach wrote: > Even better would be to make the search case insensitive. How do we know which flags are sensitive to case? > - set(CMAKE_CREATE_WIN32_EXE "/entry:WinMainCRTStartup") > - set(CMAKE_CREATE_CONSOLE_EXE "/entry:mainACRTStartup") > - set(_PLATFORM_LINK_FLAGS " /subsystem:windowsce") > + set(CMAKE_CREATE_WIN32_EXE "/SUBSYSTEM:WINDOWSCE /ENTRY:WinMainCRTStartup") > + set(CMAKE_CREATE_CONSOLE_EXE "/SUBSYSTEM:WINDOWSCE /ENTRY:mainACRTStartup") > + set(_PLATFORM_LINK_FLAGS "") That appears to un-do this recent fix: MSVC: Fix linking of DLLs on WinCE (#15013) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e1283e4 http://www.cmake.org/Bug/view.php?id=15013 that introduced _PLATFORM_LINK_FLAGS in the first place. -Brad From brad.king at kitware.com Mon Sep 8 13:17:19 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 08 Sep 2014 13:17:19 -0400 Subject: [cmake-developers] OS X packaging updates In-Reply-To: <5409AD80.2000303@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> <5408B278.2070400@kitware.com> <4C094659-30A8-4304-ADBD-C62A1788C2A0@java.pl> <5409AD80.2000303@kitware.com> Message-ID: <540DE49F.8090508@kitware.com> On 09/05/2014 08:33 AM, Brad King wrote: > Thanks. I've re-built the topic with those locally. I've merged to 'next' for testing: BundleUtilities: Use 'find' on UNIX for fast executable lookup http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=02dfaa31 GetPrerequisites: Make sure dyld placeholders are prefixes http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=195ec6b3 BundleUtilities: Resolve & replace @rpath placeholders http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7747b13e BundleUtilities: Process executables first when scanning bundle http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea9e35be BundleUtilities: Codesign needs framework's Contents/Info.plist http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd67c3ea cmake-gui: Make sure we bundle Qt5 Cocoa platform plugin http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c106311f -Brad From mantis at public.kitware.com Mon Sep 8 14:20:19 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 8 Sep 2014 14:20:19 -0400 Subject: [cmake-developers] [CMake 0015142]: Cannot set different INTERFACE_COMPILE_DEFINITIONS for different IMPORTED_CONFIGURATIONS Message-ID: <27d0080f1ae79d4de63f46cbbf63f288@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15142 ====================================================================== Reported By: Daniele E. Domenichelli Assigned To: ====================================================================== Project: CMake Issue ID: 15142 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-08 14:20 EDT Last Modified: 2014-09-08 14:20 EDT ====================================================================== Summary: Cannot set different INTERFACE_COMPILE_DEFINITIONS for different IMPORTED_CONFIGURATIONS Description: The INTERFACE_COMPILE_DEFINITIONS target property does not have an IMPORTED_CONFIGURATIONS_ analogue. This means that it is not possible for imported libraries to use different definitions depending on the configuration of the library being used. Steps to Reproduce: In my opinion it should be possible to do something like this: add_library(FOO::FOO IMPORTED UNKNOWN) set_property(TARGET FOO::FOO PROPERTY INTERFACE_INCLUDE_DIRECTORIES "${FOO_INCLUDE_DIRS}") if(FOO_LIBRARY_RELEASE) set_property(TARGET FOO::FOO APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE) set_property(TARGET FOO::FOO PROPERTY IMPORTED_LOCATION_RELEASE "${FOO_LIBRARY_RELEASE}") set_property(TARGET FOO::FOO APPEND PROPERTY INTERFACE_COMPILE_DEFINITIONS_RELEASE FOO_RELEASE) endif() if(FOO_LIBRARY_DEBUG) set_property(TARGET FOO::FOO APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG) set_property(TARGET FOO::FOO PROPERTY IMPORTED_LOCATION_DEBUG "${FOO_LIBRARY_DEBUG}") set_property(TARGET FOO::FOO APPEND PROPERTY INTERFACE_COMPILE_DEFINITIONS_DEBUG FOO_DEBUG) endif() And depending on the configuration of the library being used, it should automatically add -DFOO_RELEASE or -DFOO_DEBUG. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-08 14:20 Daniele E. DomenichelliNew Issue ====================================================================== From irwin at beluga.phys.uvic.ca Mon Sep 8 15:52:09 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 8 Sep 2014 12:52:09 -0700 (PDT) Subject: [cmake-developers] [PATCH] Fix infinite loop in file downloads if hash value not a match Message-ID: I was caught by this infinite loop issue when attempting to build Qt5.3.1 using ExternalProject.cmake. I used an MD5 sum value given by BLFS for the Qt5.3.1 tar.gz download which happened to be the wrong value. In my case the consequences were not too bad because I was "downloading" from a local disk drive "URL". However, this infinite loop could be construed as a denial-of-service attack on some open-source project if an actual download keeps getting repeated indefinitely. Note this bad retries logic in the downloads was introduced after CMake-2.8.12.2, and a search of the bug tracker for "infinite" shows nothing relevant. See attached patch in "git format-patch" form that fixes the problem for the CMake master branch. 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 __________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-infinite-loop-in-file-downloads-if-hash-value-no.patch Type: text/x-diff Size: 841 bytes Desc: Fix for ExternalProject.cmake URL: From brad.king at kitware.com Mon Sep 8 16:11:24 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 08 Sep 2014 16:11:24 -0400 Subject: [cmake-developers] OS X packaging updates In-Reply-To: <540DE49F.8090508@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> <5408B278.2070400@kitware.com> <4C094659-30A8-4304-ADBD-C62A1788C2A0@java.pl> <5409AD80.2000303@kitware.com> <540DE49F.8090508@kitware.com> Message-ID: <540E0D6C.2010402@kitware.com> On 09/08/2014 01:17 PM, Brad King wrote: > On 09/05/2014 08:33 AM, Brad King wrote: >> Thanks. I've re-built the topic with those locally. > > I've merged to 'next' for testing: I had to revert again because it causes the Qt4Deploy to fail. The topic changes the signature of gp_file_type. User projects could be calling that, so we can't change it. In this case it is the Modules/DeployQt4.cmake file that was calling it. -Brad From brad.king at kitware.com Mon Sep 8 16:38:36 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 08 Sep 2014 16:38:36 -0400 Subject: [cmake-developers] [PATCH] Fix infinite loop in file downloads if hash value not a match In-Reply-To: References: Message-ID: <540E13CC.60209@kitware.com> On 09/08/2014 03:52 PM, Alan W. Irwin wrote: > I was caught by this infinite loop issue when attempting to build > Qt5.3.1 using ExternalProject.cmake. Applied, thanks: ExternalProject: Avoid infinite loop on file download hash mismatch http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f49ac3d I based it on a commit old enough to merge to a 3.0.x bugfix release. Thanks, -Brad From pascal.bach at siemens.com Tue Sep 9 05:31:15 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 9 Sep 2014 09:31:15 +0000 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <540DE26B.20005@kitware.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> > On 09/08/2014 05:35 AM, Pascal Bach wrote: > > Even better would be to make the search case insensitive. > > How do we know which flags are sensitive to case? It has nothing to do with Visual Studio as it doesn't care about the casing. The problem is in the CMake generator. The tables in (eg. Source/cmVS10LinkFlagTable.h) map from linker flags to XML elements in the resulting .vcxproj file. One such example is the entry: {"SubSystem", "SUBSYSTEM:WINDOWSCE", "WindowsCE", "WindowsCE", 0}, This maps a flag /SUBSYSTEM:WINDOWSCE to WindowsCE As you can see the entries in the table are in upper case. And the mapping does only work if the flags are uppercase to. Maybe a better solution would be to do this matching in a case in sensitive way, this way it would work in any case even with user passed flags in lower case. > > > - set(CMAKE_CREATE_WIN32_EXE "/entry:WinMainCRTStartup") > > - set(CMAKE_CREATE_CONSOLE_EXE "/entry:mainACRTStartup") > > - set(_PLATFORM_LINK_FLAGS " /subsystem:windowsce") > > + set(CMAKE_CREATE_WIN32_EXE "/SUBSYSTEM:WINDOWSCE > /ENTRY:WinMainCRTStartup") > > + set(CMAKE_CREATE_CONSOLE_EXE "/SUBSYSTEM:WINDOWSCE > /ENTRY:mainACRTStartup") > > + set(_PLATFORM_LINK_FLAGS "") > > That appears to un-do this recent fix: > > MSVC: Fix linking of DLLs on WinCE (#15013) > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e1283e4 > http://www.cmake.org/Bug/view.php?id=15013 > > that introduced _PLATFORM_LINK_FLAGS in the first place. Rith I think I had a too simplistic view here. But even the old fix doesn't seem to work with VS. I think the /ENTRY point also needs to be set for the DLLs, I will try if I can find out how to set this. Pascal PS: Forgot to add the mailinglist. From brad.king at kitware.com Tue Sep 9 08:29:53 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Sep 2014 08:29:53 -0400 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <540EF2C1.8050701@kitware.com> On 09/09/2014 05:31 AM, Bach, Pascal wrote: > Maybe a better solution would be to do this matching in a case insensitive way, > this way it would work in any case even with user passed flags in lower case. I'm saying that some flags are case sensitive and others are not. We cannot blindly match all "cl" flags insensitive to case, for example. Anyway, I think just matching the case is good enough for now. Thanks, -Brad From pascal.bach at siemens.com Tue Sep 9 09:48:06 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 9 Sep 2014 13:48:06 +0000 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <540EF2C1.8050701@kitware.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> <540EF2C1.8050701@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> > > Maybe a better solution would be to do this matching in a case insensitive > way, > > this way it would work in any case even with user passed flags in lower > case. > > I'm saying that some flags are case sensitive and others are not. > We cannot blindly match all "cl" flags insensitive to case, for > example. Anyway, I think just matching the case is good enough > for now. Ok I didn't know that cl does care about casing for some flags. > > - set(CMAKE_CREATE_WIN32_EXE "/entry:WinMainCRTStartup") > > - set(CMAKE_CREATE_CONSOLE_EXE "/entry:mainACRTStartup") > > - set(_PLATFORM_LINK_FLAGS " /subsystem:windowsce") > > + set(CMAKE_CREATE_WIN32_EXE "/SUBSYSTEM:WINDOWSCE > /ENTRY:WinMainCRTStartup") > > + set(CMAKE_CREATE_CONSOLE_EXE "/SUBSYSTEM:WINDOWSCE > /ENTRY:mainACRTStartup") > > + set(_PLATFORM_LINK_FLAGS "") > > That appears to un-do this recent fix: > > MSVC: Fix linking of DLLs on WinCE (#15013) > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e1283e4 > http://www.cmake.org/Bug/view.php?id=15013 > > that introduced _PLATFORM_LINK_FLAGS in the first place. The values added to _PLATFORM_LINK_FLAGS do never end up in the .vcxproj file. The go into CMAKE_${lang}_CREATE_SHARED_LIBRARY [1] and CMAKE_${lang}_LINK_EXECUTABLE [2] However I can't see how this variables should end up in the VS generator. Any ideas? [1] https://github.com/Kitware/CMake/blob/6ae98ee18f6c35b93556a66dc0ce909d84aec18b/Modules/Platform/Windows-MSVC.cmake#L242 [2] https://github.com/Kitware/CMake/blob/6ae98ee18f6c35b93556a66dc0ce909d84aec18b/Modules/Platform/Windows-MSVC.cmake#L256 From brad.king at kitware.com Tue Sep 9 09:53:27 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Sep 2014 09:53:27 -0400 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> <540EF2C1.8050701@kitware.com> <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <540F0657.1010606@kitware.com> On 09/09/2014 09:48 AM, Bach, Pascal wrote: > The values added to _PLATFORM_LINK_FLAGS do never end up in the .vcxproj file. > The go into CMAKE_${lang}_CREATE_SHARED_LIBRARY [1] and CMAKE_${lang}_LINK_EXECUTABLE [2] > However I can't see how this variables should end up in the VS generator. > > Any ideas? Those are all for the Makefile and Ninja generators, as are CMAKE_CREATE_WIN32_EXE and CMAKE_CREATE_CONSOLE_EXE. For VS generators the knowledge has always been hard-coded, with a special case for Windows CE: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalVisualStudio7Generator.cxx;hb=v3.0.1#l1122 The cmVisualStudio10TargetGenerator could be taught this similarly. -Brad From pascal.bach at siemens.com Tue Sep 9 10:19:47 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 9 Sep 2014 14:19:47 +0000 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <540F0657.1010606@kitware.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> <540EF2C1.8050701@kitware.com> <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> <540F0657.1010606@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACF2F9@DEFTHW99EH4MSX.ww902.siemens.net> > Those are all for the Makefile and Ninja generators, as are > CMAKE_CREATE_WIN32_EXE and CMAKE_CREATE_CONSOLE_EXE. For VS > generators the knowledge has always been hard-coded, with a > special case for Windows CE: > > > http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalVisual > Studio7Generator.cxx;hb=v3.0.1#l1122 > > The cmVisualStudio10TargetGenerator could be taught this > similarly. Wouldn't it make sense to use the same variables in the VS10+ Generator too? It seems redundant to have the same information again. What's the reason it is hardcoded? Pascal From brad.king at kitware.com Tue Sep 9 10:27:45 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Sep 2014 10:27:45 -0400 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <355BE46A91031048906B695426A8D8E616ACF2F9@DEFTHW99EH4MSX.ww902.siemens.net> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> <540EF2C1.8050701@kitware.com> <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> <540F0657.1010606@kitware.com> <355BE46A91031048906B695426A8D8E616ACF2F9@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <540F0E61.6080605@kitware.com> On 09/09/2014 10:19 AM, Bach, Pascal wrote: > Wouldn't it make sense to use the same variables in the VS10+ Generator too? > It seems redundant to have the same information again. What's the reason it is hardcoded? That's just the way it was written. The rule variables like CMAKE_${lang}_CREATE_SHARED_LIBRARY contain command lines in which the Makefile and Ninja generators substitute for some placeholders. The VS generators do not have a command line because they just put the declarative information into the project file and let VS build the command line. If you want to refactor things to create more independent flag-holding variables that are used to construct CMAKE_${lang}_CREATE_SHARED_LIBRARY and also read by the VS generators and sent through the flag map, that's fine with me. Please also update the VS 7-9 generators to use the same information variables if possible. -Brad From pascal.bach at siemens.com Tue Sep 9 11:02:03 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 9 Sep 2014 15:02:03 +0000 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <540F0E61.6080605@kitware.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> <540EF2C1.8050701@kitware.com> <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> <540F0657.1010606@kitware.com> <355BE46A91031048906B695426A8D8E616ACF2F9@DEFTHW99EH4MSX.ww902.siemens.net> <540F0E61.6080605@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACF34D@DEFTHW99EH4MSX.ww902.siemens.net> > On 09/09/2014 10:19 AM, Bach, Pascal wrote: > > Wouldn't it make sense to use the same variables in the VS10+ Generator > too? > > It seems redundant to have the same information again. What's the reason > it is hardcoded? > > That's just the way it was written. The rule variables like > CMAKE_${lang}_CREATE_SHARED_LIBRARY contain command lines in > which the Makefile and Ninja generators substitute for some > placeholders. The VS generators do not have a command line > because they just put the declarative information into the > project file and let VS build the command line. I don't understand the purpose of the flag tables [1]. Aren't they there to map from command line to XML files? At first I tought the way things work was: Windows-MSVC.cmake and Co construct a commandline with the required flags. ==> The VS generator parses this command line and uses the cmVS7FlagTable to translate the known flags to XML elements. (Unknown arguments get passed as additional arguments). But it might be that this doesn't work because multi configuration or something else. [1] https://github.com/Kitware/CMake/blob/6ae98ee18f6c35b93556a66dc0ce909d84aec18b/Source/cmVS10LinkFlagTable.h > > If you want to refactor things to create more independent > flag-holding variables that are used to construct > CMAKE_${lang}_CREATE_SHARED_LIBRARY and also read by the > VS generators and sent through the flag map, that's fine > with me. Please also update the VS 7-9 generators to use > the same information variables if possible. If I refactor I would change it to the way described above. Pascal From brad.king at kitware.com Tue Sep 9 11:11:45 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Sep 2014 11:11:45 -0400 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <355BE46A91031048906B695426A8D8E616ACF34D@DEFTHW99EH4MSX.ww902.siemens.net> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> <540EF2C1.8050701@kitware.com> <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> <540F0657.1010606@kitware.com> <355BE46A91031048906B695426A8D8E616ACF2F9@DEFTHW99EH4MSX.ww902.siemens.net> <540F0E61.6080605@kitware.com> <355BE46A91031048906B695426A8D8E616ACF34D@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <540F18B1.5090806@kitware.com> On 09/09/2014 11:02 AM, Bach, Pascal wrote: > I don't understand the purpose of the flag tables [1]. > Aren't they there to map from command line to XML files? Yes, but they were created originally to support flags specified by users in CMAKE_C_FLAGS and a few other places. > At first I tought the way things work was: > Windows-MSVC.cmake and Co construct a commandline with the required flags. > The VS generator parses this command line and uses the cmVS7FlagTable to > translate the known flags to XML elements. > (Unknown arguments get passed as additional arguments). This is done for a subset of the sources of flags, specifically those settable by users and project code. We can't use a complete command line like that in CMAKE_${lang}_CREATE_SHARED_LIBRARY because that will contain a lot of pieces besides the flags. Also multi-configuration is an issue as you point out. You would need to create new variables in Windows-MSVC to hold the flags to be scanned by the VS generators. Then re-use the flags in constructing the other rule variables with command-lines used by the Makefile and Ninja generators. -Brad From rleigh at codelibre.net Tue Sep 9 11:35:07 2014 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 9 Sep 2014 16:35:07 +0100 Subject: [cmake-developers] [PATCH] FindIce: Remove unneeded search path modification Message-ID: <20140909153507.GO7997@codelibre.net> Hi, I have attached a minor fix to the FindIce module added a couple of weeks back. This can override the user's intended search path and was made unnecessary by the changes you requested prior to merging (the paths being added are already added as fallbacks via the list(APPEND ice_roots "/opt/Ice-${ice_version}") line earlier in the script), so the removal simply makes the behaviour consistent. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindIce-Remove-unneeded-search-path-modification.patch Type: text/x-diff Size: 912 bytes Desc: not available URL: From brad.king at kitware.com Tue Sep 9 11:48:53 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Sep 2014 11:48:53 -0400 Subject: [cmake-developers] [PATCH] FindIce: Remove unneeded search path modification In-Reply-To: <20140909153507.GO7997@codelibre.net> References: <20140909153507.GO7997@codelibre.net> Message-ID: <540F2165.6090909@kitware.com> On 09/09/2014 11:35 AM, Roger Leigh wrote: > I have attached a minor fix to the FindIce module added a couple of > weeks back. Applied, thanks: FindIce: Remove unneeded search path modification http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d5047ca1 While reviewing I noticed that there are some message(STATUS) calls not protected by if(Ice_DEBUG) or checks of Ice_FIND_QUIETLY. The latter is needed to honor the QUIET option of find_package. Please revise in a follow-up patch. Thanks, -Brad From pascal.bach at siemens.com Tue Sep 9 11:52:38 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 9 Sep 2014 15:52:38 +0000 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <540F18B1.5090806@kitware.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> <540EF2C1.8050701@kitware.com> <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> <540F0657.1010606@kitware.com> <355BE46A91031048906B695426A8D8E616ACF2F9@DEFTHW99EH4MSX.ww902.siemens.net> <540F0E61.6080605@kitware.com> <355BE46A91031048906B695426A8D8E616ACF34D@DEFTHW99EH4MSX.ww902.siemens.net> <540F18B1.5090806@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACF3A5@DEFTHW99EH4MSX.ww902.siemens.net> > > At first I tought the way things work was: > > Windows-MSVC.cmake and Co construct a commandline with the required > flags. > > The VS generator parses this command line and uses the cmVS7FlagTable > to > > translate the known flags to XML elements. > > (Unknown arguments get passed as additional arguments). > > This is done for a subset of the sources of flags, specifically > those settable by users and project code. We can't use a complete > command line like that in CMAKE_${lang}_CREATE_SHARED_LIBRARY > because that will contain a lot of pieces besides the flags. > Also multi-configuration is an issue as you point out. > > You would need to create new variables in Windows-MSVC to hold > the flags to be scanned by the VS generators. Then re-use the > flags in constructing the other rule variables with command-lines > used by the Makefile and Ninja generators. Looks like a bigger refactoring would be needed. Maybe for the moment it is better to implement it analogous to WindowsPhone and then later refactor the whole thing. Pascal From mantis at public.kitware.com Tue Sep 9 12:58:02 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 9 Sep 2014 12:58:02 -0400 Subject: [cmake-developers] [CMake 0015144]: CMake is unable to locate FreeType within the XQuartz installation Message-ID: <5d0c945159d5052152b35f4fd8afafa9@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15144 ====================================================================== Reported By: Sergey Kosarevsky Assigned To: ====================================================================== Project: CMake Issue ID: 15144 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-09 12:58 EDT Last Modified: 2014-09-09 12:58 EDT ====================================================================== Summary: CMake is unable to locate FreeType within the XQuartz installation Description: XQuartz-2.7.7.dmg is installed. The FreeType library is located in /opt/X11/include/freetype2 The CMake output is on the attached screenshot. Steps to Reproduce: CMakeLists.txt: IF(WITH_FREETYPE) FIND_PACKAGE(Freetype REQUIRED) ADD_DEFINITIONS(-DUSEFREETYPE) INCLUDE_DIRECTORIES(${FREETYPE_INCLUDE_DIRS}) SET(wcm_LIBS ${wcm_LIBS} ${FREETYPE_LIBRARIES}) ENDIF(WITH_FREETYPE) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-09 12:58 Sergey KosarevskyNew Issue 2014-09-09 12:58 Sergey KosarevskyFile Added: 29efc2ec-37b0-11e4-9a95-e78996c79ba3.jpg ====================================================================== From hobbes1069 at gmail.com Tue Sep 9 14:21:54 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Tue, 9 Sep 2014 13:21:54 -0500 Subject: [cmake-developers] include(...) or find_package(...) within another Find module Message-ID: I'm working on trying to modernize the FindFLTK module but also stuck with making sure I don't break the established behavior. The problems with the module are extensive so I'm breaking them up into individual emails where possible. The part I'm questioning in this email is: Should this be include(FindX11) as it shows or find_package(X11)? if(UNIX) include(FindX11) find_library(FLTK_MATH_LIBRARY m) set(FLTK_PLATFORM_DEPENDENT_LIBS ${X11_LIBRARIES} ${FLTK_MATH_LIBRARY}) endif() Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Tue Sep 9 14:56:56 2014 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 9 Sep 2014 19:56:56 +0100 Subject: [cmake-developers] [PATCH] FindIce: Remove unneeded search path modification In-Reply-To: <540F2165.6090909@kitware.com> References: <20140909153507.GO7997@codelibre.net> <540F2165.6090909@kitware.com> Message-ID: <20140909185656.GP7997@codelibre.net> On Tue, Sep 09, 2014 at 11:48:53AM -0400, Brad King wrote: > On 09/09/2014 11:35 AM, Roger Leigh wrote: > > I have attached a minor fix to the FindIce module added a couple of > > weeks back. > > Applied, thanks: > > FindIce: Remove unneeded search path modification > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d5047ca1 > > While reviewing I noticed that there are some message(STATUS) calls > not protected by if(Ice_DEBUG) or checks of Ice_FIND_QUIETLY. The > latter is needed to honor the QUIET option of find_package. Please > revise in a follow-up patch. I have attached a patch to do this. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-FindIce-Respect-Ice_FIND_QUIETLY-when-printing-messa.patch Type: text/x-diff Size: 1870 bytes Desc: not available URL: From brad.king at kitware.com Tue Sep 9 15:22:16 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Sep 2014 15:22:16 -0400 Subject: [cmake-developers] include(...) or find_package(...) within another Find module In-Reply-To: References: Message-ID: <540F5368.3090509@kitware.com> On 09/09/2014 02:21 PM, Richard Shaw wrote: > Should this be include(FindX11) as it shows or find_package(X11)? > > if(UNIX) > include(FindX11) > find_library(FLTK_MATH_LIBRARY m) > set(FLTK_PLATFORM_DEPENDENT_LIBS ${X11_LIBRARIES} ${FLTK_MATH_LIBRARY}) > endif() It should be find_package(X11). Thanks, -Brad From brad.king at kitware.com Tue Sep 9 15:22:22 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Sep 2014 15:22:22 -0400 Subject: [cmake-developers] [PATCH] FindIce: Remove unneeded search path modification In-Reply-To: <20140909185656.GP7997@codelibre.net> References: <20140909153507.GO7997@codelibre.net> <540F2165.6090909@kitware.com> <20140909185656.GP7997@codelibre.net> Message-ID: <540F536E.8040301@kitware.com> On 09/09/2014 02:56 PM, Roger Leigh wrote: > I have attached a patch to do this. Thanks, applied: FindIce: Respect Ice_FIND_QUIETLY when printing messages http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2131aedd -Brad From hobbes1069 at gmail.com Tue Sep 9 16:38:14 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Tue, 9 Sep 2014 15:38:14 -0500 Subject: [cmake-developers] Gold standard find module? Message-ID: Everyone has been really helpful but I don't want to be a pest. Is there a specific find package module that one could point to that would be consider the gold standard of getting it right? One with sufficient complexity (not like the wiki example). Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Tue Sep 9 18:32:16 2014 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 10 Sep 2014 00:32:16 +0200 Subject: [cmake-developers] Modern cross-platform buildsystem design requirements Message-ID: Hi, I saw the addition of the VS_WINRT_COMPONENT property. This seems to be an attribute to mark an executable specially so that it is built with appropriate flags for the WinRT platform. This reminds me of this thread: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9728 Building executables as libraries (2014-03-21) and I wonder again if a generic solution would be possible to design. I wonder what a cmake-based buildsystem would look like for a collection of executables/targets which should be built for multiple of these 'modern, extra attribute-requiring' platforms. Until a few years ago, add_library(foo foo.cpp) add_executable(myexe main.cpp) target_link_libraries(myexe foo) was all that was needed for what we then called 'cross-platform' - it is a sufficient description to generate buildsystems to generate a working library and executable on first-class targets Windows/Linux/Mac and also cross-compiling, given an appropriate toolchain file. Today, I think 'cross-platform' includes a few mobile platforms as first- class targets, and cross-compiling is part of what cross-platform means. So, I wonder what a cross-platform buildsystem necessarily looks like today, and whether it can be done better/abstracted with more first class features. I guess in addition to the above, there would need to be something like a wrapper macro around add_executable to set the appropriate target properties, and possibly use a platform-specific condition for whether to actually create an executable or a PIC shared library (as described in the above thread). Is there any known real-world project aiming to build for those varieties of platforms so we can see what abstraction is needed? According to http://www.cmake.org/Wiki/CMake_Cross_Compiling#FAQ.2FPotential_Problems "If you build software for PS3, you build software for two architectures, for the PowerPC and for the cells." That information seems to come from: http://www.cmake.org/pipermail/cmake/2008-January/018937.html I was reminded of the above by http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/50389 I don't know how common it is to use cmake in those industries/environments, but if multiple toolchains are needed, I'm reminded of the previous proposal for multiple toolchain use. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272 Partly that discussion was aborted because we already had the large topic of designing and implementing usage-requirements to deal with. As that is now complete as designed, it might be worthwhile to re-consider and discuss/design how multiple toolchains could be used at once, whether that would require or benefit from a new language for cmake (another orthogoal known possible future-direction for cmake) etc. [ The manual at Help/manual/cmake-toolchains.7.rst contains several sample toolchain files for Unix. It would be good to have some sample toolchain files using the new WinRT stuff, setting the toolset and CMAKE_GENERATOR_PLATFORM to see how that all fits together now with VisualStudio. ] Thanks, Steve. From daniel at pfeifer-mail.de Wed Sep 10 04:19:19 2014 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Wed, 10 Sep 2014 10:19:19 +0200 Subject: [cmake-developers] Modern cross-platform buildsystem design requirements In-Reply-To: References: Message-ID: Hi Steve, 2014-09-10 0:32 GMT+02:00 Stephen Kelly : > > > I wonder what a cmake-based buildsystem would look like for a collection of > executables/targets which should be built for multiple ... > I would generalize even more and finish the sentence with "options at once". This includes Debug/Release, Shared/Static, PlatformA/PlatformB, etc. With usage-requirements we now can propagate properties from dependees to dependents. What about the other direction? Imagine this: add_library(foo STATIC foo.cpp) add_library(bar SHARED bar.cpp) target_link_libraries(bar foo) add_executable(myexe main.cpp) target_link_libraries(myexe foo) A static library foo is used both in a shared library and in an executable. Depending on the platform it should be build twice: once with PIC, once without. Another example: We sometimes run code generators as custom buildsteps. add_library(foo foo.cpp) add_executable(codegen codegen.cpp) # set_target_properties(codegen PROPERTIES BUILD_FOR_HOST 1) target_link_libraries(codegen foo) add_custom_command(OUTPUT source.cpp COMMAND codegen) add_executable(myexe source.cpp) target_link_libraries(myexe foo) When crosscompiling, we need the codegenerator for the host platform (This would need some target property). But more interestingly, the library foo should be built for both the host and the target(s). Thank you for starting that discussion! -- Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Wed Sep 10 05:52:07 2014 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 10 Sep 2014 11:52:07 +0200 Subject: [cmake-developers] Gold standard find module? References: Message-ID: Richard Shaw wrote: > Everyone has been really helpful but I don't want to be a pest. > > Is there a specific find package module that one could point to that would > be consider the gold standard of getting it right? One with sufficient > complexity (not like the wiki example). Have you looked at http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#a-sample-find-module too? Thanks, Steve. From dlrdave at aol.com Wed Sep 10 06:29:13 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 10 Sep 2014 06:29:13 -0400 Subject: [cmake-developers] Gold standard find module? In-Reply-To: References: Message-ID: <8D19AF9334FB0D6-1768-38A20@webmail-m244.sysops.aol.com> I would say there are no "gold standard" find modules. The gold standard is a project config file, like Qt5 has. From http://www.cmake.org/cmake/help/v3.0/manual/cmake-qt.7.html : "the Qt 5 libraries are found using "Config-file Packages" shipped with Qt 5" Also, search this page for "Config mode": http://www.cmake.org/cmake/help/v3.0/command/find_package.html Find modules in CMake should be the last resort option, when it is simply impossible to add a project config mode file to a project. On the other hand, if the intent behind your question is to make the existing find modules all follow a given standard..... that's quite an ambitious goal. Let's see if anybody else names actual names for the "gold standard." Just my opinion, David C. From mantis at public.kitware.com Wed Sep 10 06:58:40 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 10 Sep 2014 06:58:40 -0400 Subject: [cmake-developers] [CMake 0015146]: MANIFESTUAC-Link flag results in vcxproj errors Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15146 ====================================================================== Reported By: Soeren Textor Assigned To: ====================================================================== Project: CMake Issue ID: 15146 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2014-09-10 06:58 EDT Last Modified: 2014-09-10 06:58 EDT ====================================================================== Summary: MANIFESTUAC-Link flag results in vcxproj errors Description: Adding the UAC flag like set_target_properties( XXX PROPERTIES LINK_FLAGS_DEBUG "MANIFESTUAC:\"level='requireAdministrator' uiAccess='false'\"" ) Therefore we obtain inside the vcxproj: true level='requireAdministrator' uiAccess='false' Instead of: true false RequireAdministrator what results in link errors Steps to Reproduce: Adding the UAC flag like set_target_properties( XXX PROPERTIES LINK_FLAGS_DEBUG "MANIFESTUAC:\"level='requireAdministrator' uiAccess='false'\"" ) and build a VS2013 project file Additional Information: I know there is antoher wa of adding link flags since 3.0, but we also use camke 2.8 and there it's teh same problem ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-10 06:58 Soeren Textor New Issue ====================================================================== From hobbes1069 at gmail.com Wed Sep 10 07:50:57 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Wed, 10 Sep 2014 06:50:57 -0500 Subject: [cmake-developers] Gold standard find module? In-Reply-To: References: Message-ID: On Wed, Sep 10, 2014 at 4:52 AM, Stephen Kelly wrote: > Richard Shaw wrote: > > > Everyone has been really helpful but I don't want to be a pest. > > > > Is there a specific find package module that one could point to that > would > > be consider the gold standard of getting it right? One with sufficient > > complexity (not like the wiki example). > > Have you looked at > > > http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#a-sample-find-module > > too? Thanks, that has a little more detail, but the module I'm trying to clean up is this one: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindFLTK.cmake;hb=HEAD It does a lot of questionable things, I think much of it due to the fact it's been unmaintained for so long and some of the newer commands were probably not available when it was written. One wrinkle is that you can't trust the 'fltk-config' program. If you specify "--libs" it will give you the static library location even if only shared libraries were built, so it only uses that to get the library location, not the library itself. The actual reason I took over the module is that it doesn't add the correct flags (--ldstaticflags) if you ARE actually using static libraries, but after some investigation, it really need a lot of cleanup/modernization work and I'm not sure I'm completely qualified to be the one to do it :) Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From hobbes1069 at gmail.com Wed Sep 10 07:55:55 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Wed, 10 Sep 2014 06:55:55 -0500 Subject: [cmake-developers] Gold standard find module? In-Reply-To: <8D19AF9334FB0D6-1768-38A20@webmail-m244.sysops.aol.com> References: <8D19AF9334FB0D6-1768-38A20@webmail-m244.sysops.aol.com> Message-ID: On Wed, Sep 10, 2014 at 5:29 AM, David Cole via cmake-developers < cmake-developers at cmake.org> wrote: > I would say there are no "gold standard" find modules. > > The gold standard is a project config file, like Qt5 has. > > From http://www.cmake.org/cmake/help/v3.0/manual/cmake-qt.7.html : > > "the Qt 5 libraries are found using "Config-file Packages" shipped with Qt > 5" > > Also, search this page for "Config mode": > > http://www.cmake.org/cmake/help/v3.0/command/find_package.html > > Find modules in CMake should be the last resort option, when it is simply > impossible to add a project config mode file to a project. > Yes, in fact cmake builds of FLTK actually do provide a config file and the find module tries to locate it, but as I mentioned to Stephen, I'm just trying to improve the current module at this point. > On the other hand, if the intent behind your question is to make the > existing find modules all follow a given standard..... that's quite an > ambitious goal. Let's see if anybody else names actual names for the "gold > standard." In this case just the one. I'm not that ambitious as I'm just volunteering my time to various FOSS projects and still have to maintain a day job to pay the bills! Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Wed Sep 10 08:18:54 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 10 Sep 2014 08:18:54 -0400 Subject: [cmake-developers] Gold standard find module? Message-ID: <8D19B0885668016-1768-3927B@webmail-m244.sysops.aol.com> > In this case just the one. I'm not that ambitious as I'm just > volunteering my time to various FOSS projects and still have to > maintain a day job to pay the bills! :-) In that case, I would recommend just getting it into shape so that it works best for you. (But then, that's the way we've ended up with so many ways of doing things in the find modules we do have....) As you submit changes for review, though, hopefully the reviewers will catch anything that is not recommended and ask you to revise it before pushing it into 'master'. I think asking specific questions when you have something you're not sure of is better than trying to identify a gold standard find module on which to model your contributions. HTH, David C. From mantis at public.kitware.com Wed Sep 10 08:55:04 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 10 Sep 2014 08:55:04 -0400 Subject: [cmake-developers] [CMake 0015147]: CMAKE_HOST_SYSTEM_PROCESSOR not detected on GNU/Hurd Message-ID: <2a5df639666b613c41568059de1bd383@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15147 ====================================================================== Reported By: Felix Geyer Assigned To: ====================================================================== Project: CMake Issue ID: 15147 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-10 08:55 EDT Last Modified: 2014-09-10 08:55 EDT ====================================================================== Summary: CMAKE_HOST_SYSTEM_PROCESSOR not detected on GNU/Hurd Description: CMAKE_HOST_SYSTEM_NAME is "unknown" on Debian GNU/Hurd as uname -p prints "unknown". "uname -m" works and returns i686-AT386. I guess it's usually expected to be i[3-6]86 on x86 but changing what the OS reports doesn't seem like the right thing to do. Attached is a patch that switches the uname call to "-m" like it does for Linux. I opted for an exact match for "GNU" because there is also a Debian "GNU/kFreeBSD" architecture. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-10 08:55 Felix Geyer New Issue 2014-09-10 08:55 Felix Geyer File Added: host_system_processor_gnu.diff ====================================================================== From brad.king at kitware.com Wed Sep 10 10:02:58 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 10 Sep 2014 10:02:58 -0400 Subject: [cmake-developers] Modern cross-platform buildsystem design requirements In-Reply-To: References: Message-ID: <54105A12.6070805@kitware.com> On 09/09/2014 06:32 PM, Stephen Kelly wrote: > I saw the addition of the VS_WINRT_COMPONENT property. This seems to be an > attribute to mark an executable specially so that it is built with > appropriate flags for the WinRT platform. Yes. It is similar to the WIN32_EXECUTABLE target property. > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9728 > Building executables as libraries (2014-03-21) FYI, in my Github fork you can see a WIP branch adding support for NVIDIA's Nsight Tegra Visual Studio Edition. It links executables as shared libraries unless they are marked with an ANDROID_GUI target property. The property activates creation of a .apk. > Today, I think 'cross-platform' includes a few mobile platforms as first- > class targets, and cross-compiling is part of what cross-platform means. So, > I wonder what a cross-platform buildsystem necessarily looks like today, and > whether it can be done better/abstracted with more first class features. Good question. I think support for each mobile target will have to be added on an incremental basis. If some common themes emerge over time then perhaps we can identify some abstractions. However, each of these platforms requires some kind of app manifest, and that is a different file/format for each target platform. Projects will at least have to add such manifest files for each platform they want to support. > I'm reminded of the previous proposal for multiple toolchain use. > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272 > > Partly that discussion was aborted because we already had the large topic of > designing and implementing usage-requirements to deal with. As that is now > complete as designed, it might be worthwhile to re-consider and > discuss/design how multiple toolchains could be used at once, whether that > would require or benefit from a new language for cmake (another orthogoal > known possible future-direction for cmake) etc. The main challenge here is that CMake exposes a lot of information about "the one" toolchain per language selected during configuration in the CMake language as variables. Your "toolchain scope" proposal would provide a context for code that will see the toolchain information for each enabled target toolchain. However, perhaps it would be better in the long run to consider something more declarative and with a new language. When cross-compiling it is common to build some tools for the host system to be used during the build itself. There is always exactly one host platform, so perhaps we can design a new mode of support for cross-compiling that configures "the one" toolchain for the *host* system only. Then provide some kind of declarative or delayed-until- generate-time specification, perhaps using a new language, for the cross-compiled pieces. Eventually that spec could be used for the host system too. -Brad From mantis at public.kitware.com Wed Sep 10 11:01:59 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 10 Sep 2014 11:01:59 -0400 Subject: [cmake-developers] [CMake 0015148]: CMAKE_FORCE_C_COMPILER requests full path to cl.exe Message-ID: <494adc7d1ee9b4aa83c57394fd77b502@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15148 ====================================================================== Reported By: a.grudin Assigned To: ====================================================================== Project: CMake Issue ID: 15148 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-10 11:01 EDT Last Modified: 2014-09-10 11:01 EDT ====================================================================== Summary: CMAKE_FORCE_C_COMPILER requests full path to cl.exe Description: The CMake version 2.8 requires just relative path to cl.exe. Like: include(CMakeForceCompiler) CMAKE_FORCE_C_COMPILER("cl.exe" "ARM") And it was convinient. But for new one the options requires to be absolute path. CMAKE_FORCE_C_COMPILER("C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/WPSDK/WP80/bin/cl.exe" "ARM") Steps to Reproduce: Command line: cmake -G "Visual Studio 11 2012 ARM" -T"v110_wp80" ../Project CMakeLists.txt: include(CMakeForceCompiler) CMAKE_FORCE_C_COMPILER("cl.exe" "ARM") CMAKE_FORCE_CXX_COMPILER("cl.exe" "ARM") endif() project(SE) Additional Information: Also check system files when warning about unused and uninitialized variables. CMake Error at CMakeLists.txt:385 (project): The CMAKE_C_COMPILER: cl.exe is not a full path and was not found in the PATH. -- Configuring incomplete, errors occurred! ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-10 11:01 a.grudin New Issue ====================================================================== From brad.king at kitware.com Wed Sep 10 11:33:07 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 10 Sep 2014 11:33:07 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <540DCCBF.6010002@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> Message-ID: <54106F33.3040504@kitware.com> On 09/08/2014 11:35 AM, Nils Gladitz wrote: > I updated the topic, squished and merged. Thanks. I've updated the topic to include all the actual fixes for CMP0054 warnings within CMake's own code that I've found so far. I have a few more changes to request that you add to the topic: * The wording of the warning says what the change in behavior is, but does not inform the user that the old behavior is being used for compatibility. Currently without reading the policy documentation one might think from the messages that the logic is being executed differently than before. * In cmIfCommand we should avoid doing the lookups when the policy is NEW. Instead of calling mf->GetPolicyStatus on every step of the way, call it once at the beginning of the if() command execution and save the result in a member. Then in cmIfCommand::GetDefinitionIfUnquoted, check for quoting and the policy status before even trying to do the lookup. That should make processing of quoted arguments much faster because we won't have to check for a definition with every string value. * The CMP0054-keywords-NEW test does not cover "(" and ")". (Good catch on implementing those, BTW.) * The tests need to cover if() inside while() and foreach() as well as macro() and function(). Also add nested if() for completeness. Thanks, -Brad From hobbes1069 at gmail.com Wed Sep 10 11:38:44 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Wed, 10 Sep 2014 10:38:44 -0500 Subject: [cmake-developers] Gold standard find module? In-Reply-To: <8D19B0885668016-1768-3927B@webmail-m244.sysops.aol.com> References: <8D19B0885668016-1768-3927B@webmail-m244.sysops.aol.com> Message-ID: On Wed, Sep 10, 2014 at 7:18 AM, David Cole wrote: > > In this case just the one. I'm not that ambitious as I'm just > > volunteering my time to various FOSS projects and still have to > > maintain a day job to pay the bills! > > In that case, I would recommend just getting it into shape so that it > works best for you. (But then, that's the way we've ended up with so > many ways of doing things in the find modules we do have....) As you > submit changes for review, though, hopefully the reviewers will catch > anything that is not recommended and ask you to revise it before > pushing it into 'master'. > That's kinda what I was thinking as well but some of the problem I'm trying to fix are requiring some significant changes that looking at a simple diff may not really be helpful... > I think asking specific questions when you have something you're not > sure of is better than trying to identify a gold standard find module > on which to model your contributions. I'm sure I'll still have plenty of questions, I was just hoping to have a really good example to go by to catch the easy stuff. Although, thinking about it now I haven't found a whole lot in my googling so perhaps the discussions here we help other future CMake users/developers. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Wed Sep 10 11:49:54 2014 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 10 Sep 2014 17:49:54 +0200 Subject: [cmake-developers] Modern cross-platform buildsystem design requirements References: <54105A12.6070805@kitware.com> Message-ID: Brad King wrote: > On 09/09/2014 06:32 PM, Stephen Kelly wrote: >> I saw the addition of the VS_WINRT_COMPONENT property. This seems to be >> an attribute to mark an executable specially so that it is built with >> appropriate flags for the WinRT platform. > > Yes. It is similar to the WIN32_EXECUTABLE target property. > >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9728 >> Building executables as libraries (2014-03-21) > > FYI, in my Github fork you can see a WIP branch adding support for > NVIDIA's Nsight Tegra Visual Studio Edition. It links executables > as shared libraries unless they are marked with an ANDROID_GUI target > property. I notice there is also a ANDROID_API target property. Presumably that allows things like foreach(api 16 19) add_library(mylib-android-${api} mylib.cpp) set_property(TARGET mylib-android-${api} PROPERTY ANDROID_API ${api}) endforeach() I wonder if it would instead make sense to provide some INTERFACE targets with INTERFACE_ANDROID_API set and then target_link_libraries(mylib cmake::android-16) for example. This has the disadvantage of requiring the android-${api} targets to be predefined, but maybe a use-story of set(CMAKE_ANDROID_APIS 16 19) include(CMakeAndroidTargets) would avoid a need to hardcode them. The INTERFACE_ANDROID_API, along with compatibility requirements, would prevent mistakes (?) like add_library(lib1 ...) add_library(lib2 ...) set_property(TARGET lib1 PROPERTY ANDROID_API 16) set_property(TARGET lib1 PROPERTY ANDROID_API 19) target_link_libraries(lib1 lib2) # Not the same API version. > The property activates creation of a .apk. The approach I prototyped for BB10 .bar packages was to generate them with cpack. https://gitorious.org/cmake/steveires-cmake/commit/c7715486 This has the effect that the description of build-targets and their dependencies etc is mostly 'normal' and free from BB10-specific stuff, and there is a list of cpack/BAR-related variables in the cpack section of the CMakeLists (where there could also be a list of cpack/android-related variables). Should there be some merging of functionality from cpack into cmake? > >> Today, I think 'cross-platform' includes a few mobile platforms as first- >> class targets, and cross-compiling is part of what cross-platform means. >> So, I wonder what a cross-platform buildsystem necessarily looks like >> today, and whether it can be done better/abstracted with more first class >> features. > > Good question. I think support for each mobile target will have to be > added on an incremental basis. If some common themes emerge over time > then perhaps we can identify some abstractions. It seems that with these changes, a project aiming to be 'cross-platform' would end up writing a macro like macro(set_properties_for_platform tgt) if (CROSS_COMPILING) if (ANDROID) set_property(TARGET ${tgt} ...) elseif (BLACKBERRY) set_property(TARGET ${tgt} ...) elseif (WinRT) set_property(TARGET ${tgt} ...) endif() endif() endmacro() # This now looks 'normal' and 'cross platform' add_executable(hello_world main.cpp) # Call this for each target: set_properties_for_platform(hello_world) That's assuming such a macro has all the information it would need to set the appropriate properties... > However, each of these > platforms requires some kind of app manifest, and that is a different > file/format for each target platform. Projects will at least have to > add such manifest files for each platform they want to support. Do each such files have the same or similar content? Author, url, siging key etc? That might be a good avenue to explore for a cross-platform abstraction. > >> I'm reminded of the previous proposal for multiple toolchain use. >> >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272 >> >> Partly that discussion was aborted because we already had the large topic >> of designing and implementing usage-requirements to deal with. As that is >> now complete as designed, it might be worthwhile to re-consider and >> discuss/design how multiple toolchains could be used at once, whether >> that would require or benefit from a new language for cmake (another >> orthogoal known possible future-direction for cmake) etc. > > The main challenge here is that CMake exposes a lot of information about > "the one" toolchain per language selected during configuration in the > CMake language as variables. Your "toolchain scope" proposal would > provide a context for code that will see the toolchain information > for each enabled target toolchain. However, perhaps it would be better > in the long run to consider something more declarative and with a > new language. Yes, perhaps. A new language creates a lot of sunk-cost for people porting and learning it though of course. There would need to be enough justification for doing it. This could be designed to be part of that justification. I think there may be other justifications for designing a new language too. Are you still thinking of a 'pure'-Lua-based (not via CMakeLists which loads Lua somehow) system as an end-goal? I believe part of the motivation for qbs (the next Qt build tool) is multiple architecture support, which I believe is preferred by some to create Android APKs targeting multiple architectures http://blog.qt.digia.com/blog/2014/03/26/qt-weekly-3-qt-for-android-tips-and-tricks/#comment-1193255 So, that's at least how this stuff in this thread fits together and can be considered together. I don't understand the motivation to put multiple architectures into one package (everyone downloading the package gets N-1 times the amount of stuff they need), but so it is. Anyway the above problem is not solved with the suggestion below. > When cross-compiling it is common to build some tools for the host > system to be used during the build itself. There is always exactly > one host platform, so perhaps we can design a new mode of support for > cross-compiling that configures "the one" toolchain for the *host* > system only. Then provide some kind of declarative or delayed-until- > generate-time specification, perhaps using a new language, for the > cross-compiled pieces. Eventually that spec could be used for the > host system too. Yes, that would be a good intermediate goal. There are many interesting design requirements even for that, such as the example from Daniel of building a library for both host and target, and whether find_package would need multiple modes of operation etc. For example, in a single cmake buildsystem I would need two Qt5Core packages - one host used by a generator and one target. Currently there is only one cache and one possible Qt5Core_DIR etc. When you refer to 'a new language' here, do you mean in the same sense of how generator expressions were a new language (without a departure from the current cmake language as a whole), or do you mean something different? Thanks, Steve. From nilsgladitz at gmail.com Wed Sep 10 15:42:12 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 10 Sep 2014 21:42:12 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <54106F33.3040504@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> Message-ID: <5410A994.1040805@gmail.com> On 09/10/2014 05:33 PM, Brad King wrote: > Thanks. I've updated the topic to include all the actual fixes > for CMP0054 warnings within CMake's own code that I've found so > far. Thanks! > I have a few more changes to request that you add to the topic: > > * The wording of the warning says what the change in behavior > is, but does not inform the user that the old behavior is > being used for compatibility. Currently without reading the > policy documentation one might think from the messages that > the logic is being executed differently than before. Done. > * In cmIfCommand we should avoid doing the lookups when the > policy is NEW. Instead of calling mf->GetPolicyStatus on > every step of the way, call it once at the beginning of the > if() command execution and save the result in a member. > Then in cmIfCommand::GetDefinitionIfUnquoted, check for > quoting and the policy status before even trying to do the > lookup. That should make processing of quoted arguments > much faster because we won't have to check for a definition > with every string value. The functions for condition evaluation were global or static (I assume so they could be shared with while()) and I would have had to pass through the policy state as extra parameters. This was also done with CMP0012 but I figured I might just as well extract everything into its own class "cmConditionEvaluator" and have it keep everything that was being passed around as members instead. > * The CMP0054-keywords-NEW test does not cover "(" and ")". > (Good catch on implementing those, BTW.) > > * The tests need to cover if() inside while() and foreach() > as well as macro() and function(). Also add nested if() > for completeness. I added tests but specifically for the loops I am not entirely sure what to cover given that the context of recording and replaying is basically the same (unlike with functions/macros)? I wouldn't mind some extra scrutiny to make sure they cover what you had in mind. Thanks. Nils From neundorf at kde.org Wed Sep 10 16:30:09 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Wed, 10 Sep 2014 22:30:09 +0200 Subject: [cmake-developers] Gold standard find module? In-Reply-To: References: <8D19B0885668016-1768-3927B@webmail-m244.sysops.aol.com> Message-ID: <8109727.83lFbJIXnr@tuxedo.neundorf.net> On Wednesday, September 10, 2014 10:38:44 Richard Shaw wrote: > On Wed, Sep 10, 2014 at 7:18 AM, David Cole wrote: > > > In this case just the one. I'm not that ambitious as I'm just > > > volunteering my time to various FOSS projects and still have to > > > maintain a day job to pay the bills! > > > > In that case, I would recommend just getting it into shape so that it > > works best for you. (But then, that's the way we've ended up with so > > many ways of doing things in the find modules we do have....) As you > > submit changes for review, though, hopefully the reviewers will catch > > anything that is not recommended and ask you to revise it before > > pushing it into 'master'. > > That's kinda what I was thinking as well but some of the problem I'm trying > to fix are requiring some significant changes that looking at a simple diff > may not really be helpful... > > > I think asking specific questions when you have something you're not > > sure of is better than trying to identify a gold standard find module > > on which to model your contributions. > > I'm sure I'll still have plenty of questions, I was just hoping to have a > really good example to go by to catch the easy stuff. Just a few things: - variables should be named ExactCaseName_SOMETHING - try to detect the version number - use find_package_handle_standard_args() in the new mode - make sure it works also on systems without pkg-config Alex From mantis at public.kitware.com Wed Sep 10 18:50:18 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 11 Sep 2014 00:50:18 +0200 Subject: [cmake-developers] [CMake 0015149]: Document that the CHECK_* macros create cache variables Message-ID: <8e001ca2a2f25c387785e60555bce7e9@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15149 ====================================================================== Reported By: sleske Assigned To: ====================================================================== Project: CMake Issue ID: 15149 Category: Documentation Reproducibility: N/A Severity: text Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-11 00:50 CEST Last Modified: 2014-09-11 00:50 CEST ====================================================================== Summary: Document that the CHECK_* macros create cache variables Description: The various CHECK_* macros (CHECK_C_COMPILER_FLAG, CHECK_FORTRAN_FUNCTION_EXISTS Etc.) set a result variable whose name is specified as a parameter. However, the macros do not document that the result variable is created as a cache variable. While this is probaby obvious to experienced CMake users, it can be confusing for newbies. For example, calling multiple CHECK_* macros with the same result variable will not work as expected, because the variable is only set once. This should be documented. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-11 00:50 sleske New Issue ====================================================================== From pascal.bach at siemens.com Thu Sep 11 05:07:35 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Thu, 11 Sep 2014 11:07:35 +0200 Subject: [cmake-developers] [PATCH] WINCE: Document the WINCE variable Message-ID: <1410426455-18272-1-git-send-email-pascal.bach@siemens.com> --- Help/manual/cmake-variables.7.rst | 1 + Help/variable/WINCE.rst | 5 +++++ 2 files changed, 6 insertions(+) create mode 100644 Help/variable/WINCE.rst diff --git a/Help/manual/cmake-variables.7.rst b/Help/manual/cmake-variables.7.rst index 149e4ac..b00c16e 100644 --- a/Help/manual/cmake-variables.7.rst +++ b/Help/manual/cmake-variables.7.rst @@ -192,6 +192,7 @@ Variables that Describe the System /variable/MSVC_VERSION /variable/UNIX /variable/WIN32 + /variable/WINCE /variable/WINDOWS_PHONE /variable/WINDOWS_STORE /variable/XCODE_VERSION diff --git a/Help/variable/WINCE.rst b/Help/variable/WINCE.rst new file mode 100644 index 0000000..54ff7de --- /dev/null +++ b/Help/variable/WINCE.rst @@ -0,0 +1,5 @@ +WINCE +----- + +True when the :variable:`CMAKE_SYSTEM_NAME` variable is set +to ``WindowsCE``. -- 1.7.10.4 From mantis at public.kitware.com Thu Sep 11 05:29:48 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 11 Sep 2014 05:29:48 -0400 Subject: [cmake-developers] [CMake 0015150]: Eclipse generator produces very bad symbol browsing quality for plain C, due to __cplusplus being set unconditionally Message-ID: <564073d666d3a5d8c8b3973113295f3a@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15150 ====================================================================== Reported By: Martin Oberhuber Assigned To: ====================================================================== Project: CMake Issue ID: 15150 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-11 05:29 EDT Last Modified: 2014-09-11 05:29 EDT ====================================================================== Summary: Eclipse generator produces very bad symbol browsing quality for plain C, due to __cplusplus being set unconditionally Description: When I import my plain C project generated with the "Eclipse CDT4 - Unix Makefiles" generator into Eclipse, I see very bad symbol quality: Indexed 'myproject at linux64' (365 sources, 800 headers) in 24.2 sec: 81,605 declarations; 665,941 references; 54 unresolved inclusions; 3,708 syntax errors; 107,398 unresolved names (13%) Note the 13% unresolved names, which means that the calltree (referenced-by) will fail 13% of the time ! This is way too unreliable. Investigation showed that the main problem is cmake generating "__cplusplus=1" unconditionally into the Project Properties > C/C++ Include Paths. When deleting the incorrect __cplusplus setting I get almost perfect symbol quality: Indexed 'myproject at linux64' (365 sources, 800 headers) in 23.2 sec: 98,095 declarations; 785,956 references; 54 unresolved inclusions; 2,230 syntax errors; 4,732 unresolved names (0.53%) --> Note only 0.53% unresolved names now (in this case due to some Windows headers). Also note that a __cplusplus macro will be added automatically by Eclipse CDT when looking at any *.cpp / *.cxx / *.cc files. So that macro really should not be set hard-coded by the project generator ! Steps to Reproduce: cmake -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_ECLIPSE_VERSION=4.4 ../myproject make # Now import the generated project into Eclipse for C/C++ 4.4 Additional Information: Workaround: After importing the generated project, right-click > C/C++ Include Paths and manually delete the __cplusplus macro setting. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-11 05:29 Martin OberhuberNew Issue ====================================================================== From brad.king at kitware.com Thu Sep 11 08:48:39 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 08:48:39 -0400 Subject: [cmake-developers] [PATCH] WINCE: Document the WINCE variable In-Reply-To: <1410426455-18272-1-git-send-email-pascal.bach@siemens.com> References: <1410426455-18272-1-git-send-email-pascal.bach@siemens.com> Message-ID: <54119A27.2080905@kitware.com> On 09/11/2014 05:07 AM, Pascal Bach wrote: > Help/manual/cmake-variables.7.rst | 1 + > Help/variable/WINCE.rst | 5 +++++ Applied, thanks: Help: Document the WINCE variable http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4b4555de -Brad From brad.king at kitware.com Thu Sep 11 09:04:18 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 09:04:18 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5410A994.1040805@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> Message-ID: <54119DD2.4080606@kitware.com> On 09/10/2014 03:42 PM, Nils Gladitz wrote: > extract everything into its own class "cmConditionEvaluator" and have it > keep everything that was being passed around as members instead. Good work. I think the net change is now in good shape. To make it easier to review now and bisect in the future, please rewrite the topic to start with refactoring cmIfCommand to split out the cmConditionEvaluator, and then add the rest of the changes. Thanks, -Brad From nilsgladitz at gmail.com Thu Sep 11 09:20:10 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 11 Sep 2014 15:20:10 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <54119DD2.4080606@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> Message-ID: <5411A18A.7060106@gmail.com> On 11.09.2014 15:04, Brad King wrote: > Good work. I think the net change is now in good shape. To make it > easier to review now and bisect in the future, please rewrite the > topic to start with refactoring cmIfCommand to split out the > cmConditionEvaluator, and then add the rest of the changes. Thanks. Is there a trick to recreate the history in that order or would I have to start from scratch? Nils From brad.king at kitware.com Thu Sep 11 09:28:28 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 09:28:28 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411A18A.7060106@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> Message-ID: <5411A37C.1070101@kitware.com> On 09/11/2014 09:20 AM, Nils Gladitz wrote: > Is there a trick to recreate the history in that order or > would I have to start from scratch? First rewrite the branch to squash your updates back into the first commit, leaving all my CMP0054 warning commits later in the topic. Then start a new branch from the squashed commit containing only your part of the changes. Note the sha1 of this commit, say a01b2c3. Then edit it to *remove* the changes besides the refactoring and amend the commit. The result should be just one commit with the refactoring parts. Then you can use the "git commit-tree" plumbing to create a commit with the tree object of your original change but set its parent as the edited commit. This will manufacture a commit that makes the changes on top of the refactoring: commit=$(git commit-tree a01b2c3^{tree} -p HEAD) git merge $commit git commit --amend -C a01b2c3 Finally, rebase the rest of the topic back onto that. The tip of the resulting topic should look identical to what is on the stage now. Thanks, -Brad From nilsgladitz at gmail.com Thu Sep 11 11:35:42 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 11 Sep 2014 17:35:42 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411A37C.1070101@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> Message-ID: <5411C14E.7000207@gmail.com> On 11.09.2014 15:28, Brad King wrote: > First rewrite the branch to squash your updates back into > the first commit, leaving all my CMP0054 warning commits > later in the topic. Then start a new branch from the > squashed commit containing only your part of the changes. > Note the sha1 of this commit, say a01b2c3. Then edit it > to *remove* the changes besides the refactoring Thanks for the walk through. I am a bit stuck on removing the CMP0054 changes from cmConditionEvaluator.cxx part given that file is new and didn't exist without the changes. I'll redo the refactoring part manually from scratch if I can't figure out something better. Might take me a bit; I haven't had much experience with those git aspects yet. Nils From brad.king at kitware.com Thu Sep 11 11:39:17 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 11:39:17 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411C14E.7000207@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> Message-ID: <5411C225.7020706@kitware.com> On 09/11/2014 11:35 AM, Nils Gladitz wrote: > Thanks for the walk through. > > I am a bit stuck on removing the CMP0054 changes from > cmConditionEvaluator.cxx part given that file is new and didn't exist > without the changes. The file should exist, just remove the CMP0054 parts from it and amend the commit. > I'll redo the refactoring part manually from scratch if I can't figure > out something better. > > Might take me a bit; I haven't had much experience with those git > aspects yet. If it takes too much time, don't bother doing this part unless you are really interested in using it as a learning opportunity. Let me know either way, please. Thanks, -Brad From brad.king at kitware.com Thu Sep 11 11:47:37 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 11:47:37 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <540A14A2.30904@kitware.com> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> <5409C1CE.1010501@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC74@DEFTHW99EH4MSX.ww902.siemens.net> <540A14A2.30904@kitware.com> Message-ID: <5411C419.6060201@kitware.com> On 09/05/2014 03:53 PM, Brad King wrote: > I think "CMAKE_GENERATOR_PLATFORM" may be a suitable name. Ideally > this setting should be added as a general-purpose replacement for > putting "ARM" or "Win64" in the generator name. The changes for > that are more sweeping than I'd like to ask of you just for WinCE > support, so I drafted them myself. This is now in 'master'. On 09/04/2014 06:42 AM, Bach, Pascal wrote: >> At the beginning of this block you should check/reject when >> the generator name specified a platform name. Something like: >> >> if(this->PlatformName != "Win32") >> { >> cmOStringStream e; >> e << "CMAKE_SYSTEM_NAME is 'WindowsCE' but CMAKE_GENERATOR " >> << "specifies a platform too: '" << this->GetName() << "'"; >> mf->IssueMessage(cmake::FATAL_ERROR, e.str()); >> return false; >> } > > This won't' work as the code gets called multiple times Along with the above changes I also made SetSystemName not get called more than once. The "PlatformName" member is now "DefaultPlatformName". Initially it corresponds to the default based on the generator name, so you should be able to check it as shown above. SetSystemName can modify DefaultPlatformName for specific systems to have a different default in case CMAKE_GENERATOR_PLATFORM is not set. The value of that setting is then processed by SetGeneratorPlatform. -Brad From nilsgladitz at gmail.com Thu Sep 11 11:52:10 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 11 Sep 2014 17:52:10 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411C225.7020706@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> Message-ID: <5411C52A.7020801@gmail.com> On 11.09.2014 17:39, Brad King wrote: > On 09/11/2014 11:35 AM, Nils Gladitz wrote: >> Thanks for the walk through. >> >> I am a bit stuck on removing the CMP0054 changes from >> cmConditionEvaluator.cxx part given that file is new and didn't exist >> without the changes. > The file should exist, just remove the CMP0054 parts from it > and amend the commit. I might be missing something obvious. cmConditionEvaluator.cxx doesn't exist without the CMP0054 changes because I created it after I did most of the CMP0054 changes. Since most of the changes are replacements rather than plain additions *removing* those changes would mean having to restore those code parts which however used to be in cmIf.cxx rather than cmConditionEvaluator.cxx. Nils From robert.maynard at kitware.com Thu Sep 11 12:26:14 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 11 Sep 2014 12:26:14 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.0.2 Released Message-ID: We are pleased to announce that CMake 3.0.2 is now available for download. Please use the latest release from our download page: http://www.cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.0.2 since 3.0.1: Alan W. Irwin (1): ExternalProject: Avoid infinite loop on file download hash mismatch Brad King (6): CMP0047: Fix CMAKE_COMPILER_IS_GNU(CC|CXX) in OLD behavior CMP0022: Fix version documented to support LINK_PUBLIC/LINK_PRIVATE cmListFileLexer: Fix lexing of single '[' character (#15092) Xcode: Generate per-target file references (#15111) Fix finding binutils when cross-compiling with Clang CMake 3.0.2 Christian Svensson (2): KWIML: Teach ABI.h about OpenRISC 1000 KWSys CPU: Add support for OpenRISC 1000 Stephen Kelly (2): QtAutogen: Use the basename for resource files. QtAutogen: Fix use of multiple ui files in a single target. Tim Blechmann (1): BundleUtilities: Allow Info.plist files which use CR line endings From brad.king at kitware.com Thu Sep 11 12:53:13 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 12:53:13 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411C52A.7020801@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> Message-ID: <5411D379.1060807@kitware.com> On 09/11/2014 11:52 AM, Nils Gladitz wrote: > cmConditionEvaluator.cxx doesn't exist without the CMP0054 changes > because I created it after I did most of the CMP0054 changes. > Since most of the changes are replacements rather than plain additions > *removing* those changes would mean having to restore those code parts > which however used to be in cmIf.cxx rather than cmConditionEvaluator.cxx. I think you missed the part about squashing your changes together into the first commit of the topic. I just rewrote the topic to do that. Now you can start working from commit 5922fc2c: git checkout -b tmp 5922fc2c git rm Help/policy/CMP0054.rst Help/release/dev/if-sanity.rst git checkout HEAD~1 -- Help git rm -rf Tests/RunCMake/CMP0054 git checkout HEAD~1 -- Tests/RunCMake/CMakeLists.txt git commit --amend Then keep editing the files and amending the commit to leave behind only the refactoring pieces. Amend the commit message accordingly too. Then do: commit=$(git commit-tree 5922fc2c^{tree} -p HEAD) git merge $commit git commit --amend -C 5922fc2c to restore the rest of the commit's changes. Then rebase the rest of the topic to get the warning cleanups. -Brad From nilsgladitz at gmail.com Thu Sep 11 12:57:03 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 11 Sep 2014 18:57:03 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411D379.1060807@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> <5411D379.1060807@kitware.com> Message-ID: <5411D45F.5040504@gmail.com> On 11.09.2014 18:53, Brad King wrote: > On 09/11/2014 11:52 AM, Nils Gladitz wrote: >> cmConditionEvaluator.cxx doesn't exist without the CMP0054 changes >> because I created it after I did most of the CMP0054 changes. >> Since most of the changes are replacements rather than plain additions >> *removing* those changes would mean having to restore those code parts >> which however used to be in cmIf.cxx rather than cmConditionEvaluator.cxx. > I think you missed the part about squashing your changes together > into the first commit of the topic. I just rewrote the topic > to do that. Now you can start working from commit 5922fc2c: No I did that as well. > git checkout -b tmp 5922fc2c > git rm Help/policy/CMP0054.rst Help/release/dev/if-sanity.rst > git checkout HEAD~1 -- Help > git rm -rf Tests/RunCMake/CMP0054 > git checkout HEAD~1 -- Tests/RunCMake/CMakeLists.txt > git commit --amend I think I did all that too. > Then keep editing the files and amending the commit to leave > behind only the refactoring pieces. That is the part I was stuck at. Nils From brad.king at kitware.com Thu Sep 11 12:59:05 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 12:59:05 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411D45F.5040504@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> <5411D379.1060807@kitware.com> <5411D45F.5040504@gmail.com> Message-ID: <5411D4D9.50004@kitware.com> On 09/11/2014 12:57 PM, Nils Gladitz wrote: >> Then keep editing the files and amending the commit to leave >> behind only the refactoring pieces. > > That is the part I was stuck at. At this point cmConditionEvaluator.cxx exists in the source tree. What is the problem? -Brad From nilsgladitz at gmail.com Thu Sep 11 13:07:13 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 11 Sep 2014 19:07:13 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411D4D9.50004@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> <5411D379.1060807@kitware.com> <5411D45F.5040504@gmail.com> <5411D4D9.50004@kitware.com> Message-ID: <5411D6C1.2080200@gmail.com> On 11.09.2014 18:59, Brad King wrote: > At this point cmConditionEvaluator.cxx exists in the source tree. > What is the problem? I can not create a CMP0054 free version of cmConditionEvaluator.cxx by simply removing content from the file (or the patch). I would have to add back lines to cmConditionEvaluator.cxx which where removed while they were still in cmIfCommand.cxx. The problem is that I am not sure how to do that properly. Nils From brad.king at kitware.com Thu Sep 11 13:14:53 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 13:14:53 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411D6C1.2080200@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> <5411D379.1060807@kitware.com> <5411D45F.5040504@gmail.com> <5411D4D9.50004@kitware.com> <5411D6C1.2080200@gmail.com> Message-ID: <5411D88D.2080404@kitware.com> On 09/11/2014 01:07 PM, Nils Gladitz wrote: > I would have to add back lines to cmConditionEvaluator.cxx which where > removed while they were still in cmIfCommand.cxx. Look at the diff in commit 5922fc2c and you will see all those lines as removed from cmIfCommand. You can put them all in cmConditionEvaluator. Some of the work is manual. Effectively you are re-doing the refactoring from scratch without the CMP0054 pieces. The use of Git up to this point is just to help get close. The reason I'm asking for this is that the refactoring done to create cmConditionEvaluator is more intrusive than the original CMP0054 change. It will be much easier to convince myself that the whole thing is correct if I can see the refactoring done first and independently. Thanks, -Brad From nilsgladitz at gmail.com Thu Sep 11 13:24:11 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 11 Sep 2014 19:24:11 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411D88D.2080404@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> <5411D379.1060807@kitware.com> <5411D45F.5040504@gmail.com> <5411D4D9.50004@kitware.com> <5411D6C1.2080200@gmail.com> <5411D88D.2080404@kitware.com> Message-ID: <5411DABB.7050303@gmail.com> On 11.09.2014 19:14, Brad King wrote: > On 09/11/2014 01:07 PM, Nils Gladitz wrote: >> I would have to add back lines to cmConditionEvaluator.cxx which where >> removed while they were still in cmIfCommand.cxx. > Look at the diff in commit 5922fc2c and you will see all those lines as > removed from cmIfCommand. You can put them all in cmConditionEvaluator. > Some of the work is manual. Effectively you are re-doing the refactoring > from scratch without the CMP0054 pieces. The use of Git up to this point > is just to help get close. > > The reason I'm asking for this is that the refactoring done to create > cmConditionEvaluator is more intrusive than the original CMP0054 change. > It will be much easier to convince myself that the whole thing is correct > if I can see the refactoring done first and independently. Certainly, I don't argue against the change itself. It sounded like there might have been some sort of git magic that would have made it less manual. Thanks. Nils From nilsgladitz at gmail.com Thu Sep 11 15:40:17 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 11 Sep 2014 21:40:17 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411D88D.2080404@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> <5411D379.1060807@kitware.com> <5411D45F.5040504@gmail.com> <5411D4D9.50004@kitware.com> <5411D6C1.2080200@gmail.com> <5411D88D.2080404@kitware.com> Message-ID: <5411FAA1.4050805@gmail.com> I think I've got it rewritten properly but I didn't know what half the git commands I ran did most of the time so I am not entirely secure with the result. Would have probably not figured this out without your help. Thanks again! Nils From pascal.bach at siemens.com Fri Sep 12 03:42:35 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Fri, 12 Sep 2014 07:42:35 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <5411C419.6060201@kitware.com> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> <5409C1CE.1010501@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC74@DEFTHW99EH4MSX.ww902.siemens.net> <540A14A2.30904@kitware.com> <5411C419.6060201@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616AD0228@DEFTHW99EH4MSX.ww902.siemens.net> > On 09/05/2014 03:53 PM, Brad King wrote: > > I think "CMAKE_GENERATOR_PLATFORM" may be a suitable name. Ideally > > this setting should be added as a general-purpose replacement for > > putting "ARM" or "Win64" in the generator name. The changes for > > that are more sweeping than I'd like to ask of you just for WinCE > > support, so I drafted them myself. > > This is now in 'master'. > I tried master and the Platform selections works great. Thanks. Now in order to have it fully working on WindowsCE the following issues remain: 1. The subsystem for EXE and DLL currently it is set to Console or Windows depending on the WIN32_EXECUTABLE property of the target. For WinCE the subsystem needs to be always set to WindowsCE and the entry point needs to change based on the WIN32_EXECUTABLE property. 2. The Toolset variable needs to be set manually using CMAKE_GENERATOR_TOOLSET and it needs to match the selected Windows CE version. I'm updating my earlier patch to address this issue and I hope I can send it in today. Pascal From brad.king at kitware.com Fri Sep 12 08:23:22 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 12 Sep 2014 08:23:22 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <355BE46A91031048906B695426A8D8E616AD0228@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> <5409C1CE.1010501@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC74@DEFTHW99EH4MSX.ww902.siemens.net> <540A14A2.30904@kitware.com> <5411C419.6060201@kitware.com> <355BE46A91031048906B695426A8D8E616AD0228@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <5412E5BA.1070708@kitware.com> On 09/12/2014 03:42 AM, Bach, Pascal wrote: > Now in order to have it fully working on WindowsCE the following issues remain: > 1. The subsystem for EXE and DLL currently it is set to Console or Windows depending on the WIN32_EXECUTABLE property of the target. For WinCE the subsystem needs to be always set to WindowsCE and the entry point needs to change based on the WIN32_EXECUTABLE property. FYI, I would be happy with hard-coding knowledge of this in the C++ generator implementation for now. Refactoring things to use the flag parser as we discussed before can be done later. Of course if you already have that well underway then it would be fine too ;) Thanks, -Brad From brad.king at kitware.com Fri Sep 12 08:24:03 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 12 Sep 2014 08:24:03 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411FAA1.4050805@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> <5411D379.1060807@kitware.com> <5411D45F.5040504@gmail.com> <5411D4D9.50004@kitware.com> <5411D6C1.2080200@gmail.com> <5411D88D.2080404@kitware.com> <5411FAA1.4050805@gmail.com> Message-ID: <5412E5E3.2060005@kitware.com> On 09/11/2014 03:40 PM, Nils Gladitz wrote: > I think I've got it rewritten properly Yes, it looks good! Thanks, -Brad From pascal.bach at siemens.com Fri Sep 12 08:47:06 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Fri, 12 Sep 2014 14:47:06 +0200 Subject: [cmake-developers] [PATCH] WINCE, VS: Make the Visual Studio 10+ generator Windows CE In-Reply-To: <5412E5BA.1070708@kitware.com> References: <5412E5BA.1070708@kitware.com> Message-ID: <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> - If Windows CE is targeted set the Subsystem and EntryPointSymbol accordingly - For Windows CE 2013 (8.0) set the toolset to C800 by default --- Source/cmGlobalVisualStudio10Generator.cxx | 40 ++++++++++++++++++++++++++++ Source/cmGlobalVisualStudio10Generator.h | 7 +++++ Source/cmVisualStudio10TargetGenerator.cxx | 20 ++++++++++++-- 3 files changed, 65 insertions(+), 2 deletions(-) diff --git a/Source/cmGlobalVisualStudio10Generator.cxx b/Source/cmGlobalVisualStudio10Generator.cxx index e2d4645..e87a69f 100644 --- a/Source/cmGlobalVisualStudio10Generator.cxx +++ b/Source/cmGlobalVisualStudio10Generator.cxx @@ -179,6 +179,14 @@ bool cmGlobalVisualStudio10Generator::InitializeSystem(cmMakefile* mf) return false; } } + else if (this->SystemName == "WindowsCE") + { + this->SystemIsWindowsCE = true; + if (!this->InitializeWindowsCE(mf)) + { + return false; + } + } return true; } @@ -201,6 +209,38 @@ bool cmGlobalVisualStudio10Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio10Generator::InitializeWindowsCE(cmMakefile* mf) + { + // To preserve the old behaviour just keep the DefaultPlatformToolset + // for unknown Windows CE versions, in the worst case the user has to set + // CMAKE_GENERATOR_TOOLSET manually. In that case warn the user. + std::string platformToolset = this->SelectWindowsCEToolset(); + if (!platformToolset.empty()) + { + this->DefaultPlatformToolset = platformToolset; + } + else + { + cmOStringStream e; + e << this->GetName() << " Windows CE version '" << this->SystemVersion + << "' might require CMAKE_GENERATOR_TOOLSET to be set."; + mf->IssueMessage(cmake::WARNING, e.str()); + } + + return true; + } + +//---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio10Generator::SelectWindowsCEToolset() const + { + if (this->SystemVersion == "8.0") + { + return "CE800"; + } + return ""; + } + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio10Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 11.00\n"; diff --git a/Source/cmGlobalVisualStudio10Generator.h b/Source/cmGlobalVisualStudio10Generator.h index f1ff9a4..a80222f 100644 --- a/Source/cmGlobalVisualStudio10Generator.h +++ b/Source/cmGlobalVisualStudio10Generator.h @@ -76,6 +76,10 @@ public: bool TargetsWindowsStore() const { return this->SystemIsWindowsStore; } + /** Return true if building for WindowsCE */ + bool TargetsWindowsCE() const + { return this->SystemIsWindowsCE; } + /** * Where does this version of Visual Studio look for macros for the * current user? Returns the empty string if this version of Visual @@ -107,8 +111,10 @@ protected: virtual bool InitializeSystem(cmMakefile* mf); virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const { return ""; } virtual std::string SelectWindowsStoreToolset() const { return ""; } + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "10.0"; } @@ -120,6 +126,7 @@ protected: std::string SystemVersion; bool SystemIsWindowsPhone; bool SystemIsWindowsStore; + bool SystemIsWindowsCE; bool ExpressEdition; bool UseFolderProperty(); diff --git a/Source/cmVisualStudio10TargetGenerator.cxx b/Source/cmVisualStudio10TargetGenerator.cxx index c525b7c..681b8c7 100644 --- a/Source/cmVisualStudio10TargetGenerator.cxx +++ b/Source/cmVisualStudio10TargetGenerator.cxx @@ -2115,11 +2115,27 @@ cmVisualStudio10TargetGenerator::ComputeLinkOptions(std::string const& config) if ( this->Target->GetPropertyAsBool("WIN32_EXECUTABLE") ) { - linkOptions.AddFlag("SubSystem", "Windows"); + if (this->GlobalGenerator->TargetsWindowsCE()) + { + linkOptions.AddFlag("SubSystem", "WindowsCE"); + linkOptions.AddFlag("EntryPointSymbol", "WinMainCRTStartup"); + } + else + { + linkOptions.AddFlag("SubSystem", "Windows"); + } } else { - linkOptions.AddFlag("SubSystem", "Console"); + if (this->GlobalGenerator->TargetsWindowsCE()) + { + linkOptions.AddFlag("SubSystem", "WindowsCE"); + linkOptions.AddFlag("EntryPointSymbol", "mainACRTStartup"); + } + else + { + linkOptions.AddFlag("SubSystem", "Console"); + }; } if(const char* stackVal = -- 1.7.10.4 From brad.king at kitware.com Fri Sep 12 09:04:22 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 12 Sep 2014 09:04:22 -0400 Subject: [cmake-developers] Modern cross-platform buildsystem design requirements In-Reply-To: References: <54105A12.6070805@kitware.com> Message-ID: <5412EF56.2040804@kitware.com> On 09/10/2014 11:49 AM, Stephen Kelly wrote: > target_link_libraries(mylib cmake::android-16) Interesting idea. These could be predefined in the Platform/Android.cmake module. However, I do not think the current ANDROID_API property will be outdated by such a design, so I think we can keep it as-is for now and consider an INTERFACE feature when things have matured somewhat. >> The property activates creation of a .apk. > > The approach I prototyped for BB10 .bar packages was to generate them with > cpack. In the current work, the goal is to let Nsight Tegra handle everything from the generated .vcxproj file. > macro(set_properties_for_platform tgt) > if (CROSS_COMPILING) > if (ANDROID) > set_property(TARGET ${tgt} ...) > elseif (BLACKBERRY) > set_property(TARGET ${tgt} ...) > elseif (WinRT) > set_property(TARGET ${tgt} ...) > endif() > endif() > endmacro() I don't see any reason the properties could not just always be set by the project. The ones not relevant to the current cross-compiling target would simply be ignored. >> However, each of these platforms requires some kind of app manifest > > Do each such files have the same or similar content? Author, url, siging key > etc? That might be a good avenue to explore for a cross-platform > abstraction. Perhaps, but not for a while. Authors targeting mobile devices will need very specific control over the manifest files, packaging, and signing. Only when we see lots of duplication across manifests for different targets should we consider such abstraction. > Are you still thinking of a 'pure'-Lua-based (not via > CMakeLists which loads Lua somehow) system as an end-goal? No, but I wouldn't rule it out forever. > I believe part of the motivation for qbs (the next Qt build tool) is > multiple architecture support, which I believe is preferred by some to > create Android APKs targeting multiple architectures [snip] > whether find_package would need multiple modes of operation etc. The fundamental problem with supporting multiple architectures is that pretty much all of CMake is designed to support one architecture at a time. Modules/*, CMakeCache.txt, etc. are all built around only finding, using, and building one artifact per library (OS X universal binaries work with multiple architectures because they are still only one file). I think even your "toolchain scope" approach would end up being used in practice to wrap the entire CMakeLists.txt file. The only approach I can think of that solves this without being a complete rewrite is to support multiple separate configuration passes, with separate CMakeCache.txt and everything as now, but that all feed in to a single generation step. (Note the separate config passes could be independent and perhaps run in threads.) > When you refer to 'a new language' here, do you mean in the same sense of > how generator expressions were a new language (without a departure from the > current cmake language as a whole), or do you mean something different? I don't mean anything in particular except that we should not constrain ourselves to solving the problem with the current CMake language only. -Brad From brad.king at kitware.com Fri Sep 12 09:36:59 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 12 Sep 2014 09:36:59 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Make the Visual Studio 10+ generator Windows CE In-Reply-To: <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> References: <5412E5BA.1070708@kitware.com> <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> Message-ID: <5412F6FB.3030005@kitware.com> On 09/12/2014 08:47 AM, Pascal Bach wrote: > - If Windows CE is targeted set the Subsystem and EntryPointSymbol accordingly > - For Windows CE 2013 (8.0) set the toolset to C800 by default Great, thanks. > +bool cmGlobalVisualStudio10Generator::InitializeWindowsCE(cmMakefile* mf) > + { Here please add this check: if(this->DefaultPlatformName != "Win32") { cmOStringStream e; e << "CMAKE_SYSTEM_NAME is 'WindowsCE' but CMAKE_GENERATOR " << "specifies a platform too: '" << this->GetName() << "'"; mf->IssueMessage(cmake::FATAL_ERROR, e.str()); return false; } This code should no longer be called multiple times so it is safe to check here now. > + // To preserve the old behaviour just keep the DefaultPlatformToolset > + // for unknown Windows CE versions, in the worst case the user has to set > + // CMAKE_GENERATOR_TOOLSET manually. In that case warn the user. > + std::string platformToolset = this->SelectWindowsCEToolset(); > + if (!platformToolset.empty()) > + { > + this->DefaultPlatformToolset = platformToolset; > + } > + else > + { > + cmOStringStream e; > + e << this->GetName() << " Windows CE version '" << this->SystemVersion > + << "' might require CMAKE_GENERATOR_TOOLSET to be set."; > + mf->IssueMessage(cmake::WARNING, e.str()); > + } I think this will always warn when CMAKE_SYSTEM_VERSION != 8.0 even if the user has set a CMAKE_GENERATOR_TOOLSET. Instead, cmGlobalVisualStudio10Generator::SetGeneratorToolset should implement the warning: * Have InitializeWindowsCE always do this->DefaultPlatformToolset = this->SelectWindowsCEToolset() even when it is empty. * Teach SetGeneratorToolset to check for SystemIsWindowsCE *and* ts.empty() *and* DefaultPlatformToolset.empty(). If this is all true, then generate an error asking the user to specify the toolset, or perhaps just a warning if the toolset is not always required. Thanks, -Brad From andy.bauer at kitware.com Fri Sep 12 11:27:23 2014 From: andy.bauer at kitware.com (Andy Bauer) Date: Fri, 12 Sep 2014 11:27:23 -0400 Subject: [cmake-developers] documentation patch Message-ID: Hi, Attached is a patch for a documentation correction for setting test properties. Can someone check on this and merge it into CMake if it's acceptable? Thanks, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Help-Fixing-set_test_properties-documentation.patch Type: text/x-patch Size: 844 bytes Desc: not available URL: From brad.king at kitware.com Fri Sep 12 11:34:29 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 12 Sep 2014 11:34:29 -0400 Subject: [cmake-developers] documentation patch In-Reply-To: References: Message-ID: <54131285.6080302@kitware.com> On 09/12/2014 11:27 AM, Andy Bauer wrote: > Attached is a patch for a documentation correction Applied, thanks: Help: Fix set_tests_properties documentation typo http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d8054987 -Brad From mantis at public.kitware.com Fri Sep 12 12:23:46 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 12 Sep 2014 12:23:46 -0400 Subject: [cmake-developers] [CMake 0015154]: Ninja complains about missing rule Message-ID: <30b65c403293279aa0ef858a9aa11749@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15154 ====================================================================== Reported By: Clinton Stimpson Assigned To: ====================================================================== Project: CMake Issue ID: 15154 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-12 12:23 EDT Last Modified: 2014-09-12 12:23 EDT ====================================================================== Summary: Ninja complains about missing rule Description: With the attached example project, Ninja will complain with an error saying "ninja: error: 'lib/libmylib.a', needed by 'myapp', missing and no known rule to make it" I'm using ExternalProject_Add() and then using imported library targets. I then set the imported target to depend on the ExternalProject to make sure it is up to date. This works fine with Visual Studio, NMake, Make, Xcode, etc.... Steps to Reproduce: See attached project. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-12 12:23 Clinton StimpsonNew Issue 2014-09-12 12:23 Clinton StimpsonFile Added: test-ninja-external-build.tar.gz ====================================================================== From mantis at public.kitware.com Sun Sep 14 00:37:03 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 14 Sep 2014 00:37:03 -0400 Subject: [cmake-developers] [CMake 0015155]: cmlistfilecache: error can not open file Message-ID: <2fa8e986ed5bd1b85b4fa4eef90b1ee2@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15155 ====================================================================== Reported By: David Zemon Assigned To: ====================================================================== Project: CMake Issue ID: 15155 Category: CMake Reproducibility: always Severity: block Priority: high Status: new ====================================================================== Date Submitted: 2014-09-14 00:37 EDT Last Modified: 2014-09-14 00:37 EDT ====================================================================== Summary: cmlistfilecache: error can not open file Description: Upon generating the Makefiles for my project, CMake prings the following two lines for each new language that I enable: CMake Error: cmListFileCache: error can not open file C:/Users/David/Documents/GitHub/PropWare CMake Error: Could not find cmake module file: No other errors are reported. No extra text comes afterward (not even a single space after the semicolon). The path in the first line is the root of my project - not a file. Two lines are printed at the very bottom saying that I can look at the CMakeOutput.log and CMakeError.log files, but they do not seem to provide any useful information. Steps to Reproduce: The PropWare project should exist on in a user-writable path. A version of GCC ported for the Parallax Propeller is required to build my project. The environment variable "PROPWARE_PATH" must be set to the project root directory. All files from /CMakeModules should be copied into the CMake installation directory. All of the above requirements can be most easily satisfied by downloading the release-2.0-nightly branch of PropWare from github (https://github.com/DavidZemon/PropWare/tree/release-2.0-nightly) and running INSTALL.py from within the `util` directory. This will download PropGCC and CMake 3.0.2 (if a version of CMake >= 3.0 is not in the PATH) and copy over the necessary files into your CMake installation directory as well as setting a couple environment variables. If you choose to run INSTALL.py, it will attempt to build the PropWare libraries and will fail with the above errors. If you choose to configure everything manually, the error will appear as soon as you try to configure the makefiles for the project. I use 'cmake -G "Unix Makefiles" ..' from within a child directory of the root (GNU Make is distributed with the Windows release of PropGCC). I found the same error occurs when I use the default Makefile generator of Visual Studio. Attempting to use MinGW Makefiles throws lots of different errors (can't find the compiler). Additional Information: PropWare is ready to be released to the public as an easy-to-use build-system for the Parallax Propeller, but without windows compatibility, the whole project is nearly useless. Probably 95% of my potential users are on Windows, so until I either find the problem or get a work around, my project isn't worth squat. Sorry if the "severity" and "priority" are set too strong or wrong. I'm not sure what to compare it with - but it is a blocking problem for me and I have not been able to find a way around it. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-14 00:37 David Zemon New Issue ====================================================================== From mantis at public.kitware.com Sun Sep 14 08:33:04 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 14 Sep 2014 08:33:04 -0400 Subject: [cmake-developers] [CMake 0015156]: Sometime, CMake can't find clang/clang++ Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15156 ====================================================================== Reported By: Meng-Yuan Huang Assigned To: ====================================================================== Project: CMake Issue ID: 15156 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-14 08:33 EDT Last Modified: 2014-09-14 08:33 EDT ====================================================================== Summary: Sometime, CMake can't find clang/clang++ Description: I have a CMake C++ project, test. I want to build it by clang/clang++ on CentOS 6.5. I run cmake by this command line: cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ . Unfortunately, sometime, cmake said it can't find clang/clang++. Strangely, if I run the command line again, it becomes to able to find them. Strangely again, if run the command line again, it becomes to not able to find them. ... If cmake can find clang/clang++, then running make will invoke clang/clang++. Otherwise, if cmake can't find clang/clang++, then running make will invoke gcc/g++. I recorded a video to show the problem: http://1drv.ms/1uwXVek Please fix this problem. CMake 3.0.2 also has a similar but different problem as 2.8.12. Steps to Reproduce: 1. Download the attached test project, test.tar.gz and extract it. 2. Run cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ . for several times and inspect the cmake output messages. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-14 08:33 Meng-Yuan HuangNew Issue 2014-09-14 08:33 Meng-Yuan HuangFile Added: test.tar.gz ====================================================================== From mantis at public.kitware.com Sun Sep 14 12:39:11 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 14 Sep 2014 12:39:11 -0400 Subject: [cmake-developers] [CMake 0015157]: FindCUDA.cmake: separate compilation not working as expected Message-ID: <8fdf61d573320138789338d3e12fd843@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15157 ====================================================================== Reported By: bchretien Assigned To: ====================================================================== Project: CMake Issue ID: 15157 Category: Modules Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2014-09-14 12:39 EDT Last Modified: 2014-09-14 12:39 EDT ====================================================================== Summary: FindCUDA.cmake: separate compilation not working as expected Description: I tried using separate compilation for CUDA with CMake, but I had the issue described by someone else on Stack Overflow: https://stackoverflow.com/questions/22540783/nvlink-error-when-linking-cuda-code-against-cuda-static-library-cmake In the CUDA SDK samples, there's a "simpleSeparateCompilation" sample that uses a Makefile to build a device static library and link it to the executable. I tried to adapt it to CMake, but the same CUDA linker error arises. If this is simply because this should be done some other way, then I guess the documentation in FindCUDA.cmake should be completed. Else, this may be an error in the module. Steps to Reproduce: Add the enclosed CMakeLists to $CUDA_HOME/samples/0_Simple/simpleSeparateCompilation. $ mkdir /tmp/test && cd /tmp/test $ cmake $CUDA_HOME/samples/0_Simple/simpleSeparateCompilation $ make ... [100%] Building NVCC intermediate link file CMakeFiles/simpleSeparateCompilation.dir/./simpleSeparateCompilation_intermediate_link.o nvlink error : Undefined reference to '_Z13multiplyByTwof' in '/tmp/test/CMakeFiles/simpleSeparateCompilation.dir//./simpleSeparateCompilation_generated_simpleSeparateCompilation.cu.o' nvlink error : Undefined reference to '_Z11divideByTwof' in '/tmp/test/CMakeFiles/simpleSeparateCompilation.dir//./simpleSeparateCompilation_generated_simpleSeparateCompilation.cu.o' CMakeFiles/simpleSeparateCompilation.dir/build.make:61: recipe for target 'CMakeFiles/simpleSeparateCompilation.dir/./simpleSeparateCompilation_intermediate_link.o' failed Additional Information: I tested this on Arch Linux with CUDA 6.5 and CMake 3.0.2. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-14 12:39 bchretien New Issue 2014-09-14 12:39 bchretien File Added: CMakeLists.txt ====================================================================== From i-love-spam at yandex.ru Sun Sep 14 14:15:55 2014 From: i-love-spam at yandex.ru (i-love-spam) Date: Sun, 14 Sep 2014 22:15:55 +0400 Subject: [cmake-developers] alternative gui for CMAKE (webgui) Message-ID: <5550691410718555@web17o.yandex.ru> Hello Cmake, in our project we develop for most of the platforms (android, ios, macos, WinRT, Win32, blackbery-qnx etc). We are starting to switch more and more projects to Cmake. For most of the stuff that we build we use buildservers to make release, and the buildservers are totally hand written code. Cmake-gui basically interprets all the options from cmake files and dynamically generates gui to be displayed for the user. Is there something already exist that generates html gui instead? Is it easy to add that kind of option so that we could have familiar cmake style web gui in our buildservers? For now, if add some kind of option, somebody has to go and modify php code to present and handle that option on the web and pass it to cmake or some other build system. What I'm looking for is to skip that step and directly generate html from cmake files the way cmake-gui generates gui with all the available options. From daniel at pfeifer-mail.de Sun Sep 14 15:48:18 2014 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Sun, 14 Sep 2014 21:48:18 +0200 Subject: [cmake-developers] alternative gui for CMAKE (webgui) In-Reply-To: <5550691410718555@web17o.yandex.ru> References: <5550691410718555@web17o.yandex.ru> Message-ID: 2014-09-14 20:15 GMT+02:00 i-love-spam : > Hello Cmake, > > in our project we develop for most of the platforms (android, ios, macos, > WinRT, Win32, blackbery-qnx etc). We are starting to switch more and more > projects to Cmake. > For most of the stuff that we build we use buildservers to make release, > and the buildservers are totally hand written code. > Cmake-gui basically interprets all the options from cmake filesand > dynamically generates gui to be displayed for the user. Hi Yandex, cmake-gui and ccmake are "cache editors". They generate a GUI from the CMake cache, which is generated from the cmake files. You find the CMake cache in the file CMakeCache.txt in your build directory. It is rather easy to parse. It should be straight-forward to build a cache manager in PHP. For a start, have a look at the file https://github.com/Kitware/CMake/blob/master/Source/cmCacheManager.cxx Cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascal.bach at siemens.com Mon Sep 15 09:51:50 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Mon, 15 Sep 2014 13:51:50 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Make the Visual Studio 10+ generator Windows CE In-Reply-To: <5412F6FB.3030005@kitware.com> References: <5412E5BA.1070708@kitware.com> <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> <5412F6FB.3030005@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616AD17EA@DEFTHW99EH4MSX.ww902.siemens.net> > Here please add this check: > > if(this->DefaultPlatformName != "Win32") > { > cmOStringStream e; > e << "CMAKE_SYSTEM_NAME is 'WindowsCE' but CMAKE_GENERATOR " > << "specifies a platform too: '" << this->GetName() << "'"; > mf->IssueMessage(cmake::FATAL_ERROR, e.str()); > return false; > } > > This code should no longer be called multiple times so it is safe to > check here now. Done check is added. > > > + // To preserve the old behaviour just keep the DefaultPlatformToolset > > + // for unknown Windows CE versions, in the worst case the user has to > set > > + // CMAKE_GENERATOR_TOOLSET manually. In that case warn the user. > > + std::string platformToolset = this->SelectWindowsCEToolset(); > > + if (!platformToolset.empty()) > > + { > > + this->DefaultPlatformToolset = platformToolset; > > + } > > + else > > + { > > + cmOStringStream e; > > + e << this->GetName() << " Windows CE version '" << this- > >SystemVersion > > + << "' might require CMAKE_GENERATOR_TOOLSET to be set."; > > + mf->IssueMessage(cmake::WARNING, e.str()); > > + } > > I think this will always warn when CMAKE_SYSTEM_VERSION != 8.0 > even if the user has set a CMAKE_GENERATOR_TOOLSET. Instead, > cmGlobalVisualStudio10Generator::SetGeneratorToolset should > implement the warning: I'm not sure if it is always required for older versions. I just assume it is and print an error if not set. I think the user knows what toolset to use when compiling for WindowCE. Here is the updated patch: >From 1599834a97200511feede2c3a69b33bbf66560b6 Mon Sep 17 00:00:00 2001 From: Pascal Bach Date: Mon, 15 Sep 2014 15:46:43 +0200 Subject: [PATCH] WINCE, VS: Make the Visual Studio 10+ generator Windows CE - If Windows CE is targeted set the Subsystem and EntryPointSymbol accordingly - For Windows CE 2013 (8.0) set the toolset to C800 by default --- Source/cmGlobalVisualStudio10Generator.cxx | 44 ++++++++++++++++++++++++++++ Source/cmGlobalVisualStudio10Generator.h | 7 +++++ Source/cmVisualStudio10TargetGenerator.cxx | 20 +++++++++++-- 3 files changed, 69 insertions(+), 2 deletions(-) diff --git a/Source/cmGlobalVisualStudio10Generator.cxx b/Source/cmGlobalVisualStudio10Generator.cxx index e2d4645..5fef79c 100644 --- a/Source/cmGlobalVisualStudio10Generator.cxx +++ b/Source/cmGlobalVisualStudio10Generator.cxx @@ -152,6 +152,15 @@ bool cmGlobalVisualStudio10Generator::SetGeneratorToolset(std::string const& ts, cmMakefile* mf) { +if (this->SystemIsWindowsCE && ts.empty() && this->DefaultPlatformToolset.empty()) + { + cmOStringStream e; + e << this->GetName() << " Windows CE version '" << this->SystemVersion + << "' requires CMAKE_GENERATOR_TOOLSET to be set."; + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); + return false; + } + this->GeneratorToolset = ts; if(const char* toolset = this->GetPlatformToolset()) { @@ -179,6 +188,14 @@ bool cmGlobalVisualStudio10Generator::InitializeSystem(cmMakefile* mf) return false; } } + else if (this->SystemName == "WindowsCE") + { + this->SystemIsWindowsCE = true; + if (!this->InitializeWindowsCE(mf)) + { + return false; + } + } return true; } @@ -201,6 +218,33 @@ bool cmGlobalVisualStudio10Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio10Generator::InitializeWindowsCE(cmMakefile* mf) +{ + if (this->DefaultPlatformName != "Win32") + { + cmOStringStream e; + e << "CMAKE_SYSTEM_NAME is 'WindowsCE' but CMAKE_GENERATOR " + << "specifies a platform too: '" << this->GetName() << "'"; + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); + return false; + } + + this->DefaultPlatformToolset = this->SelectWindowsCEToolset(); + + return true; +} + +//---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio10Generator::SelectWindowsCEToolset() const +{ + if (this->SystemVersion == "8.0") + { + return "CE800"; + } + return ""; +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio10Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 11.00\n"; diff --git a/Source/cmGlobalVisualStudio10Generator.h b/Source/cmGlobalVisualStudio10Generator.h index f1ff9a4..a80222f 100644 --- a/Source/cmGlobalVisualStudio10Generator.h +++ b/Source/cmGlobalVisualStudio10Generator.h @@ -76,6 +76,10 @@ public: bool TargetsWindowsStore() const { return this->SystemIsWindowsStore; } + /** Return true if building for WindowsCE */ + bool TargetsWindowsCE() const + { return this->SystemIsWindowsCE; } + /** * Where does this version of Visual Studio look for macros for the * current user? Returns the empty string if this version of Visual @@ -107,8 +111,10 @@ protected: virtual bool InitializeSystem(cmMakefile* mf); virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const { return ""; } virtual std::string SelectWindowsStoreToolset() const { return ""; } + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "10.0"; } @@ -120,6 +126,7 @@ protected: std::string SystemVersion; bool SystemIsWindowsPhone; bool SystemIsWindowsStore; + bool SystemIsWindowsCE; bool ExpressEdition; bool UseFolderProperty(); diff --git a/Source/cmVisualStudio10TargetGenerator.cxx b/Source/cmVisualStudio10TargetGenerator.cxx index c525b7c..681b8c7 100644 --- a/Source/cmVisualStudio10TargetGenerator.cxx +++ b/Source/cmVisualStudio10TargetGenerator.cxx @@ -2115,11 +2115,27 @@ cmVisualStudio10TargetGenerator::ComputeLinkOptions(std::string const& config) if ( this->Target->GetPropertyAsBool("WIN32_EXECUTABLE") ) { - linkOptions.AddFlag("SubSystem", "Windows"); + if (this->GlobalGenerator->TargetsWindowsCE()) + { + linkOptions.AddFlag("SubSystem", "WindowsCE"); + linkOptions.AddFlag("EntryPointSymbol", "WinMainCRTStartup"); + } + else + { + linkOptions.AddFlag("SubSystem", "Windows"); + } } else { - linkOptions.AddFlag("SubSystem", "Console"); + if (this->GlobalGenerator->TargetsWindowsCE()) + { + linkOptions.AddFlag("SubSystem", "WindowsCE"); + linkOptions.AddFlag("EntryPointSymbol", "mainACRTStartup"); + } + else + { + linkOptions.AddFlag("SubSystem", "Console"); + }; } if(const char* stackVal = -- 1.7.10.4 From brad.king at kitware.com Mon Sep 15 11:02:42 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Sep 2014 11:02:42 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Make the Visual Studio 10+ generator Windows CE In-Reply-To: <355BE46A91031048906B695426A8D8E616AD17EA@DEFTHW99EH4MSX.ww902.siemens.net> References: <5412E5BA.1070708@kitware.com> <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> <5412F6FB.3030005@kitware.com> <355BE46A91031048906B695426A8D8E616AD17EA@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <5416FF92.9050206@kitware.com> On 09/15/2014 09:51 AM, Bach, Pascal wrote: > Here is the updated patch: Thanks! I've applied it with minor modifications to order the methods lexicographically and wrap a long line. The only functional change is that I added a missing initialization of SystemIsWindowsCE in the constructor. See: VS: Teach VS >= 10 generator about Windows CE http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3298f77 -Brad From pascal.bach at siemens.com Mon Sep 15 11:46:09 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Mon, 15 Sep 2014 15:46:09 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Make the Visual Studio 10+ generator Windows CE In-Reply-To: <5416FF92.9050206@kitware.com> References: <5412E5BA.1070708@kitware.com> <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> <5412F6FB.3030005@kitware.com> <355BE46A91031048906B695426A8D8E616AD17EA@DEFTHW99EH4MSX.ww902.siemens.net> <5416FF92.9050206@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616AD1854@DEFTHW99EH4MSX.ww902.siemens.net> > On 09/15/2014 09:51 AM, Bach, Pascal wrote: > > Here is the updated patch: > > Thanks! I've applied it with minor modifications to order the > methods lexicographically and wrap a long line. The only > functional change is that I added a missing initialization of > SystemIsWindowsCE in the constructor. See: Thanks looks like I missed that. > > VS: Teach VS >= 10 generator about Windows CE > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3298f77 > So I think we can close: http://public.kitware.com/Bug/view.php?id=15115 But I don't see an option to do that. Pascal From brad.king at kitware.com Mon Sep 15 11:50:12 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Sep 2014 11:50:12 -0400 Subject: [cmake-developers] VS 10 Windows CE support (was: WINCE, VS: Make the Visual Studio 10+ generator Windows CE) In-Reply-To: <355BE46A91031048906B695426A8D8E616AD1854@DEFTHW99EH4MSX.ww902.siemens.net> References: <5412E5BA.1070708@kitware.com> <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> <5412F6FB.3030005@kitware.com> <355BE46A91031048906B695426A8D8E616AD17EA@DEFTHW99EH4MSX.ww902.siemens.net> <5416FF92.9050206@kitware.com> <355BE46A91031048906B695426A8D8E616AD1854@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <54170AB4.8040409@kitware.com> On 09/15/2014 11:46 AM, Bach, Pascal wrote: > So I think we can close: http://public.kitware.com/Bug/view.php?id=15115 Done. Thanks for your work on this! In order to keep things working, we will need nightly testing. Would you be able to run it? Take a look at Tests/CMakeLists.txt for mention of VSWinStorePhone. Something like that should be created for WindowsCE too. Then one will need to set up nightly testing on a machine with the proper toolchain installed for this. Thanks, -Brad From pascal.bach at siemens.com Mon Sep 15 12:23:39 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Mon, 15 Sep 2014 16:23:39 +0000 Subject: [cmake-developers] VS 10 Windows CE support (was: WINCE, VS: Make the Visual Studio 10+ generator Windows CE) In-Reply-To: <54170AB4.8040409@kitware.com> References: <5412E5BA.1070708@kitware.com> <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> <5412F6FB.3030005@kitware.com> <355BE46A91031048906B695426A8D8E616AD17EA@DEFTHW99EH4MSX.ww902.siemens.net> <5416FF92.9050206@kitware.com> <355BE46A91031048906B695426A8D8E616AD1854@DEFTHW99EH4MSX.ww902.siemens.net> <54170AB4.8040409@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616AD1888@DEFTHW99EH4MSX.ww902.siemens.net> > Done. Thanks for your work on this! > > In order to keep things working, we will need nightly testing. > Would you be able to run it? We already have a build machine running. http://open.cdash.org/viewSite.php?siteid=10948&project=1¤ttime=1410742800 Currently we are just building CMake Nightly using VS12. But it's the only machine with VS12 that I see until now. My goal is to extend this to also run some more tests, especially for WindowsCE. > > Take a look at Tests/CMakeLists.txt for mention of VSWinStorePhone. > Something like that should be created for WindowsCE too. Then one > will need to set up nightly testing on a machine with the proper > toolchain installed for this. > Ok I will have a look at that. Pascal From brad.king at kitware.com Mon Sep 15 14:22:40 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Sep 2014 14:22:40 -0400 Subject: [cmake-developers] VS 10 Windows CE support In-Reply-To: <355BE46A91031048906B695426A8D8E616AD1888@DEFTHW99EH4MSX.ww902.siemens.net> References: <5412E5BA.1070708@kitware.com> <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> <5412F6FB.3030005@kitware.com> <355BE46A91031048906B695426A8D8E616AD17EA@DEFTHW99EH4MSX.ww902.siemens.net> <5416FF92.9050206@kitware.com> <355BE46A91031048906B695426A8D8E616AD1854@DEFTHW99EH4MSX.ww902.siemens.net> <54170AB4.8040409@kitware.com> <355BE46A91031048906B695426A8D8E616AD1888@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <54172E70.4070307@kitware.com> On 09/15/2014 12:23 PM, Bach, Pascal wrote: >> In order to keep things working, we will need nightly testing. >> Would you be able to run it? > > We already have a build machine running. > http://open.cdash.org/viewSite.php?siteid=10948&project=1¤ttime=1410742800 > > Currently we are just building CMake Nightly using VS12. > But it's the only machine with VS12 that I see until now. Great. I moved those submissions to the "Nightly Expected" section. Thanks! -Brad From steveire at gmail.com Mon Sep 15 19:04:00 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 16 Sep 2014 01:04 +0200 Subject: [cmake-developers] Modern cross-platform buildsystem design requirements References: <54105A12.6070805@kitware.com> <5412EF56.2040804@kitware.com> Message-ID: Brad King wrote: > On 09/10/2014 11:49 AM, Stephen Kelly wrote: >> target_link_libraries(mylib cmake::android-16) > > Interesting idea. These could be predefined in the Platform/Android.cmake > module. However, I do not think the current ANDROID_API property will be > outdated by such a design Indeed. However, validation of allowed values might be worthwhile even now. >> macro(set_properties_for_platform tgt) >> if (CROSS_COMPILING) >> if (ANDROID) >> set_property(TARGET ${tgt} ...) >> elseif (BLACKBERRY) >> set_property(TARGET ${tgt} ...) >> elseif (WinRT) >> set_property(TARGET ${tgt} ...) >> endif() >> endif() >> endmacro() > > I don't see any reason the properties could not just always be set by > the project. The ones not relevant to the current cross-compiling > target would simply be ignored. Right. That's probably true in most cases. Relatedly, I can imagine a macro like the above experiencing scope-creep though, which is a reason to not want to need it :). > I think even your "toolchain scope" approach would end > up being used in practice to wrap the entire CMakeLists.txt file. > > The only approach I can think of that solves this without being a > complete rewrite is to support multiple separate configuration > passes, with separate CMakeCache.txt and everything as now, but that > all feed in to a single generation step. (Note the separate config > passes could be independent and perhaps run in threads.) Interesting idea. I'm not certain the resulting CMakeLists files would look much different to the "toolchain scope" approach though. You would still need conditionals with your approach: if(CONFIG_PASS_HOST) # CMake could set CONFIG_PASS_HOST in the normal case to avoid # the need to check if we are cross-compiling add_executable(host_tool main.cpp) endif() add_library(mylib foo.cpp) if(CONFIG_PASS_ARMv7) # Add extra source for the config pass named ARMv7 target_sources(mylib PRIVATE foo_embedded.cpp) endif() But what is cleaner with your approach is that a find_package could be outside of any conditional if needed in all configuration passes. >> When you refer to 'a new language' here, do you mean in the same sense of >> how generator expressions were a new language (without a departure from >> the current cmake language as a whole), or do you mean something >> different? > > I don't mean anything in particular except that we should not constrain > ourselves to solving the problem with the current CMake language only. Ok. When you wrote > However, perhaps it would be better > in the long run to consider something more declarative and with a > new language. I thought you might have had something more-concrete in mind. Thanks, Steve. From mantis at public.kitware.com Tue Sep 16 09:52:28 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 16 Sep 2014 09:52:28 -0400 Subject: [cmake-developers] [CMake 0015158]: MemCheck: Valgrind with multiple supressions files Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15158 ====================================================================== Reported By: trsystran Assigned To: ====================================================================== Project: CMake Issue ID: 15158 Category: CTest Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-16 09:52 EDT Last Modified: 2014-09-16 09:52 EDT ====================================================================== Summary: MemCheck: Valgrind with multiple supressions files Description: Currently CMake only accepts one valgrind suppressions file using the "CTEST_MEMORYCHECK_SUPPRESSIONS_FILE" variable. >From Valgrind man "You may use up to 100 extra suppression files.". It would be useful to be able to set a list of suppression files instead of just one. Currently I have to generate a new suppressions files by concatenating multiple files into one, and feed this to ctest. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-16 09:52 trsystran New Issue ====================================================================== From brad.king at kitware.com Tue Sep 16 10:05:35 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Sep 2014 10:05:35 -0400 Subject: [cmake-developers] vs-nsight-tegra-generator topic Message-ID: <541843AF.5060906@kitware.com> Hi Folks, This topic introduces support for generating VS project files for the NVIDIA Nsight Tegra Visual Studio Edition, which then builds for Android. I've merged it to 'next' for testing: Merge topic 'vs-nsight-tegra-generator' into next http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=24035687 Please take a look if you are interested in Android development. Although this topic is for Nsight Tegra builds, it does add some infrastructure that could be re-used later for more Android support in other generators. Thanks, -Brad From brad.king at kitware.com Tue Sep 16 10:08:44 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Sep 2014 10:08:44 -0400 Subject: [cmake-developers] vs-nsight-tegra-generator topic In-Reply-To: <541843AF.5060906@kitware.com> References: <541843AF.5060906@kitware.com> Message-ID: <5418446C.60508@kitware.com> On 09/16/2014 10:05 AM, Brad King wrote: > Please take a look if you are interested in Android development. [snip] On 09/15/2014 07:04 PM, Stephen Kelly wrote: > Brad King wrote: >> On 09/10/2014 11:49 AM, Stephen Kelly wrote: >>> target_link_libraries(mylib cmake::android-16) >> >> Interesting idea. These could be predefined in the Platform/Android.cmake >> module. However, I do not think the current ANDROID_API property will be >> outdated by such a design > > Indeed. However, validation of allowed values might be worthwhile even now. Steve, what validation should be done for ANDROID_API? Just that it is a decimal integer value? I think we will also need an ANDROID_ARCH and ANDROID_STL property. How should these be validated? Thanks, -Brad From steveire at gmail.com Tue Sep 16 10:44:09 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 16 Sep 2014 16:44:09 +0200 Subject: [cmake-developers] vs-nsight-tegra-generator topic References: <541843AF.5060906@kitware.com> <5418446C.60508@kitware.com> Message-ID: Brad King wrote: > On 09/16/2014 10:05 AM, Brad King wrote: >> Please take a look if you are interested in Android development. > [snip] > On 09/15/2014 07:04 PM, Stephen Kelly wrote: >> Brad King wrote: >>> On 09/10/2014 11:49 AM, Stephen Kelly wrote: >>>> target_link_libraries(mylib cmake::android-16) >>> >>> Interesting idea. These could be predefined in the >>> Platform/Android.cmake >>> module. However, I do not think the current ANDROID_API property will >>> be outdated by such a design >> >> Indeed. However, validation of allowed values might be worthwhile even >> now. > > Steve, what validation should be done for ANDROID_API? Just that it > is a decimal integer value? Apparently, yes: http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels Are there any restrictions on how old an android API the tegra system works with? I think the SDK has changes significantly at least once during the android lifetime. Setting an upper limit on the allowed value might also make sense, may not be necessary? > I think we will also need an ANDROID_ARCH and ANDROID_STL property. > How should these be validated? I don't know much about the _ARCH variable. That effectively determines the particular sysroot in the NDK to use, right? If you require that the path to the NDK be known, then you can validate that the directory exists to validate it. The _STL one I would like to see be generic at least. On any machine I don't want to compile my library with libc++ and link it with my executable compiled with libstdc++. I'd also want an abstraction for specifying the - stdlib= option for clang and the 'expanded' -I and -L/-l for GCC. I think this came up several times during the compile-features http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5813 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9729 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7671 but it was an orthogonal feature. I guess an interface of CMAKE_{,CXX_STDLIB} variable/property could pass standard values (libc++ and libstdc++) to the -stdlib option of clang and the user could define variables like CMAKE_CXX_STDLIB__OPTIONS_ such as CMAKE_CXX_STDLIB_COMPILE_OPTIONS_stlport CMAKE_CXX_STDLIB_LINK_OPTIONS_stlport in a toolchain file to make it possible to use another stl, or for use with GNU. However, I suspect with your Tegra system one only has to specify the stl and you're going to want to solve only that problem with a ANDROID_STL property, right :)? Thanks, Steve. From mantis at public.kitware.com Tue Sep 16 10:47:19 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 16 Sep 2014 10:47:19 -0400 Subject: [cmake-developers] [CMake 0015159]: MemCheck & CDash: timeout reported as "failed" instead of "timeout" Message-ID: <0ebc2163582c53adbb07fa08bdb340b2@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15159 ====================================================================== Reported By: trsystran Assigned To: ====================================================================== Project: CMake Issue ID: 15159 Category: CTest Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-16 10:47 EDT Last Modified: 2014-09-16 10:47 EDT ====================================================================== Summary: MemCheck & CDash: timeout reported as "failed" instead of "timeout" Description: When running a MemCheck in CTest, some tests fail because of timeout limits. In such case the information is available in the ctest stdout/err: 240/1445 MemCheck http://www.cmake.org/Bug/view.php?id=146: some_test ....................................***Timeout 65.92 sec But it is not reported in the DynamicAnalysis.xml sent to CDash: some_test/Name> xxx/Path> some_test /usr/bin/valgrind xxx blah This information would be useful in CDash, like it's already done for normal tests. In CDash we only get "failed" status and we don't know why it has failed. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-16 10:47 trsystran New Issue ====================================================================== From gereon.kremer at cs.rwth-aachen.de Tue Sep 16 10:52:41 2014 From: gereon.kremer at cs.rwth-aachen.de (Gereon Kremer) Date: Tue, 16 Sep 2014 16:52:41 +0200 Subject: [cmake-developers] Exporting a library shared and static Message-ID: <54184EB9.4060701@cs.rwth-aachen.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I have a project that consists of a library and an application that are developed as two separated projects (different repos, separate cmake setups, etc.). Let's call them "lib" and "app". The app exports itself to ~/.cmake/ and creates a appTargets.cmake, the app simply does find_package(lib). For several reasons, we must be able to build the app dynamically and statically. Our current approach is based on a flag "STATICLIB_SWITCH" that exists in the lib and in the app. Based on it's value, we build the library as .a or .so and link the app statically or dynamically. However, there are a few drawbacks: The value of the switch has to be consistent for the lib and the app and we didn't quite manage to correctly search for all libs: The linker command line is cluttered with lots of -rdynamic etc, which also occasionally breaks down and is very hard to debug when it does. So I spent some time on this and it seems that this is meant to be done differently. My new setup looks like this: The lib has two targets, for a shared object and for a static object, that are always built and exported. The app includes whatever it needs. This would remove the switch from the lib, which would be very nice. However, it seems that the app always includes the "shared target", no matter what I do. Also, I have not been able to provide the target with the list of libraries necessary: I simply collect all libraries in a variable that are found by other find_package calls, but find_package will only find either the shared or the static versions... So basically my question is: How is this supposed to be done? (I somehow get the feeling, that both attempts are wrong :-) ) How can I use a library in another application and switch (fairly) easily between static and dynamic linking? Thanks for any hints on this! Gereon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGE65AAoJEIQ2nMX673HfLL0H/RcCrNRKdLVQaaIfJnICKCiw 5RaE6t8PXxCjD+XPBgQOmdDVOKXAy/f/t7gV1T6yRDvvbgbUyQnTpRoWUL0Qjlos J+qob54Lcm90DTglNkpnImbfdBRv3XPDS34AGA20kgkmSDVsTdhg1fjDf5Cb10f7 UlGySIQqiIWSuygiq5uawswxqQuh6VuL98/vY+vxCkjNbLnWzuvCAT5x692qaFH3 M7JI4P/SWii637z/7sMh9e+mHue6MBynrcff2PUhDNCyIiG9MiQbZfzsvcQoKYSO jDZLTvSvmy8FUPXPH+15Z8MyfjqjksErLX4UbOBFeEQ5FJwtA+G9TRYHzlDS9vc= =AfDK -----END PGP SIGNATURE----- From mantis at public.kitware.com Tue Sep 16 12:03:05 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 16 Sep 2014 12:03:05 -0400 Subject: [cmake-developers] [CMake 0015160]: Different timeout for test and memcheck Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15160 ====================================================================== Reported By: trsystran Assigned To: ====================================================================== Project: CMake Issue ID: 15160 Category: CTest Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-16 12:03 EDT Last Modified: 2014-09-16 12:03 EDT ====================================================================== Summary: Different timeout for test and memcheck Description: Currently memcheck uses the same timeout (global or test-local) as for normal ctest_test() run. This is an issue since valgrind has a slowdown factor between 5 to 100 (according to them): the normal timeouts are not relevant for memcheck runs. Possible solutions with existing code: 1/ always calibrate the test timeout for valgrind. Drawback: this value is too large for normal test runs. 2/ never use test-local timeout and only rely on global timeout: then change the CTEST_TEST_TIMEOUT before calling ctest_memcheck(). Drawback: test-local timeout are really useful so stopping using them is an issue. Possible solutions with patches: Create a new test property MEMCHECK_TIMEOUT, a new global default memcheck timeout, that only apply for memcheck runs. Default value: either their non memcheck counterpart; or use a global slowdown factor and apply it from non memcheck timeout values. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-16 12:03 trsystran New Issue ====================================================================== From ono at java.pl Tue Sep 16 12:32:20 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 18:32:20 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <1409917844-28297-3-git-send-email-ono@java.pl> References: <1409917844-28297-3-git-send-email-ono@java.pl> Message-ID: <1410885143-87513-3-git-send-email-ono@java.pl> This is done by gathering LC_RPATH commands for main bundle executable and using it for @rpath lookup in dependent frameworks. To achieve this all utility functions now take path to executable rather than path to its directory. This enabled apps using @rpath to be bundled correctly, which will be necessary for upcoming Qt 5.4 that will use @rpath for all frameworks. --- Modules/BundleUtilities.cmake | 171 +++++++++++++++++++++++++---------------- Modules/GetPrerequisites.cmake | 51 ++++++------ 2 files changed, 131 insertions(+), 91 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 7e2b173..817ac78 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -19,6 +19,7 @@ # get_bundle_and_executable # get_bundle_all_executables # get_item_key +# get_item_rpaths # clear_bundle_keys # set_bundle_key_values # get_bundle_keys @@ -75,7 +76,7 @@ # # :: # -# GET_DOTAPP_DIR( ) +# GET_DOTAPP_DIR( ) # # Returns the nearest parent dir whose name ends with ".app" given the # full path to an executable. If there is no such parent dir, then @@ -123,7 +124,7 @@ # # :: # -# SET_BUNDLE_KEY_VALUES( +# SET_BUNDLE_KEY_VALUES( # ) # # Add a key to the list (if necessary) for the given item. If added, @@ -163,7 +164,7 @@ # # :: # -# FIXUP_BUNDLE_ITEM( ) +# FIXUP_BUNDLE_ITEM( ) # # Get the direct/non-system prerequisites of the resolved embedded item. # For each prerequisite, change the way it is referenced to the value of @@ -189,11 +190,11 @@ # # :: # -# VERIFY_BUNDLE_PREREQUISITES( ) +# VERIFY_BUNDLE_PREREQUISITES( []) # # Verifies that the sum of all prerequisites of all files inside the -# bundle are contained within the bundle or are "system" libraries, -# presumed to exist everywhere. +# bundle with given optional main executable location are contained within the +# bundle or are "system" libraries, presumed to exist everywhere. # # :: # @@ -285,8 +286,8 @@ function(get_bundle_main_executable bundle result_var) endfunction() -function(get_dotapp_dir exe dotapp_dir_var) - set(s "${exe}") +function(get_dotapp_dir executable dotapp_dir_var) + set(s "${executable}") if(s MATCHES "/.*\\.app/") # If there is a ".app" parent directory, @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) endfunction() +function(get_item_rpaths item rpaths_var) + if(APPLE) + find_program(otool_cmd "otool") + mark_as_advanced(otool_cmd) + endif() + + if(otool_cmd) + execute_process( + COMMAND "${otool_cmd}" -l "${item}" + OUTPUT_VARIABLE load_cmds_ov + ) + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") + string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") + string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") + if(load_cmds_ov) + gp_append_unique(${rpaths_var} "${load_cmds_ov}") + endif() + endif() + + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) +endfunction() + + function(get_item_key item key_var) get_filename_component(item_name "${item}" NAME) if(WIN32) @@ -425,12 +449,13 @@ function(clear_bundle_keys keys_var) set(${key}_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_COPYFLAG PARENT_SCOPE) + set(${key}_RPATHS PARENT_SCOPE) endforeach() set(${keys_var} PARENT_SCOPE) endfunction() -function(set_bundle_key_values keys_var context item exepath dirs copyflag) +function(set_bundle_key_values keys_var context item executable dirs copyflag) get_filename_component(item_name "${item}" NAME) get_item_key("${item}" key) @@ -440,10 +465,17 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) list(LENGTH ${keys_var} length_after) if(NOT length_before EQUAL length_after) - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item) + # Always use the exepath of the main bundle executable for @executable_path + # replacements: + # + get_filename_component(exepath "${executable}" PATH) + + gp_resolve_item("${context}" "${item}" "${executable}" "${dirs}" resolved_item) gp_item_default_embedded_path("${item}" default_embedded_path) + get_item_rpaths("${resolved_item}" rpaths) + if(item MATCHES "[^/]+\\.framework/") # For frameworks, construct the name under the embedded path from the # opening "${item_name}.framework/" to the closing "/${item_name}": @@ -479,6 +511,7 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) set(${key}_EMBEDDED_ITEM "${embedded_item}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" PARENT_SCOPE) set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) + set(${key}_RPATHS "${rpaths}" PARENT_SCOPE) else() #message("warning: item key '${key}' already in the list, subsequent references assumed identical to first") endif() @@ -490,14 +523,9 @@ function(get_bundle_keys app libs dirs keys_var) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - # Always use the exepath of the main bundle executable for @executable_path - # replacements: - # - get_filename_component(exepath "${executable}" PATH) - # But do fixups on all executables in the bundle: # - get_bundle_all_executables("${bundle}" exes) + get_bundle_all_executables("${bundle}" file_list) # For each extra lib, accumulate a key as well and then also accumulate # any of its prerequisites. (Extra libs are typically dynamically loaded @@ -505,12 +533,12 @@ function(get_bundle_keys app libs dirs keys_var) # but that do not show up in otool -L output...) # foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -518,17 +546,17 @@ function(get_bundle_keys app libs dirs keys_var) # The list of keys should be complete when all prerequisites of all # binaries in the bundle have been analyzed. # - foreach(exe ${exes}) + foreach(f ${file_list}) # Add the exe itself to the keys: # - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${f}" "${f}" "${executable}" "${dirs}" 0) # Add each prerequisite to the keys: # set(prereqs "") - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${f}" prereqs 1 1 "${executable}" "${dirs}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${f}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -542,6 +570,7 @@ function(get_bundle_keys app libs dirs keys_var) set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) endforeach() endif() endfunction() @@ -612,7 +641,7 @@ function(copy_resolved_framework_into_bundle resolved_item resolved_embedded_ite endfunction() -function(fixup_bundle_item resolved_embedded_item exepath dirs) +function(fixup_bundle_item resolved_embedded_item executable dirs) # This item's key is "ikey": # get_item_key("${resolved_embedded_item}" ikey) @@ -622,7 +651,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) # tree, or in other varied locations around the file system, with our call to # install_name_tool. Make sure that doesn't happen here: # - get_dotapp_dir("${exepath}" exe_dotapp_dir) + get_dotapp_dir("${executable}" exe_dotapp_dir) string(LENGTH "${exe_dotapp_dir}/" exe_dotapp_dir_length) string(LENGTH "${resolved_embedded_item}" resolved_embedded_item_length) set(path_too_short 0) @@ -648,7 +677,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) endif() set(prereqs "") - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}") + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${executable}" "${dirs}") set(changes "") @@ -668,12 +697,20 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) execute_process(COMMAND chmod u+w "${resolved_embedded_item}") endif() + foreach(rpath ${${ikey}_RPATHS}) + set(changes ${changes} -delete_rpath "${rpath}") + endforeach() + + if(${ikey}_EMBEDDED_ITEM) + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") + endif() + # Change this item's id and all of its references in one call # to install_name_tool: # - execute_process(COMMAND install_name_tool - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" - ) + if(changes) + execute_process(COMMAND install_name_tool ${changes} "${resolved_embedded_item}") + endif() endfunction() @@ -685,8 +722,6 @@ function(fixup_bundle app libs dirs) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - get_filename_component(exepath "${executable}" PATH) - message(STATUS "fixup_bundle: preparing...") get_bundle_keys("${app}" "${libs}" "${dirs}" keys) @@ -732,7 +767,7 @@ function(fixup_bundle app libs dirs) math(EXPR i ${i}+1) if(APPLE) message(STATUS "${i}/${n}: fixing up '${${key}_RESOLVED_EMBEDDED_ITEM}'") - fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${exepath}" "${dirs}") + fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${executable}" "${dirs}") else() message(STATUS "${i}/${n}: fix-up not required on this platform '${${key}_RESOLVED_EMBEDDED_ITEM}'") endif() @@ -762,50 +797,50 @@ function(verify_bundle_prerequisites bundle result_var info_var) set(info "") set(count 0) - get_bundle_main_executable("${bundle}" main_bundle_exe) + if(ARGC GREATER 0) + set(executable "${ARGV0}") + else() + get_bundle_main_executable("${bundle}" executable) + endif() - file(GLOB_RECURSE file_list "${bundle}/*") + get_bundle_all_executables("${bundle}" file_list) foreach(f ${file_list}) - is_file_executable("${f}" is_executable) - if(is_executable) - get_filename_component(exepath "${f}" PATH) - math(EXPR count "${count} + 1") + math(EXPR count "${count} + 1") - message(STATUS "executable file ${count}: ${f}") + message(STATUS "executable file ${count}: ${f}") - set(prereqs "") - get_prerequisites("${f}" prereqs 1 1 "${exepath}" "") + set(prereqs "") + get_prerequisites("${f}" prereqs 1 1 "${executable}" "") - # On the Mac, - # "embedded" and "system" prerequisites are fine... anything else means - # the bundle's prerequisites are not verified (i.e., the bundle is not - # really "standalone") - # - # On Windows (and others? Linux/Unix/...?) - # "local" and "system" prereqs are fine... - # - set(external_prereqs "") + # On the Mac, + # "embedded" and "system" prerequisites are fine... anything else means + # the bundle's prerequisites are not verified (i.e., the bundle is not + # really "standalone") + # + # On Windows (and others? Linux/Unix/...?) + # "local" and "system" prereqs are fine... + # + set(external_prereqs "") - foreach(p ${prereqs}) - set(p_type "") - gp_file_type("${f}" "${p}" p_type) + foreach(p ${prereqs}) + set(p_type "") + gp_file_type("${f}" "${p}" p_type "${executable}") - if(APPLE) - if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL "system") - set(external_prereqs ${external_prereqs} "${p}") - endif() - else() - if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL "system") - set(external_prereqs ${external_prereqs} "${p}") - endif() + if(APPLE) + if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL "system") + set(external_prereqs ${external_prereqs} "${p}") + endif() + else() + if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL "system") + set(external_prereqs ${external_prereqs} "${p}") endif() - endforeach() - - if(external_prereqs) - # Found non-system/somehow-unacceptable prerequisites: - set(result 0) - set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() + endforeach() + + if(external_prereqs) + # Found non-system/somehow-unacceptable prerequisites: + set(result 0) + set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() endforeach() @@ -845,7 +880,7 @@ function(verify_app app) # Verify that the bundle does not have any "external" prerequisites: # - verify_bundle_prerequisites("${bundle}" verified info) + verify_bundle_prerequisites("${bundle}" verified info "${executable}") message(STATUS "verified='${verified}'") message(STATUS "info='${info}'") message(STATUS "") diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 49443e3..439cc10 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -41,7 +41,7 @@ # :: # # GET_PREREQUISITES( -# ) +# ) # # Get the list of shared library files required by . The list # in the variable named should be empty on first @@ -53,7 +53,7 @@ # must be 0 or 1 indicating whether to include or # exclude "system" prerequisites. If is set to 1 all # prerequisites will be found recursively, if set to 0 only direct -# prerequisites are listed. is the path to the top level +# prerequisites are listed. is the path to the top level # executable used for @executable_path replacment on the Mac. is # a list of paths where libraries might be found: these paths are # searched first when a target without any path info is given. Then @@ -113,7 +113,7 @@ # # :: # -# GP_RESOLVE_ITEM( ) +# GP_RESOLVE_ITEM( ) # # Resolve an item into an existing full path file. # @@ -122,13 +122,13 @@ # # :: # -# GP_RESOLVED_FILE_TYPE( ) +# GP_RESOLVED_FILE_TYPE( ) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named # . # -# Use and if necessary to resolve non-absolute +# Use and if necessary to resolve non-absolute # values -- but only for non-embedded items. # # Possible types are: @@ -145,11 +145,12 @@ # # :: # -# GP_FILE_TYPE( ) +# GP_FILE_TYPE( []) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named -# . +# . Optional executable is used to resolve executable relative +# library locations. # # Possible types are: # @@ -318,10 +319,12 @@ function(gp_item_default_embedded_path item default_embedded_path_var) endfunction() -function(gp_resolve_item context item exepath dirs resolved_item_var) +function(gp_resolve_item context item executable dirs resolved_item_var) set(resolved 0) set(resolved_item "${item}") + get_filename_component(exepath "${executable}" PATH) + # Is it already resolved? # if(IS_ABSOLUTE "${resolved_item}" AND EXISTS "${resolved_item}") @@ -331,7 +334,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) if(NOT resolved) if(item MATCHES "^@executable_path") # - # @executable_path references are assumed relative to exepath + # @executable_path references are assumed relative to executable # string(REPLACE "@executable_path" "${exepath}" ri "${item}") get_filename_component(ri "${ri}" ABSOLUTE) @@ -374,10 +377,11 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) # string(REPLACE "@rpath/" "" norpath_item "${item}") + get_item_key("${executable}" key) set(ri "ri-NOTFOUND") - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) + find_file(ri "${norpath_item}" ${dirs} ${${key}_RPATHS} NO_DEFAULT_PATH) if(ri) - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") + #message(STATUS "info: 'find_file' in exepath/rpaths/dirs (${ri})") set(resolved 1) set(resolved_item "${ri}") set(ri "ri-NOTFOUND") @@ -436,7 +440,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) # by whatever logic they choose: # if(COMMAND gp_resolve_item_override) - gp_resolve_item_override("${context}" "${item}" "${exepath}" "${dirs}" resolved_item resolved) + gp_resolve_item_override("${context}" "${item}" "${executable}" "${dirs}" resolved_item resolved) endif() if(NOT resolved) @@ -459,7 +463,7 @@ warning: cannot resolve item '${item}' # # context='${context}' # item='${item}' -# exepath='${exepath}' +# executable='${executable}' # dirs='${dirs}' # resolved_item_var='${resolved_item_var}' #****************************************************************************** @@ -470,7 +474,7 @@ warning: cannot resolve item '${item}' endfunction() -function(gp_resolved_file_type original_file file exepath dirs type_var) +function(gp_resolved_file_type original_file file executable dirs type_var) #message(STATUS "**") if(NOT IS_ABSOLUTE "${original_file}") @@ -489,7 +493,7 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) if(NOT is_embedded) if(NOT IS_ABSOLUTE "${file}") - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file) + gp_resolve_item("${original_file}" "${file}" "${executable}" "${dirs}" resolved_file) endif() string(TOLOWER "${original_file}" original_lower) @@ -596,20 +600,20 @@ endfunction() function(gp_file_type original_file file type_var) + set(executable "${ARGV0}") + if(NOT IS_ABSOLUTE "${original_file}") message(STATUS "warning: gp_file_type expects absolute full path for first arg original_file") endif() - get_filename_component(exepath "${original_file}" PATH) - set(type "") - gp_resolved_file_type("${original_file}" "${file}" "${exepath}" "" type) + gp_resolved_file_type("${original_file}" "${file}" "${executable}" "" type) set(${type_var} "${type}" PARENT_SCOPE) endfunction() -function(get_prerequisites target prerequisites_var exclude_system recurse exepath dirs) +function(get_prerequisites target prerequisites_var exclude_system recurse executable dirs) set(verbose 0) set(eol_char "E") @@ -738,6 +742,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if("${gp_tool}" STREQUAL "ldd") set(old_ld_env "$ENV{LD_LIBRARY_PATH}") + get_filename_component(exepath "${executable}" PATH) set(new_ld_env "${exepath}") foreach(dir ${dirs}) set(new_ld_env "${new_ld_env}:${dir}") @@ -834,7 +839,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(add_item AND ${exclude_system}) set(type "") - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type) + gp_resolved_file_type("${target}" "${item}" "${executable}" "${dirs}" type) if("${type}" STREQUAL "system") set(add_item 0) @@ -855,7 +860,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa # that the analysis tools can simply accept it as input. # if(NOT list_length_before_append EQUAL list_length_after_append) - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${target}" "${item}" "${executable}" "${dirs}" resolved_item) set(unseen_prereqs ${unseen_prereqs} "${resolved_item}") endif() endif() @@ -874,7 +879,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(${recurse}) set(more_inputs ${unseen_prereqs}) foreach(input ${more_inputs}) - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}") + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${executable}" "${dirs}") endforeach() endif() @@ -911,7 +916,7 @@ function(list_prerequisites target) get_filename_component(exepath "${target}" PATH) set(prereqs "") - get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${exepath}" "") + get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${target}" "") if(print_target) message(STATUS "File '${target}' depends on:") -- 1.9.3 (Apple Git-50) From ono at java.pl Tue Sep 16 12:35:28 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 18:35:28 +0200 Subject: [cmake-developers] OS X packaging updates In-Reply-To: <540E0D6C.2010402@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> <5408B278.2070400@kitware.com> <4C094659-30A8-4304-ADBD-C62A1788C2A0@java.pl> <5409AD80.2000303@kitware.com> <540DE49F.8090508@kitware.com> <540E0D6C.2010402@kitware.com> Message-ID: <08C314C6-9A9C-4445-9342-66FA64080BEB@java.pl> > I had to revert again because it causes the Qt4Deploy to > fail. The topic changes the signature of gp_file_type. > User projects could be calling that, so we can't change it. > In this case it is the Modules/DeployQt4.cmake file that > was calling it. Thanks for spotting that. I've send updated 3/6 patch that now takes executable as an optional argument so we don't change any existing function signatures. --Adam From clinton at elemtech.com Tue Sep 16 12:55:41 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Tue, 16 Sep 2014 10:55:41 -0600 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <1410885143-87513-3-git-send-email-ono@java.pl> References: <1409917844-28297-3-git-send-email-ono@java.pl> <1410885143-87513-3-git-send-email-ono@java.pl> Message-ID: <2787116.mGKEBQAYYv@stryke> This patch has problems. You are calling BundleUtilities::get_item_key() from GetPrerequisites::gp_resolve_item(). There are users, including myself, which sometimes use GetPrerequisites.cmake but don't use BundleUtilities.cmake. So you cannot call BundleUtilities functions from GetPrerequisites. You also modified the signature of the gp_resolve_item_override() function which is defined by some users. There are a few others which were modified as well. Instead of taking an exepath, your patch changes them to take a executable. Instead, can you extract rpaths for a binary in BundleUtilities and pass that into gp_resolve_item via the existing dirs argument? Clint On Tuesday, September 16, 2014 06:32:20 PM Adam Strzelecki wrote: > This is done by gathering LC_RPATH commands for main bundle executable and > using it for @rpath lookup in dependent frameworks. > > To achieve this all utility functions now take path to executable rather > than path to its directory. > > This enabled apps using @rpath to be bundled correctly, which will be > necessary for upcoming Qt 5.4 that will use @rpath for all frameworks. > --- > Modules/BundleUtilities.cmake | 171 > +++++++++++++++++++++++++---------------- Modules/GetPrerequisites.cmake | > 51 ++++++------ > 2 files changed, 131 insertions(+), 91 deletions(-) > > diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake > index 7e2b173..817ac78 100644 > --- a/Modules/BundleUtilities.cmake > +++ b/Modules/BundleUtilities.cmake > @@ -19,6 +19,7 @@ > # get_bundle_and_executable > # get_bundle_all_executables > # get_item_key > +# get_item_rpaths > # clear_bundle_keys > # set_bundle_key_values > # get_bundle_keys > @@ -75,7 +76,7 @@ > # > # :: > # > -# GET_DOTAPP_DIR( ) > +# GET_DOTAPP_DIR( ) > # > # Returns the nearest parent dir whose name ends with ".app" given the > # full path to an executable. If there is no such parent dir, then > @@ -123,7 +124,7 @@ > # > # :: > # > -# SET_BUNDLE_KEY_VALUES( > +# SET_BUNDLE_KEY_VALUES( > # ) > # > # Add a key to the list (if necessary) for the given item. If added, > @@ -163,7 +164,7 @@ > # > # :: > # > -# FIXUP_BUNDLE_ITEM( ) > +# FIXUP_BUNDLE_ITEM( ) > # > # Get the direct/non-system prerequisites of the resolved embedded item. > # For each prerequisite, change the way it is referenced to the value of > @@ -189,11 +190,11 @@ > # > # :: > # > -# VERIFY_BUNDLE_PREREQUISITES( ) > +# VERIFY_BUNDLE_PREREQUISITES( > []) # > # Verifies that the sum of all prerequisites of all files inside the > -# bundle are contained within the bundle or are "system" libraries, > -# presumed to exist everywhere. > +# bundle with given optional main executable location are contained within > the +# bundle or are "system" libraries, presumed to exist everywhere. # > # :: > # > @@ -285,8 +286,8 @@ function(get_bundle_main_executable bundle result_var) > endfunction() > > > -function(get_dotapp_dir exe dotapp_dir_var) > - set(s "${exe}") > +function(get_dotapp_dir executable dotapp_dir_var) > + set(s "${executable}") > > if(s MATCHES "/.*\\.app/") > # If there is a ".app" parent directory, > @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) > endfunction() > > > +function(get_item_rpaths item rpaths_var) > + if(APPLE) > + find_program(otool_cmd "otool") > + mark_as_advanced(otool_cmd) > + endif() > + > + if(otool_cmd) > + execute_process( > + COMMAND "${otool_cmd}" -l "${item}" > + OUTPUT_VARIABLE load_cmds_ov > + ) > + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) > \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") + > string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") + > string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") + > if(load_cmds_ov) > + gp_append_unique(${rpaths_var} "${load_cmds_ov}") > + endif() > + endif() > + > + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) > +endfunction() > + > + > function(get_item_key item key_var) > get_filename_component(item_name "${item}" NAME) > if(WIN32) > @@ -425,12 +449,13 @@ function(clear_bundle_keys keys_var) > set(${key}_EMBEDDED_ITEM PARENT_SCOPE) > set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) > set(${key}_COPYFLAG PARENT_SCOPE) > + set(${key}_RPATHS PARENT_SCOPE) > endforeach() > set(${keys_var} PARENT_SCOPE) > endfunction() > > > -function(set_bundle_key_values keys_var context item exepath dirs copyflag) > +function(set_bundle_key_values keys_var context item executable dirs > copyflag) get_filename_component(item_name "${item}" NAME) > > get_item_key("${item}" key) > @@ -440,10 +465,17 @@ function(set_bundle_key_values keys_var context item > exepath dirs copyflag) list(LENGTH ${keys_var} length_after) > > if(NOT length_before EQUAL length_after) > - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" > resolved_item) + # Always use the exepath of the main bundle executable > for @executable_path + # replacements: > + # > + get_filename_component(exepath "${executable}" PATH) > + > + gp_resolve_item("${context}" "${item}" "${executable}" "${dirs}" > resolved_item) > > gp_item_default_embedded_path("${item}" default_embedded_path) > > + get_item_rpaths("${resolved_item}" rpaths) > + > if(item MATCHES "[^/]+\\.framework/") > # For frameworks, construct the name under the embedded path from the > # opening "${item_name}.framework/" to the closing "/${item_name}": @@ > -479,6 +511,7 @@ function(set_bundle_key_values keys_var context item > exepath dirs copyflag) set(${key}_EMBEDDED_ITEM "${embedded_item}" > PARENT_SCOPE) > set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" > PARENT_SCOPE) set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) > + set(${key}_RPATHS "${rpaths}" PARENT_SCOPE) > else() > #message("warning: item key '${key}' already in the list, subsequent > references assumed identical to first") endif() > @@ -490,14 +523,9 @@ function(get_bundle_keys app libs dirs keys_var) > > get_bundle_and_executable("${app}" bundle executable valid) > if(valid) > - # Always use the exepath of the main bundle executable for > @executable_path - # replacements: > - # > - get_filename_component(exepath "${executable}" PATH) > - > # But do fixups on all executables in the bundle: > # > - get_bundle_all_executables("${bundle}" exes) > + get_bundle_all_executables("${bundle}" file_list) > > # For each extra lib, accumulate a key as well and then also accumulate > # any of its prerequisites. (Extra libs are typically dynamically loaded @@ > -505,12 +533,12 @@ function(get_bundle_keys app libs dirs keys_var) # but > that do not show up in otool -L output...) > # > foreach(lib ${libs}) > - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" > "${dirs}" 0) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" > "${executable}" "${dirs}" 0) > > set(prereqs "") > - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") > + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") > foreach(pr ${prereqs}) > - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" > "${dirs}" 1) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" > "${executable}" "${dirs}" 1) endforeach() > endforeach() > > @@ -518,17 +546,17 @@ function(get_bundle_keys app libs dirs keys_var) > # The list of keys should be complete when all prerequisites of all > # binaries in the bundle have been analyzed. > # > - foreach(exe ${exes}) > + foreach(f ${file_list}) > # Add the exe itself to the keys: > # > - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" > "${dirs}" 0) + set_bundle_key_values(${keys_var} "${f}" "${f}" > "${executable}" "${dirs}" 0) > > # Add each prerequisite to the keys: > # > set(prereqs "") > - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") > + get_prerequisites("${f}" prereqs 1 1 "${executable}" "${dirs}") > foreach(pr ${prereqs}) > - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" > "${dirs}" 1) + set_bundle_key_values(${keys_var} "${f}" "${pr}" > "${executable}" "${dirs}" 1) endforeach() > endforeach() > > @@ -542,6 +570,7 @@ function(get_bundle_keys app libs dirs keys_var) > set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) > set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" > PARENT_SCOPE) set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) > + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) > endforeach() > endif() > endfunction() > @@ -612,7 +641,7 @@ function(copy_resolved_framework_into_bundle > resolved_item resolved_embedded_ite endfunction() > > > -function(fixup_bundle_item resolved_embedded_item exepath dirs) > +function(fixup_bundle_item resolved_embedded_item executable dirs) > # This item's key is "ikey": > # > get_item_key("${resolved_embedded_item}" ikey) > @@ -622,7 +651,7 @@ function(fixup_bundle_item resolved_embedded_item > exepath dirs) # tree, or in other varied locations around the file system, > with our call to # install_name_tool. Make sure that doesn't happen here: > # > - get_dotapp_dir("${exepath}" exe_dotapp_dir) > + get_dotapp_dir("${executable}" exe_dotapp_dir) > string(LENGTH "${exe_dotapp_dir}/" exe_dotapp_dir_length) > string(LENGTH "${resolved_embedded_item}" resolved_embedded_item_length) > set(path_too_short 0) > @@ -648,7 +677,7 @@ function(fixup_bundle_item resolved_embedded_item > exepath dirs) endif() > > set(prereqs "") > - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" > "${dirs}") + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 > "${executable}" "${dirs}") > > set(changes "") > > @@ -668,12 +697,20 @@ function(fixup_bundle_item resolved_embedded_item > exepath dirs) execute_process(COMMAND chmod u+w > "${resolved_embedded_item}") endif() > > + foreach(rpath ${${ikey}_RPATHS}) > + set(changes ${changes} -delete_rpath "${rpath}") > + endforeach() > + > + if(${ikey}_EMBEDDED_ITEM) > + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") > + endif() > + > # Change this item's id and all of its references in one call > # to install_name_tool: > # > - execute_process(COMMAND install_name_tool > - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" > - ) > + if(changes) > + execute_process(COMMAND install_name_tool ${changes} > "${resolved_embedded_item}") + endif() > endfunction() > > > @@ -685,8 +722,6 @@ function(fixup_bundle app libs dirs) > > get_bundle_and_executable("${app}" bundle executable valid) > if(valid) > - get_filename_component(exepath "${executable}" PATH) > - > message(STATUS "fixup_bundle: preparing...") > get_bundle_keys("${app}" "${libs}" "${dirs}" keys) > > @@ -732,7 +767,7 @@ function(fixup_bundle app libs dirs) > math(EXPR i ${i}+1) > if(APPLE) > message(STATUS "${i}/${n}: fixing up > '${${key}_RESOLVED_EMBEDDED_ITEM}'") - > fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${exepath}" > "${dirs}") + fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" > "${executable}" "${dirs}") else() > message(STATUS "${i}/${n}: fix-up not required on this platform > '${${key}_RESOLVED_EMBEDDED_ITEM}'") endif() > @@ -762,50 +797,50 @@ function(verify_bundle_prerequisites bundle result_var > info_var) set(info "") > set(count 0) > > - get_bundle_main_executable("${bundle}" main_bundle_exe) > + if(ARGC GREATER 0) > + set(executable "${ARGV0}") > + else() > + get_bundle_main_executable("${bundle}" executable) > + endif() > > - file(GLOB_RECURSE file_list "${bundle}/*") > + get_bundle_all_executables("${bundle}" file_list) > foreach(f ${file_list}) > - is_file_executable("${f}" is_executable) > - if(is_executable) > - get_filename_component(exepath "${f}" PATH) > - math(EXPR count "${count} + 1") > + math(EXPR count "${count} + 1") > > - message(STATUS "executable file ${count}: ${f}") > + message(STATUS "executable file ${count}: ${f}") > > - set(prereqs "") > - get_prerequisites("${f}" prereqs 1 1 "${exepath}" "") > + set(prereqs "") > + get_prerequisites("${f}" prereqs 1 1 "${executable}" "") > > - # On the Mac, > - # "embedded" and "system" prerequisites are fine... anything else > means - # the bundle's prerequisites are not verified (i.e., the > bundle is not - # really "standalone") > - # > - # On Windows (and others? Linux/Unix/...?) > - # "local" and "system" prereqs are fine... > - # > - set(external_prereqs "") > + # On the Mac, > + # "embedded" and "system" prerequisites are fine... anything else means > + # the bundle's prerequisites are not verified (i.e., the bundle is not > + # really "standalone") > + # > + # On Windows (and others? Linux/Unix/...?) > + # "local" and "system" prereqs are fine... > + # > + set(external_prereqs "") > > - foreach(p ${prereqs}) > - set(p_type "") > - gp_file_type("${f}" "${p}" p_type) > + foreach(p ${prereqs}) > + set(p_type "") > + gp_file_type("${f}" "${p}" p_type "${executable}") > > - if(APPLE) > - if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" > STREQUAL "system") - set(external_prereqs ${external_prereqs} > "${p}") > - endif() > - else() > - if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL > "system") - set(external_prereqs ${external_prereqs} "${p}") > - endif() > + if(APPLE) > + if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL > "system") + set(external_prereqs ${external_prereqs} "${p}") > + endif() > + else() > + if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL > "system") + set(external_prereqs ${external_prereqs} "${p}") > endif() > - endforeach() > - > - if(external_prereqs) > - # Found non-system/somehow-unacceptable prerequisites: > - set(result 0) > - set(info ${info} "external prerequisites > found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() > + endforeach() > + > + if(external_prereqs) > + # Found non-system/somehow-unacceptable prerequisites: > + set(result 0) > + set(info ${info} "external prerequisites > found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() > endforeach() > > @@ -845,7 +880,7 @@ function(verify_app app) > > # Verify that the bundle does not have any "external" prerequisites: > # > - verify_bundle_prerequisites("${bundle}" verified info) > + verify_bundle_prerequisites("${bundle}" verified info "${executable}") > message(STATUS "verified='${verified}'") > message(STATUS "info='${info}'") > message(STATUS "") > diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake > index 49443e3..439cc10 100644 > --- a/Modules/GetPrerequisites.cmake > +++ b/Modules/GetPrerequisites.cmake > @@ -41,7 +41,7 @@ > # :: > # > # GET_PREREQUISITES( > -# ) > +# ) > # > # Get the list of shared library files required by . The list > # in the variable named should be empty on first > @@ -53,7 +53,7 @@ > # must be 0 or 1 indicating whether to include or > # exclude "system" prerequisites. If is set to 1 all > # prerequisites will be found recursively, if set to 0 only direct > -# prerequisites are listed. is the path to the top level > +# prerequisites are listed. is the path to the top level > # executable used for @executable_path replacment on the Mac. is > # a list of paths where libraries might be found: these paths are > # searched first when a target without any path info is given. Then > @@ -113,7 +113,7 @@ > # > # :: > # > -# GP_RESOLVE_ITEM( ) > +# GP_RESOLVE_ITEM( > ) # > # Resolve an item into an existing full path file. > # > @@ -122,13 +122,13 @@ > # > # :: > # > -# GP_RESOLVED_FILE_TYPE( > ) +# GP_RESOLVED_FILE_TYPE( > ) # > # Return the type of with respect to . String > # describing type of prerequisite is returned in variable named > # . > # > -# Use and if necessary to resolve non-absolute > +# Use and if necessary to resolve non-absolute > # values -- but only for non-embedded items. > # > # Possible types are: > @@ -145,11 +145,12 @@ > # > # :: > # > -# GP_FILE_TYPE( ) > +# GP_FILE_TYPE( []) > # > # Return the type of with respect to . String > # describing type of prerequisite is returned in variable named > -# . > +# . Optional executable is used to resolve executable relative > +# library locations. > # > # Possible types are: > # > @@ -318,10 +319,12 @@ function(gp_item_default_embedded_path item > default_embedded_path_var) endfunction() > > > -function(gp_resolve_item context item exepath dirs resolved_item_var) > +function(gp_resolve_item context item executable dirs resolved_item_var) > set(resolved 0) > set(resolved_item "${item}") > > + get_filename_component(exepath "${executable}" PATH) > + > # Is it already resolved? > # > if(IS_ABSOLUTE "${resolved_item}" AND EXISTS "${resolved_item}") > @@ -331,7 +334,7 @@ function(gp_resolve_item context item exepath dirs > resolved_item_var) if(NOT resolved) > if(item MATCHES "^@executable_path") > # > - # @executable_path references are assumed relative to exepath > + # @executable_path references are assumed relative to executable > # > string(REPLACE "@executable_path" "${exepath}" ri "${item}") > get_filename_component(ri "${ri}" ABSOLUTE) > @@ -374,10 +377,11 @@ function(gp_resolve_item context item exepath dirs > resolved_item_var) # > string(REPLACE "@rpath/" "" norpath_item "${item}") > > + get_item_key("${executable}" key) > set(ri "ri-NOTFOUND") > - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) > + find_file(ri "${norpath_item}" ${dirs} ${${key}_RPATHS} > NO_DEFAULT_PATH) if(ri) > - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") > + #message(STATUS "info: 'find_file' in exepath/rpaths/dirs (${ri})") > set(resolved 1) > set(resolved_item "${ri}") > set(ri "ri-NOTFOUND") > @@ -436,7 +440,7 @@ function(gp_resolve_item context item exepath dirs > resolved_item_var) # by whatever logic they choose: > # > if(COMMAND gp_resolve_item_override) > - gp_resolve_item_override("${context}" "${item}" "${exepath}" "${dirs}" > resolved_item resolved) + gp_resolve_item_override("${context}" > "${item}" "${executable}" "${dirs}" resolved_item resolved) endif() > > if(NOT resolved) > @@ -459,7 +463,7 @@ warning: cannot resolve item '${item}' > # > # context='${context}' > # item='${item}' > -# exepath='${exepath}' > +# executable='${executable}' > # dirs='${dirs}' > # resolved_item_var='${resolved_item_var}' > #************************************************************************** > **** @@ -470,7 +474,7 @@ warning: cannot resolve item '${item}' > endfunction() > > > -function(gp_resolved_file_type original_file file exepath dirs type_var) > +function(gp_resolved_file_type original_file file executable dirs type_var) > #message(STATUS "**") > > if(NOT IS_ABSOLUTE "${original_file}") > @@ -489,7 +493,7 @@ function(gp_resolved_file_type original_file file > exepath dirs type_var) > > if(NOT is_embedded) > if(NOT IS_ABSOLUTE "${file}") > - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" > resolved_file) + gp_resolve_item("${original_file}" "${file}" > "${executable}" "${dirs}" resolved_file) endif() > > string(TOLOWER "${original_file}" original_lower) > @@ -596,20 +600,20 @@ endfunction() > > > function(gp_file_type original_file file type_var) > + set(executable "${ARGV0}") > + > if(NOT IS_ABSOLUTE "${original_file}") > message(STATUS "warning: gp_file_type expects absolute full path for > first arg original_file") endif() > > - get_filename_component(exepath "${original_file}" PATH) > - > set(type "") > - gp_resolved_file_type("${original_file}" "${file}" "${exepath}" "" type) > + gp_resolved_file_type("${original_file}" "${file}" "${executable}" "" > type) > > set(${type_var} "${type}" PARENT_SCOPE) > endfunction() > > > -function(get_prerequisites target prerequisites_var exclude_system recurse > exepath dirs) +function(get_prerequisites target prerequisites_var > exclude_system recurse executable dirs) set(verbose 0) > set(eol_char "E") > > @@ -738,6 +742,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa > > if("${gp_tool}" STREQUAL "ldd") > set(old_ld_env "$ENV{LD_LIBRARY_PATH}") > + get_filename_component(exepath "${executable}" PATH) > set(new_ld_env "${exepath}") > foreach(dir ${dirs}) > set(new_ld_env "${new_ld_env}:${dir}") > @@ -834,7 +839,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa > > if(add_item AND ${exclude_system}) > set(type "") > - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" > type) + gp_resolved_file_type("${target}" "${item}" "${executable}" > "${dirs}" type) > > if("${type}" STREQUAL "system") > set(add_item 0) > @@ -855,7 +860,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa # that the analysis tools can simply accept it > as input. > # > if(NOT list_length_before_append EQUAL list_length_after_append) > - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" > resolved_item) + gp_resolve_item("${target}" "${item}" > "${executable}" "${dirs}" resolved_item) set(unseen_prereqs > ${unseen_prereqs} "${resolved_item}") endif() > endif() > @@ -874,7 +879,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa if(${recurse}) > set(more_inputs ${unseen_prereqs}) > foreach(input ${more_inputs}) > - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} > ${recurse} "${exepath}" "${dirs}") + get_prerequisites("${input}" > ${prerequisites_var} ${exclude_system} ${recurse} "${executable}" > "${dirs}") endforeach() > endif() > > @@ -911,7 +916,7 @@ function(list_prerequisites target) > get_filename_component(exepath "${target}" PATH) > > set(prereqs "") > - get_prerequisites("${target}" prereqs ${exclude_system} ${all} > "${exepath}" "") + get_prerequisites("${target}" prereqs ${exclude_system} > ${all} "${target}" "") > > if(print_target) > message(STATUS "File '${target}' depends on:") -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com From ono at java.pl Tue Sep 16 14:44:35 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 20:44:35 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <1410885143-87513-3-git-send-email-ono@java.pl> References: <1410885143-87513-3-git-send-email-ono@java.pl> Message-ID: <1410893078-92177-3-git-send-email-ono@java.pl> This is done by gathering LC_RPATH commands for main bundle executable and using it for @rpath lookup in dependent frameworks. To achieve this all utility functions now take path to executable rather than path to its directory. This enabled apps using @rpath to be bundled correctly, which will be necessary for upcoming Qt 5.4 that will use @rpath for all frameworks. --- Modules/BundleUtilities.cmake | 174 +++++++++++++++++++++++++---------------- Modules/GetPrerequisites.cmake | 55 +++++++------ 2 files changed, 137 insertions(+), 92 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 7e2b173..ab26157 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -19,6 +19,7 @@ # get_bundle_and_executable # get_bundle_all_executables # get_item_key +# get_item_rpaths # clear_bundle_keys # set_bundle_key_values # get_bundle_keys @@ -75,7 +76,7 @@ # # :: # -# GET_DOTAPP_DIR( ) +# GET_DOTAPP_DIR( ) # # Returns the nearest parent dir whose name ends with ".app" given the # full path to an executable. If there is no such parent dir, then @@ -123,7 +124,7 @@ # # :: # -# SET_BUNDLE_KEY_VALUES( +# SET_BUNDLE_KEY_VALUES( # ) # # Add a key to the list (if necessary) for the given item. If added, @@ -163,7 +164,7 @@ # # :: # -# FIXUP_BUNDLE_ITEM( ) +# FIXUP_BUNDLE_ITEM( ) # # Get the direct/non-system prerequisites of the resolved embedded item. # For each prerequisite, change the way it is referenced to the value of @@ -189,11 +190,11 @@ # # :: # -# VERIFY_BUNDLE_PREREQUISITES( ) +# VERIFY_BUNDLE_PREREQUISITES( []) # # Verifies that the sum of all prerequisites of all files inside the -# bundle are contained within the bundle or are "system" libraries, -# presumed to exist everywhere. +# bundle with given optional main executable location are contained within the +# bundle or are "system" libraries, presumed to exist everywhere. # # :: # @@ -285,8 +286,8 @@ function(get_bundle_main_executable bundle result_var) endfunction() -function(get_dotapp_dir exe dotapp_dir_var) - set(s "${exe}") +function(get_dotapp_dir executable dotapp_dir_var) + set(s "${executable}") if(s MATCHES "/.*\\.app/") # If there is a ".app" parent directory, @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) endfunction() +function(get_item_rpaths item rpaths_var) + if(APPLE) + find_program(otool_cmd "otool") + mark_as_advanced(otool_cmd) + endif() + + if(otool_cmd) + execute_process( + COMMAND "${otool_cmd}" -l "${item}" + OUTPUT_VARIABLE load_cmds_ov + ) + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") + string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") + string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") + if(load_cmds_ov) + gp_append_unique(${rpaths_var} "${load_cmds_ov}") + endif() + endif() + + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) +endfunction() + + function(get_item_key item key_var) get_filename_component(item_name "${item}" NAME) if(WIN32) @@ -425,12 +449,13 @@ function(clear_bundle_keys keys_var) set(${key}_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_COPYFLAG PARENT_SCOPE) + set(${key}_RPATHS PARENT_SCOPE) endforeach() set(${keys_var} PARENT_SCOPE) endfunction() -function(set_bundle_key_values keys_var context item exepath dirs copyflag) +function(set_bundle_key_values keys_var context item executable dirs copyflag) get_filename_component(item_name "${item}" NAME) get_item_key("${item}" key) @@ -440,10 +465,19 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) list(LENGTH ${keys_var} length_after) if(NOT length_before EQUAL length_after) - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item) + # Always use the exepath of the main bundle executable for @executable_path + # replacements: + # + get_filename_component(exepath "${executable}" PATH) + + get_item_key("${executable}" executable_key) + + gp_resolve_item("${context}" "${item}" "${executable}" "${dirs}" resolved_item "${${executable_key}_RPATHS}") gp_item_default_embedded_path("${item}" default_embedded_path) + get_item_rpaths("${resolved_item}" rpaths) + if(item MATCHES "[^/]+\\.framework/") # For frameworks, construct the name under the embedded path from the # opening "${item_name}.framework/" to the closing "/${item_name}": @@ -479,6 +513,7 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) set(${key}_EMBEDDED_ITEM "${embedded_item}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" PARENT_SCOPE) set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) + set(${key}_RPATHS "${rpaths}" PARENT_SCOPE) else() #message("warning: item key '${key}' already in the list, subsequent references assumed identical to first") endif() @@ -490,14 +525,9 @@ function(get_bundle_keys app libs dirs keys_var) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - # Always use the exepath of the main bundle executable for @executable_path - # replacements: - # - get_filename_component(exepath "${executable}" PATH) - # But do fixups on all executables in the bundle: # - get_bundle_all_executables("${bundle}" exes) + get_bundle_all_executables("${bundle}" file_list) # For each extra lib, accumulate a key as well and then also accumulate # any of its prerequisites. (Extra libs are typically dynamically loaded @@ -505,12 +535,12 @@ function(get_bundle_keys app libs dirs keys_var) # but that do not show up in otool -L output...) # foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -518,17 +548,19 @@ function(get_bundle_keys app libs dirs keys_var) # The list of keys should be complete when all prerequisites of all # binaries in the bundle have been analyzed. # - foreach(exe ${exes}) + foreach(f ${file_list}) # Add the exe itself to the keys: # - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${f}" "${f}" "${executable}" "${dirs}" 0) + + get_item_key("${executable}" executable_key) # Add each prerequisite to the keys: # set(prereqs "") - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${f}" prereqs 1 1 "${executable}" "${dirs}" "${${executable_key}_RPATHS}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${f}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -542,6 +574,7 @@ function(get_bundle_keys app libs dirs keys_var) set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) endforeach() endif() endfunction() @@ -612,7 +645,7 @@ function(copy_resolved_framework_into_bundle resolved_item resolved_embedded_ite endfunction() -function(fixup_bundle_item resolved_embedded_item exepath dirs) +function(fixup_bundle_item resolved_embedded_item executable dirs) # This item's key is "ikey": # get_item_key("${resolved_embedded_item}" ikey) @@ -622,7 +655,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) # tree, or in other varied locations around the file system, with our call to # install_name_tool. Make sure that doesn't happen here: # - get_dotapp_dir("${exepath}" exe_dotapp_dir) + get_dotapp_dir("${executable}" exe_dotapp_dir) string(LENGTH "${exe_dotapp_dir}/" exe_dotapp_dir_length) string(LENGTH "${resolved_embedded_item}" resolved_embedded_item_length) set(path_too_short 0) @@ -647,8 +680,10 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) message(FATAL_ERROR "cannot fixup an item that is not in the bundle...") endif() + get_item_key("${executable}" executable_key) + set(prereqs "") - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}") + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${executable}" "${dirs}" "${${executable_key}_RPATHS}") set(changes "") @@ -668,12 +703,20 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) execute_process(COMMAND chmod u+w "${resolved_embedded_item}") endif() + foreach(rpath ${${ikey}_RPATHS}) + set(changes ${changes} -delete_rpath "${rpath}") + endforeach() + + if(${ikey}_EMBEDDED_ITEM) + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") + endif() + # Change this item's id and all of its references in one call # to install_name_tool: # - execute_process(COMMAND install_name_tool - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" - ) + if(changes) + execute_process(COMMAND install_name_tool ${changes} "${resolved_embedded_item}") + endif() endfunction() @@ -685,8 +728,6 @@ function(fixup_bundle app libs dirs) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - get_filename_component(exepath "${executable}" PATH) - message(STATUS "fixup_bundle: preparing...") get_bundle_keys("${app}" "${libs}" "${dirs}" keys) @@ -732,7 +773,7 @@ function(fixup_bundle app libs dirs) math(EXPR i ${i}+1) if(APPLE) message(STATUS "${i}/${n}: fixing up '${${key}_RESOLVED_EMBEDDED_ITEM}'") - fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${exepath}" "${dirs}") + fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${executable}" "${dirs}") else() message(STATUS "${i}/${n}: fix-up not required on this platform '${${key}_RESOLVED_EMBEDDED_ITEM}'") endif() @@ -761,51 +802,46 @@ function(verify_bundle_prerequisites bundle result_var info_var) set(result 1) set(info "") set(count 0) + set(executable "${ARGV3}") - get_bundle_main_executable("${bundle}" main_bundle_exe) - - file(GLOB_RECURSE file_list "${bundle}/*") + get_bundle_all_executables("${bundle}" file_list) foreach(f ${file_list}) - is_file_executable("${f}" is_executable) - if(is_executable) - get_filename_component(exepath "${f}" PATH) - math(EXPR count "${count} + 1") + math(EXPR count "${count} + 1") - message(STATUS "executable file ${count}: ${f}") + message(STATUS "executable file ${count}: ${f}") - set(prereqs "") - get_prerequisites("${f}" prereqs 1 1 "${exepath}" "") + set(prereqs "") + get_prerequisites("${f}" prereqs 1 1 "${executable}" "") - # On the Mac, - # "embedded" and "system" prerequisites are fine... anything else means - # the bundle's prerequisites are not verified (i.e., the bundle is not - # really "standalone") - # - # On Windows (and others? Linux/Unix/...?) - # "local" and "system" prereqs are fine... - # - set(external_prereqs "") + # On the Mac, + # "embedded" and "system" prerequisites are fine... anything else means + # the bundle's prerequisites are not verified (i.e., the bundle is not + # really "standalone") + # + # On Windows (and others? Linux/Unix/...?) + # "local" and "system" prereqs are fine... + # + set(external_prereqs "") - foreach(p ${prereqs}) - set(p_type "") - gp_file_type("${f}" "${p}" p_type) + foreach(p ${prereqs}) + set(p_type "") + gp_file_type("${f}" "${p}" p_type "${executable}") - if(APPLE) - if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL "system") - set(external_prereqs ${external_prereqs} "${p}") - endif() - else() - if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL "system") - set(external_prereqs ${external_prereqs} "${p}") - endif() + if(APPLE) + if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL "system") + set(external_prereqs ${external_prereqs} "${p}") + endif() + else() + if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL "system") + set(external_prereqs ${external_prereqs} "${p}") endif() - endforeach() - - if(external_prereqs) - # Found non-system/somehow-unacceptable prerequisites: - set(result 0) - set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() + endforeach() + + if(external_prereqs) + # Found non-system/somehow-unacceptable prerequisites: + set(result 0) + set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() endforeach() @@ -845,7 +881,7 @@ function(verify_app app) # Verify that the bundle does not have any "external" prerequisites: # - verify_bundle_prerequisites("${bundle}" verified info) + verify_bundle_prerequisites("${bundle}" verified info "${executable}") message(STATUS "verified='${verified}'") message(STATUS "info='${info}'") message(STATUS "") diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 49443e3..0684f12 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -41,7 +41,7 @@ # :: # # GET_PREREQUISITES( -# ) +# []) # # Get the list of shared library files required by . The list # in the variable named should be empty on first @@ -53,7 +53,7 @@ # must be 0 or 1 indicating whether to include or # exclude "system" prerequisites. If is set to 1 all # prerequisites will be found recursively, if set to 0 only direct -# prerequisites are listed. is the path to the top level +# prerequisites are listed. is the path to the top level # executable used for @executable_path replacment on the Mac. is # a list of paths where libraries might be found: these paths are # searched first when a target without any path info is given. Then @@ -113,7 +113,8 @@ # # :: # -# GP_RESOLVE_ITEM( ) +# GP_RESOLVE_ITEM( +# []) # # Resolve an item into an existing full path file. # @@ -122,13 +123,14 @@ # # :: # -# GP_RESOLVED_FILE_TYPE( ) +# GP_RESOLVED_FILE_TYPE( +# []) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named # . # -# Use and if necessary to resolve non-absolute +# Use and if necessary to resolve non-absolute # values -- but only for non-embedded items. # # Possible types are: @@ -145,11 +147,12 @@ # # :: # -# GP_FILE_TYPE( ) +# GP_FILE_TYPE( []) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named -# . +# . Optional executable is used to resolve executable relative +# library locations. # # Possible types are: # @@ -318,9 +321,12 @@ function(gp_item_default_embedded_path item default_embedded_path_var) endfunction() -function(gp_resolve_item context item exepath dirs resolved_item_var) +function(gp_resolve_item context item executable dirs resolved_item_var) set(resolved 0) set(resolved_item "${item}") + set(rpaths "${ARGV5}") + + get_filename_component(exepath "${executable}" PATH) # Is it already resolved? # @@ -331,7 +337,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) if(NOT resolved) if(item MATCHES "^@executable_path") # - # @executable_path references are assumed relative to exepath + # @executable_path references are assumed relative to executable # string(REPLACE "@executable_path" "${exepath}" ri "${item}") get_filename_component(ri "${ri}" ABSOLUTE) @@ -375,9 +381,9 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) string(REPLACE "@rpath/" "" norpath_item "${item}") set(ri "ri-NOTFOUND") - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) + find_file(ri "${norpath_item}" ${dirs} ${rpaths} NO_DEFAULT_PATH) if(ri) - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") + #message(STATUS "info: 'find_file' in exepath/rpaths/dirs (${ri})") set(resolved 1) set(resolved_item "${ri}") set(ri "ri-NOTFOUND") @@ -436,7 +442,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) # by whatever logic they choose: # if(COMMAND gp_resolve_item_override) - gp_resolve_item_override("${context}" "${item}" "${exepath}" "${dirs}" resolved_item resolved) + gp_resolve_item_override("${context}" "${item}" "${executable}" "${dirs}" resolved_item resolved) endif() if(NOT resolved) @@ -459,7 +465,7 @@ warning: cannot resolve item '${item}' # # context='${context}' # item='${item}' -# exepath='${exepath}' +# executable='${executable}' # dirs='${dirs}' # resolved_item_var='${resolved_item_var}' #****************************************************************************** @@ -470,7 +476,8 @@ warning: cannot resolve item '${item}' endfunction() -function(gp_resolved_file_type original_file file exepath dirs type_var) +function(gp_resolved_file_type original_file file executable dirs type_var) + set(rpaths "${ARGV5}") #message(STATUS "**") if(NOT IS_ABSOLUTE "${original_file}") @@ -489,7 +496,7 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) if(NOT is_embedded) if(NOT IS_ABSOLUTE "${file}") - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file) + gp_resolve_item("${original_file}" "${file}" "${executable}" "${dirs}" resolved_file "${rpaths}") endif() string(TOLOWER "${original_file}" original_lower) @@ -596,22 +603,23 @@ endfunction() function(gp_file_type original_file file type_var) + set(executable "${ARGV3}") + if(NOT IS_ABSOLUTE "${original_file}") message(STATUS "warning: gp_file_type expects absolute full path for first arg original_file") endif() - get_filename_component(exepath "${original_file}" PATH) - set(type "") - gp_resolved_file_type("${original_file}" "${file}" "${exepath}" "" type) + gp_resolved_file_type("${original_file}" "${file}" "${executable}" "" type) set(${type_var} "${type}" PARENT_SCOPE) endfunction() -function(get_prerequisites target prerequisites_var exclude_system recurse exepath dirs) +function(get_prerequisites target prerequisites_var exclude_system recurse executable dirs) set(verbose 0) set(eol_char "E") + set(rpaths "${ARGV6}") if(NOT IS_ABSOLUTE "${target}") message("warning: target '${target}' is not absolute...") @@ -738,6 +746,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if("${gp_tool}" STREQUAL "ldd") set(old_ld_env "$ENV{LD_LIBRARY_PATH}") + get_filename_component(exepath "${executable}" PATH) set(new_ld_env "${exepath}") foreach(dir ${dirs}) set(new_ld_env "${new_ld_env}:${dir}") @@ -834,7 +843,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(add_item AND ${exclude_system}) set(type "") - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type) + gp_resolved_file_type("${target}" "${item}" "${executable}" "${dirs}" type "${rpaths}") if("${type}" STREQUAL "system") set(add_item 0) @@ -855,7 +864,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa # that the analysis tools can simply accept it as input. # if(NOT list_length_before_append EQUAL list_length_after_append) - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${target}" "${item}" "${executable}" "${dirs}" resolved_item "${rpaths}") set(unseen_prereqs ${unseen_prereqs} "${resolved_item}") endif() endif() @@ -874,7 +883,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(${recurse}) set(more_inputs ${unseen_prereqs}) foreach(input ${more_inputs}) - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}") + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${executable}" "${dirs}" "${rpaths}") endforeach() endif() @@ -911,7 +920,7 @@ function(list_prerequisites target) get_filename_component(exepath "${target}" PATH) set(prereqs "") - get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${exepath}" "") + get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${target}" "") if(print_target) message(STATUS "File '${target}' depends on:") -- 1.9.3 (Apple Git-50) From ono at java.pl Tue Sep 16 14:44:36 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 20:44:36 +0200 Subject: [cmake-developers] [PATCH 4/6] Process executables first when scanning bundle In-Reply-To: <1410885143-87513-3-git-send-email-ono@java.pl> References: <1410885143-87513-3-git-send-email-ono@java.pl> Message-ID: <1410893078-92177-4-git-send-email-ono@java.pl> This makes rpaths populated (if any), so libraries containing @rpath will be resolved properly. --- Modules/BundleUtilities.cmake | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index ab26157..ea2d924 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -529,21 +529,6 @@ function(get_bundle_keys app libs dirs keys_var) # get_bundle_all_executables("${bundle}" file_list) - # For each extra lib, accumulate a key as well and then also accumulate - # any of its prerequisites. (Extra libs are typically dynamically loaded - # plugins: libraries that are prerequisites for full runtime functionality - # but that do not show up in otool -L output...) - # - foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) - - set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") - foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) - endforeach() - endforeach() - # For each executable found in the bundle, accumulate keys as we go. # The list of keys should be complete when all prerequisites of all # binaries in the bundle have been analyzed. @@ -564,6 +549,21 @@ function(get_bundle_keys app libs dirs keys_var) endforeach() endforeach() + # For each extra lib, accumulate a key as well and then also accumulate + # any of its prerequisites. (Extra libs are typically dynamically loaded + # plugins: libraries that are prerequisites for full runtime functionality + # but that do not show up in otool -L output...) + # + foreach(lib ${libs}) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) + + set(prereqs "") + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}" "${${executable_key}_RPATHS}") + foreach(pr ${prereqs}) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) + endforeach() + endforeach() + # Propagate values to caller's scope: # set(${keys_var} ${${keys_var}} PARENT_SCOPE) -- 1.9.3 (Apple Git-50) From ono at java.pl Tue Sep 16 14:48:31 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 20:48:31 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <2787116.mGKEBQAYYv@stryke> References: <1409917844-28297-3-git-send-email-ono@java.pl> <1410885143-87513-3-git-send-email-ono@java.pl> <2787116.mGKEBQAYYv@stryke> Message-ID: > Instead, can you extract rpaths for a binary in BundleUtilities and pass that > into gp_resolve_item via the existing dirs argument? Okay, fixed this in the new 3/6 + 4/6 patches, attached to previous patch post. FYI I cannot use existing dirs arguments because other replacements search paths shouldn't look into rpath, only @rpath replacements. So instead I added extra optional rpaths argument to all GetPrerequisites functions that somewhere call gp_resolve_item so need to carry rpaths. WDYT? --Adam From clinton at elemtech.com Tue Sep 16 15:12:04 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Tue, 16 Sep 2014 13:12:04 -0600 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: References: <1409917844-28297-3-git-send-email-ono@java.pl> <2787116.mGKEBQAYYv@stryke> Message-ID: <128289242.dS4VVThf2B@stryke> On Tuesday, September 16, 2014 08:48:31 PM Adam Strzelecki wrote: > > Instead, can you extract rpaths for a binary in BundleUtilities and pass > > that into gp_resolve_item via the existing dirs argument? > > Okay, fixed this in the new 3/6 + 4/6 patches, attached to previous patch > post. > > FYI I cannot use existing dirs arguments because other replacements search > paths shouldn't look into rpath, only @rpath replacements. Sure, but the caller can also check for @rpath and in that case add the rpaths to the existing dirs argument. Yes, there are other find_file() searches in there, that could potentially mess up if the actual filename had "@rpath" in it. But I would also argue that the general fallback find_file(ri "${item}" ${exepath} ${dirs} /usr/lib) can undesirably be affected by other variables such as CMAKE_INCLUDE_PATH. > > So instead I added extra optional rpaths argument to all GetPrerequisites > functions that somewhere call gp_resolve_item so need to carry rpaths. > > WDYT? > > --Adam Can you explain the "exepath" to "executable" change in the function signatures? I have the impression you changed the signature of several functions to accept "/path/to/executable" instead of "/path/to/" No? These functions are called by other codes and we can't just change the meaning of the arguments. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com From ono at java.pl Tue Sep 16 15:25:16 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 21:25:16 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <128289242.dS4VVThf2B@stryke> References: <1409917844-28297-3-git-send-email-ono@java.pl> <2787116.mGKEBQAYYv@stryke> <128289242.dS4VVThf2B@stryke> Message-ID: > No? These functions are called by other codes and we can't just change the > meaning of the arguments. You are completely right. I am changing all stuff back, once I pass rpath as optional argument we can have exepath everywhere. Thanks for your feedback. Regards, -- Adam From ono at java.pl Tue Sep 16 16:43:33 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 22:43:33 +0200 Subject: [cmake-developers] [PATCH 3/5] Resolve & replace @rpath placeholders In-Reply-To: <1410885143-87513-3-git-send-email-ono@java.pl> References: <1410885143-87513-3-git-send-email-ono@java.pl> Message-ID: <1410900215-99370-3-git-send-email-ono@java.pl> This is done by gathering LC_RPATH commands for main bundle executable and using it for @rpath lookup in dependent frameworks. All functions that need to carry rpaths to now take optional argument. This enabled apps using @rpath to be bundled correctly, which will be necessary for upcoming Qt 5.4 that will use @rpath for all frameworks. --- Modules/BundleUtilities.cmake | 93 ++++++++++++++++++++++++++++++++++-------- Modules/GetPrerequisites.cmake | 36 ++++++++++------ 2 files changed, 99 insertions(+), 30 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 7e2b173..cc27310 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -19,6 +19,7 @@ # get_bundle_and_executable # get_bundle_all_executables # get_item_key +# get_item_rpaths # clear_bundle_keys # set_bundle_key_values # get_bundle_keys @@ -124,7 +125,7 @@ # :: # # SET_BUNDLE_KEY_VALUES( -# ) +# []) # # Add a key to the list (if necessary) for the given item. If added, # also set all the variables associated with that key. @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) endfunction() +function(get_item_rpaths item rpaths_var) + if(APPLE) + find_program(otool_cmd "otool") + mark_as_advanced(otool_cmd) + endif() + + if(otool_cmd) + execute_process( + COMMAND "${otool_cmd}" -l "${item}" + OUTPUT_VARIABLE load_cmds_ov + ) + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") + string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") + string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") + if(load_cmds_ov) + gp_append_unique(${rpaths_var} "${load_cmds_ov}") + endif() + endif() + + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) +endfunction() + + function(get_item_key item key_var) get_filename_component(item_name "${item}" NAME) if(WIN32) @@ -425,12 +449,14 @@ function(clear_bundle_keys keys_var) set(${key}_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_COPYFLAG PARENT_SCOPE) + set(${key}_RPATHS PARENT_SCOPE) endforeach() set(${keys_var} PARENT_SCOPE) endfunction() function(set_bundle_key_values keys_var context item exepath dirs copyflag) + set(rpaths "${ARGV6}") get_filename_component(item_name "${item}" NAME) get_item_key("${item}" key) @@ -440,10 +466,12 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) list(LENGTH ${keys_var} length_after) if(NOT length_before EQUAL length_after) - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item "${rpaths}") gp_item_default_embedded_path("${item}" default_embedded_path) + get_item_rpaths("${resolved_item}" item_rpaths) + if(item MATCHES "[^/]+\\.framework/") # For frameworks, construct the name under the embedded path from the # opening "${item_name}.framework/" to the closing "/${item_name}": @@ -479,6 +507,8 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) set(${key}_EMBEDDED_ITEM "${embedded_item}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" PARENT_SCOPE) set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) + set(${key}_RPATHS "${item_rpaths}" PARENT_SCOPE) + set(${key}_RDEP_RPATHS "${rpaths}" PARENT_SCOPE) else() #message("warning: item key '${key}' already in the list, subsequent references assumed identical to first") endif() @@ -499,18 +529,27 @@ function(get_bundle_keys app libs dirs keys_var) # get_bundle_all_executables("${bundle}" exes) + # Set keys for main executable first: + # + set_bundle_key_values(${keys_var} "${executable}" "${executable}" "${exepath}" "${dirs}" 0) + + # Get rpaths specified by main executable: + # + get_item_key("${executable}" executable_key) + set(main_rpaths "${${executable_key}_RPATHS}") + # For each extra lib, accumulate a key as well and then also accumulate # any of its prerequisites. (Extra libs are typically dynamically loaded # plugins: libraries that are prerequisites for full runtime functionality # but that do not show up in otool -L output...) # foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0 "${main_rpaths}") set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}" "${main_rpaths}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1 "${main_rpaths}") endforeach() endforeach() @@ -519,16 +558,27 @@ function(get_bundle_keys app libs dirs keys_var) # binaries in the bundle have been analyzed. # foreach(exe ${exes}) - # Add the exe itself to the keys: + # Main executable is scanned first above: # - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0) + if(NOT "${exe}" STREQUAL "${executable}") + # Add the exe itself to the keys: + # + set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0 "${main_rpaths}") + + # Get rpaths specified by executable: + # + get_item_key("${exe}" exe_key) + set(exe_rpaths "${main_rpaths}" "${${exe_key}_RPATHS}") + else() + set(exe_rpaths "${main_rpaths}") + endif() # Add each prerequisite to the keys: # set(prereqs "") - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}" "${exe_rpaths}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1 "${exe_rpaths}") endforeach() endforeach() @@ -542,6 +592,8 @@ function(get_bundle_keys app libs dirs keys_var) set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) + set(${key}_RDEP_RPATHS "${${key}_RDEP_RPATHS}" PARENT_SCOPE) endforeach() endif() endfunction() @@ -647,8 +699,10 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) message(FATAL_ERROR "cannot fixup an item that is not in the bundle...") endif() + set(rpaths "${${ikey}_RPATHS}" "${${ikey}_RDEP_RPATHS}") + set(prereqs "") - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}") + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}" "${rpaths}") set(changes "") @@ -668,12 +722,20 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) execute_process(COMMAND chmod u+w "${resolved_embedded_item}") endif() + foreach(rpath ${${ikey}_RPATHS}) + set(changes ${changes} -delete_rpath "${rpath}") + endforeach() + + if(${ikey}_EMBEDDED_ITEM) + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") + endif() + # Change this item's id and all of its references in one call # to install_name_tool: # - execute_process(COMMAND install_name_tool - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" - ) + if(changes) + execute_process(COMMAND install_name_tool ${changes} "${resolved_embedded_item}") + endif() endfunction() @@ -764,10 +826,8 @@ function(verify_bundle_prerequisites bundle result_var info_var) get_bundle_main_executable("${bundle}" main_bundle_exe) - file(GLOB_RECURSE file_list "${bundle}/*") + get_bundle_all_executables("${bundle}" file_list) foreach(f ${file_list}) - is_file_executable("${f}" is_executable) - if(is_executable) get_filename_component(exepath "${f}" PATH) math(EXPR count "${count} + 1") @@ -806,7 +866,6 @@ function(verify_bundle_prerequisites bundle result_var info_var) set(result 0) set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() - endif() endforeach() if(result) diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 49443e3..f8e1492 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -41,7 +41,7 @@ # :: # # GET_PREREQUISITES( -# ) +# []) # # Get the list of shared library files required by . The list # in the variable named should be empty on first @@ -113,7 +113,8 @@ # # :: # -# GP_RESOLVE_ITEM( ) +# GP_RESOLVE_ITEM( +# []) # # Resolve an item into an existing full path file. # @@ -122,7 +123,8 @@ # # :: # -# GP_RESOLVED_FILE_TYPE( ) +# GP_RESOLVED_FILE_TYPE( +# []) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named @@ -145,11 +147,12 @@ # # :: # -# GP_FILE_TYPE( ) +# GP_FILE_TYPE( []) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named -# . +# . Optional exepath is used to resolve executable relative +# library locations. # # Possible types are: # @@ -321,6 +324,7 @@ endfunction() function(gp_resolve_item context item exepath dirs resolved_item_var) set(resolved 0) set(resolved_item "${item}") + set(rpaths "${ARGV5}") # Is it already resolved? # @@ -375,9 +379,9 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) string(REPLACE "@rpath/" "" norpath_item "${item}") set(ri "ri-NOTFOUND") - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) + find_file(ri "${norpath_item}" ${exepath} ${dirs} ${rpaths} NO_DEFAULT_PATH) if(ri) - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") + #message(STATUS "info: 'find_file' in exepath/dirs/rpaths (${ri})") set(resolved 1) set(resolved_item "${ri}") set(ri "ri-NOTFOUND") @@ -471,6 +475,7 @@ endfunction() function(gp_resolved_file_type original_file file exepath dirs type_var) + set(rpaths "${ARGV5}") #message(STATUS "**") if(NOT IS_ABSOLUTE "${original_file}") @@ -489,7 +494,7 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) if(NOT is_embedded) if(NOT IS_ABSOLUTE "${file}") - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file) + gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file "${rpaths}") endif() string(TOLOWER "${original_file}" original_lower) @@ -596,12 +601,16 @@ endfunction() function(gp_file_type original_file file type_var) + if("${ARGV3}" STREQUAL "") + get_filename_component(exepath "${original_file}" PATH) + else() + set(exepath "${ARGV3}") + endif() + if(NOT IS_ABSOLUTE "${original_file}") message(STATUS "warning: gp_file_type expects absolute full path for first arg original_file") endif() - get_filename_component(exepath "${original_file}" PATH) - set(type "") gp_resolved_file_type("${original_file}" "${file}" "${exepath}" "" type) @@ -612,6 +621,7 @@ endfunction() function(get_prerequisites target prerequisites_var exclude_system recurse exepath dirs) set(verbose 0) set(eol_char "E") + set(rpaths "${ARGV6}") if(NOT IS_ABSOLUTE "${target}") message("warning: target '${target}' is not absolute...") @@ -834,7 +844,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(add_item AND ${exclude_system}) set(type "") - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type) + gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type "${rpaths}") if("${type}" STREQUAL "system") set(add_item 0) @@ -855,7 +865,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa # that the analysis tools can simply accept it as input. # if(NOT list_length_before_append EQUAL list_length_after_append) - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item "${rpaths}") set(unseen_prereqs ${unseen_prereqs} "${resolved_item}") endif() endif() @@ -874,7 +884,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(${recurse}) set(more_inputs ${unseen_prereqs}) foreach(input ${more_inputs}) - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}") + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}" "${rpaths}") endforeach() endif() -- 1.9.3 (Apple Git-50) From ono at java.pl Tue Sep 16 16:53:14 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 22:53:14 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <128289242.dS4VVThf2B@stryke> References: <1409917844-28297-3-git-send-email-ono@java.pl> <2787116.mGKEBQAYYv@stryke> <128289242.dS4VVThf2B@stryke> Message-ID: <92C864E8-9E7D-493C-BDE3-73F60D8C7FD5@java.pl> I have sent [PATCH 3/5] Resolve & replace @rpath placeholders which replaces previous 3/6 and obsoletes 4/6. Since it is getting messy like checking & fixing maybe stage account and topic branch would be more accurate. --Adam From clinton at elemtech.com Tue Sep 16 16:57:20 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Tue, 16 Sep 2014 14:57:20 -0600 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <92C864E8-9E7D-493C-BDE3-73F60D8C7FD5@java.pl> References: <1409917844-28297-3-git-send-email-ono@java.pl> <128289242.dS4VVThf2B@stryke> <92C864E8-9E7D-493C-BDE3-73F60D8C7FD5@java.pl> Message-ID: <12402410.NXmEnSXjYD@stryke> On Tuesday, September 16, 2014 10:53:14 PM Adam Strzelecki wrote: > I have sent [PATCH 3/5] Resolve & replace @rpath placeholders which replaces > previous 3/6 and obsoletes 4/6. > > Since it is getting messy like checking & fixing maybe stage account and > topic branch would be more accurate. > > --Adam Yes, it would be easier to review on stage or on github. Thanks. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com From ono at java.pl Tue Sep 16 17:01:33 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 23:01:33 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <12402410.NXmEnSXjYD@stryke> References: <1409917844-28297-3-git-send-email-ono@java.pl> <128289242.dS4VVThf2B@stryke> <92C864E8-9E7D-493C-BDE3-73F60D8C7FD5@java.pl> <12402410.NXmEnSXjYD@stryke> Message-ID: <6D2F3ECF-7F51-4458-9586-2FB028445878@java.pl> > Yes, it would be easier to review on stage or on github. Thanks. Here it is: https://github.com/nanoant/CMake/commits/fix-bundle-rpaths I would love to get stage access though ;) Cheers, -- Adam From bouffa at gmail.com Tue Sep 16 18:11:24 2014 From: bouffa at gmail.com (Mourad Boufarguine) Date: Wed, 17 Sep 2014 00:11:24 +0200 Subject: [cmake-developers] vs-nsight-tegra-generator topic Message-ID: On Tue, Sep 16, 2014 at 4:05 PM, Brad King wrote: > Hi Folks, > > This topic introduces support for generating VS project files > for the NVIDIA Nsight Tegra Visual Studio Edition, which then > builds for Android. I've merged it to 'next' for testing: > Hi Brad, I am really excited to see Nsight Tegra VS support being added to CMake, it will certainly help me (and others for sure) save so much some configuring manually my Android projects. Actually, few days ago I gave the patches you sent to the developer list back in July [1] a try. I had to make some dirty tweaks into the CMake code to make it build an Android application (java + native). So, today I tried the next branch with the new NSight stuff. It seems more accomplished than [1], but still doesn't work for me out of the box: I get an error when trying to link to an android "system" library (like GLESv1_CM , android, etc..). To reproduce the problem : target_link_libraries(myAndroidProject GLESv1_CM) I get this error when trying to build my Android application : 1> (...)/arm-linux-androideabi/bin/ld.bfd.exe: cannot find -l-lGLESv1_CM Please note the double "-l" in front of the library name. I took a look to the VS project properties, and found that in Linker>Input tab, in the "Additional Dependencies" the library name is prefixed by '-l' : -lGLESv1_CM Obviously, removing the leading '-l' in the VS project property window solves the problem (until the project gets generated again by CMake). Minor considerations: By comparing the generated vcxproj files with the manually configured ones I noticed these minor differences (I can't tell whether these have any consequences on the build) * Java files are declared using JCompile xml tags instead of None tags (using cmake) * some special files are declared using AndroidBuild xml tags (AndroidManifest.xml, build.xml, project.properties, proguard.cfg, res\values\strings.xml ...) My 2 cents, keep up the good work. Mourad [1] http://public.kitware.com/pipermail/cmake-developers/2014-July/010811.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton at elemtech.com Tue Sep 16 18:54:52 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Tue, 16 Sep 2014 16:54:52 -0600 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <6D2F3ECF-7F51-4458-9586-2FB028445878@java.pl> References: <1409917844-28297-3-git-send-email-ono@java.pl> <12402410.NXmEnSXjYD@stryke> <6D2F3ECF-7F51-4458-9586-2FB028445878@java.pl> Message-ID: <1579949.fFJZQIyjfv@stryke> On Tuesday, September 16, 2014 11:01:33 PM Adam Strzelecki wrote: > > Yes, it would be easier to review on stage or on github. Thanks. > > Here it is: > https://github.com/nanoant/CMake/commits/fix-bundle-rpaths > > I would love to get stage access though ;) > > Cheers, What is the new optional parameter to gp_file_type() used for? I don't see any code in your branch calling that function with the new parameter. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com From ono at java.pl Tue Sep 16 19:10:01 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 17 Sep 2014 01:10:01 +0200 Subject: [cmake-developers] Nice DMG layout for CMake OSX builds Message-ID: Hi, I've made simple background: https://dl.dropboxusercontent.com/u/64748870/CMakeDMGBackground.tif And together with my shell script for creating dmg with custom layout at: https://gist.github.com/nanoant/89237ad368d333795fc0 I have created installer that looks like that: So feel free to take & modify script above and TIFF file. Cheers, -- Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Test 4.png Type: image/png Size: 45986 bytes Desc: not available URL: From ono at java.pl Tue Sep 16 19:13:45 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 17 Sep 2014 01:13:45 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <1579949.fFJZQIyjfv@stryke> References: <1409917844-28297-3-git-send-email-ono@java.pl> <12402410.NXmEnSXjYD@stryke> <6D2F3ECF-7F51-4458-9586-2FB028445878@java.pl> <1579949.fFJZQIyjfv@stryke> Message-ID: > What is the new optional parameter to gp_file_type() used for? My intention was to pass exepath rather than take it from the path of original_file. But this is in fact not necessary. > I don't see any code in your branch calling that function with the new > parameter. You are right, I am not using that. So I can drop that change. --Adam From mantis at public.kitware.com Wed Sep 17 00:20:16 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 17 Sep 2014 00:20:16 -0400 Subject: [cmake-developers] [CMake 0015161]: FindProtobuf: Generated source not regenerated on library update Message-ID: <4aa62792b6ba296e93eb510cd0358549@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15161 ====================================================================== Reported By: hansmi Assigned To: ====================================================================== Project: CMake Issue ID: 15161 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-17 00:20 EDT Last Modified: 2014-09-17 00:20 EDT ====================================================================== Summary: FindProtobuf: Generated source not regenerated on library update Description: After updating from Protocol Buffers 2.5.0 to 2.6.0 compilation of the generated source failed: ?This file was generated by an older version of protoc which is incompatible with your Protocol Buffer headers. Please regenerate this file with a newer version of protoc.?. Turns out the source and headers generated by way of FindProtobuf.cmake:PROTOBUF_GENERATE_CPP aren't updated. Adding a dependency on the compiler executable fixes this issue. Proposed patch: $ diff -u FindProtobuf.cmake.orig FindProtobuf.cmake --- FindProtobuf.cmake.orig 2014-09-17 06:11:10.282377650 +0200 +++ FindProtobuf.cmake 2014-09-17 06:11:10.282377650 +0200 @@ -118,7 +118,7 @@ "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.h" COMMAND ${PROTOBUF_PROTOC_EXECUTABLE} ARGS --cpp_out ${CMAKE_CURRENT_BINARY_DIR} ${_protobuf_include_path} ${ABS_FIL} - DEPENDS ${ABS_FIL} + DEPENDS ${ABS_FIL} ${PROTOBUF_PROTOC_EXECUTABLE} COMMENT "Running C++ protocol buffer compiler on ${FIL}" VERBATIM ) endforeach() Steps to Reproduce: 1. Install Protocol Buffers 2.5.0 2. Generate source and header using 2.5.0's protoc binary 3. Install Protocol Buffers 2.6.0 4. Re-build source Additional Information: Workaround in case someone's affected by this and can't modify FindProtobuf.cmake in their environment: foreach(i ${PROTO_SRCS} ${PROTO_HDRS}) add_custom_command(OUTPUT ${i} DEPENDS ${PROTOBUF_PROTOC_EXECUTABLE} APPEND) endforeach() ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-17 00:20 hansmi New Issue ====================================================================== From helsing72 at gmail.com Wed Sep 17 02:42:27 2014 From: helsing72 at gmail.com (Mattias Helsing) Date: Wed, 17 Sep 2014 08:42:27 +0200 Subject: [cmake-developers] Suggest to not add libosgUI-NOTFOUND to OSG_INCLUDE_DIR if it wasn't required Message-ID: Hi all, I'm building against OpenScenGraph-3.0.1 AND OpenSceneGraph-3.3.3. While the latter have osgUI the former does not. My cmake scripts for the 3.0.1 build fail because the OPENSCENEGRAPH_INCLUDE_DIR gets populated with OSGUI_INCLUDE_DIR-NOTFOUND. I can solve this with for loops (remove all item containing NOTFOUND) but it's awkward. If I'm not requiring osgUI it shouldn't break my build. cheers Mattias -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Don-t-add-unfound-OSG-libs-if-they-weren-t-required.patch Type: text/x-patch Size: 1232 bytes Desc: not available URL: From ono at java.pl Wed Sep 17 07:54:29 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 17 Sep 2014 13:54:29 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison Message-ID: <1410954869-25450-1-git-send-email-ono@java.pl> This silents possible CMP0054 related warnings. --- Modules/FindCUDA.cmake | 14 +++++++------- Modules/FindCUDA/run_nvcc.cmake | 2 +- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake index 9348aa5..2e2b21c 100644 --- a/Modules/FindCUDA.cmake +++ b/Modules/FindCUDA.cmake @@ -894,15 +894,15 @@ macro(CUDA_GET_SOURCES_AND_OPTIONS _sources _cmake_options _options) set( ${_options} ) set( _found_options FALSE ) foreach(arg ${ARGN}) - if(arg STREQUAL "OPTIONS") + if("x${arg}" STREQUAL "xOPTIONS") set( _found_options TRUE ) elseif( - arg STREQUAL "WIN32" OR - arg STREQUAL "MACOSX_BUNDLE" OR - arg STREQUAL "EXCLUDE_FROM_ALL" OR - arg STREQUAL "STATIC" OR - arg STREQUAL "SHARED" OR - arg STREQUAL "MODULE" + "x${arg}" STREQUAL "xWIN32" OR + "x${arg}" STREQUAL "xMACOSX_BUNDLE" OR + "x${arg}" STREQUAL "xEXCLUDE_FROM_ALL" OR + "x${arg}" STREQUAL "xSTATIC" OR + "x${arg}" STREQUAL "xSHARED" OR + "x${arg}" STREQUAL "xMODULE" ) list(APPEND ${_cmake_options} ${arg}) else() diff --git a/Modules/FindCUDA/run_nvcc.cmake b/Modules/FindCUDA/run_nvcc.cmake index 58e0d31..abdd307 100644 --- a/Modules/FindCUDA/run_nvcc.cmake +++ b/Modules/FindCUDA/run_nvcc.cmake @@ -126,7 +126,7 @@ endif() # and other return variables are present after executing the process. macro(cuda_execute_process status command) set(_command ${command}) - if(NOT _command STREQUAL "COMMAND") + if(NOT "x${_command}" STREQUAL "xCOMMAND") message(FATAL_ERROR "Malformed call to cuda_execute_process. Missing COMMAND as second argument. (command = ${command})") endif() if(verbose) -- 1.9.3 (Apple Git-50) From eike at sf-mail.de Wed Sep 17 08:37:30 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 17 Sep 2014 14:37:30 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <1410954869-25450-1-git-send-email-ono@java.pl> References: <1410954869-25450-1-git-send-email-ono@java.pl> Message-ID: <7bb8ed244092eac42595b61f9686d874@sf-mail.de> Am 17.09.2014 13:54, schrieb Adam Strzelecki: > This silents possible CMP0054 related warnings. > --- > Modules/FindCUDA.cmake | 14 +++++++------- > Modules/FindCUDA/run_nvcc.cmake | 2 +- > 2 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake > index 9348aa5..2e2b21c 100644 > --- a/Modules/FindCUDA.cmake > +++ b/Modules/FindCUDA.cmake > @@ -894,15 +894,15 @@ macro(CUDA_GET_SOURCES_AND_OPTIONS _sources > _cmake_options _options) > set( ${_options} ) > set( _found_options FALSE ) > foreach(arg ${ARGN}) > - if(arg STREQUAL "OPTIONS") > + if("x${arg}" STREQUAL "xOPTIONS") [...] Wait, what? This is actually the opposite of what that policy is for, no? Adam, I don't blame you, just to get that said first. The question is: does this policy warning trigger far too often? What one actually wants is to write if(arg STREQUAL "OPTIONS") i.e. arg will get expanded, "OPTIONS" not. Changing everything away from that pattern will in fact make things worse, and will not help you if I introduce an xOPTION variable now. So, is this warning too noisy or are we doing something fundamentally wrong? Eike From nilsgladitz at gmail.com Wed Sep 17 08:48:19 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 17 Sep 2014 14:48:19 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <7bb8ed244092eac42595b61f9686d874@sf-mail.de> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> Message-ID: <54198313.5000001@gmail.com> On 09/17/2014 02:37 PM, Rolf Eike Beer wrote: > What one actually wants is to write > > if(arg STREQUAL "OPTIONS") > > i.e. arg will get expanded, "OPTIONS" not. Changing everything away from > that pattern will in fact make things worse, and will not help you if I > introduce an xOPTION variable now. So, is this warning too noisy or are > we doing something fundamentally wrong? One obvious case where it probably warns is if(arg STREQUAL "WIN32") Because WIN32 is also a variable with the value "1" on windows this check probably didn't actually do what it was intended to do with the old behavior. Maybe modules loaded from the cmake installation itself should implicitly have their policy version set to the current cmake version? Nils From robert.maynard at kitware.com Wed Sep 17 08:58:37 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 17 Sep 2014 08:58:37 -0400 Subject: [cmake-developers] Nice DMG layout for CMake OSX builds In-Reply-To: References: Message-ID: This looks amazing, thanks for the work. On Tue, Sep 16, 2014 at 7:10 PM, Adam Strzelecki wrote: > Hi, > > I've made simple background: > > https://dl.dropboxusercontent.com/u/64748870/CMakeDMGBackground.tif > > And together with my shell script for creating dmg with custom layout at: > > https://gist.github.com/nanoant/89237ad368d333795fc0 > > I have created installer that looks like that: > > > So feel free to take & modify script above and TIFF file. > > Cheers, > -- > Adam > > > > -- > > 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: Test 4.png Type: image/png Size: 45986 bytes Desc: not available URL: From ono at java.pl Wed Sep 17 09:24:46 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 17 Sep 2014 15:24:46 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <7bb8ed244092eac42595b61f9686d874@sf-mail.de> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> Message-ID: > Wait, what? This is actually the opposite of what that policy is for, no? Adam, I don't blame you, just to get that said first. The question is: does this policy warning trigger far too often? Yes, you are absolutely right. But the problem is that internal modules run in whatever policy is currently set. Few of them conditionally change policy for some short scopes. I was more less following how Brad has been fixing this issues on other modules, i.e.: e177e7affb10fc25b71d4c9d9796c9df7fcdb800 Honestly I would expect that all internal modules run in latest policy by default, or at least declare their policy in file header, but this is not a case. --Adam From ono at java.pl Wed Sep 17 09:27:18 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 17 Sep 2014 15:27:18 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <54198313.5000001@gmail.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> <54198313.5000001@gmail.com> Message-ID: <09A01904-0B0C-460B-87E7-23339ED9CE28@java.pl> > Maybe modules loaded from the cmake installation itself should implicitly have their policy version set to the current cmake version? Yes, this is what I was going to suggest too. All cmake files inside CMake's own Modules should have implicit latest policy. Although I'd recommend to have some (maybe hidden option) to override this implicit policy to some other value, so we can really check if existing modules don't raise any warnings. --Adam From ono at java.pl Wed Sep 17 09:58:49 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 17 Sep 2014 15:58:49 +0200 Subject: [cmake-developers] Nice DMG layout for CMake OSX builds In-Reply-To: References: Message-ID: > This looks amazing, thanks for the work. FYI I have updated TIF with sharper textual logo image taken from new website and bigger shorter and pixel aligned arrow so its shape does not overlay icon focus (once it is selected). The updated TIF file is at: https://dl.dropboxusercontent.com/u/64748870/CMakeDMGBackground.tif Source SVG file at: https://dl.dropboxusercontent.com/u/64748870/CMakeDMGBackground.svg Regards, --Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Test.png Type: image/png Size: 47000 bytes Desc: not available URL: From nilsgladitz at gmail.com Wed Sep 17 14:25:17 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 17 Sep 2014 20:25:17 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <54198313.5000001@gmail.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> <54198313.5000001@gmail.com> Message-ID: <5419D20D.9080108@gmail.com> On 17.09.2014 14:48, Nils Gladitz wrote: > > Maybe modules loaded from the cmake installation itself should > implicitly have their policy version set to the current cmake version? > I pushed "root-modules-set-policies-new" to stage which sets all policies to NEW for modules from cmake's own Modules directory if NO_POLICY_SCOPE is not used. I haven't merged it to next yet in case someone things this is the wrong thing to do in general. I figured since the new behavior only applies to cmake's own modules it should not require a policy. Nils From clinton at elemtech.com Wed Sep 17 15:29:43 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Wed, 17 Sep 2014 13:29:43 -0600 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: References: <1409917844-28297-3-git-send-email-ono@java.pl> <1579949.fFJZQIyjfv@stryke> Message-ID: <5905178.NbCzcQviLF@stryke> On Wednesday, September 17, 2014 01:13:45 AM Adam Strzelecki wrote: > > What is the new optional parameter to gp_file_type() used for? > > My intention was to pass exepath rather than take it from the path of > original_file. But this is in fact not necessary. > > I don't see any code in your branch calling that function with the new > > parameter. > > You are right, I am not using that. So I can drop that change. > > --Adam After that change is dropped, I give a +1 for the patch set. Thanks, Clint From mantis at public.kitware.com Thu Sep 18 00:55:24 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 18 Sep 2014 00:55:24 -0400 Subject: [cmake-developers] [CMake 0015162]: FindGettext.cmake documentation issue Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15162 ====================================================================== Reported By: vollmond Assigned To: ====================================================================== Project: CMake Issue ID: 15162 Category: CMake Reproducibility: always Severity: trivial Priority: low Status: new ====================================================================== Date Submitted: 2014-09-18 00:55 EDT Last Modified: 2014-09-18 00:55 EDT ====================================================================== Summary: FindGettext.cmake documentation issue Description: GETTEXT_PROCESS_POT => GETTEXT_PROCESS_POT_FILE ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-18 00:55 vollmond New Issue 2014-09-18 00:55 vollmond File Added: FindGettext.cmake.patch ====================================================================== From ono at java.pl Thu Sep 18 04:21:05 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 18 Sep 2014 10:21:05 +0200 Subject: [cmake-developers] [PATCH 3/5] Resolve & replace @rpath placeholders In-Reply-To: <1410900215-99370-3-git-send-email-ono@java.pl> References: <1410900215-99370-3-git-send-email-ono@java.pl> Message-ID: <1411028467-47190-3-git-send-email-ono@java.pl> This is done by gathering LC_RPATH commands for main bundle executable and using it for @rpath lookup in dependent frameworks. All functions that need to carry rpaths to now take optional argument. This enabled apps using @rpath to be bundled correctly, which will be necessary for upcoming Qt 5.4 that will use @rpath for all frameworks. --- Modules/BundleUtilities.cmake | 93 ++++++++++++++++++++++++++++++++++-------- Modules/GetPrerequisites.cmake | 23 +++++++---- 2 files changed, 90 insertions(+), 26 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 7e2b173..cc27310 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -19,6 +19,7 @@ # get_bundle_and_executable # get_bundle_all_executables # get_item_key +# get_item_rpaths # clear_bundle_keys # set_bundle_key_values # get_bundle_keys @@ -124,7 +125,7 @@ # :: # # SET_BUNDLE_KEY_VALUES( -# ) +# []) # # Add a key to the list (if necessary) for the given item. If added, # also set all the variables associated with that key. @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) endfunction() +function(get_item_rpaths item rpaths_var) + if(APPLE) + find_program(otool_cmd "otool") + mark_as_advanced(otool_cmd) + endif() + + if(otool_cmd) + execute_process( + COMMAND "${otool_cmd}" -l "${item}" + OUTPUT_VARIABLE load_cmds_ov + ) + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") + string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") + string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") + if(load_cmds_ov) + gp_append_unique(${rpaths_var} "${load_cmds_ov}") + endif() + endif() + + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) +endfunction() + + function(get_item_key item key_var) get_filename_component(item_name "${item}" NAME) if(WIN32) @@ -425,12 +449,14 @@ function(clear_bundle_keys keys_var) set(${key}_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_COPYFLAG PARENT_SCOPE) + set(${key}_RPATHS PARENT_SCOPE) endforeach() set(${keys_var} PARENT_SCOPE) endfunction() function(set_bundle_key_values keys_var context item exepath dirs copyflag) + set(rpaths "${ARGV6}") get_filename_component(item_name "${item}" NAME) get_item_key("${item}" key) @@ -440,10 +466,12 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) list(LENGTH ${keys_var} length_after) if(NOT length_before EQUAL length_after) - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item "${rpaths}") gp_item_default_embedded_path("${item}" default_embedded_path) + get_item_rpaths("${resolved_item}" item_rpaths) + if(item MATCHES "[^/]+\\.framework/") # For frameworks, construct the name under the embedded path from the # opening "${item_name}.framework/" to the closing "/${item_name}": @@ -479,6 +507,8 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) set(${key}_EMBEDDED_ITEM "${embedded_item}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" PARENT_SCOPE) set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) + set(${key}_RPATHS "${item_rpaths}" PARENT_SCOPE) + set(${key}_RDEP_RPATHS "${rpaths}" PARENT_SCOPE) else() #message("warning: item key '${key}' already in the list, subsequent references assumed identical to first") endif() @@ -499,18 +529,27 @@ function(get_bundle_keys app libs dirs keys_var) # get_bundle_all_executables("${bundle}" exes) + # Set keys for main executable first: + # + set_bundle_key_values(${keys_var} "${executable}" "${executable}" "${exepath}" "${dirs}" 0) + + # Get rpaths specified by main executable: + # + get_item_key("${executable}" executable_key) + set(main_rpaths "${${executable_key}_RPATHS}") + # For each extra lib, accumulate a key as well and then also accumulate # any of its prerequisites. (Extra libs are typically dynamically loaded # plugins: libraries that are prerequisites for full runtime functionality # but that do not show up in otool -L output...) # foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0 "${main_rpaths}") set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}" "${main_rpaths}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1 "${main_rpaths}") endforeach() endforeach() @@ -519,16 +558,27 @@ function(get_bundle_keys app libs dirs keys_var) # binaries in the bundle have been analyzed. # foreach(exe ${exes}) - # Add the exe itself to the keys: + # Main executable is scanned first above: # - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0) + if(NOT "${exe}" STREQUAL "${executable}") + # Add the exe itself to the keys: + # + set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0 "${main_rpaths}") + + # Get rpaths specified by executable: + # + get_item_key("${exe}" exe_key) + set(exe_rpaths "${main_rpaths}" "${${exe_key}_RPATHS}") + else() + set(exe_rpaths "${main_rpaths}") + endif() # Add each prerequisite to the keys: # set(prereqs "") - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}" "${exe_rpaths}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1 "${exe_rpaths}") endforeach() endforeach() @@ -542,6 +592,8 @@ function(get_bundle_keys app libs dirs keys_var) set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) + set(${key}_RDEP_RPATHS "${${key}_RDEP_RPATHS}" PARENT_SCOPE) endforeach() endif() endfunction() @@ -647,8 +699,10 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) message(FATAL_ERROR "cannot fixup an item that is not in the bundle...") endif() + set(rpaths "${${ikey}_RPATHS}" "${${ikey}_RDEP_RPATHS}") + set(prereqs "") - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}") + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}" "${rpaths}") set(changes "") @@ -668,12 +722,20 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) execute_process(COMMAND chmod u+w "${resolved_embedded_item}") endif() + foreach(rpath ${${ikey}_RPATHS}) + set(changes ${changes} -delete_rpath "${rpath}") + endforeach() + + if(${ikey}_EMBEDDED_ITEM) + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") + endif() + # Change this item's id and all of its references in one call # to install_name_tool: # - execute_process(COMMAND install_name_tool - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" - ) + if(changes) + execute_process(COMMAND install_name_tool ${changes} "${resolved_embedded_item}") + endif() endfunction() @@ -764,10 +826,8 @@ function(verify_bundle_prerequisites bundle result_var info_var) get_bundle_main_executable("${bundle}" main_bundle_exe) - file(GLOB_RECURSE file_list "${bundle}/*") + get_bundle_all_executables("${bundle}" file_list) foreach(f ${file_list}) - is_file_executable("${f}" is_executable) - if(is_executable) get_filename_component(exepath "${f}" PATH) math(EXPR count "${count} + 1") @@ -806,7 +866,6 @@ function(verify_bundle_prerequisites bundle result_var info_var) set(result 0) set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() - endif() endforeach() if(result) diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 49443e3..9963517 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -41,7 +41,7 @@ # :: # # GET_PREREQUISITES( -# ) +# []) # # Get the list of shared library files required by . The list # in the variable named should be empty on first @@ -113,7 +113,8 @@ # # :: # -# GP_RESOLVE_ITEM( ) +# GP_RESOLVE_ITEM( +# []) # # Resolve an item into an existing full path file. # @@ -122,7 +123,8 @@ # # :: # -# GP_RESOLVED_FILE_TYPE( ) +# GP_RESOLVED_FILE_TYPE( +# []) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named @@ -321,6 +323,7 @@ endfunction() function(gp_resolve_item context item exepath dirs resolved_item_var) set(resolved 0) set(resolved_item "${item}") + set(rpaths "${ARGV5}") # Is it already resolved? # @@ -375,9 +378,9 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) string(REPLACE "@rpath/" "" norpath_item "${item}") set(ri "ri-NOTFOUND") - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) + find_file(ri "${norpath_item}" ${exepath} ${dirs} ${rpaths} NO_DEFAULT_PATH) if(ri) - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") + #message(STATUS "info: 'find_file' in exepath/dirs/rpaths (${ri})") set(resolved 1) set(resolved_item "${ri}") set(ri "ri-NOTFOUND") @@ -471,6 +474,7 @@ endfunction() function(gp_resolved_file_type original_file file exepath dirs type_var) + set(rpaths "${ARGV5}") #message(STATUS "**") if(NOT IS_ABSOLUTE "${original_file}") @@ -489,7 +493,7 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) if(NOT is_embedded) if(NOT IS_ABSOLUTE "${file}") - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file) + gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file "${rpaths}") endif() string(TOLOWER "${original_file}" original_lower) @@ -612,6 +616,7 @@ endfunction() function(get_prerequisites target prerequisites_var exclude_system recurse exepath dirs) set(verbose 0) set(eol_char "E") + set(rpaths "${ARGV6}") if(NOT IS_ABSOLUTE "${target}") message("warning: target '${target}' is not absolute...") @@ -834,7 +839,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(add_item AND ${exclude_system}) set(type "") - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type) + gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type "${rpaths}") if("${type}" STREQUAL "system") set(add_item 0) @@ -855,7 +860,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa # that the analysis tools can simply accept it as input. # if(NOT list_length_before_append EQUAL list_length_after_append) - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item "${rpaths}") set(unseen_prereqs ${unseen_prereqs} "${resolved_item}") endif() endif() @@ -874,7 +879,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(${recurse}) set(more_inputs ${unseen_prereqs}) foreach(input ${more_inputs}) - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}") + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}" "${rpaths}") endforeach() endif() -- 1.9.3 (Apple Git-50) From ono at java.pl Thu Sep 18 04:22:05 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 18 Sep 2014 10:22:05 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <5905178.NbCzcQviLF@stryke> References: <1409917844-28297-3-git-send-email-ono@java.pl> <1579949.fFJZQIyjfv@stryke> <5905178.NbCzcQviLF@stryke> Message-ID: > After that change is dropped, I give a +1 for the patch set. Done, both in attached 3/5 patch and GitHub branch of mine. --Adam From brad.king at kitware.com Thu Sep 18 09:13:36 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 18 Sep 2014 09:13:36 -0400 Subject: [cmake-developers] Suggest to not add libosgUI-NOTFOUND to OSG_INCLUDE_DIR if it wasn't required In-Reply-To: References: Message-ID: <541ADA80.203@kitware.com> On 09/17/2014 02:42 AM, Mattias Helsing wrote: > If I'm not requiring osgUI it shouldn't break my build. Applied, thanks: FindOpenSceneGraph: Do not add unfound OSG libs if not required http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b683da3e -Brad From brad.king at kitware.com Thu Sep 18 10:05:39 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 18 Sep 2014 10:05:39 -0400 Subject: [cmake-developers] policies in CMake builtin modules (was: FindCUDA: Wrap keyword in if() string comparison) In-Reply-To: <5419D20D.9080108@gmail.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> <54198313.5000001@gmail.com> <5419D20D.9080108@gmail.com> Message-ID: <541AE6B3.1030208@kitware.com> On 09/17/2014 02:25 PM, Nils Gladitz wrote: > I pushed "root-modules-set-policies-new" to stage which sets all > policies to NEW for modules from cmake's own Modules directory if > NO_POLICY_SCOPE is not used. A minor comment on the impl: use cmSystemTools::GetCMakeRoot instead of looking up CMAKE_ROOT. However, I do not think this approach will work well in general. We do not have extensive testing covering all functionality of the builtin modules. We do not actually know that all the modules will work with every policy set to NEW right away. Typically authors of projects that use the modules will report bugs if things break when the projects set policies to NEW. Meanwhile at least existing projects keep building with the OLD policy behavior. Modules on an individual basis could use cmake_policy(PUSH/POP) and cmake_policy(SET) to get NEW behavior for specific policies that they trigger. -Brad From nilsgladitz at gmail.com Thu Sep 18 10:20:41 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 18 Sep 2014 16:20:41 +0200 Subject: [cmake-developers] policies in CMake builtin modules In-Reply-To: <541AE6B3.1030208@kitware.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> <54198313.5000001@gmail.com> <5419D20D.9080108@gmail.com> <541AE6B3.1030208@kitware.com> Message-ID: <541AEA39.6060706@gmail.com> On 09/18/2014 04:05 PM, Brad King wrote: > On 09/17/2014 02:25 PM, Nils Gladitz wrote: >> I pushed "root-modules-set-policies-new" to stage which sets all >> policies to NEW for modules from cmake's own Modules directory if >> NO_POLICY_SCOPE is not used. > > A minor comment on the impl: use cmSystemTools::GetCMakeRoot > instead of looking up CMAKE_ROOT. Thanks, I'll try to remember that for next time. I copied the use of CMAKE_ROOT from cmMakefile::GetModulesFile(). > However, I do not think this approach will work well in general. > We do not have extensive testing covering all functionality of > the builtin modules. We do not actually know that all the > modules will work with every policy set to NEW right away. > Typically authors of projects that use the modules will report > bugs if things break when the projects set policies to NEW. > Meanwhile at least existing projects keep building with the > OLD policy behavior. OK, thanks. I unstaged the topic. Nils From mantis at public.kitware.com Thu Sep 18 11:44:10 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 18 Sep 2014 11:44:10 -0400 Subject: [cmake-developers] [CMake 0015163]: wrong permissions on base files with nonstandard umask setting Message-ID: <0a15351488bf785a61d91e75296dcc57@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15163 ====================================================================== Reported By: Ilya Rusyanov Assigned To: ====================================================================== Project: CMake Issue ID: 15163 Category: (No Category) Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-18 11:44 EDT Last Modified: 2014-09-18 11:44 EDT ====================================================================== Summary: wrong permissions on base files with nonstandard umask setting Description: If umask is different from 022, CPack will generate wrong permission on base directories. Steps to Reproduce: umask 027 cmake ../src make cpack -G DEB dpkg -c test.deb drwxr-x--- root/root 0 2014-09-18 19:40 ./usr/ drwxr-x--- root/root 0 2014-09-18 19:40 ./usr/share/ drwxr-x--- root/root 0 2014-09-18 19:40 ./usr/share/testproj/ drwxr-x--- root/root 0 2014-09-18 19:40 ./usr/share/testproj/data/ drwxr-xr-x root/root 0 2014-09-18 19:40 ./usr/share/testproj/data/180-188-189/ -rw-r--r-- root/root 16 2014-09-18 15:22 ./usr/share/testproj/data/180-188-189/general.ini Additional Information: Please notice directory permissions on /usr, /usr/share, /usr/share/testproj, /usr/share/testproj/data. Everything is fine with supplied inner directories and files. INSTALL command is not given any PERMISSIONS options, and, as documentation says they should be default: 755 for directories and 644 for regular files. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-18 11:44 Ilya Rusyanov New Issue ====================================================================== From pascal.bach at siemens.com Thu Sep 18 12:03:50 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Thu, 18 Sep 2014 18:03:50 +0200 Subject: [cmake-developers] [PATCH] WINCE: Add toolchain documentation for Windows CE Message-ID: <1411056230-30313-1-git-send-email-pascal.bach@siemens.com> --- Help/manual/cmake-toolchains.7.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/Help/manual/cmake-toolchains.7.rst b/Help/manual/cmake-toolchains.7.rst index f36a43c..095a43f 100644 --- a/Help/manual/cmake-toolchains.7.rst +++ b/Help/manual/cmake-toolchains.7.rst @@ -174,5 +174,25 @@ toolchain which will be used by the compiler driver. The :variable:`CMAKE__COMPILER_EXTERNAL_TOOLCHAIN` variable can be set in a toolchain file to pass the path to the compiler driver. +Cross compiling for Windows CE requires the corresponding SDK being installed on +your system. These SDKs are usually installed under: `C:\\Program Files (x86)\\Windows CE Tools\\SDKs` + +The :variable:`CMAKE_GENERATOR_PLATFORM` tells the generator which SDK to use. +Further :variable:`CMAKE_SYSTEM_VERSION` tells the generator what version of Windows CE to use. +Currently version 8.0 (Windows Embedded Compact 2013) is supported out of the box. Other versions +my require to set :variable:`CMAKE_GENERATOR_TOOLSET` to the correct value. + +A toolchain file for Windows CE may look like this: + +.. code-block:: cmake + + set(CMAKE_SYSTEM_NAME "WindowsCE") + + set(CMAKE_SYSTEM_VERSION "8.0") + set(CMAKE_SYSTEM_PROCESSOR "arm" ) + + set(CMAKE_GENERATOR_TOOLSET "CE800") # Can be omitted for 8.0 + set(CMAKE_GENERATOR_PLATFORM "SDK_AM335X_SK_WEC2013_V310") + The :variable:`CMAKE_CROSSCOMPILING` variable is set to true when CMake is cross-compiling. -- 1.7.10.4 From ono at java.pl Thu Sep 18 12:15:51 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 18 Sep 2014 18:15:51 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: References: <1409917844-28297-3-git-send-email-ono@java.pl> <1579949.fFJZQIyjfv@stryke> <5905178.NbCzcQviLF@stryke> Message-ID: FYI I pushed stage/fix-OSX-bundle-rpaths-and-Qt5 topic for final review. Regards, -- Adam From ono at java.pl Thu Sep 18 13:00:52 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 18 Sep 2014 19:00:52 +0200 Subject: [cmake-developers] policies in CMake builtin modules In-Reply-To: <541AEA39.6060706@gmail.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> <54198313.5000001@gmail.com> <5419D20D.9080108@gmail.com> <541AE6B3.1030208@kitware.com> <541AEA39.6060706@gmail.com> Message-ID: <946430CD-55F6-4F15-85EE-7E2991233957@java.pl> If I understand correctly all modules included via include/find_package have implicit POLICY PUSH and POP at the EOF. Wouldn't it be reasonable to require all internal .cmake files to begin with: cmake_policy(VERSION 3.1) # or whatever version the module was tested against Then before next release all of these should be checked against new policies and upgraded to: cmake_policy(VERSION 3.2) # next release version Then we can safely drop all these fancy if("x${var}" STREQUAL "xVALUE") in favor of if(var STREQUAL "VALUE") and improve scripts readability, rather that do PUSHes and POPs in various places. Of course I am aware that such task needs lot of work, however I think this should be consequence of introducing CMP0054. --Adam From clinton at elemtech.com Thu Sep 18 13:01:53 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Thu, 18 Sep 2014 11:01:53 -0600 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: References: <1409917844-28297-3-git-send-email-ono@java.pl> Message-ID: <2024754.uYdjdX8BQq@stryke> On Thursday, September 18, 2014 06:15:51 PM Adam Strzelecki wrote: > FYI I pushed stage/fix-OSX-bundle-rpaths-and-Qt5 topic for final review. > > Regards, Does the functionality you add allow us to modify CMake/Tests/BundleUtilities/CMakeLists.txt such that the last part in the tests where @rpath is used can be changed to separate the binaries into bin/ and lib/ directories instead of everything in one directory. I assume so since you added the the ability to extract rpaths from a binary. Then eventually, someone can add the same capability for Linux. I'm hoping the parameter you added to functions in GetPrerequisite.cmake is not OS X specific (at the moment, it appears so). Thanks, - Clint From brad.king at kitware.com Thu Sep 18 13:39:30 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 18 Sep 2014 13:39:30 -0400 Subject: [cmake-developers] policies in CMake builtin modules In-Reply-To: <946430CD-55F6-4F15-85EE-7E2991233957@java.pl> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> <54198313.5000001@gmail.com> <5419D20D.9080108@gmail.com> <541AE6B3.1030208@kitware.com> <541AEA39.6060706@gmail.com> <946430CD-55F6-4F15-85EE-7E2991233957@java.pl> Message-ID: <541B18D2.6020106@kitware.com> On 09/18/2014 01:00 PM, Adam Strzelecki wrote: > If I understand correctly all modules included via > include/find_package have implicit POLICY PUSH and POP Yes. > at the EOF. Wouldn't it be reasonable to require all > internal .cmake files to begin with: > > cmake_policy(VERSION 3.1) # or whatever version the module was tested against > > Then before next release all of these should be checked > against new policies and upgraded to: > > cmake_policy(VERSION 3.2) # next release version Like Nils' proposal, this will not be reliable without full coverage of module functionality in the test suite (which is very hard to do because every find module depends on another external package). It could be done manually on a per-module basis. > Then we can safely drop all these fancy > if("x${var}" STREQUAL "xVALUE") in favor of if(var STREQUAL "VALUE") This can be done with just cmake_policy(SET CMP0054 NEW) at the top of any module that has been ported accordingly. Most policies do not affect CMake syntax, but several have come before this one and there are very few modules that make any explicit mention of cmake_policy. In most cases the module code can be written to work with any policy settings. On 09/17/2014 08:37 AM, Rolf Eike Beer wrote: > Wait, what? This is actually the opposite of what that policy is for, This is true, but will only affect modules that come with CMake that must work regardless of the cmake_minimum_required(VERSION) used in the project. Once a release of CMake contains this policy, project code can require that version of CMake when it is ready and then use the nicer if() tests. -Brad From brad.king at kitware.com Thu Sep 18 13:43:03 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 18 Sep 2014 13:43:03 -0400 Subject: [cmake-developers] [PATCH] WINCE: Add toolchain documentation for Windows CE In-Reply-To: <1411056230-30313-1-git-send-email-pascal.bach@siemens.com> References: <1411056230-30313-1-git-send-email-pascal.bach@siemens.com> Message-ID: <541B19A7.4000903@kitware.com> On 09/18/2014 12:03 PM, Pascal Bach wrote: > diff --git a/Help/manual/cmake-toolchains.7.rst b/Help/manual/cmake-toolchains.7.rst > index f36a43c..095a43f 100644 > --- a/Help/manual/cmake-toolchains.7.rst > +++ b/Help/manual/cmake-toolchains.7.rst > @@ -174,5 +174,25 @@ toolchain which will be used by the compiler driver. The > :variable:`CMAKE__COMPILER_EXTERNAL_TOOLCHAIN` variable can be set in a > toolchain file to pass the path to the compiler driver. > > +Cross compiling for Windows CE requires the corresponding SDK being installed on > +your system. These SDKs are usually installed under: `C:\\Program Files (x86)\\Windows CE Tools\\SDKs` Over time the "Cross Compiling" section of this manual will gain information about various target platforms. We should add a subsection header for each platform, e.g. Cross Compiling to Windows CE ----------------------------- If you don't mind, please precede this patch with a change that adds such subsection headers for the Clang and QCC cases. Thanks, -Brad From aleixpol at kde.org Thu Sep 18 20:10:12 2014 From: aleixpol at kde.org (Aleix Pol) Date: Fri, 19 Sep 2014 02:10:12 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <540DA65F.4030501@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> Message-ID: On Mon, Sep 8, 2014 at 2:51 PM, Brad King wrote: > On 09/03/2014 12:12 PM, Aleix Pol wrote: > > On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf wrote: > >> I still don't understand why this shouldn't be an additional > ExtraGenerator. > > > > Because it's not possible to change the generator of a build directory > > once it's set up. You need to nuke it and re-create it. > [snip] > On 09/01/2014 07:27 PM, Aleix Pol wrote: > > Ok, how does it sound if we have a variable, such as > CMAKE_EXPORT_COMPILE_COMMANDS? > > Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. > > A control variable like that sounds good to me. The purpose looks very > similar to CMAKE_EXPORT_COMPILE_COMMANDS, but is distinct enough to have > its own control. > > 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 > I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to enable the generation of the file. I also renamed the file to ProjectTargets.json. http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch Does it look better like this? Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Fri Sep 19 01:10:45 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 19 Sep 2014 01:10:45 -0400 Subject: [cmake-developers] [CMake 0015164]: Relative Value for CMAKE_TOOLCHAIN_FILE Does Not Work Under PowerShell Message-ID: <37c7863d68618e89e514aa9df1f45546@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15164 ====================================================================== Reported By: Janne R?nkk? Assigned To: ====================================================================== Project: CMake Issue ID: 15164 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-19 01:10 EDT Last Modified: 2014-09-19 01:10 EDT ====================================================================== Summary: Relative Value for CMAKE_TOOLCHAIN_FILE Does Not Work Under PowerShell Description: The toolchain file is not handled properly under PowerShell if the toolchain file path is relative. The issues (I have noticed so far): - CMAKE_SYSTEM_NAME is not set properly - There is warnings about include with empty file name (this seems to be the reason that at least CMAKE_SYSTEM_NAME is not set correctly) The issue is present at least in versions 3.0.0-3.0.2 (these are the version I tested). Steps to Reproduce: In PowerShell: unzip project.zip cd project mkdir build cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake -G Ninja .. Additional Information: On PowerShell with relative path: ================================= PS C:\Users\janne\project\build> cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake -G Ninja .. CMake Warning (dev) at build/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include): include() given empty file name (ignored). Call Stack (most recent call first): CMakeLists.txt:3 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- The C compiler identification is GNU 4.7.3 -- The CXX compiler identification is GNU 4.7.3 -- Check for working C compiler using: Ninja CMake Warning (dev) at C:/Users/janne/project/build/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include): include() given empty file name (ignored). Call Stack (most recent call first): CMakeLists.txt:2 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info CMake Warning (dev) at C:/Users/janne/project/build/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include): include() given empty file name (ignored). Call Stack (most recent call first): CMakeLists.txt:2 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Ninja CMake Warning (dev) at C:/Users/janne/project/build/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include): include() given empty file name (ignored). Call Stack (most recent call first): CMakeLists.txt:2 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info CMake Warning (dev) at C:/Users/janne/project/build/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include): include() given empty file name (ignored). Call Stack (most recent call first): CMakeLists.txt:2 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- Detecting CXX compiler ABI info - done CMake system name: Windows -- Configuring done -- Generating done -- Build files have been written to: C:/Users/janne/project/build ## Note the line "CMake system name: Windows" On PowerShell with absolute path: ================================= PS C:\Users\janne\project\build> cmake -DCMAKE_TOOLCHAIN_FILE=C:/users/janne/toolchain.cmake -G Ninja .. -- The C compiler identification is GNU 4.7.3 -- The CXX compiler identification is GNU 4.7.3 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake system name: Linux -- Configuring done -- Generating done -- Build files have been written to: C:/Users/janne/project/build On cmd.exe with relative path: ============================== C:\Users\janne\project\build>cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake -G Ninja .. -- The C compiler identification is GNU 4.7.3 -- The CXX compiler identification is GNU 4.7.3 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake system name: Linux -- Configuring done -- Generating done -- Build files have been written to: C:/Users/janne/project/build On cmd.exe with absolute path: ============================== C:\Users\janne\project\build>cmake -DCMAKE_TOOLCHAIN_FILE=C:/users/janne/toolchain.cmake -G Ninja .. -- The C compiler identification is GNU 4.7.3 -- The CXX compiler identification is GNU 4.7.3 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake system name: Linux -- Configuring done -- Generating done -- Build files have been written to: C:/Users/janne/project/build ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-19 01:10 Janne R?nkk? New Issue 2014-09-19 01:10 Janne R?nkk? File Added: project.zip ====================================================================== From jamesbigler at gmail.com Fri Sep 19 01:30:59 2014 From: jamesbigler at gmail.com (James Bigler) Date: Thu, 18 Sep 2014 23:30:59 -0600 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <1410954869-25450-1-git-send-email-ono@java.pl> References: <1410954869-25450-1-git-send-email-ono@java.pl> Message-ID: Could someone please explain to me why we need to change all the if statements to look super ugly? Expanding "WIN32" to dereference the value is just a recipe for confusion. Honestly I would prefer if there was a policy to never deference variables in if statements and replace the if's with: if ("${arg}" STREQAL "WIN32") This way there isn't any trickery involved with whether "WIN32" is string or a variable. By the way creating a variable that has the same string as arguments to command (see add_executable) is an unfortunate dirtying of the language ("WIN32" is a variable here, but over here it's an argument e.g. string). James On Wed, Sep 17, 2014 at 5:54 AM, Adam Strzelecki wrote: > This silents possible CMP0054 related warnings. > --- > Modules/FindCUDA.cmake | 14 +++++++------- > Modules/FindCUDA/run_nvcc.cmake | 2 +- > 2 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake > index 9348aa5..2e2b21c 100644 > --- a/Modules/FindCUDA.cmake > +++ b/Modules/FindCUDA.cmake > @@ -894,15 +894,15 @@ macro(CUDA_GET_SOURCES_AND_OPTIONS _sources > _cmake_options _options) > set( ${_options} ) > set( _found_options FALSE ) > foreach(arg ${ARGN}) > - if(arg STREQUAL "OPTIONS") > + if("x${arg}" STREQUAL "xOPTIONS") > set( _found_options TRUE ) > elseif( > - arg STREQUAL "WIN32" OR > - arg STREQUAL "MACOSX_BUNDLE" OR > - arg STREQUAL "EXCLUDE_FROM_ALL" OR > - arg STREQUAL "STATIC" OR > - arg STREQUAL "SHARED" OR > - arg STREQUAL "MODULE" > + "x${arg}" STREQUAL "xWIN32" OR > + "x${arg}" STREQUAL "xMACOSX_BUNDLE" OR > + "x${arg}" STREQUAL "xEXCLUDE_FROM_ALL" OR > + "x${arg}" STREQUAL "xSTATIC" OR > + "x${arg}" STREQUAL "xSHARED" OR > + "x${arg}" STREQUAL "xMODULE" > ) > list(APPEND ${_cmake_options} ${arg}) > else() > diff --git a/Modules/FindCUDA/run_nvcc.cmake > b/Modules/FindCUDA/run_nvcc.cmake > index 58e0d31..abdd307 100644 > --- a/Modules/FindCUDA/run_nvcc.cmake > +++ b/Modules/FindCUDA/run_nvcc.cmake > @@ -126,7 +126,7 @@ endif() > # and other return variables are present after executing the process. > macro(cuda_execute_process status command) > set(_command ${command}) > - if(NOT _command STREQUAL "COMMAND") > + if(NOT "x${_command}" STREQUAL "xCOMMAND") > message(FATAL_ERROR "Malformed call to cuda_execute_process. Missing > COMMAND as second argument. (command = ${command})") > endif() > if(verbose) > -- > 1.9.3 (Apple Git-50) > > -- > > 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 nilsgladitz at gmail.com Fri Sep 19 02:31:19 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 19 Sep 2014 08:31:19 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: References: <1410954869-25450-1-git-send-email-ono@java.pl> Message-ID: <541BCDB7.2050004@gmail.com> On 09/19/2014 07:30 AM, James Bigler wrote: > Could someone please explain to me why we need to change all the if > statements to look super ugly? It sounds like you might have missed the follow up within this thread. > Expanding "WIN32" to dereference the value is just a recipe for > confusion. Honestly I would prefer if there was a policy to never > deference variables in if statements and replace the if's with: > > if ("${arg}" STREQAL "WIN32") To recap I did introduce a policy similar to this: http://www.cmake.org/cmake/help/git-master/policy/CMP0054.html This is paradoxically also the reason for the proposed "super ugly" changes. The policy not only changes the behavior when set to NEW it also warns about ambiguities like "WIN32" in an if statement while using the OLD behavior. Since the policy may or may not be active (depending on the user's project) they might be using FindCUDA.cmake with CMP0054 set to NEW or OLD. To get identical (and warning free) behavior irregardless of the current policy setting Adam added the proposed ugliness. Afterwards I proposed setting all policies to NEW for internal CMake modules but Brad argues that since there is no proper coverage for find modules within the test suite this might have unintended consequences. As Brad further stated you could set CMP0054 to NEW explicitly within FindCUDA.cmake (so that the ugliness could be avoided) if you can verify that this does not break the module for existing projects. Nils From malak.jiri at gmail.com Fri Sep 19 02:59:36 2014 From: malak.jiri at gmail.com (Jiri Malak) Date: Fri, 19 Sep 2014 08:59:36 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release Message-ID: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> Hi, I did a several fixes to CMake related to Open Watcom which were accepteed to current development branch a few month ago. Up to now they were not included to official version 3.0 branch. What I must do to be include or I doing something wrong? Regards Jiri From nilsgladitz at gmail.com Fri Sep 19 03:13:32 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 19 Sep 2014 09:13:32 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> References: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> Message-ID: <541BD79C.8010304@gmail.com> On 09/19/2014 08:59 AM, Jiri Malak wrote: > I did a several fixes to CMake related to Open Watcom which were accepteed to current development > branch a few month ago. > Up to now they were not included to official version 3.0 branch. > What I must do to be include or I doing something wrong? The current "master" branch is the basis for a 3.1 release. Only few changes are backported for a 3.0.x release (e.g. regressions). Nils From ono at java.pl Fri Sep 19 06:05:23 2014 From: ono at java.pl (Adam Strzelecki) Date: Fri, 19 Sep 2014 12:05:23 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <541BCDB7.2050004@gmail.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> Message-ID: > Since the policy may or may not be active (depending on the user's project) they might be using FindCUDA.cmake with CMP0054 set to NEW or OLD. To get identical (and warning free) behavior irregardless of the current policy setting Adam added the proposed ugliness. Putting my 2?, we can either/or: (1) put everywhere these super ugly changes, which will make code (even more) obscure (2) put cmake_policy(SET CMP0053 NEW) at the every internal .cmake file that has been reviewed for this policy and use normal (not ugly syntax) Since include/find_package does implicit policy PUSH & POP for file scope this is IMHO much cleaner solution. Of course we would need to rollback couple of existing fixes committed by Brad. WDYT? --Adam From dlrdave at aol.com Fri Sep 19 06:23:49 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 19 Sep 2014 06:23:49 -0400 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> Message-ID: <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> I like the "cmake_policy(SET CMP0053 NEW)" solution, too. We should make a concerted effort to encourage module maintainers to do this before the 3.1 release for as many modules as possible. D From malak.jiri at gmail.com Fri Sep 19 06:40:41 2014 From: malak.jiri at gmail.com (Jiri Malak) Date: Fri, 19 Sep 2014 12:40:41 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release Message-ID: <4c4bfafad4cfbffcd56ee5eeeabf9c4c.squirrel@www.malakovi.cz> > On 09/19/2014 08:59 AM, Jiri Malak wrote: >> I did a several fixes to CMake related to Open Watcom which were accepteed to current development >> branch a few month ago. >> Up to now they were not included to official version 3.0 branch. What I must do to be include or I doing something wrong? > > The current "master" branch is the basis for a 3.1 release. > Only few changes are backported for a 3.0.x release (e.g. regressions). > > Nils > > OK, but it was accepted before v3.0.0 was released. Do you know what rules are applied for selection what will be in new release and what cutoff date for it? Jiri From nilsgladitz at gmail.com Fri Sep 19 06:54:46 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 19 Sep 2014 12:54:46 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: <4c4bfafad4cfbffcd56ee5eeeabf9c4c.squirrel@www.malakovi.cz> References: <4c4bfafad4cfbffcd56ee5eeeabf9c4c.squirrel@www.malakovi.cz> Message-ID: <541C0B76.8050208@gmail.com> On 09/19/2014 12:40 PM, Jiri Malak wrote: > OK, but it was accepted before v3.0.0 was released. > Do you know what rules are applied for selection what will be in new release and what cutoff date > for it? On Feb. 19 2014 Brad announced the cutoff [1]. So everything that was in master before that will likely be in 3.0 while everything that went into master afterwards will likely be in 3.1. Nils [1] http://public.kitware.com/pipermail/cmake-developers/2014-February/009820.html From pascal.bach at siemens.com Fri Sep 19 06:59:59 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Fri, 19 Sep 2014 10:59:59 +0000 Subject: [cmake-developers] [PATCH] WINCE: Add toolchain documentation for Windows CE In-Reply-To: <541B19A7.4000903@kitware.com> References: <1411056230-30313-1-git-send-email-pascal.bach@siemens.com> <541B19A7.4000903@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616AD3862@DEFTHW99EH4MSX.ww902.siemens.net> > If you don't mind, please precede this patch with a change that > adds such subsection headers for the Clang and QCC cases. Bellow you find the updated patch, I rearranged the cross compiling section a bit and added subsections. Pascal >From 01aa7fd739ff6bdaf05f882199e79549a04f7bda Mon Sep 17 00:00:00 2001 From: Pascal Bach Date: Fri, 19 Sep 2014 12:58:02 +0200 Subject: [PATCH] WINCE: Add toolchain documentation for Windows CE --- Help/manual/cmake-toolchains.7.rst | 58 ++++++++++++++++++++++++++++++------ 1 file changed, 49 insertions(+), 9 deletions(-) diff --git a/Help/manual/cmake-toolchains.7.rst b/Help/manual/cmake-toolchains.7.rst index f36a43c..05e05ff 100644 --- a/Help/manual/cmake-toolchains.7.rst +++ b/Help/manual/cmake-toolchains.7.rst @@ -97,12 +97,18 @@ Cross Compiling If :manual:`cmake(1)` is invoked with the command line parameter ``-DCMAKE_TOOLCHAIN_FILE=path/to/file``, the file will be loaded early to set -values for the compilers. A typical cross-compiling toolchain has content such +values for the compilers. + +Cross Compiling for Linux +------------------------- + +A typical cross-compiling toolchain for Linux has content such as: .. code-block:: cmake set(CMAKE_SYSTEM_NAME Linux) + set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_SYSROOT /home/devel/rasp-pi-rootfs) set(CMAKE_STAGING_PREFIX /home/devel/stage) @@ -118,6 +124,9 @@ as: The :variable:`CMAKE_SYSTEM_NAME` is the CMake-identifier of the target platform to build for. +The :variable:`CMAKE_SYSTEM_PROCESSOR` is the CMake-identifier of the target architecture +to build for. + The :variable:`CMAKE_SYSROOT` is optional, and may be specified if a sysroot is available. @@ -139,13 +148,17 @@ target system prefixes, whereas executables which must be run as part of the bui should be found only on the host and not on the target. This is the purpose of the ``CMAKE_FIND_ROOT_PATH_MODE_*`` variables. -Some compilers are inherently cross compilers, such as Clang and the QNX QCC -compiler. The :variable:`CMAKE__COMPILER_TARGET` can be set to pass a +Cross Compiling using Clang +--------------------------- + +Some compilers such as Clang are inherently cross compilers. +The :variable:`CMAKE__COMPILER_TARGET` can be set to pass a value to those supported compilers when compiling: .. code-block:: cmake set(CMAKE_SYSTEM_NAME Linux) + set(CMAKE_SYSTEM_PROCESSOR arm) set(triple arm-linux-gnueabihf) @@ -154,7 +167,18 @@ value to those supported compilers when compiling: set(CMAKE_CXX_COMPILER clang++) set(CMAKE_CXX_COMPILER_TARGET ${triple}) -Or, for QCC: +Similarly, some compilers do not ship their own supplementary utilities +such as linkers, but provide a way to specify the location of the external +toolchain which will be used by the compiler driver. The +:variable:`CMAKE__COMPILER_EXTERNAL_TOOLCHAIN` variable can be set in a +toolchain file to pass the path to the compiler driver. + +Cross Compiling for QNX +----------------------- + +As the Clang compiler the QNX QCC compile is inherently a cross compiler. +And the :variable:`CMAKE__COMPILER_TARGET` can be set to pass a +value to those supported compilers when compiling: .. code-block:: cmake @@ -167,12 +191,28 @@ Or, for QCC: set(CMAKE_CXX_COMPILER QCC) set(CMAKE_CXX_COMPILER_TARGET ${arch}) +Cross Compiling for Windows CE +------------------------------ -Similarly, some compilers do not ship their own supplementary utilities -such as linkers, but provide a way to specify the location of the external -toolchain which will be used by the compiler driver. The -:variable:`CMAKE__COMPILER_EXTERNAL_TOOLCHAIN` variable can be set in a -toolchain file to pass the path to the compiler driver. +Cross compiling for Windows CE requires the corresponding SDK being installed on +your system. These SDKs are usually installed under: `C:\\Program Files (x86)\\Windows CE Tools\\SDKs` + +The :variable:`CMAKE_GENERATOR_PLATFORM` tells the generator which SDK to use. +Further :variable:`CMAKE_SYSTEM_VERSION` tells the generator what version of Windows CE to use. +Currently version 8.0 (Windows Embedded Compact 2013) is supported out of the box. Other versions +my require to set :variable:`CMAKE_GENERATOR_TOOLSET` to the correct value. + +A toolchain file for Windows CE may look like this: + +.. code-block:: cmake + + set(CMAKE_SYSTEM_NAME WindowsCE) + + set(CMAKE_SYSTEM_VERSION 8.0) + set(CMAKE_SYSTEM_PROCESSOR arm) + + set(CMAKE_GENERATOR_TOOLSET CE800) # Can be omitted for 8.0 + set(CMAKE_GENERATOR_PLATFORM SDK_AM335X_SK_WEC2013_V310) The :variable:`CMAKE_CROSSCOMPILING` variable is set to true when CMake is cross-compiling. -- 1.7.10.4 From dlrdave at aol.com Fri Sep 19 07:38:58 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 19 Sep 2014 07:38:58 -0400 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release Message-ID: <8D1A2156EEDFD5C-1B24-7561@webmail-m169.sysops.aol.com> The "rule" is (roughly): after the first release candidate for a given release, no more "new features" for that particular release. Only continuing work to complete new features in rc1 and fixing regressions reported from previous versions should go in subsequent release candidates. Possible exceptions may be made for bug fixes deemed "important" and "broadly applicable and helpful." In the end, it's always a judgment call, and up to the folks preparing the releases to decide what goes in and what has to wait till next time. As Nils said, the only stuff guaranteed to be in a release is whatever is in 'master' already at the time the first release candidate is made. HTH, David C. From malak.jiri at gmail.com Fri Sep 19 07:57:22 2014 From: malak.jiri at gmail.com (Jiri Malak) Date: Fri, 19 Sep 2014 13:57:22 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: <541C0B76.8050208@gmail.com> References: <4c4bfafad4cfbffcd56ee5eeeabf9c4c.squirrel@www.malakovi.cz> <541C0B76.8050208@gmail.com> Message-ID: > On 09/19/2014 12:40 PM, Jiri Malak wrote: >> OK, but it was accepted before v3.0.0 was released. >> Do you know what rules are applied for selection what will be in new release and what cutoff >> date >> for it? > > On Feb. 19 2014 Brad announced the cutoff [1]. > So everything that was in master before that will likely be in 3.0 > while everything that went into master afterwards will likely be in 3.1. > > Nils > > [1] > http://public.kitware.com/pipermail/cmake-developers/2014-February/009820.html > Thanks for info. It is clear, it was too late to be included to 3.0. Do you have any idea when version 3.1 first release candidate is planned? Jiri From nilsgladitz at gmail.com Fri Sep 19 08:14:36 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 19 Sep 2014 14:14:36 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: References: <4c4bfafad4cfbffcd56ee5eeeabf9c4c.squirrel@www.malakovi.cz> <541C0B76.8050208@gmail.com> Message-ID: <541C1E2C.9050103@gmail.com> On 09/19/2014 01:57 PM, Jiri Malak wrote: > Thanks for info. > It is clear, it was too late to be included to 3.0. > > Do you have any idea when version 3.1 first release candidate is planned? Mantis (the issue tracker) currently has 3.1 scheduled for 2014-11-01. For now I'd take it as a non binding rough estimate though. Nils From malak.jiri at gmail.com Fri Sep 19 08:21:28 2014 From: malak.jiri at gmail.com (Jiri Malak) Date: Fri, 19 Sep 2014 14:21:28 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: <541C1E2C.9050103@gmail.com> References: <4c4bfafad4cfbffcd56ee5eeeabf9c4c.squirrel@www.malakovi.cz> <541C0B76.8050208@gmail.com> <541C1E2C.9050103@gmail.com> Message-ID: > On 09/19/2014 01:57 PM, Jiri Malak wrote: >> Thanks for info. >> It is clear, it was too late to be included to 3.0. >> >> Do you have any idea when version 3.1 first release candidate is planned? > > Mantis (the issue tracker) currently has 3.1 scheduled for 2014-11-01. > For now I'd take it as a non binding rough estimate though. > > Nils > Nils, Many Thanks for clarification. Jiri From mantis at public.kitware.com Fri Sep 19 09:12:54 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 19 Sep 2014 09:12:54 -0400 Subject: [cmake-developers] [CMake 0015165]: WiX : Remember the INSTALL_ROOT directory for upgrades Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15165 ====================================================================== Reported By: Richard Ulrich Assigned To: ====================================================================== Project: CMake Issue ID: 15165 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-19 09:12 EDT Last Modified: 2014-09-19 09:12 EDT ====================================================================== Summary: WiX : Remember the INSTALL_ROOT directory for upgrades Description: If a user installs to a custom directory, upon upgrade the directory dialog initializes to the standard location again. It would be nice if it started at the previously used custom location. I think this could help: http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern/ Additional Information: I'm in the process of implementing this in my wxs files. But I think it would be a feature that would make sense for the standard. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-19 09:12 Richard Ulrich New Issue ====================================================================== From hobbes1069 at gmail.com Fri Sep 19 09:19:14 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Fri, 19 Sep 2014 08:19:14 -0500 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> References: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> Message-ID: On Fri, Sep 19, 2014 at 1:59 AM, Jiri Malak wrote: > Hi, > > I did a several fixes to CMake related to Open Watcom which were accepteed > to current development > branch a few month ago. > Up to now they were not included to official version 3.0 branch. > What I must do to be include or I doing something wrong? I'd like to hear others opinions, but what I've done is once one of my patches is accepted, as long as it applies cleanly to the current release (and since all I mess with are modules that's usually the case) then I just email the Fedora package maintainer and he applies it within Fedora. You didn't mention if you were on Linux or Windows but if you're running a Linux distro you could probably do the same. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Sep 19 09:34:28 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 19 Sep 2014 15:34:28 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: References: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> Message-ID: <541C30E4.1010301@gmail.com> On 09/19/2014 03:19 PM, Richard Shaw wrote: > I'd like to hear others opinions, but what I've done is once one of my > patches is accepted, as long as it applies cleanly to the current release > (and since all I mess with are modules that's usually the case) then I just > email the Fedora package maintainer and he applies it within Fedora. > > You didn't mention if you were on Linux or Windows but if you're running a > Linux distro you could probably do the same. I personally rather dislike that distributions introduce behavior changes since it might result in your project not only depending on a specific version of CMake but also a specific variant as introduced by the distribution you are working on. It also results in people submitting issues with vanilla CMake which might be specific to distribution patches (e.g. [1]). Nils [1] http://www.cmake.org/Bug/view.php?id=10692 From hobbes1069 at gmail.com Fri Sep 19 09:40:56 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Fri, 19 Sep 2014 08:40:56 -0500 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: <541C30E4.1010301@gmail.com> References: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> <541C30E4.1010301@gmail.com> Message-ID: On Fri, Sep 19, 2014 at 8:34 AM, Nils Gladitz wrote: > On 09/19/2014 03:19 PM, Richard Shaw wrote: > >> I'd like to hear others opinions, but what I've done is once one of my >> patches is accepted, as long as it applies cleanly to the current release >> (and since all I mess with are modules that's usually the case) then I >> just >> email the Fedora package maintainer and he applies it within Fedora. >> >> I personally rather dislike that distributions introduce behavior changes > since it might result in your project not only depending on a specific > version of CMake but also a specific variant as introduced by the > distribution you are working on. > > It also results in people submitting issues with vanilla CMake which might > be specific to distribution patches (e.g. [1]). I don't disagree in theory, but what do you do if you need the fix? One of the fixes I submitted fixed a problem with cross compiling that I'm not sure I could have easily worked around. I don't want to sit on my hands and wait for 3.1. I guess I could have copied the module into my project module folder and applied it locally, but that seems like a worse workaround than patching at the distro level. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Fri Sep 19 09:41:16 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 19 Sep 2014 15:41:16 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: References: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> Message-ID: Richard Shaw wrote: > On Fri, Sep 19, 2014 at 1:59 AM, Jiri Malak > wrote: > >> I did a several fixes to CMake related to Open Watcom which were >> accepteed >> to current development >> branch a few month ago. >> Up to now they were not included to official version 3.0 branch. >> What I must do to be include or I doing something wrong? > > I'd like to hear others opinions, but what I've done is once one of my > patches is accepted, as long as it applies cleanly to the current > release > (and since all I mess with are modules that's usually the case) then I > just > email the Fedora package maintainer and he applies it within Fedora. > > You didn't mention if you were on Linux or Windows but if you're > running a > Linux distro you could probably do the same. While I'm not too happy with the current situation either I don't think this is a good idea as it creates a hard to verify "zoo" of CMake versions with the same version number, but different behavior. This approach is is good for distro-specific patches, something like "we ship a new Python that the upstream FindPython*.cmake does not find by default" or "we put our headers in a strange location", but I think that doing this for other stuff has the danger of making the Fedora packages some sort of shadow-upstream. Eike From nilsgladitz at gmail.com Fri Sep 19 09:50:13 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 19 Sep 2014 15:50:13 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: References: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> <541C30E4.1010301@gmail.com> Message-ID: <541C3495.1030502@gmail.com> On 09/19/2014 03:40 PM, Richard Shaw wrote: > I guess I could have copied the module into my project module folder and > applied it locally, but that seems like a worse workaround than patching at > the distro level. I think I would personally prefer that over changing the package for the whole distro. The project is under your direct control and the modified module will be available with the project on all distributions (or platforms/operating systems) that users might try to build your project e.g. not just the distribution you happen to work on. By modifying the module on the distro level this changes behavior also for projects that did not ask for that change (which might work out in some cases but might just as well break in others). Nils From brad.king at kitware.com Fri Sep 19 10:28:01 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 19 Sep 2014 10:28:01 -0400 Subject: [cmake-developers] vs-nsight-tegra-generator topic In-Reply-To: References: Message-ID: <541C3D71.7080806@kitware.com> On 09/16/2014 06:11 PM, Mourad Boufarguine wrote: > So, today I tried the next branch with the new NSight stuff. Great, thanks for testing it out. > 1> (...)/arm-linux-androideabi/bin/ld.bfd.exe: cannot find -l-lGLESv1_CM This should fix it: VS: Fix Tegra-Android platform linking of libraries by name http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=72612e2e > I noticed these minor differences > > * Java files are declared using JCompile xml tags instead of None tags (using cmake) > * some special files are declared using AndroidBuild xml tags > (AndroidManifest.xml, build.xml, project.properties, proguard.cfg, res\values\strings.xml ...) Interesting. I started with an IDE-generated project file to see what the generator needs to produce. What version of Nsight Tegra are you using? Thanks, -Brad From brad.king at kitware.com Fri Sep 19 13:26:58 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 19 Sep 2014 13:26:58 -0400 Subject: [cmake-developers] [PATCH] WINCE: Add toolchain documentation for Windows CE In-Reply-To: <355BE46A91031048906B695426A8D8E616AD3862@DEFTHW99EH4MSX.ww902.siemens.net> References: <1411056230-30313-1-git-send-email-pascal.bach@siemens.com> <541B19A7.4000903@kitware.com> <355BE46A91031048906B695426A8D8E616AD3862@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <541C6762.4030802@kitware.com> On 09/19/2014 06:59 AM, Bach, Pascal wrote: > Bellow you find the updated patch, I rearranged the cross compiling > section a bit and added subsections. Thanks. I split that into two commits with slight edits, and added my own commit to add subsections for Windows Phone and Store: Help: Add Cross Compiling subsections in cmake-toolchains.7 manual http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0d72451a Help: Add Windows CE cross-compiling to cmake-toolchains.7 manual http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=db54d872 Help: Add Windows Phone/Store cross-compiling to cmake-toolchains.7 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27022166 Please review the result to make sure I didn't munge information you intended to provide. Thanks, -Brad From Gilles.Khouzam at microsoft.com Fri Sep 19 12:59:50 2014 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Fri, 19 Sep 2014 16:59:50 +0000 Subject: [cmake-developers] Patch: Certificate files are not included in Windows Store projects Message-ID: We do write the proper tag in the VCXProj file for the certificate file, but the file is not included in the project itself causing some failures. When I moved the certificates into their own category in the GeneratorTarget, the new category was never added to the VS10TargetGenerator when the sources get written. Gilles Khouzam Senior Development Lead Microsoft OSG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Patch-Add-Certificates-Windows.patch Type: application/octet-stream Size: 1277 bytes Desc: 0001-Patch-Add-Certificates-Windows.patch URL: From brad.king at kitware.com Fri Sep 19 13:44:45 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 19 Sep 2014 13:44:45 -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> Message-ID: <541C6B8D.2020404@kitware.com> On 09/18/2014 08:10 PM, Aleix Pol wrote: > I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to > enable the generation of the file. > I also renamed the file to ProjectTargets.json. > > http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch Thanks. I made some style updates and converted it to a patch generated with 'git format-patch'. See attached. I also attached a sample ProjectTargets.json generated for the "COnly" test from our test suite. I'd really like to hear from others on the file format itself. Some comments on the format: * A version number field is needed at the top. * There needs to be support for multi-config generators. Perhaps everything that can be affected by the configuration needs to be inside a list that enumerates all configurations. In single-configuration generators the list would have only one entry for the CMAKE_BUILD_TYPE. In multi-configuration generators it would be all of the CMAKE_CONFIGURATION_TYPES. * Don't IDEs want to know the list of source files so they can be used for editing? I haven't looked at what the Extra generators produce in a while but since they are meant for IDEs they would be a good reference for the information needed. However, AFAIK there is not an extra generator for a multi-config generator. -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch Type: text/x-diff Size: 4887 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ProjectTargets.json Type: application/json Size: 1001 bytes Desc: not available URL: From brad.king at kitware.com Fri Sep 19 13:50:11 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 19 Sep 2014 13:50:11 -0400 Subject: [cmake-developers] Patch: Certificate files are not included in Windows Store projects In-Reply-To: References: Message-ID: <541C6CD3.4050108@kitware.com> On 09/19/2014 12:59 PM, Gilles Khouzam wrote: > We do write the proper tag in the VCXProj file for the certificate file, but the file is not included in the project itself causing some failures. When I moved the certificates into their own category in the GeneratorTarget, the new category was never added to the VS10TargetGenerator when the > sources get written. Applied, thanks: VS: Add Certificates to .vcxproj files http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d4ca8fb2 -Brad From eike at sf-mail.de Fri Sep 19 13:57:04 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 19 Sep 2014 19:57:04 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <541C6B8D.2020404@kitware.com> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <541C6B8D.2020404@kitware.com> Message-ID: <1461805.58uUMPt7S5@caliban.sf-tec.de> Am Freitag, 19. September 2014, 13:44:45 schrieb Brad King: > On 09/18/2014 08:10 PM, Aleix Pol wrote: > > I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to > > enable the generation of the file. > > I also renamed the file to ProjectTargets.json. > > > > http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch > > Thanks. I made some style updates and converted it to a patch > generated with 'git format-patch'. See attached. I also > attached a sample ProjectTargets.json generated for the "COnly" > test from our test suite. I see duplicated slashes in the JSON file. 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 Sep 19 14:04:25 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 19 Sep 2014 14:04:25 -0400 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <1461805.58uUMPt7S5@caliban.sf-tec.de> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <541C6B8D.2020404@kitware.com> <1461805.58uUMPt7S5@caliban.sf-tec.de> Message-ID: <541C7029.7030403@kitware.com> On 09/19/2014 01:57 PM, Rolf Eike Beer wrote: > I see duplicated slashes in the JSON file. It looks like those come from cmTarget::GetLocationForBuild. An extra + if(!location.empty()) + { + location += "/"; + } appears to have been added by this commit: Remove the Location member from cmTarget. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=638843af Steve, do you remember why it was added? All lines below that append a slash before appending other content, so it will always end up with a double slash. Is there any reason you see that it cannot be removed? Thanks, -Brad From neundorf at kde.org Fri Sep 19 15:53:40 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Fri, 19 Sep 2014 21:53:40 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <541C6B8D.2020404@kitware.com> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <541C6B8D.2020404@kitware.com> Message-ID: <1593230.4g2cNbzx16@tuxedo.neundorf.net> On Friday, September 19, 2014 13:44:45 Brad King wrote: ... > * Don't IDEs want to know the list of source files so they can > be used for editing? > > I haven't looked at what the Extra generators produce in a > while but since they are meant for IDEs they would be a good > reference for the information needed. typically a list of targets, the command to build each target, source files for each target, used include dirs and defines (-D) for code completion. > However, AFAIK there > is not an extra generator for a multi-config generator. Yes. Alex From robert.maynard at kitware.com Fri Sep 19 16:18:34 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 19 Sep 2014 16:18:34 -0400 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> Message-ID: I agree with David, I think moving packages over to using CMP0054 NEW is the best option going forward. Personally I think that CMP0054 might be the best policy ever, as it significantly reduces the complexity of reading CMake code. On Fri, Sep 19, 2014 at 6:23 AM, David Cole via cmake-developers wrote: > I like the "cmake_policy(SET CMP0053 NEW)" solution, too. We should make a > concerted effort to encourage module maintainers to do this before the 3.1 > release for as many modules as possible. > > > D > > -- > > 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 taylor at braun-jones.org Fri Sep 19 18:07:33 2014 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Fri, 19 Sep 2014 18:07:33 -0400 Subject: [cmake-developers] [CMake] Integrating ExternalData with Artifactory In-Reply-To: <541C7E2B.9080606@kitware.com> References: <541C7E2B.9080606@kitware.com> Message-ID: Shifting discussion to cmake-developers. On Fri, Sep 19, 2014 at 3:04 PM, Brad King wrote: > On 09/19/2014 12:23 PM, Taylor Braun-Jones wrote: > > integrate Artifactory with the ExternalData framework? > > > > the Artifactory REST API is a two step process > > I think it can be activated by a special format of an entry in > ExternalData_URL_TEMPLATES that specifies a lookup key that maps > to some kind of custom configuration of a .cmake script to include > or command to launch with execute_process. > How about defining new URL scheme like: externaldatacommand://<*file|module*>/<*command*> Where *file|module* is something that can be passed to the include command and defines a function or macro named *command*. *command* would then be called like: command(outputfile algo hash) So, using Artifactory as an example case, a projects CMakeLists.txt might look like: list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/Testing/CMake ) set(ARTIFACTORY_BASE_URL https://example.com/artifactory) list(APPEND ExternalData_URL_TEMPLATES "externaldatacommand://ArtifactoryExternalData/ARTIFACTORY_DOWNLOAD_FILE?ALGO=%(algo)&" ) And inside Testing/CMake/ArtifactoryExternalData.cmake it would look like: function(ARTIFACTORY_DOWNLOAD_FILE file algo hash) set(json_response_file ${CMAKE_BINARY_DIR}/artifactory_search_${algo}_${hash}.json) set(artifact_search_query ${ARTIFACTORY_BASE_URL}/api/search/checksum?${algo}=${hash}) message("Query URI: ${artifact_search_query}") file(DOWNLOAD ${artifact_search_query} ${json_response_file} STATUS status) list(GET status 0 error_code) list(GET status 1 error_message) if(error_code) file(REMOVE ${json_response_file}) message(FATAL_ERROR "Artifactory query failed with error ${error_code}: ${error_message}") endif() # For testing file(WRITE ${json_response_file} "{\"results\":[{\"uri\":\" https://example.com/artifactory/api/storage/repo1-cache/lena.png\"}]}") file(READ ${json_response_file} json_response) file(REMOVE ${json_response_file}) # Normalize the JSON response by removing any whitespace (makes it easier to parse) string(REGEX REPLACE "[ \t\n\r]+" "" json_response ${json_response}) if(NOT json_response MATCHES "\"uri\":") message(FATAL_ERROR "Artifactory file was not found") endif() string(REGEX MATCH "https?://[^\"]+" artifact_uri ${json_response}) message("Artifact URI: ${artifact_uri}") file(DOWNLOAD ${artifact_uri} ${file} STATUS status) list(GET status 0 error_code) list(GET status 1 error_message) if(error_code) message(FATAL_ERROR "Artifactory download failed with error ${error_code}: ${error_message}") endif() endfunction() Then if you had: ExternalData_Add_Test(MyProjectData NAME SmoothingTest COMMAND SmoothingExe DATA{Input/Image.png} SmoothedImage.png ) The ExternalData framework would execute: ARTIFACTORY_DOWNLOAD_FILE(${ExternalData_BINARY_ROOT}/Input/Image.png md5 1234567890abcdef1234567890abcdef) Thoughts? Taylor -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Sat Sep 20 09:18:32 2014 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 20 Sep 2014 15:18:32 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <541C6B8D.2020404@kitware.com> <1461805.58uUMPt7S5@caliban.sf-tec.de> <541C7029.7030403@kitware.com> Message-ID: Brad King wrote: > Steve, do you remember why it was added? All lines below > that append a slash before appending other content, so it > will always end up with a double slash. Is there any reason > you see that it cannot be removed? I don't know why I added it. Perhaps to deal with a dashboard error that would emerge again if removed. There is also a 'new' + location += "/"; in that patch further down which might be removable. Thanks, Steve. From ono at java.pl Sat Sep 20 09:20:42 2014 From: ono at java.pl (Adam Strzelecki) Date: Sat, 20 Sep 2014 15:20:42 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> Message-ID: I've pushed stage/CMP0054-FindCUDA: commit 8998557e7c9a7542e78e07b8b06fd728604f0bdf Author: Adam Strzelecki Date: Tue Sep 16 23:31:44 2014 +0200 FindCUDA: Audit for modern CMP0054 if() syntax Enables CMP0054 for whole module to silence quoted variable expansion warning. Just added where the actual code starts: cmake_policy(SET CMP0054 NEW) # modern if() syntax And made one simple fix with unneeded variable and unneeded quoting. I think we may do the same for the other modules. WDYT? --Adam From steveire at gmail.com Sat Sep 20 09:43:54 2014 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 20 Sep 2014 15:43:54 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration 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> Message-ID: Brad King wrote: > I'd really like to hear from others on the file format itself. > > * There needs to be support for multi-config generators. This presumable affects the "directory" and "location". I wonder what the usefulness of putting "exportName" in the file is? Is it possible there is confusion with OUTPUT_NAME? Or do you want some richer information if an IDE opens a file in the build dir generated by export()? Does this generated file enable use-cases like 'Add new file to target' or is that already easy? Or what kind of features are enabled by this? Thanks, Steve. From mantis at public.kitware.com Sat Sep 20 14:05:49 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 20 Sep 2014 14:05:49 -0400 Subject: [cmake-developers] [CMake 0015166]: cc: acomp failed for Source/CursesDialog/form/fld_arg.c Message-ID: <2d023dbb73f2209d8fde880ab7af983e@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15166 ====================================================================== Reported By: dev Assigned To: ====================================================================== Project: CMake Issue ID: 15166 Category: CMake Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-20 14:05 EDT Last Modified: 2014-09-20 14:05 EDT ====================================================================== Summary: cc: acomp failed for Source/CursesDialog/form/fld_arg.c Description: On Oracle Solaris 10 with Oracle Studio 12.3 compilers : [ 48%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 46: cannot find include file: "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 93: error: syntax error before or at: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 120: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 120: warning: syntax requires ";" after last struct/union member "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 110: error: zero-sized struct/union "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 144: error: syntax error before or at: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 291: error: syntax error before or at: ( "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 290: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292: error: syntax error before or at: * "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292: error: syntax error before or at: ) "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 293: warning: old-style declaration or incorrect type for: link_fieldtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 297: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 297: warning: undefined or missing type for: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 296: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: error: syntax error before or at: * "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: error: syntax error before or at: ) "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: warning: syntax error: empty declaration "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 313: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 313: warning: undefined or missing type for: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 316: error: syntax error before or at: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 316: warning: undefined or missing type for: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 317: error: syntax error before or at: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 317: warning: undefined or missing type for: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 321: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 321: warning: undefined or missing type for: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 327: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 327: error: syntax error before or at: field_fore "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 327: warning: old-style declaration or incorrect type for: field_fore "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 328: warning: old-style declaration or incorrect type for: field_back "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: error: identifier redeclared: bool current : int previous: function() returning int : "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292 "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: error: syntax error before or at: new_page "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: warning: old-style declaration or incorrect type for: new_page "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 331: warning: old-style declaration or incorrect type for: field_status "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 353: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 353: error: syntax error before or at: * "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 353: warning: old-style declaration or incorrect type for: form_win "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 354: warning: old-style declaration or incorrect type for: form_sub "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 365: error: syntax error before or at: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 365: warning: undefined or missing type for: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 366: error: syntax error before or at: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 366: warning: undefined or missing type for: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 394: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 394: error: syntax error before or at: data_ahead "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 394: warning: old-style declaration or incorrect type for: data_ahead "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 395: warning: old-style declaration or incorrect type for: data_behind "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 124: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 124: error: syntax error before or at: _nc_Copy_Type "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 124: warning: old-style declaration or incorrect type for: _nc_Copy_Type "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 132: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 132: error: syntax error before or at: _nc_Internal_Validation "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 132: warning: old-style declaration or incorrect type for: _nc_Internal_Validation "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 71: error: improper member use: status "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 72: error: improper member use: makearg "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 73: error: improper member use: copyarg "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 74: error: improper member use: freearg cc: acomp failed for /usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c gmake[2]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o] Error 2 gmake[1]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/all] Error 2 gmake: *** [all] Error 2 node000 $ Steps to Reproduce: fetch and extract the tarball : node000 $ wget http://www.cmake.org/files/v3.0/cmake-3.0.2.tar.gz --2014-09-20 16:25:21-- http://www.cmake.org/files/v3.0/cmake-3.0.2.tar.gz Resolving www.cmake.org... 66.194.253.19 Connecting to www.cmake.org|66.194.253.19|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 5490501 (5.2M) [application/x-gzip] Saving to: ?cmake-3.0.2.tar.gz? 0K ..... 100% 585K=9.2s 2014-09-20 16:25:31 (585 KB/s) - ?cmake-3.0.2.tar.gz? saved [5490501/5490501] node000 $ cd /usr/local/build node000 $ mdigest -a sha256 ../src/cmake-3.0.2.tar.gz 6b4ea61eadbbd9bec0ccb383c29d1f4496eacc121ef7acf37c7a24777805693e ../src/cmake-3.0.2.tar.gz node000 $ gzip -dc ../src/cmake-3.0.2.tar.gz | tar -xf - node000 $ mkdir cmake-3.0.2_SunOS5.10_sparcv9.001 node000 $ cd cmake-3.0.2_SunOS5.10_sparcv9.001 setup env vars : node000 $ env | sort AR=/usr/ccs/bin/ar AS=/usr/ccs/bin/as BUILD=/usr/local/build CC=/opt/solarisstudio12.3/bin/cc CFLAGS=-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 CONFIG_SHELL=/usr/local/bin/bash CPPFLAGS=-I/usr/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE CXXFLAGS=-dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO CXX=/opt/solarisstudio12.3/bin/CC GREP=/usr/local/bin/ggrep HOME=/export/home/dev LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LD_LIBRARY_PATH=/usr/local/lib LD_OPTIONS=-64 -R/usr/local/lib/:/usr/local/lib -L/usr/local/lib/:/usr/local/lib LD_RUN_PATH=/usr/local/lib LD=/usr/ccs/bin/sparcv9/ld LIBTOOL=/usr/local/bin/libtool LOGNAME=dev M4=/usr/local/bin/gm4 MACHTYPE=sparc-sun-solaris MAKE=/usr/local/bin/gmake MANPATH=/usr/share/man:/usr/X11/share/man NM=/usr/ccs/bin/sparcv9/nm -p OSTYPE=solaris PAGER=/usr/xpg4/bin/more PATH=/usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/opt/solarisstudio12.3/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/dt/bin:/usr/openwin/bin:/opt/schily/bin PERL=/usr/local/bin/perl PKG_CONFIG_PATH=/usr/local/lib/pkgconfig PWD=/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001 SED=/usr/local/bin/gsed SHELL=/usr/local/bin/bash SHLVL=1 SRC=/usr/local/src TERM=xterm TZ=GMT0 USER=dev _=/usr/xpg4/bin/env VISUAL=/usr/xpg6/bin/vi XTERM_LOCALE=en_US.UTF-8 Bootstrap : node000 $ ../cmake-3.0.2/bootstrap --------------------------------------------- CMake 3.0.2, Copyright 2000-2014 Kitware, Inc. C compiler on this system is: /opt/solarisstudio12.3/bin/cc -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 C++ compiler on this system is: /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO Makefile processor on this system is: /usr/local/bin/gmake /opt/solarisstudio12.3/bin/CC is not GNU compiler /opt/solarisstudio12.3/bin/CC has setenv /opt/solarisstudio12.3/bin/CC has unsetenv /opt/solarisstudio12.3/bin/CC does not have environ in stdlib.h /opt/solarisstudio12.3/bin/CC has STL in std:: namespace /opt/solarisstudio12.3/bin/CC has ANSI streams /opt/solarisstudio12.3/bin/CC has streams in std:: namespace /opt/solarisstudio12.3/bin/CC has sstream /opt/solarisstudio12.3/bin/CC has operator!=(string, char*) /opt/solarisstudio12.3/bin/CC does not have stl iterator_traits /opt/solarisstudio12.3/bin/CC does not have old iterator_category /opt/solarisstudio12.3/bin/CC has old __iterator_category /opt/solarisstudio12.3/bin/CC has standard template allocator /opt/solarisstudio12.3/bin/CC does not have allocator<>::rebind<> /opt/solarisstudio12.3/bin/CC has non-standard allocator<>::max_size argument /opt/solarisstudio12.3/bin/CC has stl containers supporting allocator objects /opt/solarisstudio12.3/bin/CC has stl wstring /opt/solarisstudio12.3/bin/CC does not have header cstddef /opt/solarisstudio12.3/bin/CC requires template friends to use <> /opt/solarisstudio12.3/bin/CC supports member templates /opt/solarisstudio12.3/bin/CC has standard template specialization syntax /opt/solarisstudio12.3/bin/CC has argument dependent lookup /opt/solarisstudio12.3/bin/CC has struct stat with st_mtim member /opt/solarisstudio12.3/bin/CC has ios::binary openmode /opt/solarisstudio12.3/bin/CC has ANSI for scoping --------------------------------------------- /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmStandardIncludes.cxx -o cmStandardIncludes.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmake.cxx -o cmake.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmakemain.cxx -o cmakemain.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmcmd.cxx -o cmcmd.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmCommandArgumentLexer.cxx -o cmCommandArgumentLexer.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmCommandArgumentParser.cxx -o cmCommandArgumentParser.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmCommandArgumentParserHelper.cxx -o cmCommandArgumentParserHelper.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmDefinitions.cxx -o cmDefinitions.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmDepends.cxx -o cmDepends.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmDependsC.cxx -o cmDependsC.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmDocumentationFormatter.cxx -o cmDocumentationFormatter.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmPolicies.cxx -o cmPolicies.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmProperty.cxx -o cmProperty.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmPropertyMap.cxx -o cmPropertyMap.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmPropertyDefinition.cxx -o cmPropertyDefinition.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmPropertyDefinitionMap.cxx -o cmPropertyDefinitionMap.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmMakeDepend.cxx -o cmMakeDepend.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmMakefile.cxx -o cmMakefile.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExportFileGenerator.cxx -o cmExportFileGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExportInstallFileGenerator.cxx -o cmExportInstallFileGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExportTryCompileFileGenerator.cxx -o cmExportTryCompileFileGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExportSet.cxx -o cmExportSet.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExportSetMap.cxx -o cmExportSetMap.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmInstallDirectoryGenerator.cxx -o cmInstallDirectoryGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGeneratedFileStream.cxx -o cmGeneratedFileStream.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGeneratorTarget.cxx -o cmGeneratorTarget.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGeneratorExpressionDAGChecker.cxx -o cmGeneratorExpressionDAGChecker.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGeneratorExpressionEvaluator.cxx -o cmGeneratorExpressionEvaluator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGeneratorExpressionLexer.cxx -o cmGeneratorExpressionLexer.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGeneratorExpressionParser.cxx -o cmGeneratorExpressionParser.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGeneratorExpression.cxx -o cmGeneratorExpression.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGlobalGenerator.cxx -o cmGlobalGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmLocalGenerator.cxx -o cmLocalGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmInstallGenerator.cxx -o cmInstallGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmInstallExportGenerator.cxx -o cmInstallExportGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmInstallFilesGenerator.cxx -o cmInstallFilesGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmInstallScriptGenerator.cxx -o cmInstallScriptGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmInstallTargetGenerator.cxx -o cmInstallTargetGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmScriptGenerator.cxx -o cmScriptGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmSourceFile.cxx -o cmSourceFile.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmSourceFileLocation.cxx -o cmSourceFileLocation.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmSystemTools.cxx -o cmSystemTools.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmTestGenerator.cxx -o cmTestGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmVersion.cxx -o cmVersion.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmFileTimeComparison.cxx -o cmFileTimeComparison.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGlobalUnixMakefileGenerator3.cxx -o cmGlobalUnixMakefileGenerator3.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmLocalUnixMakefileGenerator3.cxx -o cmLocalUnixMakefileGenerator3.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmMakefileExecutableTargetGenerator.cxx -o cmMakefileExecutableTargetGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmMakefileLibraryTargetGenerator.cxx -o cmMakefileLibraryTargetGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmMakefileTargetGenerator.cxx -o cmMakefileTargetGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmMakefileUtilityTargetGenerator.cxx -o cmMakefileUtilityTargetGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmOSXBundleGenerator.cxx -o cmOSXBundleGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmNewLineStyle.cxx -o cmNewLineStyle.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmBootstrapCommands1.cxx -o cmBootstrapCommands1.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmBootstrapCommands2.cxx -o cmBootstrapCommands2.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmCommandsForBootstrap.cxx -o cmCommandsForBootstrap.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmTarget.cxx -o cmTarget.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmTest.cxx -o cmTest.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmCustomCommand.cxx -o cmCustomCommand.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmCustomCommandGenerator.cxx -o cmCustomCommandGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmCacheManager.cxx -o cmCacheManager.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmListFileCache.cxx -o cmListFileCache.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmComputeLinkDepends.cxx -o cmComputeLinkDepends.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmComputeLinkInformation.cxx -o cmComputeLinkInformation.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmOrderDirectories.cxx -o cmOrderDirectories.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmComputeTargetDepends.cxx -o cmComputeTargetDepends.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmComputeComponentGraph.cxx -o cmComputeComponentGraph.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExprLexer.cxx -o cmExprLexer.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExprParser.cxx -o cmExprParser.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExprParserHelper.cxx -o cmExprParserHelper.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGlobalNinjaGenerator.cxx -o cmGlobalNinjaGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmLocalNinjaGenerator.cxx -o cmLocalNinjaGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmNinjaTargetGenerator.cxx -o cmNinjaTargetGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmNinjaNormalTargetGenerator.cxx -o cmNinjaNormalTargetGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmNinjaUtilityTargetGenerator.cxx -o cmNinjaUtilityTargetGenerator.o /opt/solarisstudio12.3/bin/cc -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmListFileLexer.c -o cmListFileLexer.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /usr/local/build/cmake-3.0.2/Source/kwsys/Directory.cxx -o Directory.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /usr/local/build/cmake-3.0.2/Source/kwsys/EncodingCXX.cxx -o EncodingCXX.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /usr/local/build/cmake-3.0.2/Source/kwsys/Glob.cxx -o Glob.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /usr/local/build/cmake-3.0.2/Source/kwsys/RegularExpression.cxx -o RegularExpression.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -DKWSYS_CXX_HAS_SETENV=1 -DKWSYS_CXX_HAS_UNSETENV=1 -DKWSYS_CXX_HAS_ENVIRON_IN_STDLIB_H=0 -DKWSYS_CXX_HAS_UTIMENSAT=0 -DKWSYS_CXX_HAS_UTIMES=0 -c /usr/local/build/cmake-3.0.2/Source/kwsys/SystemTools.cxx -o SystemTools.o /opt/solarisstudio12.3/bin/cc -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /usr/local/build/cmake-3.0.2/Source/kwsys/EncodingC.c -o EncodingC.o /opt/solarisstudio12.3/bin/cc -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /usr/local/build/cmake-3.0.2/Source/kwsys/ProcessUNIX.c -o ProcessUNIX.o /opt/solarisstudio12.3/bin/cc -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -DKWSYS_STRING_C -c /usr/local/build/cmake-3.0.2/Source/kwsys/String.c -o String.o /opt/solarisstudio12.3/bin/cc -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /usr/local/build/cmake-3.0.2/Source/kwsys/System.c -o System.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk cmStandardIncludes.o cmake.o cmakemain.o cmcmd.o cmCommandArgumentLexer.o cmCommandArgumentParser.o cmCommandArgumentParserHelper.o cmDefinitions.o cmDepends.o cmDependsC.o cmDocumentationFormatter.o cmPolicies.o cmProperty.o cmPropertyMap.o cmPropertyDefinition.o cmPropertyDefinitionMap.o cmMakeDepend.o cmMakefile.o cmExportFileGenerator.o cmExportInstallFileGenerator.o cmExportTryCompileFileGenerator.o cmExportSet.o cmExportSetMap.o cmInstallDirectoryGenerator.o cmGeneratedFileStream.o cmGeneratorTarget.o cmGeneratorExpressionDAGChecker.o cmGeneratorExpressionEvaluator.o cmGeneratorExpressionLexer.o cmGeneratorExpressionParser.o cmGeneratorExpression.o cmGlobalGenerator.o cmLocalGenerator.o cmInstallGenerator.o cmInstallExportGenerator.o cmInstallFilesGenerator.o cmInstallScriptGenerator.o cmInstallTargetGenerator.o cmScriptGenerator.o cmSourceFile.o cmSourceFileLocation.o cmSystemTools.o cmTestGenerator.o cmVersion.o cmFileTimeComparison.o cmGlobalUnixMakefileGenerator3.o cmLocalUnixMakefileGenerator3.o cmMakefileExecutableTargetGenerator.o cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o cmMakefileUtilityTargetGenerator.o cmOSXBundleGenerator.o cmNewLineStyle.o cmBootstrapCommands1.o cmBootstrapCommands2.o cmCommandsForBootstrap.o cmTarget.o cmTest.o cmCustomCommand.o cmCustomCommandGenerator.o cmCacheManager.o cmListFileCache.o cmComputeLinkDepends.o cmComputeLinkInformation.o cmOrderDirectories.o cmComputeTargetDepends.o cmComputeComponentGraph.o cmExprLexer.o cmExprParser.o cmExprParserHelper.o cmGlobalNinjaGenerator.o cmLocalNinjaGenerator.o cmNinjaTargetGenerator.o cmNinjaNormalTargetGenerator.o cmNinjaUtilityTargetGenerator.o cmListFileLexer.o Directory.o EncodingCXX.o Glob.o RegularExpression.o SystemTools.o EncodingC.o ProcessUNIX.o String.o System.o -o cmake loading initial cache file /usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk/InitialCacheFlags.cmake -- The C compiler identification is SunPro 5.12.0 -- The CXX compiler identification is SunPro 5.12.0 -- Check for working C compiler: /opt/solarisstudio12.3/bin/cc -- Check for working C compiler: /opt/solarisstudio12.3/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /opt/solarisstudio12.3/bin/CC -- Check for working CXX compiler: /opt/solarisstudio12.3/bin/CC -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available -- Checking whether header cstddef is available - no -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator!= for char* - yes -- Checking whether stl has iterator_traits -- Checking whether stl has iterator_traits - no -- Checking whether stl has old iterator_category -- Checking whether stl has old iterator_category - no -- Checking whether stl has internal __iterator_category -- Checking whether stl has internal __iterator_category - yes -- Checking whether stl has standard template allocator -- Checking whether stl has standard template allocator - yes -- Checking for rebind member of stl allocator -- Checking for rebind member of stl allocator - no -- Checking for non-standard argument to stl allocator<>::max_size -- Checking for non-standard argument to stl allocator<>::max_size - yes -- Checking whether stl containers support allocator objects. -- Checking whether stl containers support allocator objects. - yes -- Checking whether ios has binary openmode -- Checking whether ios has binary openmode - yes -- Checking whether "<>" is needed for template friends -- Checking whether "<>" is needed for template friends - yes -- Checking for member template support -- Checking for member template support - yes -- Checking for standard template specialization syntax -- Checking for standard template specialization syntax - yes -- Checking whether argument dependent lookup is supported -- Checking whether argument dependent lookup is supported - yes -- Checking whether struct stat has st_mtim member -- Checking whether struct stat has st_mtim member - yes -- Checking whether C++ compiler has 'long long' -- Checking whether C++ compiler has 'long long' - yes -- Checking whether C++ compiler has '__int64' -- Checking whether C++ compiler has '__int64' - no -- Checking for C type size macros -- Checking for C type size macros - compiled -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of char -- Check size of char - done -- Check size of short -- Check size of short - done -- Check size of int -- Check size of int - done -- Check size of long -- Check size of long - done -- Check size of long long -- Check size of long long - done -- Check size of __int64 -- Check size of __int64 - failed -- Checking whether char is signed -- Checking whether char is signed - yes -- Checking whether wstring is available -- Checking whether wstring is available - yes -- Checking if istream supports long long -- Checking if istream supports long long - yes -- Checking if ostream supports long long -- Checking if ostream supports long long - yes -- Checking whether C compiler has ptrdiff_t in stddef.h -- Checking whether C compiler has ptrdiff_t in stddef.h - yes -- Checking whether C compiler has ssize_t in unistd.h -- Checking whether C compiler has ssize_t in unistd.h - yes -- Checking whether CXX compiler has setenv -- Checking whether CXX compiler has setenv - yes -- Checking whether CXX compiler has unsetenv -- Checking whether CXX compiler has unsetenv - yes -- Checking whether CXX compiler has environ in stdlib.h -- Checking whether CXX compiler has environ in stdlib.h - no -- Checking whether CXX compiler has utimes -- Checking whether CXX compiler has utimes - yes -- Checking whether CXX compiler has utimensat -- Checking whether CXX compiler has utimensat - yes -- Looking for include files sys/types.h, ifaddrs.h -- Looking for include files sys/types.h, ifaddrs.h - not found -- Checking whether CXX compiler has rlimit64 -- Checking whether CXX compiler has rlimit64 - yes -- Checking whether CXX compiler has atol -- Checking whether CXX compiler has atol - yes -- Checking whether CXX compiler has atoll -- Checking whether CXX compiler has atoll - yes -- Checking whether CXX compiler has _atoi64 -- Checking whether CXX compiler has _atoi64 - no -- Looking for C++ include execinfo.h -- Looking for C++ include execinfo.h - not found -- Looking for connect in socket;dl -- Looking for connect in socket;dl - found -- Looking for gethostbyname in c -- Looking for gethostbyname in c - not found -- Looking for recv in network;dl;socket -- Looking for recv in network;dl;socket - not found -- Looking for gethostbyname in nsl;dl;socket -- Looking for gethostbyname in nsl;dl;socket - found -- Looking for getch in ws2_32;dl;socket;nsl -- Looking for getch in ws2_32;dl;socket;nsl - not found -- Looking for getch in winmm;dl;socket;nsl -- Looking for getch in winmm;dl;socket;nsl - not found -- Looking for idna_to_ascii_lz in idn;dl;socket;nsl -- Looking for idna_to_ascii_lz in idn;dl;socket;nsl - found -- Looking for dlopen in dl;socket;nsl;idn -- Looking for dlopen in dl;socket;nsl;idn - found -- Looking for process.h -- Looking for process.h - not found -- Looking for features.h -- Looking for features.h - not found -- Looking for include file stdio.h -- Looking for include file stdio.h - found -- Looking for 4 include files stdio.h, ..., inttypes.h -- Looking for 4 include files stdio.h, ..., inttypes.h - found -- Looking for 5 include files stdio.h, ..., alloca.h -- Looking for 5 include files stdio.h, ..., alloca.h - found -- Looking for 6 include files stdio.h, ..., arpa/inet.h -- Looking for 6 include files stdio.h, ..., arpa/inet.h - found -- Looking for 7 include files stdio.h, ..., dlfcn.h -- Looking for 7 include files stdio.h, ..., dlfcn.h - found -- Looking for 8 include files stdio.h, ..., fcntl.h -- Looking for 8 include files stdio.h, ..., fcntl.h - found -- Looking for 9 include files stdio.h, ..., malloc.h -- Looking for 9 include files stdio.h, ..., malloc.h - found -- Looking for 10 include files stdio.h, ..., memory.h -- Looking for 10 include files stdio.h, ..., memory.h - found -- Looking for 11 include files stdio.h, ..., netdb.h -- Looking for 11 include files stdio.h, ..., netdb.h - found -- Looking for 12 include files stdio.h, ..., sys/poll.h -- Looking for 12 include files stdio.h, ..., sys/poll.h - found -- Looking for 13 include files stdio.h, ..., assert.h -- Looking for 13 include files stdio.h, ..., assert.h - found -- Looking for 14 include files stdio.h, ..., limits.h -- Looking for 14 include files stdio.h, ..., limits.h - found -- Looking for 15 include files stdio.h, ..., sys/socket.h -- Looking for 15 include files stdio.h, ..., sys/socket.h - found -- Looking for 16 include files stdio.h, ..., netinet/in.h -- Looking for 16 include files stdio.h, ..., netinet/in.h - found -- Looking for 17 include files stdio.h, ..., net/if.h -- Looking for 17 include files stdio.h, ..., net/if.h - found -- Looking for 18 include files stdio.h, ..., netinet/if_ether.h -- Looking for 18 include files stdio.h, ..., netinet/if_ether.h - found -- Looking for 19 include files stdio.h, ..., netinet/tcp.h -- Looking for 19 include files stdio.h, ..., netinet/tcp.h - found -- Looking for 20 include files stdio.h, ..., sys/select.h -- Looking for 20 include files stdio.h, ..., sys/select.h - found -- Looking for 21 include files stdio.h, ..., utime.h -- Looking for 21 include files stdio.h, ..., utime.h - found -- Looking for 23 include files stdio.h, ..., pwd.h -- Looking for 23 include files stdio.h, ..., pwd.h - found -- Looking for 24 include files stdio.h, ..., sgtty.h -- Looking for 24 include files stdio.h, ..., sgtty.h - found -- Looking for 26 include files stdio.h, ..., stdlib.h -- Looking for 26 include files stdio.h, ..., stdlib.h - found -- Looking for 27 include files stdio.h, ..., string.h -- Looking for 27 include files stdio.h, ..., string.h - found -- Looking for 28 include files stdio.h, ..., strings.h -- Looking for 28 include files stdio.h, ..., strings.h - found -- Looking for 29 include files stdio.h, ..., sys/param.h -- Looking for 29 include files stdio.h, ..., sys/param.h - found -- Looking for 30 include files stdio.h, ..., sys/stat.h -- Looking for 30 include files stdio.h, ..., sys/stat.h - found -- Looking for 31 include files stdio.h, ..., sys/time.h -- Looking for 31 include files stdio.h, ..., sys/time.h - found -- Looking for 32 include files stdio.h, ..., sys/resource.h -- Looking for 32 include files stdio.h, ..., sys/resource.h - found -- Looking for 33 include files stdio.h, ..., termios.h -- Looking for 33 include files stdio.h, ..., termios.h - found -- Looking for 34 include files stdio.h, ..., termio.h -- Looking for 34 include files stdio.h, ..., termio.h - found -- Looking for 35 include files stdio.h, ..., io.h -- Looking for 35 include files stdio.h, ..., io.h - not found -- Looking for 35 include files stdio.h, ..., time.h -- Looking for 35 include files stdio.h, ..., time.h - found -- Looking for 36 include files stdio.h, ..., unistd.h -- Looking for 36 include files stdio.h, ..., unistd.h - found -- Looking for 37 include files stdio.h, ..., sys/utime.h -- Looking for 37 include files stdio.h, ..., sys/utime.h - found -- Looking for 38 include files stdio.h, ..., sockio.h -- Looking for 38 include files stdio.h, ..., sockio.h - not found -- Looking for 38 include files stdio.h, ..., sys/sockio.h -- Looking for 38 include files stdio.h, ..., sys/sockio.h - found -- Looking for 39 include files stdio.h, ..., x509.h -- Looking for 39 include files stdio.h, ..., x509.h - not found -- Looking for 39 include files stdio.h, ..., locale.h -- Looking for 39 include files stdio.h, ..., locale.h - found -- Looking for 40 include files stdio.h, ..., setjmp.h -- Looking for 40 include files stdio.h, ..., setjmp.h - found -- Looking for 41 include files stdio.h, ..., signal.h -- Looking for 41 include files stdio.h, ..., signal.h - found -- Looking for 42 include files stdio.h, ..., sys/ioctl.h -- Looking for 42 include files stdio.h, ..., sys/ioctl.h - found -- Looking for 43 include files stdio.h, ..., sys/utsname.h -- Looking for 43 include files stdio.h, ..., sys/utsname.h - found -- Looking for 44 include files stdio.h, ..., idn-free.h -- Looking for 44 include files stdio.h, ..., idn-free.h - not found -- Looking for 44 include files stdio.h, ..., idna.h -- Looking for 44 include files stdio.h, ..., idna.h - not found -- Looking for 44 include files stdio.h, ..., tld.h -- Looking for 44 include files stdio.h, ..., tld.h - not found -- Looking for 44 include files stdio.h, ..., arpa/tftp.h -- Looking for 44 include files stdio.h, ..., arpa/tftp.h - found -- Looking for 45 include files stdio.h, ..., errno.h -- Looking for 45 include files stdio.h, ..., errno.h - found -- Looking for 46 include files stdio.h, ..., libgen.h -- Looking for 46 include files stdio.h, ..., libgen.h - found -- Looking for 47 include files stdio.h, ..., sys/filio.h -- Looking for 47 include files stdio.h, ..., sys/filio.h - found -- Check size of size_t -- Check size of size_t - done -- Check size of ssize_t -- Check size of ssize_t - done -- Check size of long long -- Check size of long long - done -- Check size of long -- Check size of long - done -- Check size of __int64 -- Check size of __int64 - failed -- Check size of time_t -- Check size of time_t - done -- Looking for basename -- Looking for basename - found -- Looking for socket -- Looking for socket - found -- Looking for poll -- Looking for poll - found -- Looking for select -- Looking for select - found -- Looking for strdup -- Looking for strdup - found -- Looking for strstr -- Looking for strstr - found -- Looking for strtok_r -- Looking for strtok_r - found -- Looking for strftime -- Looking for strftime - found -- Looking for uname -- Looking for uname - found -- Looking for strcasecmp -- Looking for strcasecmp - found -- Looking for stricmp -- Looking for stricmp - not found -- Looking for strcmpi -- Looking for strcmpi - not found -- Looking for strncmpi -- Looking for strncmpi - not found -- Looking for gethostbyaddr -- Looking for gethostbyaddr - found -- Looking for gettimeofday -- Looking for gettimeofday - found -- Looking for inet_addr -- Looking for inet_addr - found -- Looking for inet_pton -- Looking for inet_pton - found -- Looking for inet_ntoa -- Looking for inet_ntoa - found -- Looking for inet_ntoa_r -- Looking for inet_ntoa_r - not found -- Looking for tcsetattr -- Looking for tcsetattr - found -- Looking for tcgetattr -- Looking for tcgetattr - found -- Looking for perror -- Looking for perror - found -- Looking for closesocket -- Looking for closesocket - not found -- Looking for setvbuf -- Looking for setvbuf - found -- Looking for sigsetjmp -- Looking for sigsetjmp - found -- Looking for getpass_r -- Looking for getpass_r - not found -- Looking for getpwuid -- Looking for getpwuid - found -- Looking for geteuid -- Looking for geteuid - found -- Looking for utime -- Looking for utime - found -- Looking for gmtime_r -- Looking for gmtime_r - found -- Looking for localtime_r -- Looking for localtime_r - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for gethostbyname_r -- Looking for gethostbyname_r - found -- Looking for gethostbyaddr_r -- Looking for gethostbyaddr_r - found -- Looking for signal -- Looking for signal - found -- Looking for SIGALRM -- Looking for SIGALRM - found -- Looking for strtoll -- Looking for strtoll - found -- Looking for _strtoi64 -- Looking for _strtoi64 - not found -- Looking for strerror_r -- Looking for strerror_r - found -- Looking for siginterrupt -- Looking for siginterrupt - found -- Looking for fork -- Looking for fork - found -- Looking for pipe -- Looking for pipe - found -- Looking for ftruncate -- Looking for ftruncate - found -- Looking for getprotobyname -- Looking for getprotobyname - found -- Looking for getrlimit -- Looking for getrlimit - found -- Looking for idn_free -- Looking for idn_free - not found -- Looking for idna_strerror -- Looking for idna_strerror - not found -- Looking for tld_strerror -- Looking for tld_strerror - not found -- Looking for setlocale -- Looking for setlocale - found -- Looking for setrlimit -- Looking for setrlimit - found -- Looking for sigaction -- Looking for sigaction - found -- Performing Curl Test HAVE_FIONBIO -- Performing Curl Test HAVE_FIONBIO - Failed -- Performing Curl Test HAVE_IOCTLSOCKET -- Performing Curl Test HAVE_IOCTLSOCKET - Failed -- Performing Curl Test HAVE_IOCTLSOCKET_CASE -- Performing Curl Test HAVE_IOCTLSOCKET_CASE - Failed -- Performing Curl Test HAVE_O_NONBLOCK -- Performing Curl Test HAVE_O_NONBLOCK - Success -- Performing Curl Test HAVE_SO_NONBLOCK -- Performing Curl Test HAVE_SO_NONBLOCK - Failed -- Performing Curl Test TIME_WITH_SYS_TIME -- Performing Curl Test TIME_WITH_SYS_TIME - Success -- Performing Curl Test HAVE_O_NONBLOCKHAVE_GETHOSTBYADDR_R_5 -- Performing Curl Test HAVE_O_NONBLOCKHAVE_GETHOSTBYADDR_R_5 - Failed -- Performing Curl Test HAVE_GETHOSTBYADDR_R_7 -- Performing Curl Test HAVE_GETHOSTBYADDR_R_7 - Success -- Performing Curl Test HAVE_GETHOSTBYADDR_R_8 -- Performing Curl Test HAVE_GETHOSTBYADDR_R_8 - Failed -- Performing Curl Test HAVE_GETHOSTBYADDR_R_5_REENTRANT -- Performing Curl Test HAVE_GETHOSTBYADDR_R_5_REENTRANT - Failed -- Performing Curl Test HAVE_GETHOSTBYADDR_R_7_REENTRANT -- Performing Curl Test HAVE_GETHOSTBYADDR_R_7_REENTRANT - Success -- Performing Curl Test HAVE_GETHOSTBYADDR_R_8_REENTRANT -- Performing Curl Test HAVE_GETHOSTBYADDR_R_8_REENTRANT - Failed -- Performing Curl Test HAVE_GETHOSTBYNAME_R_3 -- Performing Curl Test HAVE_GETHOSTBYNAME_R_3 - Failed -- Performing Curl Test HAVE_GETHOSTBYNAME_R_5 -- Performing Curl Test HAVE_GETHOSTBYNAME_R_5 - Success -- Performing Curl Test HAVE_GETHOSTBYNAME_R_6 -- Performing Curl Test HAVE_GETHOSTBYNAME_R_6 - Failed -- Performing Curl Test HAVE_GETHOSTBYNAME_R_3_REENTRANT -- Performing Curl Test HAVE_GETHOSTBYNAME_R_3_REENTRANT - Failed -- Performing Curl Test HAVE_GETHOSTBYNAME_R_5_REENTRANT -- Performing Curl Test HAVE_GETHOSTBYNAME_R_5_REENTRANT - Success -- Performing Curl Test HAVE_GETHOSTBYNAME_R_6_REENTRANT -- Performing Curl Test HAVE_GETHOSTBYNAME_R_6_REENTRANT - Failed -- Performing Curl Test HAVE_SOCKLEN_T -- Performing Curl Test HAVE_SOCKLEN_T - Success -- Performing Curl Test HAVE_IN_ADDR_T -- Performing Curl Test HAVE_IN_ADDR_T - Success -- Performing Curl Test STDC_HEADERS -- Performing Curl Test STDC_HEADERS - Success -- Performing Curl Test RETSIGTYPE_TEST -- Performing Curl Test RETSIGTYPE_TEST - Success -- Performing Curl Test HAVE_INET_NTOA_R_DECL -- Performing Curl Test HAVE_INET_NTOA_R_DECL - Failed -- Performing Curl Test HAVE_INET_NTOA_R_DECL_REENTRANT -- Performing Curl Test HAVE_INET_NTOA_R_DECL_REENTRANT - Failed -- Performing Curl Test HAVE_GETADDRINFO -- Performing Curl Test HAVE_GETADDRINFO - Success -- Performing Curl Test HAVE_FILE_OFFSET_BITS -- Performing Curl Test HAVE_FILE_OFFSET_BITS - Success -- Check size of curl_off_t -- Check size of curl_off_t - done -- Performing Test curl_cv_recv -- Performing Test curl_cv_recv - Success -- Performing Test int recv(int, void *, size_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, size_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, void *, size_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, size_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, void *, int, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, void *, int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, void *, socklen_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, socklen_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, void *, socklen_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, socklen_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, void *, unsigned int, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, unsigned int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, void *, unsigned int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, unsigned int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, size_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, size_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, size_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, size_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, int, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, socklen_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, socklen_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, socklen_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, socklen_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, unsigned int, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, unsigned int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, unsigned int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, unsigned int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, size_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, size_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, size_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, size_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, int, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, socklen_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, socklen_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, socklen_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, socklen_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, unsigned int, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, unsigned int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, unsigned int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, unsigned int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, size_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, size_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, size_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, size_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, int, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, socklen_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, socklen_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, socklen_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, socklen_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, unsigned int, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, unsigned int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, unsigned int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, unsigned int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, size_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, size_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, size_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, size_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, int, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, socklen_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, socklen_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, socklen_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, socklen_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, unsigned int, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, unsigned int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, unsigned int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, unsigned int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, size_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, size_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, size_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, size_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, int, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, socklen_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, socklen_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, socklen_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, socklen_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, unsigned int, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, unsigned int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, unsigned int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, unsigned int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test ssize_t recv(int, void *, size_t, int) (curl_cv_func_recv_test) -- Performing Test ssize_t recv(int, void *, size_t, int) (curl_cv_func_recv_test) - Success -- Performing Test curl_cv_send -- Performing Test curl_cv_send - Success -- Performing Test int send(int, const void *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const void *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const void *, int, int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const void *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const void *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const void *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const void *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const void *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, int, int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, int, int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, int, int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test ssize_t send(int, const void *, size_t, int) (curl_cv_func_send_test) -- Performing Test ssize_t send(int, const void *, size_t, int) (curl_cv_func_send_test) - Success -- Performing Test HAVE_MSG_NOSIGNAL -- Performing Test HAVE_MSG_NOSIGNAL - Failed -- Performing Test HAVE_STRUCT_TIMEVAL -- Performing Test HAVE_STRUCT_TIMEVAL - Success -- Check size of sig_atomic_t -- Check size of sig_atomic_t - done -- Performing Test HAVE_SIG_ATOMIC_T_NOT_VOLATILE -- Performing Test HAVE_SIG_ATOMIC_T_NOT_VOLATILE - Success -- Check size of struct sockaddr_storage -- Check size of struct sockaddr_storage - done -- Found ZLIB: cmzlib -- Found BZip2: cmbzip2 (found version "1.0.5") -- Looking for BZ2_bzCompressInit in cmbzip2 -- Looking for BZ2_bzCompressInit in cmbzip2 - not found -- Performing Test HAVE_DIRENT_H -- Performing Test HAVE_DIRENT_H - Success -- Looking for include files sys/types.h, acl/libacl.h -- Looking for include files sys/types.h, acl/libacl.h - not found -- Looking for include files sys/types.h, ctype.h -- Looking for include files sys/types.h, ctype.h - found -- Looking for 3 include files sys/types.h, ..., copyfile.h -- Looking for 3 include files sys/types.h, ..., copyfile.h - not found -- Looking for 3 include files sys/types.h, ..., direct.h -- Looking for 3 include files sys/types.h, ..., direct.h - not found -- Looking for 5 include files sys/types.h, ..., ext2fs/ext2_fs.h -- Looking for 5 include files sys/types.h, ..., ext2fs/ext2_fs.h - not found -- Performing Test HAVE_WORKING_EXT2_IOC_GETFLAGS -- Performing Test HAVE_WORKING_EXT2_IOC_GETFLAGS - Failed -- Looking for 6 include files sys/types.h, ..., grp.h -- Looking for 6 include files sys/types.h, ..., grp.h - found -- Looking for 8 include files sys/types.h, ..., langinfo.h -- Looking for 8 include files sys/types.h, ..., langinfo.h - found -- Looking for 10 include files sys/types.h, ..., linux/types.h -- Looking for 10 include files sys/types.h, ..., linux/types.h - not found -- Looking for 10 include files sys/types.h, ..., linux/fiemap.h -- Looking for 10 include files sys/types.h, ..., linux/fiemap.h - not found -- Looking for 10 include files sys/types.h, ..., linux/fs.h -- Looking for 10 include files sys/types.h, ..., linux/fs.h - not found -- Looking for 10 include files sys/types.h, ..., linux/magic.h -- Looking for 10 include files sys/types.h, ..., linux/magic.h - not found -- Looking for 12 include files sys/types.h, ..., paths.h -- Looking for 12 include files sys/types.h, ..., paths.h - not found -- Looking for 12 include files sys/types.h, ..., poll.h -- Looking for 12 include files sys/types.h, ..., poll.h - found -- Looking for 14 include files sys/types.h, ..., regex.h -- Looking for 14 include files sys/types.h, ..., regex.h - found -- Looking for 16 include files sys/types.h, ..., spawn.h -- Looking for 16 include files sys/types.h, ..., spawn.h - found -- Looking for 17 include files sys/types.h, ..., stdarg.h -- Looking for 17 include files sys/types.h, ..., stdarg.h - found -- Looking for 22 include files sys/types.h, ..., sys/acl.h -- Looking for 22 include files sys/types.h, ..., sys/acl.h - found -- Looking for 23 include files sys/types.h, ..., sys/cdefs.h -- Looking for 23 include files sys/types.h, ..., sys/cdefs.h - not found -- Looking for 24 include files sys/types.h, ..., sys/mkdev.h -- Looking for 24 include files sys/types.h, ..., sys/mkdev.h - found -- Looking for 25 include files sys/types.h, ..., sys/mount.h -- Looking for 25 include files sys/types.h, ..., sys/mount.h - found -- Looking for 30 include files sys/types.h, ..., sys/statfs.h -- Looking for 30 include files sys/types.h, ..., sys/statfs.h - found -- Looking for 31 include files sys/types.h, ..., sys/statvfs.h -- Looking for 31 include files sys/types.h, ..., sys/statvfs.h - found -- Looking for 35 include files sys/types.h, ..., sys/vfs.h -- Looking for 35 include files sys/types.h, ..., sys/vfs.h - found -- Looking for 36 include files sys/types.h, ..., sys/wait.h -- Looking for 36 include files sys/types.h, ..., sys/wait.h - found -- Looking for 40 include files sys/types.h, ..., wchar.h -- Looking for 40 include files sys/types.h, ..., wchar.h - found -- Looking for 41 include files sys/types.h, ..., wctype.h -- Looking for 41 include files sys/types.h, ..., wctype.h - found -- Looking for 42 include files sys/types.h, ..., windows.h -- Looking for 42 include files sys/types.h, ..., windows.h - not found -- Looking for 42 include files sys/types.h, ..., wincrypt.h -- Looking for 42 include files sys/types.h, ..., wincrypt.h - not found -- Looking for 42 include files sys/types.h, ..., winioctl.h -- Looking for 42 include files sys/types.h, ..., winioctl.h - not found -- Performing Test SAFE_TO_DEFINE_EXTENSIONS -- Performing Test SAFE_TO_DEFINE_EXTENSIONS - Success -- Looking for MD5Init in md -- Looking for MD5Init in md - found -- Looking for _CrtSetReportMode -- Looking for _CrtSetReportMode - not found -- Looking for chflags -- Looking for chflags - not found -- Looking for chown -- Looking for chown - found -- Looking for chroot -- Looking for chroot - found -- Looking for ctime_r -- Looking for ctime_r - found -- Looking for dirfd -- Looking for dirfd - not found -- Looking for fchdir -- Looking for fchdir - found -- Looking for fchflags -- Looking for fchflags - not found -- Looking for fchmod -- Looking for fchmod - found -- Looking for fchown -- Looking for fchown - found -- Looking for fcntl -- Looking for fcntl - found -- Looking for fdopendir -- Looking for fdopendir - found -- Looking for fstat -- Looking for fstat - found -- Looking for fstatat -- Looking for fstatat - found -- Looking for fstatfs -- Looking for fstatfs - found -- Looking for fstatvfs -- Looking for fstatvfs - found -- Looking for futimens -- Looking for futimens - found -- Looking for futimes -- Looking for futimes - not found -- Looking for futimesat -- Looking for futimesat - found -- Looking for getgrgid_r -- Looking for getgrgid_r - found -- Looking for getgrnam_r -- Looking for getgrnam_r - found -- Looking for getpwnam_r -- Looking for getpwnam_r - found -- Looking for getpwuid_r -- Looking for getpwuid_r - found -- Looking for getpid -- Looking for getpid - found -- Looking for getvfsbyname -- Looking for getvfsbyname - not found -- Looking for lchflags -- Looking for lchflags - not found -- Looking for lchmod -- Looking for lchmod - not found -- Looking for lchown -- Looking for lchown - found -- Looking for link -- Looking for link - found -- Looking for lstat -- Looking for lstat - found -- Looking for lutimes -- Looking for lutimes - not found -- Looking for mbrtowc -- Looking for mbrtowc - found -- Looking for memmove -- Looking for memmove - found -- Looking for mkdir -- Looking for mkdir - found -- Looking for mkfifo -- Looking for mkfifo - found -- Looking for mknod -- Looking for mknod - found -- Looking for mkstemp -- Looking for mkstemp - found -- Looking for nl_langinfo -- Looking for nl_langinfo - found -- Looking for openat -- Looking for openat - found -- Looking for posix_spawnp -- Looking for posix_spawnp - found -- Looking for readlink -- Looking for readlink - found -- Looking for setenv -- Looking for setenv - found -- Looking for statfs -- Looking for statfs - found -- Looking for statvfs -- Looking for statvfs - found -- Looking for strchr -- Looking for strchr - found -- Looking for strerror -- Looking for strerror - found -- Looking for strncpy_s -- Looking for strncpy_s - not found -- Looking for strrchr -- Looking for strrchr - found -- Looking for symlink -- Looking for symlink - found -- Looking for timegm -- Looking for timegm - not found -- Looking for tzset -- Looking for tzset - found -- Looking for utimes -- Looking for utimes - found -- Looking for utimensat -- Looking for utimensat - found -- Looking for vfork -- Looking for vfork - found -- Looking for wcrtomb -- Looking for wcrtomb - found -- Looking for wcscmp -- Looking for wcscmp - found -- Looking for wcscpy -- Looking for wcscpy - found -- Looking for wcslen -- Looking for wcslen - found -- Looking for wctomb -- Looking for wctomb - found -- Looking for _ctime64_s -- Looking for _ctime64_s - not found -- Looking for _fseeki64 -- Looking for _fseeki64 - not found -- Looking for _get_timezone -- Looking for _get_timezone - not found -- Looking for _localtime64_s -- Looking for _localtime64_s - not found -- Looking for _mkgmtime64 -- Looking for _mkgmtime64 - not found -- Looking for cygwin_conv_path -- Looking for cygwin_conv_path - not found -- Looking for fseeko -- Looking for fseeko - found -- Looking for vprintf -- Looking for vprintf - found -- Looking for wmemcmp -- Looking for wmemcmp - found -- Looking for wmemcpy -- Looking for wmemcpy - found -- Performing Test HAVE_READDIR_R -- Performing Test HAVE_READDIR_R - Success -- Performing Test HAVE_READLINKAT -- Performing Test HAVE_READLINKAT - Failed -- Performing Test MAJOR_IN_MKDEV -- Performing Test MAJOR_IN_MKDEV - Success -- Performing Test MAJOR_IN_SYSMACROS -- Performing Test MAJOR_IN_SYSMACROS - Success -- Looking for EFTYPE -- Looking for EFTYPE - not found -- Looking for EILSEQ -- Looking for EILSEQ - found -- Looking for D_MD_ORDER -- Looking for D_MD_ORDER - not found -- Looking for INT64_MAX -- Looking for INT64_MAX - found -- Looking for INT64_MIN -- Looking for INT64_MIN - found -- Looking for UINT32_MAX -- Looking for UINT32_MAX - found -- Looking for UINT64_MAX -- Looking for UINT64_MAX - found -- Looking for SIZE_MAX -- Looking for SIZE_MAX - found -- Looking for SSIZE_MAX -- Looking for SSIZE_MAX - found -- Performing Test HAVE_STRUCT_TM_TM_GMTOFF -- Performing Test HAVE_STRUCT_TM_TM_GMTOFF - Failed -- Performing Test HAVE_STRUCT_TM___TM_GMTOFF -- Performing Test HAVE_STRUCT_TM___TM_GMTOFF - Failed -- Performing Test HAVE_STRUCT_STATFS_F_NAMEMAX -- Performing Test HAVE_STRUCT_STATFS_F_NAMEMAX - Failed -- Performing Test HAVE_STRUCT_STAT_ST_BIRTHTIME -- Performing Test HAVE_STRUCT_STAT_ST_BIRTHTIME - Failed -- Performing Test HAVE_STRUCT_STAT_ST_BIRTHTIMESPEC_TV_NSEC -- Performing Test HAVE_STRUCT_STAT_ST_BIRTHTIMESPEC_TV_NSEC - Failed -- Performing Test HAVE_STRUCT_STAT_ST_MTIMESPEC_TV_NSEC -- Performing Test HAVE_STRUCT_STAT_ST_MTIMESPEC_TV_NSEC - Failed -- Performing Test HAVE_STRUCT_STAT_ST_MTIM_TV_NSEC -- Performing Test HAVE_STRUCT_STAT_ST_MTIM_TV_NSEC - Success -- Performing Test HAVE_STRUCT_STAT_ST_MTIME_N -- Performing Test HAVE_STRUCT_STAT_ST_MTIME_N - Failed -- Performing Test HAVE_STRUCT_STAT_ST_UMTIME -- Performing Test HAVE_STRUCT_STAT_ST_UMTIME - Failed -- Performing Test HAVE_STRUCT_STAT_ST_MTIME_USEC -- Performing Test HAVE_STRUCT_STAT_ST_MTIME_USEC - Failed -- Performing Test HAVE_STRUCT_STAT_ST_BLKSIZE -- Performing Test HAVE_STRUCT_STAT_ST_BLKSIZE - Success -- Performing Test HAVE_STRUCT_STAT_ST_FLAGS -- Performing Test HAVE_STRUCT_STAT_ST_FLAGS - Failed -- Performing Test HAVE_STRUCT_STATVFS_F_IOSIZE -- Performing Test HAVE_STRUCT_STATVFS_F_IOSIZE - Failed -- Check size of short -- Check size of short - done -- Check size of int -- Check size of int - done -- Check size of long -- Check size of long - done -- Check size of long long -- Check size of long long - done -- Check size of unsigned short -- Check size of unsigned short - done -- Check size of unsigned -- Check size of unsigned - done -- Check size of unsigned long -- Check size of unsigned long - done -- Check size of unsigned long long -- Check size of unsigned long long - done -- Check size of __int64 -- Check size of __int64 - failed -- Check size of unsigned __int64 -- Check size of unsigned __int64 - failed -- Check size of int16_t -- Check size of int16_t - done -- Check size of int32_t -- Check size of int32_t - done -- Check size of int64_t -- Check size of int64_t - done -- Check size of intmax_t -- Check size of intmax_t - done -- Check size of uint8_t -- Check size of uint8_t - done -- Check size of uint16_t -- Check size of uint16_t - done -- Check size of uint32_t -- Check size of uint32_t - done -- Check size of uint64_t -- Check size of uint64_t - done -- Check size of uintmax_t -- Check size of uintmax_t - done -- Check size of dev_t -- Check size of dev_t - done -- Check size of gid_t -- Check size of gid_t - done -- Check size of id_t -- Check size of id_t - done -- Check size of mode_t -- Check size of mode_t - done -- Check size of off_t -- Check size of off_t - done -- Check size of size_t -- Check size of size_t - done -- Check size of ssize_t -- Check size of ssize_t - done -- Check size of uid_t -- Check size of uid_t - done -- Check size of pid_t -- Check size of pid_t - done -- Check size of intptr_t -- Check size of intptr_t - done -- Check size of uintptr_t -- Check size of uintptr_t - done -- Check size of wchar_t -- Check size of wchar_t - done -- Checking _FILE_OFFSET_BITS for large files -- Checking _FILE_OFFSET_BITS for large files - not needed -- Checking support for ARCHIVE_CRYPTO_MD5_LIBC -- Checking support for ARCHIVE_CRYPTO_MD5_LIBC -- not found -- Checking support for ARCHIVE_CRYPTO_RMD160_LIBC -- Checking support for ARCHIVE_CRYPTO_RMD160_LIBC -- not found -- Checking support for ARCHIVE_CRYPTO_SHA1_LIBC -- Checking support for ARCHIVE_CRYPTO_SHA1_LIBC -- not found -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBC -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBC -- not found -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBC -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBC -- not found -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBC -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBC -- not found -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBC2 -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBC2 -- not found -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBC2 -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBC2 -- not found -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBC2 -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBC2 -- not found -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBC3 -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBC3 -- not found -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBC3 -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBC3 -- not found -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBC3 -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBC3 -- not found -- Checking support for ARCHIVE_CRYPTO_MD5_LIBSYSTEM -- Checking support for ARCHIVE_CRYPTO_MD5_LIBSYSTEM -- not found -- Checking support for ARCHIVE_CRYPTO_SHA1_LIBSYSTEM -- Checking support for ARCHIVE_CRYPTO_SHA1_LIBSYSTEM -- not found -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBSYSTEM -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBSYSTEM -- not found -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBSYSTEM -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBSYSTEM -- not found -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBSYSTEM -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBSYSTEM -- not found -- Checking support for ARCHIVE_CRYPTO_MD5_LIBMD -- Checking support for ARCHIVE_CRYPTO_MD5_LIBMD -- found -- Checking support for ARCHIVE_CRYPTO_RMD160_LIBMD -- Checking support for ARCHIVE_CRYPTO_RMD160_LIBMD -- not found -- Checking support for ARCHIVE_CRYPTO_SHA1_LIBMD -- Checking support for ARCHIVE_CRYPTO_SHA1_LIBMD -- not found -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBMD -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBMD -- not found -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBMD -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBMD -- not found -- Check if the system is big endian -- Searching 16 bit integer -- Check size of unsigned short -- Check size of unsigned short - done -- Using unsigned short -- Check if the system is big endian - big endian -- Looking for wsyncup in /usr/lib/64/libcurses.so -- Looking for wsyncup in /usr/lib/64/libcurses.so - found -- Looking for cbreak in /usr/local/lib/libncurses.a -- Looking for cbreak in /usr/local/lib/libncurses.a - found -- Looking for elf.h -- Looking for elf.h - found -- Looking for a Fortran compiler -- Looking for a Fortran compiler - NOTFOUND -- Configuring done -- Generating done -- Build files have been written to: /usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001 --------------------------------------------- CMake has bootstrapped. Now run /usr/local/bin/gmake. node000 $ node000 $ /usr/local/bin/gmake Scanning dependencies of target cmIML_test [ 0%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test.c.o [ 0%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_ABI_C.c.o [ 0%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_INT_C.c.o [ 1%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_include_C.c.o [ 1%] Building CXX object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_ABI_CXX.cxx.o [ 1%] Building CXX object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_INT_CXX.cxx.o [ 1%] Building CXX object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_include_CXX.cxx.o Linking CXX executable cmIML_test [ 1%] Built target cmIML_test Scanning dependencies of target cmsys [ 1%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/ProcessUNIX.c.o [ 1%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/Base64.c.o [ 2%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/EncodingC.c.o [ 2%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/MD5.c.o [ 2%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/Terminal.c.o [ 2%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/System.c.o [ 3%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/String.c.o [ 3%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/Directory.cxx.o [ 3%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/DynamicLoader.cxx.o [ 3%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/EncodingCXX.cxx.o [ 3%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/Glob.cxx.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/RegularExpression.cxx.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemTools.cxx.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/CommandLineArguments.cxx.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/IOStream.cxx.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemInformation.cxx.o Linking CXX static library libcmsys.a [ 4%] Built target cmsys Scanning dependencies of target cmsysTestDynload [ 5%] Building C object Source/kwsys/CMakeFiles/cmsysTestDynload.dir/testDynload.c.o Linking C shared module libcmsysTestDynload.so [ 5%] Built target cmsysTestDynload Scanning dependencies of target cmsys_c [ 5%] Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/ProcessUNIX.c.o [ 6%] Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/Base64.c.o [ 6%] Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/EncodingC.c.o [ 6%] Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/MD5.c.o [ 6%] Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/Terminal.c.o [ 6%] Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/System.c.o [ 7%] Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/String.c.o Linking C static library libcmsys_c.a [ 7%] Built target cmsys_c Scanning dependencies of target cmsysTestProcess [ 7%] Building C object Source/kwsys/CMakeFiles/cmsysTestProcess.dir/testProcess.c.o Linking C executable cmsysTestProcess [ 7%] Built target cmsysTestProcess Scanning dependencies of target cmsysTestSharedForward [ 7%] Building C object Source/kwsys/CMakeFiles/cmsysTestSharedForward.dir/testSharedForward.c.o Linking C executable cmsysTestSharedForward [ 7%] Built target cmsysTestSharedForward Scanning dependencies of target cmsysTestsC [ 7%] Building C object Source/kwsys/CMakeFiles/cmsysTestsC.dir/cmsysTestsC.c.o [ 8%] Building C object Source/kwsys/CMakeFiles/cmsysTestsC.dir/testEncode.c.o [ 8%] Building C object Source/kwsys/CMakeFiles/cmsysTestsC.dir/testTerminal.c.o Linking C executable cmsysTestsC [ 8%] Built target cmsysTestsC Scanning dependencies of target cmsysTestsCxx [ 8%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/cmsysTestsCxx.cxx.o [ 8%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testAutoPtr.cxx.o [ 8%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testHashSTL.cxx.o [ 9%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testIOS.cxx.o [ 9%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testSystemTools.cxx.o [ 9%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testCommandLineArguments.cxx.o [ 9%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testCommandLineArguments1.cxx.o [ 10%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testEncoding.cxx.o [ 10%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testFStream.cxx.o [ 10%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testSystemInformation.cxx.o [ 10%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testDynamicLoader.cxx.o Linking CXX executable cmsysTestsCxx [ 10%] Built target cmsysTestsCxx Scanning dependencies of target cmzlib [ 10%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/adler32.c.o [ 10%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/compress.c.o [ 10%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/crc32.c.o [ 11%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/deflate.c.o [ 11%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/gzio.c.o [ 11%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/inffast.c.o [ 11%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/inflate.c.o [ 11%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/inftrees.c.o [ 12%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/trees.c.o [ 12%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/uncompr.c.o [ 12%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/zutil.c.o Linking C static library libcmzlib.a [ 12%] Built target cmzlib Scanning dependencies of target cmcurl [ 13%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/base64.c.o [ 13%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/connect.c.o [ 13%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/content_encoding.c.o [ 13%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/cookie.c.o [ 13%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/dict.c.o [ 14%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/easy.c.o [ 14%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/escape.c.o [ 14%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/file.c.o [ 14%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/formdata.c.o [ 15%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/ftp.c.o [ 15%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/getenv.c.o [ 15%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/getinfo.c.o [ 15%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/gtls.c.o [ 15%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hash.c.o [ 16%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hostares.c.o [ 16%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hostasyn.c.o [ 16%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hostip4.c.o [ 16%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hostip6.c.o [ 16%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hostip.c.o [ 17%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hostsyn.c.o [ 17%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hostthre.c.o [ 17%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/http.c.o [ 17%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/http_chunks.c.o [ 18%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/http_digest.c.o [ 18%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/http_negotiate.c.o [ 18%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/http_ntlm.c.o [ 18%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/if2ip.c.o [ 18%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/inet_ntop.c.o [ 19%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/inet_pton.c.o [ 19%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/krb4.c.o [ 19%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/ldap.c.o [ 19%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/llist.c.o [ 20%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/md5.c.o [ 20%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/mprintf.c.o [ 20%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/multi.c.o [ 20%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/netrc.c.o [ 20%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/parsedate.c.o [ 21%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/progress.c.o [ 21%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/security.c.o [ 21%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/select.c.o [ 21%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/sendf.c.o [ 22%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/share.c.o [ 22%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/socks.c.o [ 22%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/speedcheck.c.o [ 22%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/splay.c.o [ 22%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/ssh.c.o [ 23%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/sslgen.c.o [ 23%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/ssluse.c.o [ 23%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/strdup.c.o [ 23%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/strequal.c.o [ 23%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/strerror.c.o [ 24%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/telnet.c.o [ 24%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/tftp.c.o [ 24%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/timeval.c.o [ 24%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/transfer.c.o [ 25%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/url.c.o [ 25%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/version.c.o Linking C static library libcmcurl.a [ 25%] Built target cmcurl Scanning dependencies of target LIBCURL [ 25%] Building C object Utilities/cmcurl/CMakeFiles/LIBCURL.dir/Testing/curltest.c.o Linking C executable LIBCURL [ 25%] Built target LIBCURL Scanning dependencies of target cmcompress [ 25%] Building C object Utilities/cmcompress/CMakeFiles/cmcompress.dir/cmcompress.c.o Linking C static library libcmcompress.a [ 25%] Built target cmcompress Scanning dependencies of target cmbzip2 [ 25%] Building C object Utilities/cmbzip2/CMakeFiles/cmbzip2.dir/blocksort.c.o [ 25%] Building C object Utilities/cmbzip2/CMakeFiles/cmbzip2.dir/huffman.c.o [ 25%] Building C object Utilities/cmbzip2/CMakeFiles/cmbzip2.dir/crctable.c.o [ 25%] Building C object Utilities/cmbzip2/CMakeFiles/cmbzip2.dir/randtable.c.o [ 26%] Building C object Utilities/cmbzip2/CMakeFiles/cmbzip2.dir/compress.c.o [ 26%] Building C object Utilities/cmbzip2/CMakeFiles/cmbzip2.dir/decompress.c.o [ 26%] Building C object Utilities/cmbzip2/CMakeFiles/cmbzip2.dir/bzlib.c.o "/usr/local/build/cmake-3.0.2/Utilities/cmbzip2/bzlib.c", line 857: warning: statement not reached "/usr/local/build/cmake-3.0.2/Utilities/cmbzip2/bzlib.c", line 1218: warning: statement not reached Linking C static library libcmbzip2.a [ 26%] Built target cmbzip2 Scanning dependencies of target cmlibarchive [ 27%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_acl.c.o [ 27%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_check_magic.c.o [ 27%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_cmdline.c.o [ 27%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_crypto.c.o [ 28%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_entry.c.o [ 28%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_entry_copy_stat.c.o [ 28%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_entry_link_resolver.c.o [ 28%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_entry_sparse.c.o [ 28%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_entry_stat.c.o [ 29%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_entry_strmode.c.o [ 29%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_entry_xattr.c.o [ 29%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_getdate.c.o [ 29%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_match.c.o [ 29%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_options.c.o [ 30%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_pathmatch.c.o [ 30%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_ppmd7.c.o [ 30%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_rb.c.o [ 30%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read.c.o [ 31%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_append_filter.c.o [ 31%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_data_into_fd.c.o [ 31%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_disk_entry_from_file.c.o [ 31%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_disk_posix.c.o [ 31%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_disk_set_standard_lookup.c.o [ 32%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_extract.c.o [ 32%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_open_fd.c.o [ 32%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_open_file.c.o [ 32%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_open_filename.c.o [ 33%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_open_memory.c.o [ 33%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_set_format.c.o [ 33%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_set_options.c.o [ 33%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_all.c.o [ 33%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_bzip2.c.o [ 34%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_compress.c.o [ 34%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_gzip.c.o [ 34%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_grzip.c.o [ 34%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_lrzip.c.o [ 34%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_lzop.c.o [ 35%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_none.c.o [ 35%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_program.c.o [ 35%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_rpm.c.o [ 35%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_uu.c.o [ 36%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_xz.c.o [ 36%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_7zip.c.o [ 36%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_all.c.o [ 36%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_ar.c.o [ 36%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_by_code.c.o [ 37%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_cab.c.o [ 37%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_cpio.c.o [ 37%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_empty.c.o [ 37%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_iso9660.c.o [ 38%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_lha.c.o [ 38%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_mtree.c.o [ 38%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_rar.c.o [ 38%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_raw.c.o [ 38%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_tar.c.o [ 39%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_xar.c.o [ 39%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_zip.c.o [ 39%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_string.c.o [ 39%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_string_sprintf.c.o [ 39%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_util.c.o [ 40%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_virtual.c.o [ 40%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write.c.o [ 40%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_disk_acl.c.o [ 40%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_disk_posix.c.o [ 41%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_disk_set_standard_lookup.c.o [ 41%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_open_fd.c.o [ 41%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_open_file.c.o [ 41%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_open_filename.c.o [ 41%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_open_memory.c.o [ 42%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter.c.o [ 42%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_b64encode.c.o [ 42%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_by_name.c.o [ 42%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_bzip2.c.o [ 43%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_compress.c.o [ 43%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_grzip.c.o [ 43%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_gzip.c.o [ 43%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_lrzip.c.o [ 43%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_lzop.c.o [ 44%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_none.c.o [ 44%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_program.c.o [ 44%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_uuencode.c.o [ 44%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_xz.c.o [ 45%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format.c.o [ 45%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_7zip.c.o [ 45%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_ar.c.o [ 45%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_by_name.c.o [ 45%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_cpio.c.o [ 46%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_cpio_newc.c.o [ 46%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_gnutar.c.o [ 46%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_iso9660.c.o [ 46%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_mtree.c.o [ 46%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_pax.c.o [ 47%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_shar.c.o [ 47%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_ustar.c.o [ 47%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_v7tar.c.o [ 47%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_xar.c.o [ 48%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_zip.c.o [ 48%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_options.c.o [ 48%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/filter_fork_posix.c.o Linking C static library libcmlibarchive.a [ 48%] Built target cmlibarchive Scanning dependencies of target cmexpat [ 48%] Building C object Utilities/cmexpat/CMakeFiles/cmexpat.dir/xmlparse.c.o [ 48%] Building C object Utilities/cmexpat/CMakeFiles/cmexpat.dir/xmltok.c.o [ 48%] Building C object Utilities/cmexpat/CMakeFiles/cmexpat.dir/xmlrole.c.o Linking C static library libcmexpat.a [ 48%] Built target cmexpat Scanning dependencies of target cmForm [ 48%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 46: cannot find include file: "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 93: error: syntax error before or at: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 120: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 120: warning: syntax requires ";" after last struct/union member "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 110: error: zero-sized struct/union "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 144: error: syntax error before or at: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 291: error: syntax error before or at: ( "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 290: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292: error: syntax error before or at: * "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292: error: syntax error before or at: ) "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 293: warning: old-style declaration or incorrect type for: link_fieldtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 297: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 297: warning: undefined or missing type for: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 296: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: error: syntax error before or at: * "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: error: syntax error before or at: ) "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: warning: syntax error: empty declaration "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 313: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 313: warning: undefined or missing type for: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 316: error: syntax error before or at: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 316: warning: undefined or missing type for: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 317: error: syntax error before or at: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 317: warning: undefined or missing type for: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 321: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 321: warning: undefined or missing type for: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 327: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 327: error: syntax error before or at: field_fore "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 327: warning: old-style declaration or incorrect type for: field_fore "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 328: warning: old-style declaration or incorrect type for: field_back "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: error: identifier redeclared: bool current : int previous: function() returning int : "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292 "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: error: syntax error before or at: new_page "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: warning: old-style declaration or incorrect type for: new_page "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 331: warning: old-style declaration or incorrect type for: field_status "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 353: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 353: error: syntax error before or at: * "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 353: warning: old-style declaration or incorrect type for: form_win "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 354: warning: old-style declaration or incorrect type for: form_sub "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 365: error: syntax error before or at: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 365: warning: undefined or missing type for: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 366: error: syntax error before or at: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 366: warning: undefined or missing type for: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 394: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 394: error: syntax error before or at: data_ahead "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 394: warning: old-style declaration or incorrect type for: data_ahead "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 395: warning: old-style declaration or incorrect type for: data_behind "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 124: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 124: error: syntax error before or at: _nc_Copy_Type "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 124: warning: old-style declaration or incorrect type for: _nc_Copy_Type "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 132: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 132: error: syntax error before or at: _nc_Internal_Validation "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 132: warning: old-style declaration or incorrect type for: _nc_Internal_Validation "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 71: error: improper member use: status "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 72: error: improper member use: makearg "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 73: error: improper member use: copyarg "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 74: error: improper member use: freearg cc: acomp failed for /usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c gmake[2]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o] Error 2 gmake[1]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/all] Error 2 gmake: *** [all] Error 2 node000 $ Additional Information: Problem may be the commented out bit in Source/CursesDialog/form/form.h . . . /**************************************************************************** * Author: Juergen Pfeifer 1995,1997 * ****************************************************************************/ #ifndef FORM_H #define FORM_H #if defined(__sun__) && defined(__GNUC__) #define _MSE_INT_H #endif #include /* figure out which curses.h to include */ # if defined(CURSES_HAVE_NCURSES_H) # include # elif defined(CURSES_HAVE_NCURSES_NCURSES_H) # include # elif defined(CURSES_HAVE_NCURSES_CURSES_H) # include # else # include # endif #include #include . . . So looks like no curses.h or ncurses.h is ever include'd. By the way : node000 $ ls -lap /usr/local/include/ncurses/curses.h -rw-r--r-- 1 root bin 76233 Sep 19 2012 /usr/local/include/ncurses/curses.h In which I see : /**************************************************************************** * Author: Zeyd M. Ben-Halim 1992,1995 * * and: Eric S. Raymond * * and: Thomas E. Dickey 1996-on * ****************************************************************************/ /* $Id: curses.h.in,v 1.220 2011/01/22 19:47:20 tom Exp $ */ ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-20 14:05 dev New Issue ====================================================================== From tobias.hunger at gmail.com Sat Sep 20 15:57:25 2014 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sat, 20 Sep 2014 21:57:25 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration Message-ID: Hello! Sorry for breaking the threading, I only joined this ML just now to comment on this thread:-) Thanks Stephen for pointing me here! I am not a regular cmake user (used to be a couple of years ago), but I im interested in this topic since I work on Qt Creator. While cmake currently is not our focus, I would personally like to see better cmake integration into our tool. Unfortunately I do not have the time to work on this myself:-/ I do want to provide some input to this discussion though. >From my experience we would need a bit more information than proposed in http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=1100 This is the structure suggested for each target: { "name": "testc1", "type": "STATIC_LIBRARY", "directory": "/tmp/COnly-bld", "location": "/tmp/COnly-bld//libtestc1.a", "exportName": "testc1", "backtrace": ["/tmp/COnly-src/CMakeLists.txt:6"], "installed": false }, That information will be valuable. I would love to see two additional field with information: The first is should this be run in a terminal or is this a GUI. Not sure whether cmake has that information. 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. 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. 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. 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. The general list can be clutched around by just assuming that all source files in the current project directory belong to the project. But how can I know that "something_win.h" will not be used when building on my Linux box? Best Regards, Tobias From joubert.sy at gmail.com Sat Sep 20 16:55:01 2014 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Sat, 20 Sep 2014 22:55:01 +0200 Subject: [cmake-developers] [PATCH] Prevent compilers to be silently modified when using Ninja, generator Message-ID: <541DE9A5.6060902@gmail.com> Hi, Please find attached a patch that fixes Ninja generator. Unlike Unix Makefiles generator it was possible to change compiler path without being notified, without the cache being deleted and more important the generated Ninja solution was not updated with the new compilers while the CMake cache was. I also activated the tests for this feature when building/testing CMake using Ninja Regards, Sylvain -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Prevent-compilers-to-be-silently-modified-when-using.patch Type: text/x-patch Size: 1840 bytes Desc: not available URL: From nilsgladitz at gmail.com Sat Sep 20 17:53:38 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sat, 20 Sep 2014 23:53:38 +0200 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: References: Message-ID: <541DF762.2000107@gmail.com> On 20.09.2014 23:31, Roland Schulz wrote: > Hi, > > it would be nice if there were a way to emulate rpath under Windows. > As far as I can see there are two possible approaches: > - Generate a shell script which sets PATH > - Generate a manifest for the application and a manifest for the > dependencies. > http://sourceforge.net/p/mingw-w64/mailman/message/30019971/ has an > example of how to do it. > > To generate either the script or the manifest, all paths to the all > required libraries need to be queried for an executable target. Then > those paths could be put into the script/manifest with e.g. > coonfigure_file. Those paths correspond to those used to set the rpath. I suppose it might be slightly more complex given that the import library that is being linked to and the DLL that corresponds to the import library might not be in the same location (and cmake might know the location of the one but not always the location of the the other). > This functionality has been suggested in this issue: > http://www.cmake.org/Bug/bug_relationship_graph.php?bug_id=10449 > The issue has been suspended with a comment that this idea, needs more > discussion on the mailing list first. Brad probably meant the developer's rather than the user's mailing list. (I am sending this reply to both) Nils From ono at java.pl Sun Sep 21 12:45:24 2014 From: ono at java.pl (Adam Strzelecki) Date: Sun, 21 Sep 2014 18:45:24 +0200 Subject: [cmake-developers] [PATCH] stage/compact-status-log Message-ID: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> I have pushed new branch stage/compact-status-log for review. Idea behind is to reduce cmake output when we are in terminal. When we are outputting message "Trying feature" we can later remove it when new output comes using ANSI escape codes. This is done by appending (but not flushing) \e[9999D\e[K to stdout. Once new status comes and flushes stdout (explicitly or implicitly by \n) these codes will be executed and will clear the line, so we get: Trying some feature - success Instead of: Trying some feature Trying some feature - success NOTE this behavior only applies to terminal (isatty check), so when piping cmake output to file is works as before. Waiting for your feedback. --Adam commit 224a515538f9574af80bb8a2d28525a44039ead7 Author: Adam Strzelecki Date: Sun Sep 21 18:29:33 2014 +0200 Use message(CLEAR "...") when starting checks This emits more compact logs when cmake is running in terminal. commit 61b57ec4549606bcafdfc2f5579c570ab8644b53 Author: Adam Strzelecki Date: Sun Sep 21 18:22:40 2014 +0200 message(...) function now accepts CLEAR keyword Status text emitted with message(CLEAR "...") will be immediately cleared when next stdout output arrives. This ensures we get more compact message logs, e.g.: Trying some feature - success Instead of: Trying some feature Trying some feature - success From dev at cor0.com Sun Sep 21 12:53:14 2014 From: dev at cor0.com (dev) Date: Sun, 21 Sep 2014 12:53:14 -0400 (EDT) Subject: [cmake-developers] =?utf-8?q?cc=3A_=E2=80=8Bacomp_failed_forSour?= =?utf-8?b?4oCLY2UvQ3Vyc2VzRGlhbG9nL2Zvcm3igIsvZmxkX2FyZy5j4oCL?= Message-ID: <1620003916.19615.1411318394744.JavaMail.vpopmail@webmail2.networksolutionsemail.com> Ran into what looks like a small issue : [ 48%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 46: cannot find include file: which is odd because I do have /usr/local/include/ncurses/curses.h which says inside it : /* $Id: curses.h.in,v 1.220 2011/01/22 19:47:20 tom Exp $ */ So I am thinking somehow that the -I/usr/local/include was ignored or some other such nuisance. Any hints ? dev documented to death here : http://public.kitware.com/Bug/view.php?id=15166 From ono at java.pl Sun Sep 21 14:34:15 2014 From: ono at java.pl (Adam Strzelecki) Date: Sun, 21 Sep 2014 20:34:15 +0200 Subject: [cmake-developers] [PATCH] stage/fix-OSX-bundle-rpaths-and-Qt5 In-Reply-To: References: <1409917844-28297-3-git-send-email-ono@java.pl> <1579949.fFJZQIyjfv@stryke> <5905178.NbCzcQviLF@stryke> Message-ID: <2C02EADD-4EAB-4E30-BB4E-B3989F01CB7A@java.pl> FYI I pushed updated branch stage/fix-OSX-bundle-rpaths-and-Qt5 with reworked codesign fix at e6cdf62d3a7d8b30466bb82f04026f8a06222c8a. The previous worked well for <= 10.9.4, but doesn't work anymore. Since 10.9.5 there is new policy that prevents codesign when bundle contains framework with invalid layout, this commit tries to fix the layout (which is the case of Qt frameworks!). https://developer.apple.com/library/mac/technotes/tn2206 Altogether with this updated commit it now builds CMake.app well again with Qt5 and it can be code signed with: codesign -s 'Developer ID' --deep CMake.app on 10.9.5 and Yosemite. commit e6cdf62d3a7d8b30466bb82f04026f8a06222c8a Author: Adam Strzelecki Date: Thu Sep 4 15:01:17 2014 +0200 Framework codesign Resources/Info.plist & Current We need to ensure copied framework has proper layout with Resources/Info.plist present next to versioned binary and Current symlink in Versions: https://developer.apple.com/library/mac/technotes/tn2206 https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html If Resources/ is not present we may try to copy Contents/Info.plist if present to embedded Resources/Info.plist. This is a case of Qt5 that has obsolete/invalid framework layout (see QTBUG-38511). --Adam From ono at java.pl Sun Sep 21 14:48:45 2014 From: ono at java.pl (Adam Strzelecki) Date: Sun, 21 Sep 2014 20:48:45 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> Message-ID: FYI unfortunately this solution does not work for CMakeFiles.txt with cmake_minimum_required(VERSION 2.6.1) or earlier because of CMP0011 that does implicit PUSH/POP does not work there. So setting cmake_policy(SET CMP0054 NEW) is internal modules will cause this policy to be not popped and carried out of the module. This is pretty nasty surprise, since I thought this implicit PUSH/POP happened since the beginning. So currently I do not have any idea how to solve this in some elegant fashion therefore for now I removed stage/CMP0054-FindCUDA branch. Maybe you can suggest something? --Adam From ono at java.pl Sun Sep 21 14:50:46 2014 From: ono at java.pl (Adam Strzelecki) Date: Sun, 21 Sep 2014 20:50:46 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> Message-ID: Addendum: Maybe CMP0011 should be forced implicitly for all built-in modules? --Adam From neundorf at kde.org Sun Sep 21 16:27:49 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Sun, 21 Sep 2014 22:27:49 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <1593230.4g2cNbzx16@tuxedo.neundorf.net> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <541C6B8D.2020404@kitware.com> <1593230.4g2cNbzx16@tuxedo.neundorf.net> Message-ID: <2678382.YpKxU8K3e4@tuxedo.neundorf.net> On Friday, September 19, 2014 21:53:40 Alexander Neundorf wrote: > On Friday, September 19, 2014 13:44:45 Brad King wrote: > ... > > > * Don't IDEs want to know the list of source files so they can > > > > be used for editing? > > > > I haven't looked at what the Extra generators produce in a > > while but since they are meant for IDEs they would be a good > > reference for the information needed. > > typically a list of targets, the command to build each target, source files > for each target, used include dirs and defines (-D) for code completion. > > > However, AFAIK there > > is not an extra generator for a multi-config generator. > > Yes. also after reading the other replies, I still don't understand why this shouldn't be a generator. If I understand correctly, this is for people who simply run cmake and later on want to use kdevelop on the existing build tree. How about simply adding support for an environment variable like "CMAKE_GENERATOR", which, when set, will be used as generator as long as no other generator has been set via -G ? KDE developers could set this variable, still run their build scripts, and later on use kdevelop. I have a hard time imagining a user who uses let's say Eclipse with the Eclipse generator, who then suddenly wants to use kdevelop on his build tree. Alex From mantis at public.kitware.com Mon Sep 22 04:22:11 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 22 Sep 2014 04:22:11 -0400 Subject: [cmake-developers] [CMake 0015167]: How to detect --debug-output and/or --trace Message-ID: <4ab9490c56e500d96601f47a0d1b560a@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15167 ====================================================================== Reported By: kurt.dupont Assigned To: ====================================================================== Project: CMake Issue ID: 15167 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-22 04:22 EDT Last Modified: 2014-09-22 04:22 EDT ====================================================================== Summary: How to detect --debug-output and/or --trace Description: I want to detect if the project is configured with --debug-output and/or --trace. I could not find a (list) of CMake variable that is set when the options are supplied. I want to pass the options on to (sub)projects integrated as external projects. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-22 04:22 kurt.dupont New Issue ====================================================================== From nilsgladitz at gmail.com Mon Sep 22 05:03:06 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 22 Sep 2014 11:03:06 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: Message-ID: <541FE5CA.7030002@gmail.com> On 09/20/2014 09:57 PM, Tobias Hunger wrote: > Hello! > > Sorry for breaking the threading, I only joined this ML just now to > comment on this thread:-) Thanks Stephen for pointing me here! > > I am not a regular cmake user (used to be a couple of years ago), but > I im interested in this topic since I work on Qt Creator. While cmake > currently is not our focus, I would personally like to see better > cmake integration into our tool. Unfortunately I do not have the time > to work on this myself:-/ > > I do want to provide some input to this discussion though. > > From my experience we would need a bit more information than proposed > in http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=1100 > > This is the structure suggested for each target: > > > { > "name": "testc1", > "type": "STATIC_LIBRARY", > "directory": "/tmp/COnly-bld", > "location": "/tmp/COnly-bld//libtestc1.a", > "exportName": "testc1", > "backtrace": ["/tmp/COnly-src/CMakeLists.txt:6"], > "installed": false > }, > > > That information will be valuable. > > I would love to see two additional field with information: > > The first is should this be run in a terminal or is this a GUI. Not > sure whether cmake has that information. At least on windows where there are distinct link time subsystems for console and gui applications the information is known; don't think it is available anywhere else(?) > > 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. That might not be necessary since CMake automatically constructs build time RPATHs by default. Might be nice for platforms where RPATHs aren't supported (e.g. Windows) though a generic, non IDE specific solution might be preferable: http://public.kitware.com/pipermail/cmake-developers/2014-September/011373.html Nils From steveire at gmail.com Mon Sep 22 09:39:24 2014 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 22 Sep 2014 15:39:24 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration References: <541FE5CA.7030002@gmail.com> Message-ID: Nils Gladitz wrote: > Might be nice for platforms where RPATHs aren't supported (e.g. Windows) > though a generic, non IDE specific solution might be preferable: > The proposed ProjectTargets.json isn't particularly IDE specific. That's only the motivation. Thanks, Steve. From nilsgladitz at gmail.com Mon Sep 22 09:42:48 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 22 Sep 2014 15:42:48 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <541FE5CA.7030002@gmail.com> Message-ID: <54202758.1060702@gmail.com> On 09/22/2014 03:39 PM, Stephen Kelly wrote: > Nils Gladitz wrote: > >> Might be nice for platforms where RPATHs aren't supported (e.g. Windows) >> though a generic, non IDE specific solution might be preferable: >> > > The proposed ProjectTargets.json isn't particularly IDE specific. That's > only the motivation. I meant it would be imo preferable if CMake could implement a solution for this directly rather than leaving it to any IDE or target buildsystem. e.g. something that would also work without an IDE (like RPATHs where currently supported). Nils From mantis at public.kitware.com Mon Sep 22 09:48:05 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 22 Sep 2014 09:48:05 -0400 Subject: [cmake-developers] [CMake 0015168]: incomplete builds with CMake, Make backend Message-ID: <5fc55f7657bb0ae2a3c1dfe2e5bea3e6@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15168 ====================================================================== Reported By: dhardy Assigned To: ====================================================================== Project: CMake Issue ID: 15168 Category: CMake Reproducibility: sometimes Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-22 09:48 EDT Last Modified: 2014-09-22 09:48 EDT ====================================================================== Summary: incomplete builds with CMake, Make backend Description: Several times recently running 'make' has resulted in incomplete builds, resulting in mysteriously failing unit tests or commits which at the time appeared fine but actually contained build errors. At least sometimes this is the result of changing "foo.h", and finding that "bar.cpp", which indirectly imports "foo.h" does not get rebuilt whenever touching foo.h. Running gc with -MD does correctly tell me that bar.cpp depends on foo.h. Steps to Reproduce: Following these instructions you can get roughly the same set up I have. When I try this, however, the issue is not reproduced in the new checkout. Diffing the two build folders, I am not able to see why one should have this dependency problem and not the other. git clone https://code.google.com/p/openmalaria/ cd openmalaria git checkout ccf0d9b5b292b68a284cb72d4d83f0c0c1d97fcf mkdir build cd build ccmake .. # see https://code.google.com/p/openmalaria/wiki/UnixBuildOpenMalaria for help make -j5 # full build touch ../include/util/DecayFunction.h make # should rebuild interventions/Vaccine.cpp among others Additional Information: I have a tarball of the offending build directory for the above example, so I may be able to provide more information given specific questions. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-22 09:48 dhardy New Issue ====================================================================== From steveire at gmail.com Mon Sep 22 10:03:44 2014 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 22 Sep 2014 16:03:44 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration References: Message-ID: Tobias Hunger 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. > 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. > 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"] } ] > 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 > 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. 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. ) 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. From brad.king at kitware.com Mon Sep 22 10:07:23 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 10:07:23 -0400 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> Message-ID: <54202D1B.5040300@kitware.com> On 09/21/2014 02:48 PM, Adam Strzelecki wrote: > FYI unfortunately this solution does not work for CMakeFiles.txt > with cmake_minimum_required(VERSION 2.6.1) or earlier because of > CMP0011 that does implicit PUSH/POP does not work there. So > setting cmake_policy(SET CMP0054 NEW) is internal modules will > cause this policy to be not popped and carried out of the module. > > I do not have any idea how to solve this in some elegant fashion This is one reason I just fixed the warnings with the "super ugly" approach on some of the other modules. It is a cost we pay upstream to support older clients, but the policy will still allow cleaner code in applications. Or, one could add the explicit PUSH/POP in modules, e.g. cmake_policy(PUSH) cmake_policy(SET CMP0054 NEW) ... module code ... cmake_policy(POP) -Brad From brad.king at kitware.com Mon Sep 22 10:07:38 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 10:07:38 -0400 Subject: [cmake-developers] [CMake] Integrating ExternalData with Artifactory In-Reply-To: References: <541C7E2B.9080606@kitware.com> Message-ID: <54202D2A.5020706@kitware.com> On 09/19/2014 06:07 PM, Taylor Braun-Jones wrote: > On Fri, Sep 19, 2014 at 3:04 PM, Brad King wrote: >> I think it can be activated by a special format of an entry in >> ExternalData_URL_TEMPLATES that specifies a lookup key that maps >> to some kind of custom configuration of a .cmake script to include >> or command to launch with execute_process. > > How about defining new URL scheme like: > > externaldatacommand://<*file|module*>/<*command*> Yes, something along these lines is what I had in mind. > list(APPEND ExternalData_URL_TEMPLATES > "externaldatacommand://ArtifactoryExternalData/ARTIFACTORY_DOWNLOAD_FILE?ALGO=%(algo)&" > ) > > And inside Testing/CMake/ArtifactoryExternalData.cmake it would look like: > > function(ARTIFACTORY_DOWNLOAD_FILE file algo hash) Since CMake does not support variable evaluation in a command name, this would require configuring a file with code in it to launch for each entry of this form in the url templates list. Also CMAKE_MODULE_PATH will not be available to the ExternalData module when it is launched at build time to do the download. The include() will have to work with a full path, perhaps stored in the configured copy of "ExternalData_config.cmake.in". It could be indexed with a key. Perhaps: list(APPEND ExternalData_URL_TEMPLATES "ExternalDataCustomScript://MyFetch/%(algo)/%(hash)" ) set(ExternalData_CUSTOM_SCRIPT_MyFetch /path/to/MyFetch.cmake) The script would be include()-ed in place of the current call to _ExternalData_download_file with the part of the URL after the "MyFetch/" already parsed into some variable(s). -Brad From brad.king at kitware.com Mon Sep 22 10:07:30 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 10:07:30 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> Message-ID: <54202D22.8030708@kitware.com> On 09/21/2014 12:45 PM, Adam Strzelecki wrote: > I have pushed new branch stage/compact-status-log for review. Neat. > Idea behind is to reduce cmake output when we are in terminal. > When we are outputting message "Trying feature" we can later > remove it when new output comes using ANSI escape codes. > This is done by appending (but not flushing) \e[9999D\e[K > to stdout. What if stdout's buffer happens to fill up and flush anyway? I think the text needs to be buffered somewhere for CMake to decide whether to clear it. The message()s have to be paired somehow so that we clear the first one only if the second one is the very next message to print. > NOTE this behavior only applies to terminal (isatty check), > so when piping cmake output to file is works as before. Look at Source/kwsys/Terminal.c for detection of whether we are actually working with a terminal capable of VT100 escapes. Thanks, -Brad From brad.king at kitware.com Mon Sep 22 10:07:46 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 10:07:46 -0400 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <541C6B8D.2020404@kitware.com> <1461805.58uUMPt7S5@caliban.sf-tec.de> <541C7029.7030403@kitware.com> Message-ID: <54202D32.6010206@kitware.com> On 09/20/2014 09:18 AM, Stephen Kelly wrote: > I don't know why I added it. > > There is also a 'new' > > + location += "/"; > > in that patch further down which might be removable. Thanks for pointing that one out too. I've removed both with a commit message that explains one hypothesis as to why they appeared: Remove extra slashes from LOCATION target property value http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=92b2c618 Thanks, -Brad From brad.king at kitware.com Mon Sep 22 10:07:53 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 10:07:53 -0400 Subject: [cmake-developers] [PATCH] Prevent compilers to be silently modified when using Ninja, generator In-Reply-To: <541DE9A5.6060902@gmail.com> References: <541DE9A5.6060902@gmail.com> Message-ID: <54202D39.60709@kitware.com> On 09/20/2014 04:55 PM, Sylvain Joubert wrote: > Please find attached a patch that fixes Ninja generator. Applied, thanks: Ninja: Prevent compilers to be silently modified http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6120fca8 -Brad From pascal.bach at siemens.com Mon Sep 22 10:19:10 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Mon, 22 Sep 2014 14:19:10 +0000 Subject: [cmake-developers] [PATCH] WINCE: Add toolchain documentation for Windows CE In-Reply-To: <541C6762.4030802@kitware.com> References: <1411056230-30313-1-git-send-email-pascal.bach@siemens.com> <541B19A7.4000903@kitware.com> <355BE46A91031048906B695426A8D8E616AD3862@DEFTHW99EH4MSX.ww902.siemens.net> <541C6762.4030802@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616AD3B80@DEFTHW99EH4MSX.ww902.siemens.net> > Thanks. I split that into two commits with slight edits, and added > my own commit to add subsections for Windows Phone and Store: > > Help: Add Cross Compiling subsections in cmake-toolchains.7 manual > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0d72451a > > Help: Add Windows CE cross-compiling to cmake-toolchains.7 manual > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=db54d872 > > Help: Add Windows Phone/Store cross-compiling to cmake-toolchains.7 > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27022166 > > Please review the result to make sure I didn't munge information > you intended to provide. > Looks fine to me. Pascal From pascal.bach at siemens.com Mon Sep 22 10:19:36 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Mon, 22 Sep 2014 16:19:36 +0200 Subject: [cmake-developers] [PATCH] VS, WINCE: Only set EntryPointSymbol for executables Message-ID: <1411395576-6621-1-git-send-email-pascal.bach@siemens.com> --- Source/cmVisualStudio10TargetGenerator.cxx | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/Source/cmVisualStudio10TargetGenerator.cxx b/Source/cmVisualStudio10TargetGenerator.cxx index 4b5c83f..e0a32a2 100644 --- a/Source/cmVisualStudio10TargetGenerator.cxx +++ b/Source/cmVisualStudio10TargetGenerator.cxx @@ -2118,7 +2118,10 @@ cmVisualStudio10TargetGenerator::ComputeLinkOptions(std::string const& config) if (this->GlobalGenerator->TargetsWindowsCE()) { linkOptions.AddFlag("SubSystem", "WindowsCE"); - linkOptions.AddFlag("EntryPointSymbol", "WinMainCRTStartup"); + if (this->Target->GetType() == cmTarget::EXECUTABLE) + { + linkOptions.AddFlag("EntryPointSymbol", "WinMainCRTStartup"); + } } else { @@ -2130,7 +2133,10 @@ cmVisualStudio10TargetGenerator::ComputeLinkOptions(std::string const& config) if (this->GlobalGenerator->TargetsWindowsCE()) { linkOptions.AddFlag("SubSystem", "WindowsCE"); - linkOptions.AddFlag("EntryPointSymbol", "mainACRTStartup"); + if (this->Target->GetType() == cmTarget::EXECUTABLE) + { + linkOptions.AddFlag("EntryPointSymbol", "mainACRTStartup"); + } } else { -- 1.7.10.4 From brad.king at kitware.com Mon Sep 22 10:24:26 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 10:24:26 -0400 Subject: [cmake-developers] [PATCH] VS, WINCE: Only set EntryPointSymbol for executables In-Reply-To: <1411395576-6621-1-git-send-email-pascal.bach@siemens.com> References: <1411395576-6621-1-git-send-email-pascal.bach@siemens.com> Message-ID: <5420311A.1010503@kitware.com> On 09/22/2014 10:19 AM, Pascal Bach wrote: > --- > Source/cmVisualStudio10TargetGenerator.cxx | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) VS, WINCE: Only set EntryPointSymbol for executables http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7aeb79f Thanks, -Brad From taylor at braun-jones.org Mon Sep 22 10:28:29 2014 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Mon, 22 Sep 2014 10:28:29 -0400 Subject: [cmake-developers] [CMake] Integrating ExternalData with Artifactory In-Reply-To: <54202D2A.5020706@kitware.com> References: <541C7E2B.9080606@kitware.com> <54202D2A.5020706@kitware.com> Message-ID: On Mon, Sep 22, 2014 at 10:07 AM, Brad King wrote: > Perhaps: > > list(APPEND ExternalData_URL_TEMPLATES > "ExternalDataCustomScript://MyFetch/%(algo)/%(hash)" > ) > set(ExternalData_CUSTOM_SCRIPT_MyFetch /path/to/MyFetch.cmake) > > The script would be include()-ed in place of the current call > to _ExternalData_download_file with the part of the URL after > the "MyFetch/" already parsed into some variable(s). > This all sounds reasonable to me. I'd love to see this land in a future CMake release. I'm willing to help if you need a tester/reviewer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at cor0.com Mon Sep 22 12:08:43 2014 From: dev at cor0.com (dev) Date: Mon, 22 Sep 2014 12:08:43 -0400 (EDT) Subject: [cmake-developers] Fwd: Re: How to get a nightly build process going. Message-ID: <1440402903.30242.1411402123884.JavaMail.vpopmail@webmail2.networksolutionsemail.com> Please see last comment at http://public.kitware.com/Bug/view.php?id=15166 ---------- Original Message ---------- Date: September 1, 2014 at 2:35 PM Subject: Re: [cmake-developers] How to get a nightly build process going. Back on topic... > Solaris 10 + SolarisStudio > http://open.cdash.org/buildSummary.php?buildid=3470493 > No build failures, 4 test failures > > Solaris 10 + GCC (from OpenCSW) > http://open.cdash.org/buildSummary.php?buildid=3470687 > No build failures, 5 test failures > I dug more into the test failures. 3 of the failures were due to a borked mercurial install on the machine, i.e. not a cmake problem but a system problem, which has since been fixed. Another was a FindGTK2 bug, which I just pushed a fix to next for. Given the _Bool fix and GTK2 fix, all tests should pass for nightly next on Solaris + suncc, and 1 failure for Solaris + GCC. So once you get your nightly submissions set up, I would expect a clean Solaris Studio build and test and a clean GCC build with 1 test failure. From ono at java.pl Mon Sep 22 12:26:45 2014 From: ono at java.pl (Adam Strzelecki) Date: Mon, 22 Sep 2014 18:26:45 +0200 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <54202D22.8030708@kitware.com> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> Message-ID: > What if stdout's buffer happens to fill up and flush anyway? I think I can provide other terminal-less solution via filtering stdout and stderr via pipe and background thread. I got some proof-of-concept program already. Idea is: stdout & stderr are duped and proxied by some background thread. (1) When background thread finds a line beginning with '--' on stdout then it writes it to real stdout without trailing new line, and stores it in some lookup variable (2a) When something new that comes to stdout begins exactly the same as previous line (previous line is prefix of new coming line) then only the difference suffix is wrote out to stdout (2b) Otherwise when anything new comes to stderr or stdout that does not start exactly as previous line then suspended new line and new coming text is wrote to real stderr/stdout This should effectively compact all successive try & success/fail lines together is there was no other output in between them. Also this will require absolutely no changes in .cmake files or any cmake commands. WDYT? --Adam From brad.king at kitware.com Mon Sep 22 12:37:25 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 12:37:25 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> Message-ID: <54205045.1060607@kitware.com> On 09/22/2014 12:26 PM, Adam Strzelecki wrote: > stdout & stderr are duped and proxied by some background thread. IMO that is too much infrastructure to solve what is essentially a cosmetic problem. -Brad From brad.king at kitware.com Mon Sep 22 12:50:18 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 12:50:18 -0400 Subject: [cmake-developers] How to get a nightly build process going. In-Reply-To: <1440402903.30242.1411402123884.JavaMail.vpopmail@webmail2.networksolutionsemail.com> References: <1440402903.30242.1411402123884.JavaMail.vpopmail@webmail2.networksolutionsemail.com> Message-ID: <5420534A.80101@kitware.com> On 09/22/2014 12:08 PM, dev wrote: > Please see last comment at > http://public.kitware.com/Bug/view.php?id=15166 [snip] > Your nightly process needs to have mercurial around it seems and not > subversion or git which I have. Only git is needed. If hg or svn is available some extra tests are activated, but they are not required. > I also think that cmake nightly needs "cmake" to be around also. The nightly process is driven by "ctest" so you need to bootstrap a CMake to get that first. You don't need ccmake for that. Once one version is installed it can be used to run nightly testing for the nightly versions. Chuck's fixes are in our 'master' branch now so you can check out from there and try bootstrapping with: ../cmake/bootstrap -- -DBUILD_CursesDialog=OFF make Then use the resulting "bin/ctest" to drive the dashboard script: http://www.cmake.org/Wiki/CMake/Git/Dashboard -Brad From ono at java.pl Mon Sep 22 15:08:15 2014 From: ono at java.pl (Adam Strzelecki) Date: Mon, 22 Sep 2014 21:08:15 +0200 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <54205045.1060607@kitware.com> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> Message-ID: <98B3C804-F496-4879-8686-6141639E8B71@java.pl> > IMO that is too much infrastructure to solve what is essentially > a cosmetic problem. Well, IMHO it is usability problem, because cmake emits simply too much (redundant) information. FYI I have pushed new stage/compact-status-log which does include this automatic subsequent status log line merging facility without using any ANSI escape sequences or any changes to .cmake files and it works with any UNIX having pipe, select & pthreads. What's more good it works regardless if cmake output is piped to file or goes directly terminal. Here's a commit log: commit e464a698e773dcbaba26b5af0327561312717b58 Author: Adam Strzelecki Date: Mon Sep 22 20:53:48 2014 +0200 Automatically compact two subsequent status lines This is done with background thread acting as stdout/stderr proxy monitoring subsequent lines emitted to stdout. Only lines beginning with "--" (status lines) are considered. If previously emitted line is a prefix to currently emitted line then this line gets merged, e.g.: -- Looking for iconv.h -- Looking for iconv.h - Found Is replaced with: -- Looking for iconv.h - Found However if there is any output both on stdout and stderr in between then the merging is not executed, e.g: -- Looking for iconv.h -- Cannot compile test.c -- Looking for iconv.h - Not found This currently works only on UNIX. And the results when running cmake on cmake: $ /tmp/cmake.PTeJch9J/bin/cmake ~/Code/SDK/cmake -- The C compiler identification is AppleClang 6.0.0.6000054 -- The CXX compiler identification is AppleClang 6.0.0.6000054 -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info - done -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream - found -- Check for STD namespace - found -- Check for ANSI scope - found -- Check for sstream - found -- Looking for unsetenv - found -- Looking for environ - not found -- Checking whether header cstdio is available - yes -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available - yes -- Checking whether stl string has operator!= for char* - yes -- Checking whether stl has iterator_traits - yes -- Checking whether stl has standard template allocator - yes -- Checking for rebind member of stl allocator - yes -- Checking for non-standard argument to stl allocator<>::max_size - no -- Checking whether stl containers support allocator objects. - yes -- Checking whether ios has binary openmode - yes -- Checking whether "<>" is needed for template friends - yes -- Checking for member template support - yes -- Checking for standard template specialization syntax - yes -- Checking whether argument dependent lookup is supported - yes -- Checking whether struct stat has st_mtim member - no -- Checking whether C++ compiler has 'long long' - yes -- Checking whether C++ compiler has '__int64' - no -- Checking for C type size macros - compiled -- Looking for sys/types.h - found -- Looking for stdint.h - found -- Looking for stddef.h - found Versus old non-compact cmake: $ /Volumes/cmake-3.0.2-Darwin64-universal/CMake.app/Contents/bin/cmake ~/Code/SDK/cmake -- The C compiler identification is AppleClang 6.0.0.6000054 -- The CXX compiler identification is AppleClang 6.0.0.6000054 -- 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 -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available -- Checking whether header cstddef is available - yes -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator!= for char* - yes -- Checking whether stl has iterator_traits -- Checking whether stl has iterator_traits - yes -- Checking whether stl has standard template allocator -- Checking whether stl has standard template allocator - yes -- Checking for rebind member of stl allocator -- Checking for rebind member of stl allocator - yes -- Checking for non-standard argument to stl allocator<>::max_size -- Checking for non-standard argument to stl allocator<>::max_size - no -- Checking whether stl containers support allocator objects. -- Checking whether stl containers support allocator objects. - yes -- Checking whether ios has binary openmode -- Checking whether ios has binary openmode - yes -- Checking whether "<>" is needed for template friends -- Checking whether "<>" is needed for template friends - yes -- Checking for member template support -- Checking for member template support - yes -- Checking for standard template specialization syntax -- Checking for standard template specialization syntax - yes -- Checking whether argument dependent lookup is supported -- Checking whether argument dependent lookup is supported - yes -- Checking whether struct stat has st_mtim member --Adam From mantis at public.kitware.com Mon Sep 22 15:36:45 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 22 Sep 2014 15:36:45 -0400 Subject: [cmake-developers] [CMake 0015169]: CPackRPM: component-specific settings "fall through" to next component Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15169 ====================================================================== Reported By: Sam Hartsfield Assigned To: ====================================================================== Project: CMake Issue ID: 15169 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-22 15:36 EDT Last Modified: 2014-09-22 15:36 EDT ====================================================================== Summary: CPackRPM: component-specific settings "fall through" to next component Description: When component support is enabled in CPackRPM, component-specific settings get applied not only to the specified component, but also to any subsequent components. Some of these settings can be unset for the latter components, but some cannot (e.g. CPACK_RPM_USER_BINARY_SPECFILE). Steps to Reproduce: See attached example. For spec.in file, use a standard template (cpack -D CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE=1 -G RPM). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-22 15:36 Sam Hartsfield New Issue 2014-09-22 15:36 Sam Hartsfield File Added: CMakeLists.txt ====================================================================== From aleixpol at kde.org Mon Sep 22 19:15:40 2014 From: aleixpol at kde.org (Aleix Pol) Date: Tue, 23 Sep 2014 01:15:40 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <541C6B8D.2020404@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> Message-ID: On Fri, Sep 19, 2014 at 7:44 PM, Brad King wrote: > On 09/18/2014 08:10 PM, Aleix Pol wrote: > > I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to > > enable the generation of the file. > > I also renamed the file to ProjectTargets.json. > > > > http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch > > Thanks. I made some style updates and converted it to a patch > generated with 'git format-patch'. See attached. I also > attached a sample ProjectTargets.json generated for the "COnly" > test from our test suite. > Cool! Thanks a lot for taking your time to look into this! > > I'd really like to hear from others on the file format itself. > > Some comments on the format: > > * A version number field is needed at the top. > Sure, can't hurt. So you'd encapsulate it such as: { version: "1.0", targets: [...] } > > * There needs to be support for multi-config generators. > Perhaps everything that can be affected by the configuration > needs to be inside a list that enumerates all configurations. > In single-configuration generators the list would have only > one entry for the CMAKE_BUILD_TYPE. In multi-configuration > generators it would be all of the CMAKE_CONFIGURATION_TYPES. > I've never worked with those, but it sounds like it would make sense. What about: { version: .. configurations: { { name: "Debug", targets: [...] }, { name: "Release", targets: [...] } } } > > * Don't IDEs want to know the list of source files so they can > be used for editing? > It would probably make sense, yes. We can introduce an input field. > > I haven't looked at what the Extra generators produce in a > while but since they are meant for IDEs they would be a good > reference for the information needed. However, AFAIK there > is not an extra generator for a multi-config generator. > > -Brad > Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Sep 23 03:05:57 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 23 Sep 2014 09:05:57 +0200 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: <541DF762.2000107@gmail.com> References: <541DF762.2000107@gmail.com> Message-ID: <54211BD5.4010108@gmail.com> On 09/20/2014 11:53 PM, Nils Gladitz wrote: > On 20.09.2014 23:31, Roland Schulz wrote: >> it would be nice if there were a way to emulate rpath under Windows. >> As far as I can see there are two possible approaches: >> - Generate a shell script which sets PATH >> - Generate a manifest for the application and a manifest for the >> dependencies. >> http://sourceforge.net/p/mingw-w64/mailman/message/30019971/ has an >> example of how to do it. So I am thinking opt-in (target property) wrapper binaries that take the place of the actual binaries. e.g. # Initializes ENABLE_EXECUTABLE_WRAPPER target property set(CMAKE_ENABLE_EXECUTABLE_WRAPPER ON) add_executable(foo foo.cpp) Could produce foo.exe.real # Actual target binary foo.exe.wrapper # CMake generated configuration file foo.exe # Wrapper binary that reads "foo.exe.wrapper", sets up the environment and runs "foo.exe.real" COMMANDs (add_custom_command()/add_custom_target()/add_test()) could transparently call foo.exe (like they would have done without the wrapper). install(TARGETS) should ignore the wrapper and transparently install and rename the real binary. $ should continue to point at the real binary. A new $ could point at the wrapper binary. The wrapper binary itself could be precompiled and included with cmake itself. It would determine which configuration to read and which binary to run by inspecting its own name. I primarily had windows native builds in mind. Are there additional use cases? Nils From steveire at gmail.com Tue Sep 23 03:58:58 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 23 Sep 2014 09:58:58 +0200 Subject: [cmake-developers] Was AUTOMOC designed to run for each build? Message-ID: Hi (especially Alex), I noticed that the automoc target is run each time, even for a trivial project: cmake_minimum_required(VERSION 2.8) project(automoctest) set(CMAKE_AUTOMOC ON) find_package(Qt5Widgets REQUIRED) add_executable(main main.cpp) target_link_libraries(main Qt5::Widgets) Each time I run make I get [ 33%] Automatic moc for target main /path/to/cmake -E cmake_autogen /path/to/build/CMakeFiles/main_automoc.dir/ "" I checked CMake 2.8.7 and it executes the target each time too. In the implementation, makefile->AddUtilityCommand is called with 'true' to set the excludeFromAll parameter. I don't see why the target is executed each time, but is it that way by design? Thanks, Steve. From florent.castelli at gmail.com Tue Sep 23 04:26:52 2014 From: florent.castelli at gmail.com (Florent Castelli) Date: Tue, 23 Sep 2014 10:26:52 +0200 Subject: [cmake-developers] iOS support Message-ID: Hi! My company is organizing soon a hack week where each employee is able to work on any project he wants. So, I've decided to work with Cmake and improve support for iOS to help the product team getting rid of manual project files, constant merge conflicts and bad project file documentation, while improving our tooling possibilities (all that with Cmake!). I've had a quick look at the first issue that popped into my mind the other day and fixed try_compile by adding another variable to set the executable type in the generated project (it has to be MACOSX_BUNDLE) and fixing the search path for the resulting binary. So this is now working... Providing we are targeting the simulator. Due to the nature of Xcode projects that can easily target either the simulator or devices, thus using different compilation flags, the resulting projects aren't working in both case. There are conflicts between some options like the minimum iOS version target and the minimum iOS simulator target for example (which you need to build the try_compile binaries without signing them). Also, the Xcode support is very OSX focused and all variables have MACOSX in their name, which is confusing. So, has anyone worked on similar issues and can suggest a way to progress and improve support for iOS? In the end, I'd like to have a working Xcode project with separate settings for both simulator and device, Cmake compiler flag detection working, and possibly later Make/Ninja projects working too. Regards, /Orphis -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Tue Sep 23 07:45:51 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 23 Sep 2014 07:45:51 -0400 Subject: [cmake-developers] [CMake 0015170]: CMAKE_SYSTEM_PROCESSOR is broken on Windows Message-ID: <1cd35aa1e53b7fa428fbc40e9fb33fa5@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15170 ====================================================================== Reported By: stopiccot Assigned To: ====================================================================== Project: CMake Issue ID: 15170 Category: CMake Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-23 07:45 EDT Last Modified: 2014-09-23 07:45 EDT ====================================================================== Summary: CMAKE_SYSTEM_PROCESSOR is broken on Windows Description: According to it's description CMAKE_SYSTEM_PROCESSOR should have value of "The name of the CPU CMake is building for". On Windows x64 hosts it always has value of AMD64 no matter which architecture you are building for: x86/x64 or arm. I have a strong opinion that this behavior should be fixed cause otherwise this var is completely useless on windows. And yes I know there is a CMAKE_CL_64 var for determining what arch we are building for. But it looks like a x64-only dirty hack not a generic solution ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-23 07:45 stopiccot New Issue ====================================================================== From robert.maynard at kitware.com Tue Sep 23 08:09:38 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 23 Sep 2014 08:09:38 -0400 Subject: [cmake-developers] iOS support In-Reply-To: References: Message-ID: The lowest hanging fruit would be to transition over to setting the global variable CMAKE_MACOSX_BUNDLE which is used to initialize the MACOSX_BUNDLE property on all the targets. CMake also supports CMAKE_XCODE_ATTRIBUTE global variables to allow easy code signing etc. Lastly have you looked at setting up different toolchains for the simulator and device? On Tue, Sep 23, 2014 at 4:26 AM, Florent Castelli wrote: > Hi! > > My company is organizing soon a hack week where each employee is able to > work on any project he wants. So, I've decided to work with Cmake and > improve support for iOS to help the product team getting rid of manual > project files, constant merge conflicts and bad project file documentation, > while improving our tooling possibilities (all that with Cmake!). > > I've had a quick look at the first issue that popped into my mind the other > day and fixed try_compile by adding another variable to set the executable > type in the generated project (it has to be MACOSX_BUNDLE) and fixing the > search path for the resulting binary. > So this is now working... Providing we are targeting the simulator. > Due to the nature of Xcode projects that can easily target either the > simulator or devices, thus using different compilation flags, the resulting > projects aren't working in both case. There are conflicts between some > options like the minimum iOS version target and the minimum iOS simulator > target for example (which you need to build the try_compile binaries without > signing them). > Also, the Xcode support is very OSX focused and all variables have MACOSX in > their name, which is confusing. > > So, has anyone worked on similar issues and can suggest a way to progress > and improve support for iOS? > In the end, I'd like to have a working Xcode project with separate settings > for both simulator and device, Cmake compiler flag detection working, and > possibly later Make/Ninja projects working too. > > Regards, > /Orphis > > > -- > > 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 DLRdave at aol.com Tue Sep 23 09:13:25 2014 From: DLRdave at aol.com (David Cole) Date: Tue, 23 Sep 2014 09:13:25 -0400 Subject: [cmake-developers] [CMake] Windows rpath emulation Message-ID: What is the problem that this feature is trying to solve? It seems unnecessary to me as a first-class feature of CMake. I must be missing something... But if you do pursue something like this, it seems to me that install(TARGETS ...) should install all files including the wrapper. Is this only for executable files, or would something like this also be possible/necessary for shared libraries, too? Slicer and ParaView do (or did in the past) have similar wrappers to set up necessary environment variables before invoking the "real" exe. Thanks, David C. On Tue, Sep 23, 2014 at 3:05 AM, Nils Gladitz wrote: > On 09/20/2014 11:53 PM, Nils Gladitz wrote: >> >> On 20.09.2014 23:31, Roland Schulz wrote: >>> >>> it would be nice if there were a way to emulate rpath under Windows. >>> As far as I can see there are two possible approaches: >>> - Generate a shell script which sets PATH >>> - Generate a manifest for the application and a manifest for the >>> dependencies. >>> http://sourceforge.net/p/mingw-w64/mailman/message/30019971/ has an >>> example of how to do it. > > > So I am thinking opt-in (target property) wrapper binaries that take the > place of the actual binaries. > > e.g. > # Initializes ENABLE_EXECUTABLE_WRAPPER target property > set(CMAKE_ENABLE_EXECUTABLE_WRAPPER ON) > > add_executable(foo foo.cpp) > > Could produce > foo.exe.real # Actual target binary > foo.exe.wrapper # CMake generated configuration file > foo.exe # Wrapper binary that reads "foo.exe.wrapper", sets up > the environment and runs "foo.exe.real" > > COMMANDs (add_custom_command()/add_custom_target()/add_test()) could > transparently call foo.exe (like they would have done without the wrapper). > > install(TARGETS) should ignore the wrapper and transparently install and > rename the real binary. > > $ should continue to point at the real binary. > A new $ could point at the wrapper binary. > > The wrapper binary itself could be precompiled and included with cmake > itself. It would determine which configuration to read and which binary to > run by inspecting its own name. > > I primarily had windows native builds in mind. > Are there additional use cases? > > 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 Tue Sep 23 09:24:58 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 23 Sep 2014 15:24:58 +0200 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: References: <541DF762.2000107@gmail.com> <54211BD5.4010108@gmail.com> Message-ID: <542174AA.3060907@gmail.com> On 09/23/2014 03:11 PM, David Cole wrote: > What is the problem that this feature is trying to solve? Being able to run binaries with DLL dependencies within the build tree. Basically the same thing that the build time RPATH feature does on e.g. linux. If you are e.g. linking to Qt5 (shared) and don't have the Qt5 bin directory in your PATH the binary will not run since it can not locate the DLL on its own. As workarounds people often copy the DLLs into their build directories, output all runtime files into a single directory and/or set up custom wrappers that set up PATH. > But if you do pursue something like this, it seems to me that > install(TARGETS ...) should install all files including the wrapper. CMake replaces build time RPATHs with installation RPATHs when deploying. I think the same should apply to these wrappers. They are only useful for a build tree. > Is this only for executable files, or would something like this also > be possible/necessary for shared libraries, too? I have been pondering DLLs as well but would restrict it to executables for now. For DLLs this probably only makes sense in a context where the DLL is build by CMake and used as-is without deployment in a context outside of CMake's control. Also I am guessing this might not be as simple to set up as it is for executables. Thanks for the feedback! Nils From bill.hoffman at kitware.com Tue Sep 23 10:06:11 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 23 Sep 2014 10:06:11 -0400 Subject: [cmake-developers] iOS support In-Reply-To: References: Message-ID: <54217E53.2070902@kitware.com> On 9/23/2014 8:09 AM, Robert Maynard wrote: > The lowest hanging fruit would be to transition over to setting the > global variable CMAKE_MACOSX_BUNDLE which is used to initialize the > MACOSX_BUNDLE property on all the targets. CMake also supports > CMAKE_XCODE_ATTRIBUTE global variables to allow easy code signing etc. > > Lastly have you looked at setting up different toolchains for the > simulator and device? We have recently looked at this problem. Setting CMAKE_MACOSX_BUNDLE in the toolchain file gets you part of the way there. However, some try_compile stuff will still fail because it can not find the app bundles. cmake_minimum_required(VERSION 2.8) project(foo) include(TestBigEndian) test_big_endian(CMAKE_WORDS_BIGENDIAN) https://github.com/Kitware/VTK/blob/master/CMake/ios.toolchain.xcode.cmake This will get you to the problem: cmake -GXcode -DCMAKE_TOOLCHAIN_FILE=../ios.toolchain.xcode.cmake .. -DIOS_PLATFORM=SIMULATOR Trouble is in cmake/Modules/CheckTypeSize.cmake where it does a try_compile with COPY_FILE. The COPY_FILE in cmCoreTryCompile.cxx does not look for the bundle option and therefore can not find the executable. However, now that I look at it, I think I might be able to fix it pretty easy. That said it would be really cool to beef up the xcode support enough to be able to create an actual ios app. I have not dug into that enough. Should be able to do most of it with CMAKE_XCODE_ATTRIBUTE. I will look into this try_compile COPY_FILE issue today and get back to the list. It would be great if you could get an example/Test in place that builds an app for a device and works with Xcode and for a stretch goal also works with makefiles or ninja. -Bill From bill.hoffman at kitware.com Tue Sep 23 10:56:22 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 23 Sep 2014 10:56:22 -0400 Subject: [cmake-developers] iOS support In-Reply-To: <54217E53.2070902@kitware.com> References: <54217E53.2070902@kitware.com> Message-ID: <54218A16.1010008@kitware.com> > That said it would be really cool to beef up the xcode support enough to > be able to create an actual ios app. I have not dug into that enough. > Should be able to do most of it with CMAKE_XCODE_ATTRIBUTE. I will > look into this try_compile COPY_FILE issue today and get back to the list. > > It would be great if you could get an example/Test in place that builds > an app for a device and works with Xcode and for a stretch goal also > works with makefiles or ninja. > Couple of more things. 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. This would be a great thing to work on. Also, Robert M reminded me that there is a test that could be extended as this stuff is developed: https://github.com/Kitware/CMake/tree/master/Tests/iOSNavApp ) as it already builds targeting the iphone simulator. -Bill From florent.castelli at gmail.com Tue Sep 23 11:42:01 2014 From: florent.castelli at gmail.com (Florent Castelli) Date: Tue, 23 Sep 2014 17:42:01 +0200 Subject: [cmake-developers] iOS support In-Reply-To: <54218A16.1010008@kitware.com> References: <54217E53.2070902@kitware.com> <54218A16.1010008@kitware.com> Message-ID: On 23 Sep 2014, at 16:56, Bill Hoffman wrote: > >> That said it would be really cool to beef up the xcode support enough to >> be able to create an actual ios app. I have not dug into that enough. >> Should be able to do most of it with CMAKE_XCODE_ATTRIBUTE. I will >> look into this try_compile COPY_FILE issue today and get back to the list. >> >> It would be great if you could get an example/Test in place that builds >> an app for a device and works with Xcode and for a stretch goal also >> works with makefiles or ninja. >> > Couple of more things. > > 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. This would be a great thing to work on. > 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. Generating projects for Makefiles or Ninja would probably require a dedicated toolchain though (or proper platform files indeed), but that can be done later. > Also, Robert M reminded me that there is a test that could be extended as this stuff is developed: > > https://github.com/Kitware/CMake/tree/master/Tests/iOSNavApp ) as it > already builds targeting the iphone simulator. > > -Bill > Nice, I will have a look! I also have a couple of patches for finding the binary during a try_compile that works with my other change to have an extra variable for the add_executable and I would need to change it. It's mostly changing cmCoreTryCompile::FindOutputFile() and adds "/" + targetName + ".app/Contents/MacOS" to the searchDirs. I'll try to pickup those toolchain files though and see how they work for me soon. I'll probably have some options to override a few things and make it find the compiler properly. Right now, it's hardcoding /usr/bin/clang and that's a no go :) (it should be found in the path or through DEVELOPER_DIR eventually). Not forcing the compiler would be sweet too (but that requires the try_compile fixup first) as it means we could use ccache or an alternative compiler (for reasons). /Orphis > > -- > > 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 bill.hoffman at kitware.com Tue Sep 23 12:18:08 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 23 Sep 2014 12:18:08 -0400 Subject: [cmake-developers] iOS support In-Reply-To: References: <54217E53.2070902@kitware.com> <54218A16.1010008@kitware.com> Message-ID: <54219D40.5010407@kitware.com> On 9/23/2014 11:42 AM, Florent Castelli wrote: > I also have a couple of patches for finding the binary during a try_compile that works with my other change to have an extra variable for the add_executable and I would need to change it. > It's mostly changing cmCoreTryCompile::FindOutputFile() and adds "/" + targetName + ".app/Contents/MacOS" to the searchDirs. I just pushed something to next that adds targetName.app. That worked for the example I was building. -Bill From roland at utk.edu Tue Sep 23 12:37:38 2014 From: roland at utk.edu (Roland Schulz) Date: Tue, 23 Sep 2014 12:37:38 -0400 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: <16db33e45f564825918f0e4e8a4c72bb@DM2PR02MB464.namprd02.prod.outlook.com> References: <541DF762.2000107@gmail.com> <54211BD5.4010108@gmail.com> <16db33e45f564825918f0e4e8a4c72bb@DM2PR02MB464.namprd02.prod.outlook.com> Message-ID: Hi, On Tue, Sep 23, 2014 at 3:05 AM, Nils Gladitz wrote: > On 09/20/2014 11:53 PM, Nils Gladitz wrote: > > On 20.09.2014 23:31, Roland Schulz wrote: > >> it would be nice if there were a way to emulate rpath under Windows. > >> As far as I can see there are two possible approaches: > >> - Generate a shell script which sets PATH > >> - Generate a manifest for the application and a manifest for the > >> dependencies. > >> http://sourceforge.net/p/mingw-w64/mailman/message/30019971/ has an > >> example of how to do it. > > So I am thinking opt-in (target property) wrapper binaries that take the > place of the actual binaries. Why do you prefer that solution over a batch script or a manifest? On Tue, Sep 23, 2014 at 9:24 AM, Nils Gladitz wrote: > On 09/23/2014 03:11 PM, David Cole wrote: > > What is the problem that this feature is trying to solve? > > Being able to run binaries with DLL dependencies within the build tree. > Basically the same thing that the build time RPATH feature does on e.g. > linux. > Why only for the build tree? Even after installing not all DLLs might be in install folder. Or would you recommend to always copy all DLLs? Even things like for e.g. for MingW the libgcc*dll? Roland -- ORNL/UT Center for Molecular Biophysics cmb.ornl.gov 865-241-1537, ORNL PO BOX 2008 MS6309 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Sep 23 12:53:57 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 23 Sep 2014 18:53:57 +0200 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: References: <541DF762.2000107@gmail.com> <54211BD5.4010108@gmail.com> <16db33e45f564825918f0e4e8a4c72bb@DM2PR02MB464.namprd02.prod.outlook.com> Message-ID: <5421A5A5.1080201@gmail.com> On 23.09.2014 18:27, Roland Schulz wrote: > > > So I am thinking opt-in (target property) wrapper binaries that > take the > place of the actual binaries. > > > Why do you prefer that solution over a batch script or a manifest? I looked at manifests but as far as I can tell they won't allow loading libraries from arbitrary locations. File references next to manifests are not allowed a path component. Libraries could at best be put in direct subdirectories next to the consuming executables. Executable wrappers can be drop in replacements for the actual executables and I was considering AddDllDirectory() over modifying PATH hoping that is less intrusive. > > On Tue, Sep 23, 2014 at 9:24 AM, Nils Gladitz > wrote: > > On 09/23/2014 03:11 PM, David Cole wrote: > > What is the problem that this feature is trying to solve? > > Being able to run binaries with DLL dependencies within the build > tree. > Basically the same thing that the build time RPATH feature does on > e.g. > linux. > > > Why only for the build tree? Even after installing not all DLLs might > be in install folder. Or would you recommend to always copy all DLLs? > Even things like for e.g. for MingW the libgcc*dll? On windows when you deploy to a system different from your own it is expected and common practice that you deploy your runtime requirements as well. You can not expect a preexisting installation of your library requirements nor can you expect them to be in the same location as in your development system. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at utk.edu Tue Sep 23 13:12:13 2014 From: roland at utk.edu (Roland Schulz) Date: Tue, 23 Sep 2014 13:12:13 -0400 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: References: <541DF762.2000107@gmail.com> <54211BD5.4010108@gmail.com> <16db33e45f564825918f0e4e8a4c72bb@DM2PR02MB464.namprd02.prod.outlook.com> Message-ID: On Tue, Sep 23, 2014 at 12:53 PM, Nils Gladitz wrote: > On 23.09.2014 18:27, Roland Schulz wrote: > > > >> So I am thinking opt-in (target property) wrapper binaries that take the >> place of the actual binaries. > > > Why do you prefer that solution over a batch script or a manifest? > > > I looked at manifests but as far as I can tell they won't allow loading > libraries from arbitrary locations. > File references next to manifests are not allowed a path component. > I think you're right. There seems to be robust way to refer to DLLs in arbitrary locations. It only works well if the DLL has a manifest in its location, because one can refer to other manifests in arbitrary locations. But that wouldn't be a general solution. Executable wrappers can be drop in replacements for the actual executables > and I was considering AddDllDirectory() over modifying PATH hoping that is > less intrusive. > Seems reasonable. Have you got a solution to the problem you mentioned in your first email: I suppose it might be slightly more complex given that the import > library that is being linked to and the DLL that corresponds to the > import library might not be in the same location (and cmake might know > the location of the one but not always the location of the the other). > On windows when you deploy to a system different from your own it is > expected and common practice that you deploy your runtime requirements as > well. > You can not expect a preexisting installation of your library requirements > nor can you expect them to be in the same location as in your development > system. > I think you are referring to making a binary cpack installation package. I was thinking about installing on the build system. Then It would still be different from the build directory. Roland -- ORNL/UT Center for Molecular Biophysics cmb.ornl.gov 865-241-1537, ORNL PO BOX 2008 MS6309 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Sep 23 13:37:42 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 23 Sep 2014 19:37:42 +0200 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: References: <541DF762.2000107@gmail.com> <54211BD5.4010108@gmail.com> <16db33e45f564825918f0e4e8a4c72bb@DM2PR02MB464.namprd02.prod.outlook.com> Message-ID: <5421AFE6.2050207@gmail.com> On 23.09.2014 19:12, Roland Schulz wrote: > > Have you got a solution to the problem you mentioned in your first email: > > I suppose it might be slightly more complex given that the import > library that is being linked to and the DLL that corresponds to the > import library might not be in the same location (and cmake might know > the location of the one but not always the location of the the other). > > - For local targets CMake does have the location (these are also interesting but the main selling point would imo be external libraries). - For imported targets CMake may have DLL locations. More likely when set up by package configuration files (e.g. Qt5 sets them) than when set up by find modules (e.g. FindQt4 does not set them). There might be incentive to add those locations when they start to be more useful. - It might be possible to guess the DLL location from a given import library (assuming it was provided with a full path); probably not something you can rely on but it might be able to guess the location often enough to be convenient - Additional locations could be provided manually by target property > On windows when you deploy to a system different from your own it > is expected and common practice that you deploy your runtime > requirements as well. > You can not expect a preexisting installation of your library > requirements nor can you expect them to be in the same location as > in your development system. > > > I think you are referring to making a binary cpack installation > package. I was thinking about installing on the build system. Then It > would still be different from the build directory. Yes, but I think that is the least common use case (maybe even more so on windows). CPack uses the same install commands for packaging and local install and I don't think CMake makes the distinction between deploying locally and remotely. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From neundorf at kde.org Tue Sep 23 16:27:51 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 23 Sep 2014 22:27:51 +0200 Subject: [cmake-developers] Was AUTOMOC designed to run for each build? In-Reply-To: References: Message-ID: <1701926.YV4YG1IxjZ@tuxedo.neundorf.net> On Tuesday, September 23, 2014 09:58:58 Stephen Kelly wrote: > Hi (especially Alex), > > I noticed that the automoc target is run each time, even for a trivial > project: > > cmake_minimum_required(VERSION 2.8) > project(automoctest) > > set(CMAKE_AUTOMOC ON) > > find_package(Qt5Widgets REQUIRED) > > add_executable(main main.cpp) > target_link_libraries(main Qt5::Widgets) > > Each time I run make I get > > [ 33%] Automatic moc for target main > /path/to/cmake -E cmake_autogen /path/to/build/CMakeFiles/main_automoc.dir/ > " > > I checked CMake 2.8.7 and it executes the target each time too. > > In the implementation, makefile->AddUtilityCommand is called with 'true' to > set the excludeFromAll parameter. > > I don't see why the target is executed each time, but is it that way by > design? iirc, yes. The moc files have to be generated before any of the source files is compiled, so automoc is in a target the actual target depends on. IIRC it is exclude_from_all so that it is only built when the actual target is built. Do you think it should only rerun if any of the source files has changed ? There was some problem with this. The headers are usually not part of the listed source files. I would have to check to find out the details again. Alex From d3ck0r at gmail.com Wed Sep 24 03:17:43 2014 From: d3ck0r at gmail.com (J Decker) Date: Wed, 24 Sep 2014 00:17:43 -0700 Subject: [cmake-developers] OpenWatcom wMake and VERBOSE=1 Message-ID: VERBOSE=1 only triggers the first level to be verbose in a make... any subsequent call to wmake passes '-s' option and not VERBOSE=1 continuously... I'm not sure where the '-s' option on wmake is coming from, browsed the code a little... but it'd be kind of nice if this feature worked. -------------- next part -------------- An HTML attachment was scrubbed... URL: From samho5888 at gmail.com Wed Sep 24 07:18:00 2014 From: samho5888 at gmail.com (Sam H.) Date: Wed, 24 Sep 2014 19:18:00 +0800 Subject: [cmake-developers] Integrate fixdep for kconfig Message-ID: Hi, 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. My scratch is attached. 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. So could any expert in CMake development give me some recommendations? Thanks, Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_kconfig.diff.gz Type: application/x-gzip Size: 2708 bytes Desc: not available URL: From ono at java.pl Wed Sep 24 08:02:25 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 24 Sep 2014 14:02:25 +0200 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <98B3C804-F496-4879-8686-6141639E8B71@java.pl> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> Message-ID: <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> FYI stage/compact-status-log was updated with more elegant C++ implementation introducing new cmStdoutFilter & cmThread utility classes enabled when certain headers are present in the system, so in cmakemain.cxx we simply put: cmStdoutFilter stdoutFilter("-- "); --Adam From ono at java.pl Wed Sep 24 08:26:55 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 24 Sep 2014 14:26:55 +0200 Subject: [cmake-developers] [OSX CMake.dmg] Replace >10.6 build with 64-bit only and use bzip2 compression Message-ID: <1AE2B46D-8E37-43C1-BAB2-F7C8D03AB26C@java.pl> Not an big issue but official DMG bundles are 40 MB where my manually built one is 21 MB (half of it). So any reason for: * providing universal FAT binaries instead of 64-bit only for >=10.6 Darwin64 build, as anyway there is 32-bit build for these who have 32-bit only CPU? * using DMG zlib compression instead bzip2 for all builds which is available for 10.4+ and provides much better compression ratio? --Adam From mornymorny at gmail.com Wed Sep 24 08:28:38 2014 From: mornymorny at gmail.com (Christopher Maughan) Date: Wed, 24 Sep 2014 13:28:38 +0100 Subject: [cmake-developers] Windows shader compile options Message-ID: I've been playing with the Windows shader options. I can see that it's now possible to set the following: set_property(SOURCE ${PIXELSHADER_FILES} PROPERTY VS_SHADER_TYPE Pixel) set_property(SOURCE ${VERTEXSHADER_FILES} PROPERTY VS_SHADER_TYPE Vertex) Which is cool, but I can't see if there's a way to specify the other options to the shader compiler, such as output header file, shader model, etc. Is there a way to do that, or is it a TODO? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Sep 24 08:36:30 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 08:36:30 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> Message-ID: <5422BACE.2070600@kitware.com> On 09/24/2014 08:02 AM, Adam Strzelecki wrote: > cmThread utility class Introducing threads is exactly the "too much infrastructure" to which I was referring in my previous response. I'm sorry to reject all the effort you put into the threads approach so far, but I did say this earlier. > cmake emits simply too much (redundant) information. IIRC the original reason for having separate -- Looking for iconv.h -- Looking for iconv.h - Found lines is that the first one prints what is about to be done in case something happens (e.g. crash) that prevents the second output from ever showing up. That helps a lot in tracking down the problem. If another thread buffers the first message then it might not show up at all. The terminal escape codes approach does not have that problem. The same de-dup you do in the threaded filter could be done with a shell alias that pipes 'cmake' output through a sed script or something to de-dup it. That would handle local interactive terminal use of cmake without any upstream changes. -Brad From chuck.atkins at kitware.com Wed Sep 24 09:44:27 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 24 Sep 2014 09:44:27 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <5422BACE.2070600@kitware.com> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> Message-ID: I like the idea of reducing the extra-verbose output, and maybe I'm missing something here but could this possibly be done with a much simpler approach? It seems the way these double messages happen is with the following CMake code: message(STATUS "Doing something") # Do some stuff message(STATUS "Doing something - Result") Couldn't the same thing be achieved in a platform agnostic way by adding a NOENDL option (or something similar) to the message command? Then you could achieve the same result with: message(STATUS "Doing something" NOENDL) # Do some stuff message(STATUS " - Result") Just a bit of logic to add the NOENDL option and then another to omit the message prefix if the previous call used NOENDL. It seems this could achieve the compact log result, do it in a platform agnostic way, and also provide the useful feature to the message command for users. It would be a two-step process: first, enhance the message command, second, update the various .cmake files in Sources/Modules to leverage the new syntax. Just my 2 cents. - Chuck On Wed, Sep 24, 2014 at 8:36 AM, Brad King wrote: > On 09/24/2014 08:02 AM, Adam Strzelecki wrote: > > cmThread utility class > > Introducing threads is exactly the "too much infrastructure" > to which I was referring in my previous response. I'm sorry > to reject all the effort you put into the threads approach so > far, but I did say this earlier. > > > cmake emits simply too much (redundant) information. > > IIRC the original reason for having separate > > -- Looking for iconv.h > -- Looking for iconv.h - Found > > lines is that the first one prints what is about to be > done in case something happens (e.g. crash) that prevents > the second output from ever showing up. That helps a lot > in tracking down the problem. If another thread buffers > the first message then it might not show up at all. The > terminal escape codes approach does not have that problem. > > The same de-dup you do in the threaded filter could be done > with a shell alias that pipes 'cmake' output through a sed > script or something to de-dup it. That would handle local > interactive terminal use of cmake without any upstream > changes. > > -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 Wed Sep 24 09:48:24 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 09:48:24 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> Message-ID: <5422CBA8.5030201@kitware.com> On 09/24/2014 09:44 AM, Chuck Atkins wrote: > message(STATUS "Doing something" NOENDL) > # Do some stuff > message(STATUS " - Result") What happens if something else occurs in between that prints a message? Do we tolerate -- Doing something-- Unrelated Message - Result instead of -- Doing something -- Unrelated Message -- Doing something - Result ? Also the approach needs to work in ccmake where only one status line is shown at a time. -Brad From brad.king at kitware.com Wed Sep 24 09:55:42 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 09:55:42 -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> Message-ID: <5422CD5E.7020008@kitware.com> 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. -Brad From robert.maynard at kitware.com Wed Sep 24 10:07:10 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 24 Sep 2014 10:07:10 -0400 Subject: [cmake-developers] [OSX CMake.dmg] Replace >10.6 build with 64-bit only and use bzip2 compression In-Reply-To: <1AE2B46D-8E37-43C1-BAB2-F7C8D03AB26C@java.pl> References: <1AE2B46D-8E37-43C1-BAB2-F7C8D03AB26C@java.pl> Message-ID: I believe that the reason for both of these behaviors is that the DragNDrop generator was written when a significant number of < 10.6 machines existed in the wild. I don't see any reason why we shouldn't update the default for CPACK_DMG_FORMAT to be UDBZ instead of UDZO On Wed, Sep 24, 2014 at 8:26 AM, Adam Strzelecki wrote: > Not an big issue but official DMG bundles are 40 MB where my manually built one is 21 MB (half of it). > > So any reason for: > * providing universal FAT binaries instead of 64-bit only for >=10.6 Darwin64 build, as anyway there is 32-bit build for these who have 32-bit only CPU? > * using DMG zlib compression instead bzip2 for all builds which is available for 10.4+ and provides much better compression ratio? > > --Adam > > -- > > 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 chuck.atkins at kitware.com Wed Sep 24 10:11:56 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 24 Sep 2014 10:11:56 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <5422CBA8.5030201@kitware.com> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> <5422CBA8.5030201@kitware.com> Message-ID: > > What happens if something else occurs in between that prints > a message? Do we tolerate > > -- Doing something-- Unrelated Message > - Result > > instead of > > -- Doing something > -- Unrelated Message > -- Doing something - Result > Sure, why not? There's no requirement to use the NOENDL, it would just be an additional option. The places where this happens is most in the Modules/* code for system introspection. If the code path allows for extensive messaging in between status messages, then just don't use the NOENDL option. It would be entirely optional and up to whomever is writing the CMake code whether or not to use it. We could easily use it in most of the system introspection modules without worry though. > Also the approach needs to work in ccmake where only one > status line is shown at a time. > Sure it would. Nothing monumental would need to change though. It currently output's every message separately, but it could just output the current message append to the previous message and then when an endline is found then clear the append message buffer. I'm not saying it should be done this way, just offering an alternate approach that might be more flexible. The details and tests would still need to be worked out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Sep 24 10:13:16 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 10:13:16 -0400 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <54202D1B.5040300@kitware.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> <54202D1B.5040300@kitware.com> Message-ID: <5422D17C.3000408@kitware.com> On 09/22/2014 10:07 AM, Brad King wrote: > Or, one could add the explicit PUSH/POP in modules, e.g. > > cmake_policy(PUSH) > cmake_policy(SET CMP0054 NEW) > ... module code ... > cmake_policy(POP) Until such time as someone wishes to port a module explicitly with the above approach we can use the explicit dereference approach Adam first posted. I've applied his patch here: FindCUDA: Avoid if() auto-dereference in string comparisons http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=84e3fde9 -Brad From brad.king at kitware.com Wed Sep 24 10:15:29 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 10:15:29 -0400 Subject: [cmake-developers] [OSX CMake.dmg] Replace >10.6 build with 64-bit only and use bzip2 compression In-Reply-To: References: <1AE2B46D-8E37-43C1-BAB2-F7C8D03AB26C@java.pl> Message-ID: <5422D201.5010808@kitware.com> On 09/24/2014 10:07 AM, Robert Maynard wrote: > I believe that the reason for both of these behaviors is that the > DragNDrop generator was written when a significant number of < 10.6 > machines existed in the wild. > > I don't see any reason why we shouldn't update the default for > CPACK_DMG_FORMAT to be UDBZ instead of UDZO IIUC Adam was talking about the CMake binary distribution itself, not CPack defaults. I don't think we should change the defaults in a minor release, but we can change the way our official binary is built. Thanks, -Brad From robert.maynard at kitware.com Wed Sep 24 10:22:30 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 24 Sep 2014 10:22:30 -0400 Subject: [cmake-developers] [OSX CMake.dmg] Replace >10.6 build with 64-bit only and use bzip2 compression In-Reply-To: <5422D201.5010808@kitware.com> References: <1AE2B46D-8E37-43C1-BAB2-F7C8D03AB26C@java.pl> <5422D201.5010808@kitware.com> Message-ID: Okay I have just merged into next a topic that switches over the official release to be built with UDBZ. Once the dashboards are happy I will update the x86_64 release to not be universal binaries. On Wed, Sep 24, 2014 at 10:15 AM, Brad King wrote: > On 09/24/2014 10:07 AM, Robert Maynard wrote: >> I believe that the reason for both of these behaviors is that the >> DragNDrop generator was written when a significant number of < 10.6 >> machines existed in the wild. >> >> I don't see any reason why we shouldn't update the default for >> CPACK_DMG_FORMAT to be UDBZ instead of UDZO > > IIUC Adam was talking about the CMake binary distribution itself, > not CPack defaults. I don't think we should change the defaults > in a minor release, but we can change the way our official binary > is built. > > Thanks, > -Brad > From ono at java.pl Wed Sep 24 10:29:39 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 24 Sep 2014 16:29:39 +0200 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <5422CBA8.5030201@kitware.com> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> <5422CBA8.5030201@kitware.com> Message-ID: <04D547CB-627C-40A2-8644-AC8016EF745C@java.pl> > What happens if something else occurs in between that prints > a message? That's why my solution is completely automatic, does not require any changes in existing modules, and it works as desired so only: -- Doing something -- Doing something - Result That arrive to stdout are compacted to: -- Doing something - Result When anything comes in between both to stdout and stderr then compaction does not occur. Also the preliminary message "-- Doing something" is of course emitted, but cursor waits on end of line instead new line, just in case we get 2nd matching Result line. If next line is anything else then new line gets appended and rest goes as usual. Please try to build this stage branch and try to run cmake agains cmake :) (FYI fixed bug preventing compiling on Linux) --Adam From brad.king at kitware.com Wed Sep 24 10:34:45 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 10:34:45 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <04D547CB-627C-40A2-8644-AC8016EF745C@java.pl> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> <5422CBA8.5030201@kitware.com> <04D547CB-627C-40A2-8644-AC8016EF745C@java.pl> Message-ID: <5422D685.1030201@kitware.com> On 09/24/2014 10:29 AM, Adam Strzelecki wrote: > Please try to build this stage branch and try to run cmake In case I was not clear the last two times: We will *NOT* be introducing use of *THREADS* in CMake just to filter our own output. -Brad From ono at java.pl Wed Sep 24 10:47:45 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 24 Sep 2014 16:47:45 +0200 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <5422D685.1030201@kitware.com> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> <5422CBA8.5030201@kitware.com> <04D547CB-627C-40A2-8644-AC8016EF745C@java.pl> <5422D685.1030201@kitware.com> Message-ID: > We will *NOT* be introducing use of *THREADS* in CMake just > to filter our own output. Yeah, got it. Are subprocess allowed then? > (?) just to filter our own output. Please note that such solution that filters stdout low level is superior to doing it as CMake owns level because cmake may be launching some external program, library or whatever that also pushes something to stdout/stderr and if we don't take this into account then output will get likely broken. --Adam From ono at java.pl Wed Sep 24 10:49:19 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 24 Sep 2014 16:49:19 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <5422D17C.3000408@kitware.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> <54202D1B.5040300@kitware.com> <5422D17C.3000408@kitware.com> Message-ID: <3142951A-E638-46A3-8F4E-E84B767C1933@java.pl> Again, shouldn't we consider having CMP0011 always NEW for internal modules / or do implicit push&pop for include when CMP0011 is NEW *OR* when included module is part of CMake own modules? --Adam From brad.king at kitware.com Wed Sep 24 10:55:09 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 10:55:09 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> <5422CBA8.5030201@kitware.com> <04D547CB-627C-40A2-8644-AC8016EF745C@java.pl> <5422D685.1030201@kitware.com> Message-ID: <5422DB4D.2030707@kitware.com> On 09/24/2014 10:47 AM, Adam Strzelecki wrote: > Are subprocess allowed then? > >> (?) just to filter our own output. > > Please note that such solution that filters stdout low level Yes, but I do not think we should have to do any filtering at all. The output should just be written to match what we want in the first place. I think the delayed-\n approach is the simplest. In the case that the output is interrupted by other content it almost certainly means something is going wrong anyway. -Brad From brad.king at kitware.com Wed Sep 24 10:58:03 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 10:58:03 -0400 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <3142951A-E638-46A3-8F4E-E84B767C1933@java.pl> References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> <54202D1B.5040300@kitware.com> <5422D17C.3000408@kitware.com> <3142951A-E638-46A3-8F4E-E84B767C1933@java.pl> Message-ID: <5422DBFB.8060806@kitware.com> On 09/24/2014 10:49 AM, Adam Strzelecki wrote: > do implicit push&pop for include when CMP0011 is NEW *OR* > when included module is part of CMake own modules I think this would be okay, as long as NO_POLICY_SCOPE is still honored when given explicitly to include() and find_package(). The only reason for the pre-CMP0011 behavior and NO_POLICY_SCOPE is in case the purpose of a module is to set policies. None of the builtin modules do that. Thanks, -Brad From aleixpol at kde.org Wed Sep 24 12:51:26 2014 From: aleixpol at kde.org (Aleix Pol) Date: Wed, 24 Sep 2014 18:51:26 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <5422CD5E.7020008@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> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gilles.Khouzam at microsoft.com Wed Sep 24 13:40:47 2014 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Wed, 24 Sep 2014 17:40:47 +0000 Subject: [cmake-developers] Windows shader compile options In-Reply-To: References: Message-ID: <275c0f79a0274db39a920d60c97fa930@CY1PR0301MB0713.namprd03.prod.outlook.com> Hi Christopher, We added the support for shaders but have only added the basic support to include shaders. Let me check what can be done to add the other properties. Gilles Khouzam Senior Development Lead Microsoft OSG From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Christopher Maughan Sent: Wednesday, September 24, 2014 05:29 To: cmake-developers at cmake.org Subject: [cmake-developers] Windows shader compile options I've been playing with the Windows shader options. I can see that it's now possible to set the following: set_property(SOURCE ${PIXELSHADER_FILES} PROPERTY VS_SHADER_TYPE Pixel) set_property(SOURCE ${VERTEXSHADER_FILES} PROPERTY VS_SHADER_TYPE Vertex) Which is cool, but I can't see if there's a way to specify the other options to the shader compiler, such as output header file, shader model, etc. Is there a way to do that, or is it a TODO? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Sep 24 14:40:15 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 14:40:15 -0400 Subject: [cmake-developers] vs-nsight-tegra-generator topic In-Reply-To: <541C3D71.7080806@kitware.com> References: <541C3D71.7080806@kitware.com> Message-ID: <5423100F.3030205@kitware.com> On 09/20/2014 12:09 PM, Mourad Boufarguine wrote: > On 09/19/2014 10:28 AM, Brad King wrote: >> Interesting. I started with an IDE-generated project file to >> see what the generator needs to produce. What version of >> Nsight Tegra are you using? > > I'm using Nsight Tegra 1.6. I used 1.5.1 originally. It looks like the use of JCompile is new in 1.6. I've added a mapping: VS: Map Nsight Tegra file types in .vcxproj files http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1167882a Thanks, -Brad From Anton.Makeev at jetbrains.com Thu Sep 25 03:14:38 2014 From: Anton.Makeev at jetbrains.com (Anton Makeev) Date: Thu, 25 Sep 2014 07:14:38 +0000 (UTC) Subject: [cmake-developers] Extracting target metadata, IDE integration References: Message-ID: Hey everyone, We are developing CLion at JetBrains that utilizes CMake as its main project model. Stephen Kelly timely drew our attention to this discussion, and I?d like to share some thoughts. Here are the general ones and I?ll also comment on separate messages in the thread. We?ve managed to get almost all the necessary project information, using ?GNU/MinGW Makefiles? generators: * list of targets comes from 'CMakeFiles/TargetDirectories.txt' * list of source files from ?CMakeFiles/A.dir/DependInfo.cmake? * list of headers and resources from ?codeblocks.cbp? file * per-file/target compiler and its flags from ?CMakeFiles/Target.dir/flags.make? * location of product files from ?CMakeFiles/Target.dir/build.make? What we miss (not all of them are directly related the targets metadata, but I'd like to share anyway since the topic is about IDE integration): * Location of every source file and target in CMakeLists - it would greatly help to refactorings, navigation etc. * Complete list of headers and resource files - they are only listed in special generators like code blocks. * An easily parseable list of errors and warnings with origin information. At the moment we parse error output but not everything can be parsed reliably. * No progress indication. Since the generation may take several minutes, providing feedback is crucial. * Ability to distinguish a library from an executable target. This will help to offer a better UI for run/debug configurations. * Possibility to collect information for every build target in one run. Currently, we have to invoke generator for every CMAKE_BUILT_TYPE separately. * CMake stops processing when it find a missing file, so that IDE cannot have full project model, until this files is created. * When there are existing in-source generated files in the project dir, CMake doesn't allow generating into a separate out-of-source folder. An IDE has to invent workarounds here. * Not sure if it?s possible at all - a lightweight phase where CMake only collects necessary information (list of files/targets, compiler settings). This will help IDE react to the changes much faster. Here is why I think the discussed functionality should not be a separate generator: CLion doesn?t have it?s own project model nor is intended as build tool replacement. Currently, the only option for CLion users is makefiles build, that is not a best option for everyone: there is a good and fast alternative ?Ninja?. Ideally, users should be able to choose whatever tool better suites them. The problem is that the generated Makefiles are used both, for internal needs, like reading project structure, and also to build and run the user?s program. If we wanted to support Ninja generator, we would need to rewrite all the logic that retrieves the project information, using the files that are created by Ninja generator. While I suppose it?s possible, it?s not the best option - very error prone and resource demanding. If CMake generated a separate descriptor, regardless the generator used (Makefiles, Ninja), it would be much easier to support; and the users will benefit from better, more reliable and faster CMake integration in an IDE. Regards, Anton Makeev From nilsgladitz at gmail.com Thu Sep 25 08:45:22 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 25 Sep 2014 14:45:22 +0200 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: <541DF762.2000107@gmail.com> References: <541DF762.2000107@gmail.com> Message-ID: <54240E62.9070001@gmail.com> @Brad: Before I rush into implementing anything and given that David already raised concerns ... would anything like this be considered for merge into CMake? Nils From brad.king at kitware.com Thu Sep 25 09:17:24 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 25 Sep 2014 09:17:24 -0400 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: <54240E62.9070001@gmail.com> References: <541DF762.2000107@gmail.com> <54240E62.9070001@gmail.com> Message-ID: <542415E4.7030708@kitware.com> On 09/25/2014 08:45 AM, Nils Gladitz wrote: > @Brad: Before I rush into implementing anything and given that David > already raised concerns ... would anything like this be considered for > merge into CMake? I'm not convinced it should be a builtin CMake feature. KWSys provides the "SharedForward" component specifically to help projects create launcher executables like this. It even helps create relocatable binaries on *NIX without $ORIGIN, and works for redistributable packages on both Windows and *NIX. All of this works without any special CMake features. While it would be nice to provide a helper for applications to do this, the only reason to include it in CMake would be to avoid an additional external dependency for the application. The same dependency management argument could be made for any library, and we can't include the world in CMake. > $ should continue to point at the real binary. > A new $ could point at the wrapper binary. The original purpose of $ was for add_custom_command and add_test to be able to refer to executables to run on command lines. That would have to be the wrapper for this use case. However, other use cases may want to pass the real binary with $. This makes the behavior of a magic wrapper hard to define in general, so it would be better to have application code manage the separate targets explicitly. Note that CMake now has a "cmake -E env" feature that could be used in custom commands and tests to set PATH before launching an executable. -Brad From ono at java.pl Thu Sep 25 09:43:23 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 25 Sep 2014 15:43:23 +0200 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <5422DB4D.2030707@kitware.com> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> <5422CBA8.5030201@kitware.com> <04D547CB-627C-40A2-8644-AC8016EF745C@java.pl> <5422D685.1030201@kitware.com> <5422DB4D.2030707@kitware.com> Message-ID: <5F27DAAB-BDE1-40FE-8377-18ED08FE6DAA@java.pl> > I think the delayed-\n approach is the simplest. In the > case that the output is interrupted by other content it > almost certainly means something is going wrong anyway. Does CMake use popen to launch processes? Or it just spawns them providing them direct access to stdin/out/err? If it was using popen then we can circumvent that too. --Adam From brad.king at kitware.com Thu Sep 25 09:49:11 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 25 Sep 2014 09:49:11 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <5F27DAAB-BDE1-40FE-8377-18ED08FE6DAA@java.pl> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> <5422CBA8.5030201@kitware.com> <04D547CB-627C-40A2-8644-AC8016EF745C@java.pl> <5422D685.1030201@kitware.com> <5422DB4D.2030707@kitware.com> <5F27DAAB-BDE1-40FE-8377-18ED08FE6DAA@java.pl> Message-ID: <54241D57.5040001@kitware.com> On 09/25/2014 09:43 AM, Adam Strzelecki wrote: >> I think the delayed-\n approach is the simplest. In the >> case that the output is interrupted by other content it >> almost certainly means something is going wrong anyway. > > Does CMake use popen to launch processes? Or it just spawns > them providing them direct access to stdin/out/err? In Source/kwsys/Process.h.in there is an API for executing child processes. Most of CMake uses a RunSingleCommand method wrapping it up here: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmSystemTools.cxx;hb=v3.0.2#l624 Some call sites share stdout/stderr and some do not. The execute_process() command is implemented with the KWSys Process API too, and that command has options for what to do with the pipes. As for the check message lines, I think it should be up to the check macro to ensure it does not invoke anything that could print intermediate output between the beginning of the line and the result of the check. -Brad From nilsgladitz at gmail.com Thu Sep 25 09:49:33 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 25 Sep 2014 15:49:33 +0200 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: <542415E4.7030708@kitware.com> References: <541DF762.2000107@gmail.com> <54240E62.9070001@gmail.com> <542415E4.7030708@kitware.com> Message-ID: <54241D6D.7030709@gmail.com> On 09/25/2014 03:17 PM, Brad King wrote: > Note that CMake now has a "cmake -E env" feature that could be > used in custom commands and tests to set PATH before launching > an executable. I currently use CMake scripts as wrappers for custom commands which set ENV{PATH} and the ENVIRONMENT property in tests. I don't currently have anything to conveniently run binaries manually from the build tree but I guess I could come up with something custom for that as well without having to make this a first class feature. It would just have been convenient having something more transparent and without manual set up for every project given how common this seems. Given the opposition I won't pursue this further. Thanks. Nils From neundorf at kde.org Thu Sep 25 16:29:44 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 25 Sep 2014 22:29:44 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: Message-ID: <1434786.OYXG2l82AR@tuxedo.neundorf.net> On Thursday, September 25, 2014 07:14:38 Anton Makeev wrote: ... > Here is why I think the discussed functionality should not be a separate > generator: > > CLion doesn?t have it?s own project model nor is intended as build tool > replacement. Currently, the only option for CLion users is makefiles build, > that is not a best option for everyone: there is a good and fast > alternative ?Ninja?. Ideally, users should be able to choose whatever tool > better suites them. > > The problem is that the generated Makefiles are used both, for internal > needs, like reading project structure, and also to build and run the user?s > program. If we wanted to support Ninja generator, we would need to rewrite > all the logic that retrieves the project information, using the files that > are created by Ninja generator. While I suppose it?s possible, it?s not the > best option - very error prone and resource demanding. > > If CMake generated a separate descriptor, regardless the generator used > (Makefiles, Ninja), it would be much easier to support; and the users will > benefit from better, more reliable and faster CMake integration in an IDE. not sure I fully understand, but it seems you are maybe not aware how the "extra generators" in cmake work. Those are basically run additionally to a "normal" generator. I.e. cmake generates makefiles or ninja files, and additionally project files for an IDE. This project file typically contains the list of targets, and for each target the build command. At that point it doesn't matter much anymore for the IDE whether the main generator is make or ninja. This is implemented with the Eclipse generator, the CodeBlocks generator and the Kate generator. They all write a project file for the IDE additionally to the makefiles/ninja files for the actual building. Alex From aklitzing at gmail.com Thu Sep 25 16:40:52 2014 From: aklitzing at gmail.com (A. Klitzing) Date: Thu, 25 Sep 2014 22:40:52 +0200 Subject: [cmake-developers] Support of codesign In-Reply-To: References: Message-ID: Hi there, I refactored the patches of Brian Milco to support code signing of bundles in MacOS. As we don't need AppStore support at the moment we didn't added the special generator for it. That could be a separate step later. As long as it runs codesign only it should be trivial enough to add it. Is it possible to add it to cmake 3.1? Original commits are taken from github: https://github.com/iPenguin/cmake Best regards Andr? Klitzing -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-codesign-on-MacOS.patch Type: text/x-diff Size: 9248 bytes Desc: not available URL: From mantis at public.kitware.com Thu Sep 25 19:17:30 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 26 Sep 2014 01:17:30 +0200 Subject: [cmake-developers] [CMake 0015172]: Show progress during generation step Message-ID: <38991cd01570a1516e6bac3c1a048a36@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15172 ====================================================================== Reported By: Stephen Kelly Assigned To: ====================================================================== Project: CMake Issue ID: 15172 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-26 01:17 CEST Last Modified: 2014-09-26 01:17 CEST ====================================================================== Summary: Show progress during generation step Description: CMake gives a lot of output during the configure step, but no output during the generate step. As of the last few releases, CMake is doing more during the generation stage to resolve transitive build properties, which can take more time, so feedback could be more valuable. CMake could show more output during the multiple stages of cmGlobalGenerator::Generate quite easily, however, the granularity of that is only the directory level. For the granularity of generating for individual targets (if that is desirable/possible/practical), each of the concrete generators would need to be modified to produce output. The output would have to be the same for each generator so that it could be uniformly parsed. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-26 01:17 Stephen Kelly New Issue ====================================================================== From steveire at gmail.com Thu Sep 25 19:25:21 2014 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 26 Sep 2014 01:25:21 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration References: Message-ID: Anton Makeev wrote: > Hey everyone, > > We are developing CLion at JetBrains that utilizes CMake as its main > project model. Stephen Kelly timely drew our attention to this discussion, > and I?d like to share some thoughts. Here are the general ones and I?ll > also comment on separate messages in the thread. Thanks! > * Location of every source file and target in CMakeLists > - it would greatly help to refactorings, navigation etc. Ok, that seems to already be part of the current design/implementation. > * Complete list of headers and resource files > - they are only listed in special generators like code blocks. That generator guesses that if foo.cpp is in the project and foo.h exists, then foo.h must also be part of the project: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmExtraCodeBlocksGenerator.cxx;h=56a6edbb;hb=HEAD#l449 That might not be true, but you can probably make the same guess inside CLion anyway? > * An easily parseable list of errors and warnings with origin information. > At the moment we parse error output but not everything can be parsed > reliably. That non-reliability of parsing that stuff might be something to file bugs about. I think it's out of scope of the metadata file design. > * No progress indication. Since the generation may take several minutes, > providing feedback is crucial. There is feedback during the configure stage, and as the generation stage may take longer as of the last few releases, I have thought that showing some progress could be worthwhile. I haven't looked into it though. I filed http://public.kitware.com/Bug/view.php?id=15172 to track the idea. Again though, this is out of scope of the target metadata file. > * Ability to distinguish a library from an executable target. > This will help to offer a better UI for run/debug configurations. This is already part of the current design/implementation. > * Possibility to collect information for every build target in one run. > Currently, we have to invoke generator for every CMAKE_BUILD_TYPE > separately. This is part of the updated design. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11041 > * CMake stops processing when it find a missing file, so that IDE cannot > have > full project model, until this files is created. True. However, if cmake stops processing (because of a missing file or many other reasons, such as a missing dependency), the full project model is not known. I'm not sure this is 'fixable'. > * When there are existing in-source generated files in the project dir, > CMake doesn't allow generating into a separate out-of-source folder. > An IDE has to invent workarounds here. I'm not sure CMake can provide a better solution to this. Would you want to run cmake in a mode which clears out such files somehow? I'm not sure that would be accepted. > Here is why I think the discussed functionality should not be a separate > generator: I think that ship has sailed. The feature is being implemented with a variable for control, not a generator. Thanks for the feedback! Steve. From steveire at gmail.com Thu Sep 25 19:27:58 2014 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 26 Sep 2014 01:27:58 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration 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: Aleix Pol wrote: > Hi, > Here's another iteration of the patch [1]. Thanks for this. Can you tell me why exportName is part of the output? http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11009 Thanks, Steve. From steveire at gmail.com Thu Sep 25 19:53:35 2014 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 26 Sep 2014 01:53:35 +0200 Subject: [cmake-developers] Was AUTOMOC designed to run for each build? References: <1701926.YV4YG1IxjZ@tuxedo.neundorf.net> Message-ID: Alexander Neundorf wrote: >> I don't see why the target is executed each time, but is it that way by >> design? > > iirc, yes. > The moc files have to be generated before any of the source files is > compiled, so automoc is in a target the actual target depends on. > IIRC it is exclude_from_all so that it is only built when the actual > target is built. > Do you think it should only rerun if any of the source files has changed ? > There was some problem with this. > The headers are usually not part of the listed source files. Hmm, well, we do know which header is relevant right? Because it's the one (or many) we set up commands to run moc on. Maybe we only know the relevant headers too late (at the time of running the -E cmake_autogen command, not at cmake time)? Something else I've wondered is why the parsing of the files is done 'delayed' with the -E cmake_autogen command. Is it just to avoid doing that task during cmake time (because it's time consuming), and to allow parallelization? Thanks, Steve. From aklitzing at gmail.com Fri Sep 26 03:29:47 2014 From: aklitzing at gmail.com (A. Klitzing) Date: Fri, 26 Sep 2014 09:29:47 +0200 Subject: [cmake-developers] Support of codesign In-Reply-To: References: Message-ID: Well, first patch had a little mistake. I attached an update... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-codesign-on-MacOS.patch Type: text/x-diff Size: 8649 bytes Desc: not available URL: From brad.king at kitware.com Fri Sep 26 09:52:52 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 26 Sep 2014 09:52:52 -0400 Subject: [cmake-developers] Support of codesign In-Reply-To: References: Message-ID: <54256FB4.1000903@kitware.com> On 09/25/2014 04:40 PM, A. Klitzing wrote: > I refactored the patches of Brian Milco to support > code signing of bundles in MacOS. [snip] On 09/26/2014 03:29 AM, A. Klitzing wrote: > Well, first patch had a little mistake. I attached an update... Thanks! I've applied the patch and merged to our 'next' branch for testing: CPack: Add support for code signing of bundles on MacOS http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1a9b0668 I would appreciate any feedback from others too. -Brad From clinton at elemtech.com Fri Sep 26 10:08:42 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Fri, 26 Sep 2014 08:08:42 -0600 (MDT) Subject: [cmake-developers] Support of codesign In-Reply-To: <54256FB4.1000903@kitware.com> References: <54256FB4.1000903@kitware.com> Message-ID: <731237400.306083.1411740522094.JavaMail.zimbra@elemtech.com> 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. Clint ----- Original Message ----- > On 09/25/2014 04:40 PM, A. Klitzing wrote: > > I refactored the patches of Brian Milco to support > > code signing of bundles in MacOS. > [snip] > On 09/26/2014 03:29 AM, A. Klitzing wrote: > > Well, first patch had a little mistake. I attached an update... > > Thanks! > > I've applied the patch and merged to our 'next' branch for > testing: > > CPack: Add support for code signing of bundles on MacOS > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1a9b0668 > > I would appreciate any feedback from others too. > > -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 > From brad.king at kitware.com Fri Sep 26 15:15:35 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 26 Sep 2014 15:15:35 -0400 Subject: [cmake-developers] Support of codesign In-Reply-To: <54256FB4.1000903@kitware.com> References: <54256FB4.1000903@kitware.com> Message-ID: <5425BB57.5080003@kitware.com> On 09/26/2014 09:52 AM, Brad King wrote: > I've applied the patch and merged to our 'next' branch for > testing: > > CPack: Add support for code signing of bundles on MacOS > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1a9b0668 I reverted the topic because several CPackComponents tests fail on OS X when the 'codesign' binary is not available. > + const std::string codesign_path = cmSystemTools::FindProgram("codesign", > + std::vector(), false); > + if(codesign_path.empty()) > + { > + cmCPackLogger(cmCPackLog::LOG_ERROR, > + "Cannot locate codesign command" > + << std::endl); > + return 0; > + } > + this->SetOptionIfNotSet("CPACK_COMMAND_CODESIGN", codesign_path.c_str()); It should not be an error for 'codesign' to not be available in the PATH. The user may have set CPACK_COMMAND_CODESIGN to some other location. The error should only occur if no value for CPACK_COMMAND_CODESIGN is available when the tool is actually needed for signing. -Brad From neundorf at kde.org Fri Sep 26 16:04:23 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Fri, 26 Sep 2014 22:04:23 +0200 Subject: [cmake-developers] Was AUTOMOC designed to run for each build? In-Reply-To: References: <1701926.YV4YG1IxjZ@tuxedo.neundorf.net> Message-ID: <201690555.7z5O7jgyHi@tuxedo.neundorf.net> On Friday, September 26, 2014 01:53:35 Stephen Kelly wrote: > Alexander Neundorf wrote: > >> I don't see why the target is executed each time, but is it that way by > >> design? > > > > iirc, yes. > > The moc files have to be generated before any of the source files is > > compiled, so automoc is in a target the actual target depends on. > > IIRC it is exclude_from_all so that it is only built when the actual > > target is built. > > Do you think it should only rerun if any of the source files has changed ? > > There was some problem with this. > > The headers are usually not part of the listed source files. > > Hmm, well, we do know which header is relevant right? Because it's the one > (or many) we set up commands to run moc on. Maybe we only know the relevant > headers too late (at the time of running the -E cmake_autogen command, not > at cmake time)? > > Something else I've wondered is why the parsing of the files is done > 'delayed' with the -E cmake_autogen command. Is it just to avoid doing that > task during cmake time (because it's time consuming), and to allow > parallelization? it can't be done at cmake time, because editing a cpp file and inserting #include "foo.moc" does not cause cmake to rerun, so the parsing must happen during buildtime. Alex From aleixpol at kde.org Fri Sep 26 19:09:40 2014 From: aleixpol at kde.org (Aleix Pol) Date: Sat, 27 Sep 2014 01:09:40 +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 Fri, Sep 26, 2014 at 1:27 AM, Stephen Kelly wrote: > Aleix Pol wrote: > > Hi, > > Here's another iteration of the patch [1]. > > Thanks for this. > > Can you tell me why exportName is part of the output? > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11009 > > Thanks, > > Steve. > > I just looked into it, GetOutputName is a private method. Now that you mention it though, we can just probably not output the exportName, at least for now. I can provide a new version of the patch if requested. Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sat Sep 27 15:25:24 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 27 Sep 2014 15:25:24 -0400 Subject: [cmake-developers] [CMake 0015173]: MinGW compiler can NOT be used when also Visual Studio 2013 is installed Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15173 ====================================================================== Reported By: Christoph Bastuck Assigned To: ====================================================================== Project: CMake Issue ID: 15173 Category: CMake Reproducibility: always Severity: major Priority: none Status: new ====================================================================== Date Submitted: 2014-09-27 15:25 EDT Last Modified: 2014-09-27 15:25 EDT ====================================================================== Summary: MinGW compiler can NOT be used when also Visual Studio 2013 is installed Description: Using Cmake 3.0.2 and compiling my project with MinGW with following command for Makefile generation: cmake X:\Projects\Path -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_RC_COMPILER=windres -G "MinGW Makefiles" gcc/g++ is in PATH and cl/link is NOT. CMake is actually detecting g++/gcc compiler and tries to compile a test sample. But uses visual studio style compiler flags instead of gcc style, i.e. /DWIN32 instead of -DWIN32. Hence compiling fails. Currently there seems possibility to choose MinGW (explicitly). So downgraded to Cmake 2.8. Here selecting the generator with flag "-G" work as expected. Steps to Reproduce: 1. Install MinGW compiler and Visual Studio 2013 on same machine 2. PATH must hold to MingGW compiler 3. remove cl/link from PATH if exists 4. Create MinGW Makefile for your project wirh command: cmake X:\Projects\Path -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_RC_COMPILER=windres -G "MinGW Makefiles" ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-27 15:25 Christoph BastuckNew Issue ====================================================================== From mantis at public.kitware.com Sun Sep 28 09:44:09 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 28 Sep 2014 09:44:09 -0400 Subject: [cmake-developers] [CMake 0015174]: TARGET_LINK_LIBRARIES adds libraries to INTERFACE_LINK_LIBRARIES without LINK_INTERFACE_LIBRARIES Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15174 ====================================================================== Reported By: Marc Seebold Assigned To: ====================================================================== Project: CMake Issue ID: 15174 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-28 09:44 EDT Last Modified: 2014-09-28 09:44 EDT ====================================================================== Summary: TARGET_LINK_LIBRARIES adds libraries to INTERFACE_LINK_LIBRARIES without LINK_INTERFACE_LIBRARIES Description: TARGET_LINK_LIBRARIES(MYTARGET PRIVATE "mylib.lib") adds "mylib.lib" to "INTERFACE_LINK_LIBRARIES" property of target "MYTARGET". However, only in LINK_INTERFACE_LIBRARIES mode this property should be set. Steps to Reproduce: TARGET_LINK_LIBRARIES(MYTARGET PRIVATE "mylib.lib") Additional Information: Hotfix: SET_PROPERTY(TARGET MYTARGET PROPERTY INTERFACE_LINK_LIBRARIES "") ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-28 09:44 Marc Seebold New Issue ====================================================================== From mantis at public.kitware.com Sun Sep 28 14:26:45 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 28 Sep 2014 14:26:45 -0400 Subject: [cmake-developers] [CMake 0015175]: Intel Fortran 15.0 Visual Studio integration requires TargetName property for renamed targets Message-ID: <10099103d363557a20fed7f6f0070e60@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15175 ====================================================================== Reported By: Ian Harvey Assigned To: ====================================================================== Project: CMake Issue ID: 15175 Category: CMake Reproducibility: sometimes Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-28 14:26 EDT Last Modified: 2014-09-28 14:26 EDT ====================================================================== Summary: Intel Fortran 15.0 Visual Studio integration requires TargetName property for renamed targets Description: A change to the behaviour of the Visual Studio integration with ifort 15.0 means that executable and DLL projects that have the base part of the output filename different to the name of the project need to have the TargetName property set for the project, or the integration will issue warnings during the build and the manifest tool will fail (an EXE or DLL may still be produced). Steps to Reproduce: With the following Fortran source in a file named HelloWorld.f90: IMPLICIT NONE PRINT "('Hello world')" END and the following CMakeLists.txt in the same directory as above: cmake_minimum_required(VERSION 3.0.2) project(helloworld Fortran) add_executable(helloworld "HelloWorld.f90") set_target_properties(helloworld PROPERTIES OUTPUT_NAME foobar) >From within an Intel Fortran command prompt in a build subdirectory run cmake: >"c:\Program Files (x86)\CMake\bin\cmake.exe" .. -- Building for: Visual Studio 10 2010 -- The Fortran compiler identification is Intel -- Check for working Fortran compiler using: Visual Studio 10 2010 -- Check for working Fortran compiler using: Visual Studio 10 2010 -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Determine Intel Fortran Compiler Implicit Link Path -- Determine Intel Fortran Compiler Implicit Link Path -- done -- Checking whether C:/Program Files (x86)/Intel/Composer XE 2015/bin/ia32/ifort.exe supports Fortran 90 -- Checking whether C:/Program Files (x86)/Intel/Composer XE 2015/bin/ia32/ifort.exe supports Fortran 90 -- yes -- Configuring done -- Generating done -- Build files have been written to: H:/Projects/cmake-test/build Use cmake to then build the generated solution: >"c:\Program Files (x86)\CMake\bin\cmake.exe" --build . 1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32 ------ 1> Checking Build System 1> CMake does not need to re-run because H:/Projects/cmake-test/build/CMakeFiles/generate.stamp is up-to-date. 2>------ Build started: Project: helloworld, Configuration: Debug Win32 ------ 2>helloworld: warning: TargetPath(H:\Projects\cmake-test\build\Debug\helloworld.exe) does not match the Linker's OutputF ile property value (H:\Projects\cmake-test\build\Debug\foobar.exe). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile). 2>Compiling with Intel(R) Visual Fortran Compiler XE 15.0.0.108 [IA-32]... 2>HelloWorld.f90 2>Compiling manifest to resources... 2>Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385 2>Copyright (C) Microsoft Corporation. All rights reserved. 2>Linking... 2>Microsoft (R) Incremental Linker Version 10.00.40219.01 2>Copyright (C) Microsoft Corporation. All rights reserved. 2>/OUT:H:\Projects\cmake-test\build\Debug\foobar.exe 2>/VERSION:0.0 2>/MANIFEST 2>/MANIFESTFILE:helloworld.dir\Debug\helloworld.exe.intermediate.manifest 2>"/MANIFESTUAC:level='asInvoker' uiAccess='false'" 2>/DEBUG 2>/PDB:H:\Projects\cmake-test\build\Debug/foobar.pdb 2>/SUBSYSTEM:CONSOLE 2>/IMPLIB:H:\Projects\cmake-test\build\Debug\foobar.lib 2>user32.lib 2>/machine:X86 2>/debug 2>/INCREMENTAL 2>helloworld.dir\Debug\HelloWorld.obj 2>helloworld.dir\Debug\helloworld.exe.embed.manifest.res 2>Embedding manifest... 2>mt.exe : general error c10100b1: Failed to load file "H:\Projects\cmake-test\build\Debug\helloworld.exe". The system c annot find the file specified. 2> 2>Build log written to "file://H:\Projects\cmake-test\build\helloworld.dir\Debug\BuildLog.htm" 2>helloworld - 1 error(s), 1 warning(s) 3>------ Build started: Project: ALL_BUILD, Configuration: Debug Win32 ------ 3> Building Custom Rule H:/Projects/cmake-test/CMakeLists.txt 3> CMake does not need to re-run because H:\Projects\cmake-test\build\CMakeFiles\generate.stamp is up-to-date. 3> Build all projects ========== Build: 3 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== Additional Information: This patch applied to cmLocalVisualStudio7Generator.cxx is a crude fix. 637a638,641 > > // stolen from cmGlobalVisualStudio7Generator.cxx > #define CM_INTEL_PLUGIN_GUID "{B68A201D-CB9B-47AF-A52F-7EEC72E217E4}" > 651a656,677 > // ifort 15.0 integration uses TargetName property. Installed integration > // version test lifted from cmGlobalVisualStudio7Generator.cxx. > unsigned int intelVersionNumber = ~0u; > if (this->FortranProject) { > cmGlobalVisualStudio7Generator* gg = > static_cast( > this->GlobalGenerator ); > std::string intel_registry_version; > std::string vskey = gg->GetRegistryBase(); > vskey += "\\Packages\\" CM_INTEL_PLUGIN_GUID ";ProductVersion"; > cmSystemTools::ReadRegistryValue(vskey.c_str(), intel_registry_version, > cmSystemTools::KeyWOW64_32); > sscanf(intel_registry_version.c_str(), "%u", &intelVersionNumber); > if (intelVersionNumber == 15) { > std::string prefix; > std::string base; > std::string suffix; > target.GetFullNameComponents(prefix, base, suffix); > fout << "\t\t\tTargetName=\"" << this->EscapeForXML(base.c_str()) > << "\"\n"; > } > } ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-28 14:26 Ian Harvey New Issue ====================================================================== From mantis at public.kitware.com Mon Sep 29 06:24:22 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 29 Sep 2014 06:24:22 -0400 Subject: [cmake-developers] [CMake 0015176]: typo in Modules/GNUInstallDirs.cmake Message-ID: <55bf009b044a5d83380b3603a10a6242@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15176 ====================================================================== Reported By: David Coppa Assigned To: ====================================================================== Project: CMake Issue ID: 15176 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-29 06:24 EDT Last Modified: 2014-09-29 06:24 EDT ====================================================================== Summary: typo in Modules/GNUInstallDirs.cmake Description: Commit d4fdd9c189f85d659f4294f8ec6da3e7e51215ec ("GNUInstallDirs: use the proper default for info and man paths on OpenBSD") introduced a typo: CMAKE_INSTALL_MANDDIR -> CMAKE_INSTALL_MANDIR The attached diff fixes the issue. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-29 06:24 David Coppa New Issue 2014-09-29 06:24 David Coppa File Added: 0001-Fix-typo-in-Modules-GNUInstallDirs.cmake.patch ====================================================================== From aklitzing at gmail.com Mon Sep 29 06:29:20 2014 From: aklitzing at gmail.com (A. Klitzing) Date: Mon, 29 Sep 2014 12:29:20 +0200 Subject: [cmake-developers] Support of codesign In-Reply-To: <5425BB57.5080003@kitware.com> References: <54256FB4.1000903@kitware.com> <5425BB57.5080003@kitware.com> Message-ID: > > It should not be an error for 'codesign' to not be available > in the PATH. The user may have set CPACK_COMMAND_CODESIGN > to some other location. The error should only occur if no > value for CPACK_COMMAND_CODESIGN is available when the tool > is actually needed for signing. > I attached another patch that will fix the broken tests. It will check for defined CPACK_APPLE_CERT_APP before it will search for 'codesign'. Well, the FindProgram line for codesign looks like the line for Rez, hdiutil, SetFile and so on. I don't know cmake sources enough... but shouldn't it be the same here? Andr? -------------- 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: 8662 bytes Desc: not available URL: From ruslan_baratov at yahoo.com Mon Sep 29 09:35:21 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Mon, 29 Sep 2014 17:35:21 +0400 Subject: [cmake-developers] iOS support In-Reply-To: References: <54217E53.2070902@kitware.com> <54218A16.1010008@kitware.com> Message-ID: <54296019.40602@yahoo.com> On 23-Sep-14 19:42, Florent Castelli wrote: > On 23 Sep 2014, at 16:56, Bill Hoffman wrote: > >>> That said it would be really cool to beef up the xcode support enough to >>> be able to create an actual ios app. I have not dug into that enough. >>> Should be able to do most of it with CMAKE_XCODE_ATTRIBUTE. I will >>> look into this try_compile COPY_FILE issue today and get back to the list. >>> >>> It would be great if you could get an example/Test in place that builds >>> an app for a device and works with Xcode and for a stretch goal also >>> works with makefiles or ninja. >>> >> Couple of more things. >> >> 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. This would be a great thing to work on. >> > 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. > Hi, Universal libraries can be built by setting CMAKE_OSX_SYSROOT to "iphoneos". This is how it works for me: * https://github.com/ruslo/polly/blob/master/ios-7-1.cmake * https://github.com/ruslo/polly/blob/master/os/iphone.cmake * https://github.com/ruslo/polly/wiki/Toolchain-list#ios real root was found by invoking `xcode-select -print-path`, i.e. you can switch iOS version by providing appropriate DEVELOPER_DIR environment variable. Works for Xcode only (since Xcode 5.0). Ruslo From clinton at elemtech.com Mon Sep 29 09:55:28 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Mon, 29 Sep 2014 07:55:28 -0600 (MDT) Subject: [cmake-developers] Support of codesign In-Reply-To: References: <54256FB4.1000903@kitware.com> <5425BB57.5080003@kitware.com> Message-ID: <1481907634.197627.1411998928462.JavaMail.zimbra@elemtech.com> ----- Original Message ----- > > It should not be an error for 'codesign' to not be available > > > in the PATH. The user may have set CPACK_COMMAND_CODESIGN > > > to some other location. The error should only occur if no > > > value for CPACK_COMMAND_CODESIGN is available when the tool > > > is actually needed for signing. > > I attached another patch that will fix the broken tests. It will check for > defined CPACK_APPLE_CERT_APP before it will search for 'codesign'. > Well, the FindProgram line for codesign looks like the line for Rez, hdiutil, > SetFile and so on. I don't know cmake sources enough... but shouldn't it be > the same here? 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? Thanks, Clint -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Mon Sep 29 10:19:45 2014 From: DLRdave at aol.com (David Cole) Date: Mon, 29 Sep 2014 10:19:45 -0400 Subject: [cmake-developers] Support of codesign In-Reply-To: <1481907634.197627.1411998928462.JavaMail.zimbra@elemtech.com> References: <54256FB4.1000903@kitware.com> <5425BB57.5080003@kitware.com> <1481907634.197627.1411998928462.JavaMail.zimbra@elemtech.com> Message-ID: Maybe it shouldn't even be a CPack thing..... Maybe it should be an install time step so that all CPack generators will contains signed binaries if codesign is used... D On Mon, Sep 29, 2014 at 9:55 AM, wrote: > > > ________________________________ >> >> It should not be an error for 'codesign' to not be available >> in the PATH. The user may have set CPACK_COMMAND_CODESIGN >> to some other location. The error should only occur if no >> value for CPACK_COMMAND_CODESIGN is available when the tool >> is actually needed for signing. > > > I attached another patch that will fix the broken tests. It will check for > defined CPACK_APPLE_CERT_APP before it will search for 'codesign'. > > Well, the FindProgram line for codesign looks like the line for Rez, > hdiutil, SetFile and so on. I don't know cmake sources enough... but > shouldn't it be the same here? > > > 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? > > Thanks, > Clint > > -- > > 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 chuck.atkins at kitware.com Mon Sep 29 13:23:04 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 29 Sep 2014 13:23:04 -0400 Subject: [cmake-developers] Support of codesign In-Reply-To: References: <54256FB4.1000903@kitware.com> <5425BB57.5080003@kitware.com> <1481907634.197627.1411998928462.JavaMail.zimbra@elemtech.com> Message-ID: > > Maybe it shouldn't even be a CPack thing..... Maybe it should be an > install time step so that all CPack generators will contains signed > binaries if codesign is used... > I know this is a bit after the fact and I'm jumping in here pretty late, but... It would be nice to have package signing as a general top level CPack feature. Most supported package formats support some form of signing, rpm and deb with gpg keys, apple bundles, dmgs, nsis installers, etc. Could this be done as a generic CPack variable, CPACK_PACKAGE_SIGNING_KEY, for example, and then if set, then each CPack generator would use it accordingly? Just a thought, not to derail this current patch though. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton at elemtech.com Mon Sep 29 14:00:59 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Mon, 29 Sep 2014 12:00:59 -0600 Subject: [cmake-developers] Support of codesign In-Reply-To: References: Message-ID: <2614570.QAlDDbOxL6@stryke> On Monday, September 29, 2014 01:23:04 PM Chuck Atkins wrote: > > Maybe it shouldn't even be a CPack thing..... Maybe it should be an > > install time step so that all CPack generators will contains signed > > binaries if codesign is used... > > I know this is a bit after the fact and I'm jumping in here pretty late, > but... > > It would be nice to have package signing as a general top level CPack > feature. Most supported package formats support some form of signing, rpm > and deb with gpg keys, apple bundles, dmgs, nsis installers, etc. Could > this be done as a generic CPack variable, CPACK_PACKAGE_SIGNING_KEY, for > example, and then if set, then each CPack generator would use it > accordingly? > > Just a thought, not to derail this current patch though. The patch does introduce a SignPackage() function, but what its really doing is signing the application, not the package. There is another suggestion for the patch -- rename the SignPackage() function to be clear that the application is being signed, not the package. At least in the CPack context, the package is the .dmg file, not the .app bundle. The Bundle generator creates an application bundle plus the package. Because the Bundle generator makes the application, a user would want a way to sign it. This is why its Bundle generator specific. With any other generator, the application signing can be done with an install() command. 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. Clint From mantis at public.kitware.com Tue Sep 30 06:38:12 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 30 Sep 2014 06:38:12 -0400 Subject: [cmake-developers] [CMake 0015178]: CMake very slow at generation stage Message-ID: <68f6564abd8b35cd72fe1a50c397fbe0@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15178 ====================================================================== Reported By: Christophe Prud'homme Assigned To: ====================================================================== Project: CMake Issue ID: 15178 Category: (No Category) Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-30 06:38 EDT Last Modified: 2014-09-30 06:38 EDT ====================================================================== Summary: CMake very slow at generation stage Description: on macosx the generation stage is very slow and it seems that it is the dependencies computation. On our projet (http://www.feelpp.org) is takes minutes for the generation stage while it took seconds in the previous version. On Linux no such issues. It seems that there are a lot of call to otool on macosx and it might be that that slows down thinks ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-30 06:38 Christophe Prud'hommeNew Issue ====================================================================== From ewmailing at gmail.com Tue Sep 30 07:07:32 2014 From: ewmailing at gmail.com (Eric Wing) Date: Tue, 30 Sep 2014 04:07:32 -0700 Subject: [cmake-developers] iOS support In-Reply-To: References: Message-ID: On 9/23/14, Florent Castelli wrote: > Hi! > > My company is organizing soon a hack week where each employee is able to > work on any project he wants. So, I've decided to work with Cmake and > improve support for iOS to help the product team getting rid of manual > project files, constant merge conflicts and bad project file documentation, > while improving our tooling possibilities (all that with Cmake!). > > I've had a quick look at the first issue that popped into my mind the other > day and fixed try_compile by adding another variable to set the executable > type in the generated project (it has to be MACOSX_BUNDLE) and fixing the > search path for the resulting binary. > So this is now working... Providing we are targeting the simulator. > Due to the nature of Xcode projects that can easily target either the > simulator or devices, thus using different compilation flags, the resulting > projects aren't working in both case. There are conflicts between some > options like the minimum iOS version target and the minimum iOS simulator > target for example (which you need to build the try_compile binaries > without signing them). > Also, the Xcode support is very OSX focused and all variables have MACOSX > in their name, which is confusing. > > So, has anyone worked on similar issues and can suggest a way to progress > and improve support for iOS? > In the end, I'd like to have a working Xcode project with separate settings > for both simulator and device, Cmake compiler flag detection working, and > possibly later Make/Ninja projects working too. > > Regards, > /Orphis > This is off the top of my head, and its late... Some context...I'm developing a new SDK for game developers. I've been spending a lot of time with the generators (Windows, Linux, Mac, iOS, Android, and playing with Windows Phone recently). CMake is the best game in town for handling all these platforms. But there are also a ton of things that annoy me. My goal is to help people build apps they can ship, but much of CMake's thought process is about building apps locally for your system and the work flow isn't correct in my opinion. I've done a lot to address these short-comings and I hope to clear some time to talk about all this and share my changes in the near future. (Especially the Android stuff...I had to build a lot of crap to make that work and I would like to fold that back into the CMake core because it is evil.) As for iOS (and some Mac), one of my peevs is that the application bundle process doesn't happen as part of the build. For a normal Mac/iOS development, you always rebuild your code and your application bundle. CMake treats this as two discrete steps so what you develop/test is different from what you ship. (And incidentally in the Visual Studio case, I discovered it is impossible to launch your app via the debugger because of this too.) Additionally, the iOS/CMake stuff is flakey about letting you switch between device and simulator. You shouldn't have to generate a completely different project to test between the two. This is not how iOS developers work nor how the Xcode toolchain is designed. (And now that we have 32-bit and 64-bit versions of both, it's ridiculous.) I some how got mine to the point where I can switch targets in the same project, but it's flakey due to the way CMake injects paths/values into the Xcode project. It isn't the same exact values as Apple, so somethings like finding frameworks/libraries cause me to do some tricks. Also on that note, just getting CMake to pick the proper "Lastest SDK" value by default would be nice. It is hard coding some full path which seems to work in base cases, but causes me problems in other cases. I noticed when Xcode versions change, this often is the main culprit for new breakage. All the configuration options are blank for me. The Mac one works, but iOS is blank for me. This means thinks like all my optimization settings are the same (debug and release have the same values). I can set these values manually, but I have only been able to do it to my own targets explicitly. My attempts to set the values globally (at the root) have not succeeded. I still haven't dealt with launch images and icons. A proper sized launch image is required to get the iPhone 5 and iPhone 6 "tall" resolutions without letterboxing. I'm not sure what the right thing to do here is with CMake. I'm doing my own application bundling to some degree. As I said, CMake's normal process goes against the grain of the normal workflow so I changed it to behave like the real thing. I'm having trouble remembering, but I think the CMake/Mac had better handling than CMake/iOS. CMake was doing some stuff for me better than iOS, but I don't fully remember. (May have something to do with listing resources as part of the target.) But one place I found CMake to be really annoying was with nested directories and also symlinks. Copying a framework into a bundle is a good example because it has both. And ideally, you only want to do it when there is a change. (I think I got lazy and call rsync in some places since I know it is installed on Mac.) Codesigning for both Mac and iOS I haven't figured out yet either. On iOS, you have development and distribution keys. On Mac, you also have Mac App Store vs. GateKeeper. Xcode normally gives you a display to let you see and configure important things like Sandboxing options, launch images, icon resolutions, code signing. But when going through the CMake generator, it doesn't show any of this stuff. I don't know why, but it's disturbing/scary (because it feels broken/fragile) and annoying. Maybe updating the underlying Xcode template CMake uses will help? I would like CMake's install/packaging system to work seamlessly with the built in archiving system which is what people use to prepare an iOS app for submission to the App Store. There is a bug I sometimes hit where the generated Xcode project causes the "Indexing" phase to get stuck and I have to kill Xcode. And when it happens to me, it keeps happening. This really scares me, but I can't reliably reproduce it. Xcode 6 seems to have improved the problem for me (so far). For building libraries instead of applications, iOS 8 now has 3rd party framework support (to support their new plugin system). I have not tested this. But the framework layout is different than in Mac (similar to how the .app bundle layout differs between iOS and Mac). I'm guessing this will need to be adjusted in CMake. Also, FYI, flat dylibs are not supported as far as I know...only frameworks. Also, I think the @rpath stuff is still important, and I read that Apple has now split the setting that was once the "install path" into two separate entries, where the new entry is just for the rpath. (Install path never made a lot of sense the way Apple does things since there is never really an install path.) Yes, it would be nice to build Universal binaries with simulator and devices in the same fat binary, but Apple doesn't do this for you, and I don't know if CMake should do this for you either. I saw on the Xcode list, one senior Apple engineer was being difficult when pressed on this issue. I think Apple is trying to leave open the possibility that there could be an x86 device target some day, in which case it would conflict with an x86 simulator target. Annoying. Currently, I just lipo everything myself manually and say screw it. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ From nilsgladitz at gmail.com Tue Sep 30 10:05:43 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 30 Sep 2014 16:05:43 +0200 Subject: [cmake-developers] kwsys SystemTools::RelativePath() Message-ID: <542AB8B7.8020102@gmail.com> When both operands are the same absolute path I get the empty string as a result. Should it be "."? Nils From norman-k-williams at uiowa.edu Tue Sep 30 10:14:15 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Tue, 30 Sep 2014 14:14:15 +0000 Subject: [cmake-developers] find_package issues with ITK and VTK (and SlicerExecution Model) Message-ID: This is a problem that has been cropping up in our projects that use ITK, VTK and SlicerExecutionModel. You won?t see it UNLESS you turn on the ITKVTK/ITKVtkGlue modules. The problem is this: if you find packages in this order: find_package(VTK REQUIRED) find_package(ITK REQUIRED) You can?t real compile anything that needs VTK, because down in the ITK deployment stuff, it calls find_package(VTK) like this: find_package(VTK COMPONENTS vtkCommonCore vtkRenderingCore vtkRenderingOpenGL vtkRenderingFreeType vtkInteractionStyle vtkIOImage vtkImagingSources REQUIRED) Which blows away the larger list of include directories and libraries that the first find_package(VTK REQUIRED) built. Even better ? or worse ? Modules/Segmentation/LevelSetsv4Visualization/CMakeLists.txt also include find_package(VTK) ? so ITK tries to import VTK twice, with different module lists. It doesn?t even help to reverse the order: find_package(ITK REQUIRED) find_package(VTK REQUIRED) because apparently there?s some hangover from the find_package(VTK) inside the ITK CMake deployment files. The only thing that works is to use COMPONENTS, i.e. find_package(ITK REQUIRED) find_package(VTK COMPONENTS vtkCommonCore vtkRenderingAnnotation ? REQUIRED) Which seems to trigger a proper re-scan and build of the library/include lists. It gets even worse if you use find_package(SlicerExecutionModel) after find_package(ITK), for the same reason ? SlicerExecutionModel depends on ITK, so it clobbers the include/library lists from the first find_package(ITK). ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Sep 30 10:48:47 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 30 Sep 2014 10:48:47 -0400 Subject: [cmake-developers] [ITK-dev] find_package issues with ITK and VTK (and SlicerExecution Model) In-Reply-To: References: Message-ID: <542AC2CF.7030008@kitware.com> On 09/30/2014 10:14 AM, Williams, Norman K wrote: > find_package(VTK REQUIRED) > find_package(ITK REQUIRED) > > You can?t real compile anything that needs VTK, because down in > the ITK deployment stuff, it calls find_package(VTK) like this: [snip] > Which blows away the larger list of include directories and libraries One may use the itk_module_config and vtk_module_config macros from the *ModuleAPI.cmake modules that come with the respective packages to compute the list of libraries and include dirs for a given list of components. All ITKConfig and VTKConfig do with the list of components is: itk_module_config(ITK ${ITK_MODULES_REQUESTED}) # sets ITK_LIBRARIES, ITK_INCLUDE_DIRS, etc. and vtk_module_config(VTK ${VTK_MODULES_REQUESTED}) # sets VTK_LIBRARIES, VTK_INCLUDE_DIRS, etc. One can invoke these directly: itk_module_config(ITK ${MY_LIST_OF_ITK_COMPONENTS}) vtk_module_config(VTK ${MY_LIST_OF_VTK_COMPONENTS}) at any time after the find_package calls. One could even use a different prefix: itk_module_config(MyITK ${MY_LIST_OF_ITK_COMPONENTS}) # sets MyITK_LIBRARIES, MyITK_INCLUDE_DIRS, etc. In the long run the plan is to stop recommending use of component lists at find_package time and instead use imported targets and usage requirements: http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#build-specification-and-usage-requirements but that will have to wait until we can require CMake 3.0. -Brad From brad.king at kitware.com Tue Sep 30 11:22:57 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 30 Sep 2014 11:22:57 -0400 Subject: [cmake-developers] [ITK-dev] find_package issues with ITK and VTK (and SlicerExecution Model) In-Reply-To: References: <542AC2CF.7030008@kitware.com> Message-ID: <542ACAD1.2040805@kitware.com> On 09/30/2014 11:13 AM, Bradley Lowekamp wrote: > Do you have a suggestion on how to conditionally include a > module if it's available? e.g. Use ITKDeprecated if ITK was > configure with it? find_package(ITK REQUIRED) set(MY_ITK_COMPONENTS ...) # list required mods here if(";${ITK_MODULES_ENABLED};" MATCHES ";ITKDeprecated;") list(APPEND MY_ITK_COMPONENTS ITKDeprecated) endif() itk_module_config(ITK ${MY_ITK_COMPONENTS}) I think the if() line could also be written if(TARGET ITKDeprecated) but I don't remember off the top of my head whether the library names and module names always match exactly. -Brad From brad.king at kitware.com Tue Sep 30 11:27:12 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 30 Sep 2014 11:27:12 -0400 Subject: [cmake-developers] Integrate fixdep for kconfig In-Reply-To: References: Message-ID: <542ACBD0.3030209@kitware.com> 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 From brad.king at kitware.com Tue Sep 30 11:37:27 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 30 Sep 2014 11:37:27 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic Message-ID: <542ACE37.1040302@kitware.com> Hi Folks, Picking up from the end of an earlier thread: [PATCH] stage/fix-OSX-bundle-rpaths-and-Qt5 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10781/focus=11016 Is the fix-OSX-bundle-rpaths-and-Qt5 topic ready to be merged to 'next' for testing? Clinton, have your comments been addressed? Thanks, -Brad From clinton at elemtech.com Tue Sep 30 11:54:59 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Tue, 30 Sep 2014 09:54:59 -0600 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <542ACE37.1040302@kitware.com> References: <542ACE37.1040302@kitware.com> Message-ID: <5370725.77ofmgz3NP@stryke> On Tuesday, September 30, 2014 11:37:27 AM Brad King wrote: > Hi Folks, > > Picking up from the end of an earlier thread: > > [PATCH] stage/fix-OSX-bundle-rpaths-and-Qt5 > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10781/focu > s=11016 > > Is the fix-OSX-bundle-rpaths-and-Qt5 topic ready to be merged to > 'next' for testing? Clinton, have your comments been addressed? > > Thanks, > -Brad My concerns of breaking backward compatibility were already addressed. However, I do wish there is a test for this. Although the commits target OS X, I would like to see some proof that the API changes in GetPrerequisites for supporting rpaths will work on other platforms such as Linux. A test for both OS X and Linux will help justify the API changes. Clint From ono at java.pl Tue Sep 30 12:24:29 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 30 Sep 2014 18:24:29 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <5370725.77ofmgz3NP@stryke> References: <542ACE37.1040302@kitware.com> <5370725.77ofmgz3NP@stryke> Message-ID: > A test for both OS X and Linux will help justify the API changes. Well. All I can say that failing tests were already addressed in latest version of this branch. Also it does not break existing functions signature or behavior. All new parameters are optional. I have no other means to prove that everything is OK. --Adam From mantis at public.kitware.com Tue Sep 30 12:49:34 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 30 Sep 2014 12:49:34 -0400 Subject: [cmake-developers] [CMake 0015179]: Please set default CMAKE_{C, CXX}_FLAGS_DEBUG to -g -Og if -Og is available Message-ID: <8ea06d3ca2251d41808eb9b4915a3548@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15179 ====================================================================== Reported By: Daniel Schepler Assigned To: ====================================================================== Project: CMake Issue ID: 15179 Category: CMake Reproducibility: have not tried Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-30 12:49 EDT Last Modified: 2014-09-30 12:49 EDT ====================================================================== Summary: Please set default CMAKE_{C,CXX}_FLAGS_DEBUG to -g -Og if -Og is available Description: gcc-4.8 introduced the new -Og flag, to enable some minor optimizations which don't interfere with debugging. It would be nice to have this set by default in debug builds. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-30 12:49 Daniel ScheplerNew Issue ====================================================================== From matt.mccormick at kitware.com Tue Sep 30 12:59:39 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 30 Sep 2014 12:59:39 -0400 Subject: [cmake-developers] [ITK-dev] find_package issues with ITK and VTK (and SlicerExecution Model) In-Reply-To: References: Message-ID: Hi Kent, On Tue, Sep 30, 2014 at 10:14 AM, Williams, Norman K wrote: > This is a problem that has been cropping up in our projects that use ITK, > VTK and SlicerExecutionModel. > > You won?t see it UNLESS you turn on the ITKVTK/ITKVtkGlue modules. > > The problem is this: if you find packages in this order: > > find_package(VTK REQUIRED) > find_package(ITK REQUIRED) > > You can?t real compile anything that needs VTK, because down in the ITK > deployment stuff, it calls find_package(VTK) like this: > find_package(VTK COMPONENTS > vtkCommonCore > vtkRenderingCore > vtkRenderingOpenGL > vtkRenderingFreeType > vtkInteractionStyle > vtkIOImage > vtkImagingSources > REQUIRED) > > Which blows away the larger list of include directories and libraries that > the first find_package(VTK REQUIRED) built. > > Even better ? or worse ? > Modules/Segmentation/LevelSetsv4Visualization/CMakeLists.txt also include > find_package(VTK) ? so ITK tries to import VTK twice, with different module > lists. > > It doesn?t even help to reverse the order: > find_package(ITK REQUIRED) > find_package(VTK REQUIRED) > > because apparently there?s some hangover from the find_package(VTK) inside > the ITK CMake deployment files. The only thing that works is to use > COMPONENTS, i.e. > > find_package(ITK REQUIRED) > find_package(VTK COMPONENTS vtkCommonCore vtkRenderingAnnotation ? REQUIRED) > > Which seems to trigger a proper re-scan and build of the library/include > lists. This was discussed in this thread [1]. There does not seem to be interest at this time to have mixed COMPONENTS / non-COMPONENTS calls to find_package. It is also recommended to use the MODULE option to find_package. A "newer" version of VTK 6 is also required. > It gets even worse if you use find_package(SlicerExecutionModel) after > find_package(ITK), for the same reason ? SlicerExecutionModel depends on > ITK, so it clobbers the include/library lists from the first > find_package(ITK). > A patch was merged a few days ago that might address this issue [2]. Is this behavior still see with current ITK? Thanks, Matt [1] http://public.kitware.com/pipermail/vtk-developers/2014-September/015376.html [2] http://review.source.kitware.com/#/c/16963/ From brad.king at kitware.com Tue Sep 30 13:00:46 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 30 Sep 2014 13:00:46 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: References: <542ACE37.1040302@kitware.com> <5370725.77ofmgz3NP@stryke> Message-ID: <542AE1BE.4000608@kitware.com> On 09/30/2014 12:24 PM, Adam Strzelecki wrote: > I have no other means to prove that everything is OK. Please merge the topic to 'next' for testing when you're ready. We can at least see if the dashboard stays clean with it. Thanks, -Brad From mantis at public.kitware.com Tue Sep 30 13:04:56 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 30 Sep 2014 13:04:56 -0400 Subject: [cmake-developers] [CMake 0015180]: FindGLUT.cmake should search for glut64 instead of glut32 on 64-bit Windows Message-ID: <0c3ab23d76d06da7291caeaa52c02f7f@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15180 ====================================================================== Reported By: Daniel Schepler Assigned To: ====================================================================== Project: CMake Issue ID: 15180 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-30 13:04 EDT Last Modified: 2014-09-30 13:04 EDT ====================================================================== Summary: FindGLUT.cmake should search for glut64 instead of glut32 on 64-bit Windows Description: On 64-bit Windows, the GLUT stub library is named glut64.lib instead of glut32.lib. So, find_package(GLUT) should be searching for glut64 instead of glut32 on that platform. (Or maybe search for both with glut64 preferred, if in fact there are some 64-bit versions of glut32.lib/glut32.dll out there.) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-30 13:04 Daniel ScheplerNew Issue ====================================================================== From mantis at public.kitware.com Tue Sep 30 13:18:37 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 30 Sep 2014 13:18:37 -0400 Subject: [cmake-developers] [CMake 0015181]: math can't handle negative numbers. Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15181 ====================================================================== Reported By: tron_thomas Assigned To: ====================================================================== Project: CMake Issue ID: 15181 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-30 13:18 EDT Last Modified: 2014-09-30 13:18 EDT ====================================================================== Summary: math can't handle negative numbers. Description: The math command cannot do addition with negative numbers Steps to Reproduce: Run CMake against the following CMakeLists.txt file: cmake_minimum_required (VERSION 2.8) project (MathFailure) set (value -1) math (EXPR value "${value} + 1") Expected: value should be incremented to zero Actual: CMake Error at CMakeLists.txt:6 (math): math cannot parse the expression: "-1 + 1": syntax error, unexpected exp_MINUS, expecting exp_OPENPARENT or exp_NUMBER (1) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-30 13:18 tron_thomas New Issue ====================================================================== From ono at java.pl Tue Sep 30 13:44:56 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 30 Sep 2014 19:44:56 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <542AE1BE.4000608@kitware.com> References: <542ACE37.1040302@kitware.com> <5370725.77ofmgz3NP@stryke> <542AE1BE.4000608@kitware.com> Message-ID: > 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. --Adam From mantis at public.kitware.com Tue Sep 30 16:26:23 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 30 Sep 2014 16:26:23 -0400 Subject: [cmake-developers] [CMake 0015182]: FindMPI.cmake fails to properly detect Intel MPI 5.0.1 Message-ID: <0c0f9f12fa13f2b7bc935abc68d50e60@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15182 ====================================================================== Reported By: Kelly Thompson Assigned To: ====================================================================== Project: CMake Issue ID: 15182 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-30 16:26 EDT Last Modified: 2014-09-30 16:26 EDT ====================================================================== Summary: FindMPI.cmake fails to properly detect Intel MPI 5.0.1 Description: The FindMPI.cmake module queries for include path and link libraries by attempting to use various options (e.g.: -showme:compile) of MPI_${lang}_COMPILER. # Check whether the -showme:compile option works. This indicates that we have either OpenMPI # or a newer version of LAM-MPI, and implies that -showme:link will also work. execute_process( COMMAND ${MPI_${lang}_COMPILER} -showme:compile OUTPUT_VARIABLE MPI_COMPILE_CMDLINE OUTPUT_STRIP_TRAILING_WHITESPACE ERROR_VARIABLE MPI_COMPILE_CMDLINE ERROR_STRIP_TRAILING_WHITESPACE RESULT_VARIABLE MPI_COMPILER_RETURN) For Intel MPI, MPI_CXX_COMPILER has the value 'mpiicpc.' The command 'mpiicpc -showme:compile' fails, but returns a '0' error code: % mpiicpc -showme:comple; echo $? icpc: command line warning http://public.kitware.com/Bug/view.php?id=10006: ignoring unknown option '-showme:comple' /var/lib/perceus/vnfs/asc-fe/rootfs/usr/bin/../lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' 0 I have contacted Intel support and they confirmed that this is by design. Unknown compiler options are considered to be warnings, not errors. This issue can be fixed by adding more complex logic to test the error state of the 'mpiicpc -showme:compile' command. In my local install of CMake, I added the following logic: if( "${MPI_COMPILE_CMDLINE}" MATCHES "undefined reference") set( MPI_COMPILER_RETURN 255 ) endif() This appears to solve the problem of incorrect information being saved in MPI_LINK_CMDLINE, MPI_INCDIRS, and MPI_LIBDIRS. Steps to Reproduce: Before running cmake, I needed to set these environment variables: export CXX=`which mpiicpc` export CC=`which mpiicc` export MPIEXEC=`which srun` So that FindMPI would query the correct MPI compile wrappers. See bug description for more details. Additional Information: I can reproduce this issue with Intel MPI 5.0.1 and Intel MPI 4.1.3 on two different systems (RHEL 6.4 and RHEL 6.5) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-30 16:26 Kelly Thompson New Issue ====================================================================== From ewmailing at gmail.com Tue Sep 30 19:42:07 2014 From: ewmailing at gmail.com (Eric Wing) Date: Tue, 30 Sep 2014 16:42:07 -0700 Subject: [cmake-developers] iOS support In-Reply-To: References: Message-ID: 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 From pascal.bach at siemens.com Mon Sep 1 03:52:46 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Mon, 1 Sep 2014 07:52:46 +0000 Subject: [cmake-developers] Cross compile tests on open.cdash.org In-Reply-To: <54009DAD.7090003@kitware.com> References: <355BE46A91031048906B695426A8D8E616AC19C1@DEFTHW99EH4MSX.ww902.siemens.net> <54009DAD.7090003@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACA9B2@DEFTHW99EH4MSX.ww902.siemens.net> Hi > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] > On Behalf Of Bill Hoffman > Sent: Freitag, 29. August 2014 17:35 > To: cmake-developers at cmake.org > Subject: Re: [cmake-developers] Cross compile tests on open.cdash.org > > On 8/29/2014 9:47 AM, Bach, Pascal wrote: > > Hi Everybody > > > > I'm interested in cross compilation, and am already using it extensively for > Linux and Embedded Linux. > > But now I ran into some problems cross compiling for Windows Compact > Embedded 2013 using Visual Studio. > > After some discussion on IRC, Nils Gladitz pointed out that there are no > cross compilation tests on the public CDash > (http://open.cdash.org/index.php?project=CMake). > > > > It might be worth to start a discussion on that topic and maybe find a way > to improve that. > > > > One question is if there is already somebody working in this direction or > maybe even already has a running cross compilation test using CMake? > > What would be necessary to extend the current test for a cross compilation > scenario? > > > > With best regards, > > Pascal Bach > > > > Hi, > > This is a good idea. There has been some recent work on the windows > phone support: Tests/VSWinStorePhone/. However, I would think what you > would want would be a more comprehensive test of CMake. Most of the > tests run executables that are built. We would either have to not do > that, or run them on a simulator or have an actual device that the tests > are pushed to for running. The other option would be to create one or > more specific cross compile tests. I would for a start suggest to run the tests in a simulator. The simplest thing to set up would be to have a cross compile on linux and the run the tests using qemu. > It would require someone to setup dashboard clients as well: > http://www.cmake.org/cmake/resources/testing.html. Would you be able > to run clients like that? I'm currently clarifying if we can provide some build/test machines. I would like to be able to provide a Linux x86 -> Linux ARM and a Windows 64bit -> Windows CE ARM build including target/simulator to run the tests on. But I can't promise yet. - Pascal From eike at sf-mail.de Mon Sep 1 04:35:34 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 01 Sep 2014 10:35:34 +0200 Subject: [cmake-developers] Cross compile tests on open.cdash.org In-Reply-To: <54009DAD.7090003@kitware.com> References: <355BE46A91031048906B695426A8D8E616AC19C1@DEFTHW99EH4MSX.ww902.siemens.net> <54009DAD.7090003@kitware.com> Message-ID: <9bdf3242bf375181f7aee0d9c36fdec6@sf-mail.de> Am 29.08.2014 17:35, schrieb Bill Hoffman: > On 8/29/2014 9:47 AM, Bach, Pascal wrote: >> Hi Everybody >> >> I'm interested in cross compilation, and am already using it >> extensively for Linux and Embedded Linux. >> But now I ran into some problems cross compiling for Windows Compact >> Embedded 2013 using Visual Studio. >> After some discussion on IRC, Nils Gladitz pointed out that there are >> no cross compilation tests on the public CDash >> (http://open.cdash.org/index.php?project=CMake). >> >> It might be worth to start a discussion on that topic and maybe find a >> way to improve that. >> >> One question is if there is already somebody working in this direction >> or maybe even already has a running cross compilation test using >> CMake? >> What would be necessary to extend the current test for a cross >> compilation scenario? > This is a good idea. There has been some recent work on the windows > phone support: Tests/VSWinStorePhone/. However, I would think what > you would want would be a more comprehensive test of CMake. Most of > the tests run executables that are built. We would either have to not > do that, or run them on a simulator or have an actual device that the > tests are pushed to for running. The other option would be to create > one or more specific cross compile tests. > > It would require someone to setup dashboard clients as well: > http://www.cmake.org/cmake/resources/testing.html. Would you be able > to run clients like that? I think I will be able to provide some Linux x86_64 -> * cross-builds, likely ARM and MIPS, maybe something more. Eike From aleixpol at kde.org Mon Sep 1 09:53:26 2014 From: aleixpol at kde.org (Aleix Pol) Date: Mon, 1 Sep 2014 15:53:26 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: Message-ID: On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol wrote: > Dear cmake'rs, > I'm rewriting the KDevelop plugin from scratch to fetch the information > from the build directory. > > Now in the first implementation I'm using the compile_commands.json file > that cmake already can generate for some time. It works quite well already, > given how data just comes out ready to be consumed (almost). The problem > now is that we're lacking some information, namely information about the > targets, their location and such *. > > To that end, I wrote a little patch to be taken as a proof of concept, > that generates (some of) the needed information. I would like to know if > you think it's an approach that would be accepted in the cmake code-base or > if I need to take a different approach. > > Patch http://proli.net/meu/kdevelop/cmake-targetsdata.patch > Output: http://proli.net/meu/kdevelop/AwesomeTargets.json > > Cheers! > Aleix > > * Yes, I'm aware of generators, but I'm not comfortable with the idea of > tying a build directory to an editor (even if it's my editor). Our users > usually build the projects with different tools and asking them to > re-create their build only for being comfortable with KDevelop sometimes is > a burden. It would be for me too! > Bump? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascal.bach at siemens.com Mon Sep 1 11:25:05 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Mon, 1 Sep 2014 15:25:05 +0000 Subject: [cmake-developers] Cross compile tests on open.cdash.org In-Reply-To: <9bdf3242bf375181f7aee0d9c36fdec6@sf-mail.de> References: <355BE46A91031048906B695426A8D8E616AC19C1@DEFTHW99EH4MSX.ww902.siemens.net> <54009DAD.7090003@kitware.com> <9bdf3242bf375181f7aee0d9c36fdec6@sf-mail.de> Message-ID: <355BE46A91031048906B695426A8D8E616ACCB31@DEFTHW99EH4MSX.ww902.siemens.net> Hi Guys > > > This is a good idea. There has been some recent work on the windows > > phone support: Tests/VSWinStorePhone/. However, I would think what > > you would want would be a more comprehensive test of CMake. Most of > > the tests run executables that are built. We would either have to not > > do that, or run them on a simulator or have an actual device that the > > tests are pushed to for running. The other option would be to create > > one or more specific cross compile tests. I gave it some thought and I think it might be better to have some cross compile tests. This because it might not be possible to compile all of CMake for a given target. Does somebody already have an idea where to put this tests? I'm still digging through the code ;) > > > > It would require someone to setup dashboard clients as well: > > http://www.cmake.org/cmake/resources/testing.html. Would you be > able > > to run clients like that? > > I think I will be able to provide some Linux x86_64 -> * cross-builds, > likely ARM and MIPS, maybe something more. > That would be good Erik, I will then try to focus on providing a Windows CE machine first. Pascal From chuck.atkins at kitware.com Mon Sep 1 14:35:41 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 1 Sep 2014 14:35:41 -0400 Subject: [cmake-developers] How to get a nightly build process going. In-Reply-To: References: <1625614106.25599.1409412011499.JavaMail.vpopmail@webmail2.networksolutionsemail.com> <1442524.tQkLfgu6xA@caliban.sf-tec.de> <1568432513.23189.1409428834864.JavaMail.vpopmail@webmail2.networksolutionsemail.com> <2411065.ulDJNWIhbH@caliban.sf-tec.de> <1565610899.23232.1409429367244.JavaMail.vpopmail@webmail2.networksolutionsemail.com> <540234AB.6080306@gmail.com> <1915404470.31130.1409449872395.JavaMail.vpopmail@webmail2.networksolutionsemail.com> Message-ID: Back on topic... > Solaris 10 + SolarisStudio > http://open.cdash.org/buildSummary.php?buildid=3470493 > No build failures, 4 test failures > > Solaris 10 + GCC (from OpenCSW) > http://open.cdash.org/buildSummary.php?buildid=3470687 > No build failures, 5 test failures > I dug more into the test failures. 3 of the failures were due to a borked mercurial install on the machine, i.e. not a cmake problem but a system problem, which has since been fixed. Another was a FindGTK2 bug, which I just pushed a fix to next for. Given the _Bool fix and GTK2 fix, all tests should pass for nightly next on Solaris + suncc, and 1 failure for Solaris + GCC. So once you get your nightly submissions set up, I would expect a clean Solaris Studio build and test and a clean GCC build with 1 test failure. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Mon Sep 1 15:26:12 2014 From: dlrdave at aol.com (David Cole) Date: Mon, 1 Sep 2014 15:26:12 -0400 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: Message-ID: <8D19431B9E085CE-1284-18364@webmail-vm008.sysops.aol.com> The approach looks reasonable, but having it unconditionally spit out a file in cmGlobalGenerator regardless of generator is probably not what we want. Seems like it should be based on a variable, or be in a specific generator, or somehow have a limited scope. HTH, David C. From mantis at public.kitware.com Mon Sep 1 16:29:19 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 1 Sep 2014 16:29:19 -0400 Subject: [cmake-developers] [CMake 0015121]: OpenSceneGraph module broken Message-ID: <2f142d0b17dc7860f03f0aa462f42c24@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15121 ====================================================================== Reported By: Hartmut Seichter Assigned To: ====================================================================== Project: CMake Issue ID: 15121 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-01 16:29 EDT Last Modified: 2014-09-01 16:29 EDT ====================================================================== Summary: OpenSceneGraph module broken Description: On Arch Linux and Mac OS X 10.9.3 the find module for OpenSceneGraph stopped working. Seems the combination cmake 3.0.x and OSG 3.2.1 is having issues. Also setting OSG_DIR and CMAKE_PREFIX_PATH seem to have no effect. This is quite an issue as most OSG dependent project will use cmake as build system. An OSX example with debug on ... cmake -DOpenSceneGraph_DEBUG=ON -DCMAKE_PREFIX_PATH=/opt/local -DOSG_DIR=/opt/local ../VisionSpace -- [ FindOpenSceneGraph.cmake:128 ] Components = osg;OpenThreads -- [ FindOpenSceneGraph.cmake:200 ] Calling find_package(osg ) -- Could NOT find osg (missing: OSG_LIBRARY OSG_INCLUDE_DIR) -- [ FindOpenSceneGraph.cmake:200 ] Calling find_package(OpenThreads ) -- Could NOT find OpenThreads (missing: OPENTHREADS_LIBRARY OPENTHREADS_INCLUDE_DIR) CMake Error at /opt/local/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:136 (message): Could NOT find OpenSceneGraph (missing: OPENSCENEGRAPH_LIBRARIES OPENSCENEGRAPH_INCLUDE_DIR OSG_FOUND OPENTHREADS_FOUND) Call Stack (most recent call first): /opt/local/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:343 (_FPHSA_FAILURE_MESSAGE) /opt/local/share/cmake-3.0/Modules/FindOpenSceneGraph.cmake:230 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:11 (find_package) Steps to Reproduce: Arch Linux (x86_64, cmake-3.0.1-1, openscenegraph-3.2.1-1) Mavericks (MacPorts, CMake @3.0.0_3, OpenSceneGraph @3.2.1) Clear cache (it kept working on an install where the cache was moved over from an older CMake build). Minimal project (https://github.com/seichter/sandbox/tree/master/bugreports/cmake-osg) with find_package(OpenSceneGraph REQUIRED) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-01 16:29 Hartmut SeichterNew Issue ====================================================================== From neundorf at kde.org Mon Sep 1 17:22:06 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Mon, 01 Sep 2014 23:22:06 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <8D19431B9E085CE-1284-18364@webmail-vm008.sysops.aol.com> References: <8D19431B9E085CE-1284-18364@webmail-vm008.sysops.aol.com> Message-ID: <1616912.3Bv1RU2FhA@tuxedo.neundorf.net> On Monday, September 01, 2014 15:26:12 David Cole via cmake-developers wrote: > The approach looks reasonable, but having it unconditionally spit out a > file in cmGlobalGenerator regardless of generator is probably not what > we want. Seems like it should be based on a variable, or be in a > specific generator, or somehow have a limited scope. I agree. IMO this should be a generator, I don't see why it should work around that. Alex From aleixpol at kde.org Mon Sep 1 19:27:27 2014 From: aleixpol at kde.org (Aleix Pol) Date: Tue, 2 Sep 2014 01:27:27 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <8D19431B9E085CE-1284-18364@webmail-vm008.sysops.aol.com> References: <8D19431B9E085CE-1284-18364@webmail-vm008.sysops.aol.com> Message-ID: On Mon, Sep 1, 2014 at 9:26 PM, David Cole wrote: > The approach looks reasonable, but having it unconditionally spit out a > file in cmGlobalGenerator regardless of generator is probably not what we > want. Seems like it should be based on a variable, or be in a specific > generator, or somehow have a limited scope. > > HTH, > David C. > Ok, how does it sound if we have a variable, such as CMAKE_EXPORT_COMPILE_COMMANDS? Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Tue Sep 2 01:37:04 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 02 Sep 2014 07:37:04 +0200 Subject: [cmake-developers] How to get a nightly build process going. In-Reply-To: References: <1625614106.25599.1409412011499.JavaMail.vpopmail@webmail2.networksolutionsemail.com> Message-ID: <1966586.ILOyKsinXl@caliban.sf-tec.de> Am Montag, 1. September 2014, 14:35:41 schrieb Chuck Atkins: > Back on topic... > > > Solaris 10 + SolarisStudio > > http://open.cdash.org/buildSummary.php?buildid=3470493 > > No build failures, 4 test failures > > > > Solaris 10 + GCC (from OpenCSW) > > http://open.cdash.org/buildSummary.php?buildid=3470687 > > No build failures, 5 test failures > > I dug more into the test failures. 3 of the failures were due to a borked > mercurial install on the machine, i.e. not a cmake problem but a system > problem, which has since been fixed. Another was a FindGTK2 bug, which I > just pushed a fix to next for. Isn't "if (D)" enough there instead of the MATCHES? 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 Tue Sep 2 07:03:43 2014 From: dlrdave at aol.com (David Cole) Date: Tue, 2 Sep 2014 07:03:43 -0400 Subject: [cmake-developers] Extracting target metadata, IDE integration Message-ID: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> > Ok, how does it sound if we have a variable, such as > CMAKE_EXPORT_COMPILE_COMMANDS? > Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. I would prefer CMAKE_EXPORT_TARGETS_FILE, or some name that implies it is a filename value, with the value of the variable being the name of the file to generate. Who's the consumer of this file? Is it just one particular IDE, or is it meant to be general and possibly be used by multiple IDE generators? (I'm not sure I fully understand the context of the intent here based on the prior emails.... Can you explain it a little more?) Thanks, David C. From aleixpol at kde.org Tue Sep 2 07:28:15 2014 From: aleixpol at kde.org (Aleix Pol) Date: Tue, 2 Sep 2014 13:28:15 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> Message-ID: On Tue, Sep 2, 2014 at 1:03 PM, David Cole wrote: > > Ok, how does it sound if we have a variable, such as > > CMAKE_EXPORT_COMPILE_COMMANDS? > > Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. > > > I would prefer CMAKE_EXPORT_TARGETS_FILE, or some name that implies it > is a filename value, with the value of the variable being the name of > the file to generate. > I think it's better to do an "ON/OFF" setting, given that from an IDE point of view what we want is to be able to run cmake again and get the file. If Eclipse generated the file I will still want to open it, and then we'd have to agree on a file name or need to modify the build directory, which kind of defeats the purpose. > > Who's the consumer of this file? Is it just one particular IDE, or is > it meant to be general and possibly be used by multiple IDE generators? > (I'm not sure I fully understand the context of the intent here based > on the prior emails.... Can you explain it a little more?) > The consumer of this file is the IDE or anyone who needs to be able to figure out the project's data. We need ways to describe the targets generated by the project to let the IDE user know what targets the project has and to be able to use them. To get some context, let me define one of our use-cases, which would be a KDE user. To build a KDE Plasma 5 installation you need > 100 repositories to be built and configured. This means that all these are configured and installed to a prefix, possibly with an external tool. Our user will want to develop one of those projects. To do so, he will open the project and choose the build directory tied to it, from there we need to infer all the information he will need to develop the project. Here's where the targets file comes into place, the IDE will just need to open this file and the compile_commands.json files. If they're not created the IDE will set the cache values then generate to be able to access them. I hope it makes sense now. Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Tue Sep 2 09:25:51 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Tue, 2 Sep 2014 09:25:51 -0400 Subject: [cmake-developers] How to get a nightly build process going. In-Reply-To: <1966586.ILOyKsinXl@caliban.sf-tec.de> References: <1625614106.25599.1409412011499.JavaMail.vpopmail@webmail2.networksolutionsemail.com> <1966586.ILOyKsinXl@caliban.sf-tec.de> Message-ID: It seems so. I was thrown off by the multiple levels of indirection happening since the actual values in the OPTIONAL_INCLUDES end up as "foo1;foo2-NOTFOUND;bar". I was thinking that if(VARNAME) would only work if the value of VARNAME was actually "VARNAME-NOTFOUND" but that's not the case, it works so long as "-NOTFOUND" is a suffix. - Chuck On Tue, Sep 2, 2014 at 1:37 AM, Rolf Eike Beer wrote: > Am Montag, 1. September 2014, 14:35:41 schrieb Chuck Atkins: > > Back on topic... > > > > > Solaris 10 + SolarisStudio > > > http://open.cdash.org/buildSummary.php?buildid=3470493 > > > No build failures, 4 test failures > > > > > > Solaris 10 + GCC (from OpenCSW) > > > http://open.cdash.org/buildSummary.php?buildid=3470687 > > > No build failures, 5 test failures > > > > I dug more into the test failures. 3 of the failures were due to a > borked > > mercurial install on the machine, i.e. not a cmake problem but a system > > problem, which has since been fixed. Another was a FindGTK2 bug, which I > > just pushed a fix to next for. > > Isn't "if (D)" enough there instead of the MATCHES? > > Eike -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Tue Sep 2 09:58:37 2014 From: dlrdave at aol.com (David Cole) Date: Tue, 2 Sep 2014 09:58:37 -0400 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> Message-ID: <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> It makes sense. But what IDE are you referring to? Eclipse? Some other concrete example? Or just "any IDE and this feature should work everywhere CMake works...?" From brad.king at kitware.com Tue Sep 2 10:12:21 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Sep 2014 10:12:21 -0400 Subject: [cmake-developers] Mixing generator expressions and debug|optimized|general keywords in target_link_libraries() In-Reply-To: <54004758.7000506@gmail.com> References: <54004758.7000506@gmail.com> Message-ID: <5405D045.4030803@kitware.com> On 08/29/2014 05:26 AM, Nils Gladitz wrote: > I tried wrapping the libraries returned by FindBoost.cmake in > $ in a target_link_libraries() call and noticed that > this breaks because of the debug/optimized keywords that the find module > inserts. > > Specifically it results in CMake trying to link e.g. "optimized.lib". > > Should/could these keywords be handled at generation time (after > generator expressions expansion)? These keywords are meaningful to target_link_libraries and nothing else, just like the PRIVATE/PUBLIC/INTERFACE keywords. It is the responsibility of that command to handle them. One can put a genex in the value after the keyword: "optimized $<...>", but otherwise they are not really meant to mix. The use of generator expressions and imported targets is supposed to supersede use of the old keywords. There was recent work posted on this list to add imported targets to the FindBoost results. > There don't seem to be generator expressions that correspond to the > debug/optimized keywords exactly. Can/should there be? Steve K and I discussed this once. Since DEBUG_CONFIGURATIONS can be set differently in exporting and importing projects so there is no global meaning across all targets. See the cmTarget::GetDebugGeneratorExpressions method: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;hb=v3.0.1#l908 It constructs a $ expression of $ expressions for each entry in DEBUG_CONFIGURATIONS. This is how target_link_libraries transforms debug/optimized keywords when constructing the INTERFACE_LINK_LIBRARIES value. -Brad From nilsgladitz at gmail.com Tue Sep 2 10:40:26 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 02 Sep 2014 16:40:26 +0200 Subject: [cmake-developers] Mixing generator expressions and debug|optimized|general keywords in target_link_libraries() In-Reply-To: <5405D045.4030803@kitware.com> References: <54004758.7000506@gmail.com> <5405D045.4030803@kitware.com> Message-ID: <5405D6DA.90401@gmail.com> On 09/02/2014 04:12 PM, Brad King wrote: > On 08/29/2014 05:26 AM, Nils Gladitz wrote: > Steve K and I discussed this once. Since DEBUG_CONFIGURATIONS can be > set differently in exporting and importing projects so there is no > global meaning across all targets. See the > cmTarget::GetDebugGeneratorExpressions method: > > http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;hb=v3.0.1#l908 > > It constructs a $ expression of $ expressions > for each entry in DEBUG_CONFIGURATIONS. This is how > target_link_libraries transforms debug/optimized keywords when > constructing the INTERFACE_LINK_LIBRARIES value. For some reason I thought RelWithDebInfo was per default a debug configuration but that does not actually seem to be the case. Given that Debug is the only (default) configuration in the set that simplifies things greatly - for me at least :p I'll manually transform the library lists until FindBoost.cmake exports targets or Boost itself provides a config file. Thanks! Nils From brad.king at kitware.com Tue Sep 2 11:00:19 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Sep 2014 11:00:19 -0400 Subject: [cmake-developers] VS 2013 WindowsCE support (was: VS12: Allow specifying an installed SDK as target platform for the generator.) In-Reply-To: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> Message-ID: <5405DB83.7040605@kitware.com> On 08/28/2014 08:52 AM, Pascal Bach wrote: > This brings the behavior of Visual Studio 2013 in line with the one of Visual Studio 2012. In combination with your related issue report: WindowsCE: /SUBSYSTEM and /ENTRYPOINT does not end up in the generated Visual Studio project http://www.cmake.org/Bug/view.php?id=15115 it looks like a bit of work is needed to get Windows CE support working with VS 2013. Also, since the work was done for VS 2012, our infrastructure for cross-compiling with Visual Studio generators has improved. Rather than putting the target platform in the generator name (leading to a vs-version/platform combinatorial explosion), we should now be able to activate cross-compiling with -DCMAKE_SYSTEM_NAME=WindowsCE or -DCMAKE_TOOLCHAIN_FILE=... while still using -G "Visual Studio 12 2013" as the generator. This will be the preferred approach for new upstream support. I can help guide anyone interested in making the needed changes. -Brad From pascal.bach at siemens.com Tue Sep 2 11:27:10 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 2 Sep 2014 15:27:10 +0000 Subject: [cmake-developers] VS 2013 WindowsCE support (was: VS12: Allow specifying an installed SDK as target platform for the generator.) In-Reply-To: <5405DB83.7040605@kitware.com> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> Hi Brad > In combination with your related issue report: > > WindowsCE: /SUBSYSTEM and /ENTRYPOINT does not end up in the > generated Visual Studio project > http://www.cmake.org/Bug/view.php?id=15115 > > it looks like a bit of work is needed to get Windows CE support > working with VS 2013. Also, since the work was done for VS 2012, > our infrastructure for cross-compiling with Visual Studio generators > has improved. Rather than putting the target platform in the > generator name (leading to a vs-version/platform combinatorial > explosion), we should now be able to activate cross-compiling > with -DCMAKE_SYSTEM_NAME=WindowsCE or - > DCMAKE_TOOLCHAIN_FILE=... > while still using -G "Visual Studio 12 2013" as the generator. > This will be the preferred approach for new upstream support. I think proposal would make things cleaner. I think specifying only -DCMAKE_SYSTEM_NAME=WindowsCE wouldn't be enough or how does VS know what compiler to use? I would like it if we had a toolchain file for each SDK but then I'm not clear what it contains. In this toolchain file do we specify compiler etc like it is done for gcc for example, or would the toolchain file contain a variable like CMAKE_VS_SDK pointing to one of the installed SDKs? I'm not yet familiar with the VS build environment . > I can help guide anyone interested in making the needed changes. I might be able to invest some time into this so some guidance would be welcome ;) Pascal From brad.king at kitware.com Tue Sep 2 12:02:53 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Sep 2014 12:02:53 -0400 Subject: [cmake-developers] VS 2013 WindowsCE support In-Reply-To: <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <5405EA2D.4070801@kitware.com> On 09/02/2014 11:27 AM, Bach, Pascal wrote: >> we should now be able to activate cross-compiling >> with -DCMAKE_SYSTEM_NAME=WindowsCE or - >> DCMAKE_TOOLCHAIN_FILE=... >> while still using -G "Visual Studio 12 2013" as the generator. > > I think proposal would make things cleaner. Great. It should be able to work for VS 2010 and greater. > I think specifying only -DCMAKE_SYSTEM_NAME=WindowsCE wouldn't be > enough or how does VS know what compiler to use? Correct. We would need another variable to specify the SDK. It could be added to the command line or set in a toolchain file. > I would like it if we had a toolchain file for each SDK but > then I'm not clear what it contains. In this toolchain file do > we specify compiler etc like it is done for gcc for example, > or would the toolchain file contain a variable like CMAKE_VS_SDK > pointing to one of the installed SDKs? The following block in Modules/CMakeDetermineSystem.cmake: elseif(CMAKE_VS_WINCE_VERSION) set(CMAKE_SYSTEM_NAME "WindowsCE") set(CMAKE_SYSTEM_VERSION "${CMAKE_VS_WINCE_VERSION}") set(CMAKE_SYSTEM_PROCESSOR "${MSVC_C_ARCHITECTURE_ID}") is basically a mini toolchain file. A real toolchain file would explicitly specify the values. We would also need a new variable to tell the generator which SDK to use. Currently the info is in the internal CMAKE_VS_PLATFORM_NAME variable that corresponds to the platform component of the generator name. >> I can help guide anyone interested in making the needed changes. > > I might be able to invest some time into this so some guidance > would be welcome ;) Take a look at cmGlobalVisualStudio10Generator::InitializeSystem in recent 'master' versions. That is likely the place to hook in to recognize the "WindowsCE" name and look up the SDK variable. -Brad From neundorf at kde.org Tue Sep 2 15:45:19 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 02 Sep 2014 21:45:19 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> Message-ID: <1508558.GIL7YTuQJT@tuxedo.neundorf.net> On Tuesday, September 02, 2014 09:58:37 David Cole via cmake-developers wrote: > It makes sense. But what IDE are you referring to? Eclipse? Some other > concrete example? Or just "any IDE and this feature should work > everywhere CMake works...?" AFAIK it is kdevelop4, and the goal is that developers don't have to tell cmake to run a kdevelop4 generator, but just the normal makefile generator, and still be able to use kdevelop4 on these build trees. Alex From irwin at beluga.phys.uvic.ca Tue Sep 2 15:52:46 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 2 Sep 2014 12:52:46 -0700 (PDT) Subject: [cmake-developers] --debug-trycompile not working as documented with the results being overwritten Message-ID: Preliminaries to this topic have already been posted on the cmake list, but the only response there (from Mark Abraham) was "Raw try_compile is not a great idiom for general use (though it is unclear why it is not working well for you). Using the Modules/Check*cmake gear is a much better option, e.g. with check_symbol_exists()" which was useful in working around the issue, but not responsive about the issue itself which I now believe is a try_compile documentation bug. The (CMake-2.8.12.1) documentation says: "If you use --debug-trycompile, you can only debug one try_compile call at a time. The recommended procedure is to configure with cmake all the way through once, then delete the cache entry associated with the try_compile call of interest, and then re-run cmake again with --debug-trycompile." That implies every call to the second signature of try_compile, i.e., try_compile(RESULT_VAR [optional arguments]) is implicitly protected inside the implementation of try_compile by if(NOT DEFINED RESULT_VAR) [...] endif(NOT DEFINED RESULT_VAR) logic, but my tests show this is not the case and this second form of try_compile signature always repeated no matter if RESULT_VAR is defined or not in the cache. In fact, if you look at all the try_compile usage in Modules/Check*cmake, every such try_compile call is protected _outside_ the call by either if(NOT DEFINED VARIABLE) logic or the equivalent (using CMake logic available in 2006 (!)) if("${VARIABLE}" MATCHES "^${VARIABLE}$") logic. Which in turn implies all the different writers of the Modules/Check*cmake modules were well aware over the years that try_compile repeats (unless protected by such DEFINED logic) for each cmake invocation contrary to the above try_compile documentation. So to fix this documentation bug, I suggest This recommended procedure obviously only works if every try_compile call using the second signature in any given build system is protected by "if(NOT DEFINED RESULT_VAR)" logic. be appended to the try_compile documentation. I am willing to write this up as a bug report, but I believe this bug fix is pretty much a no-brainer which requires only checking my experimental results that the try_compile implementation is not protected internally by a DEFINED check of the variable before adding the above sentence to the documentation. So I hope to convince a CMake developer to just go ahead an fix this documentation bug without going through the normal dance of putting it on the bug tracker, watching it get ignored there because of all the noise from low-quality bug reports there, keep advocating here this really is a useful documentation fix, etc. 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 pascal.bach at siemens.com Wed Sep 3 05:23:28 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Wed, 3 Sep 2014 09:23:28 +0000 Subject: [cmake-developers] VS 2013 WindowsCE support In-Reply-To: <5405EA2D.4070801@kitware.com> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> <5405EA2D.4070801@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACE504@DEFTHW99EH4MSX.ww902.siemens.net> > On 09/02/2014 11:27 AM, Bach, Pascal wrote: > >> we should now be able to activate cross-compiling > >> with -DCMAKE_SYSTEM_NAME=WindowsCE or - > >> DCMAKE_TOOLCHAIN_FILE=... > >> while still using -G "Visual Studio 12 2013" as the generator. > > > > I think proposal would make things cleaner. > > Great. It should be able to work for VS 2010 and greater. > > > I think specifying only -DCMAKE_SYSTEM_NAME=WindowsCE wouldn't be > > enough or how does VS know what compiler to use? > > Correct. We would need another variable to specify the SDK. > It could be added to the command line or set in a toolchain file. > > > I would like it if we had a toolchain file for each SDK but > > then I'm not clear what it contains. In this toolchain file do > > we specify compiler etc like it is done for gcc for example, > > or would the toolchain file contain a variable like CMAKE_VS_SDK > > pointing to one of the installed SDKs? > > The following block in Modules/CMakeDetermineSystem.cmake: > > elseif(CMAKE_VS_WINCE_VERSION) > set(CMAKE_SYSTEM_NAME "WindowsCE") > set(CMAKE_SYSTEM_VERSION "${CMAKE_VS_WINCE_VERSION}") > set(CMAKE_SYSTEM_PROCESSOR "${MSVC_C_ARCHITECTURE_ID}") Do we need to preserve the current behavior? CMAKE_VS_WINCE_VERSION seems to be undocumented. The new way would be to set CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_VERSION in a toolchain file. > > is basically a mini toolchain file. A real toolchain file would > explicitly specify the values. We would also need a new variable > to tell the generator which SDK to use. Currently the info is > in the internal CMAKE_VS_PLATFORM_NAME variable that corresponds > to the platform component of the generator name. So do you agree that the right thing would be to add a CMAKE_VS_PLATFORM_SDK (or CMAKE_GENERATOR_SDK ?) variable that the user can set? A resulting toolchain file would look something like this: set(CMAKE_SYSTEM_NAME "WindowsCE") set(CMAKE_SYSTEM_VERSION "8.0") set(CMAKE_SYSTEM_PROCESSOR "arm" ) set(CMAKE_GENERATOR_TOOLSET "CE800") # I still don't know if this is needed ;) set(CMAKE_GENERATOR_SDK "MYSDK01") I don't understand the purpose of CMAKE_GENERATOR_TOOLSET resp. CMAKE_VS_PLATFORM_TOOLSET. As far as I understand they are independent of the SDK selected? > > >> I can help guide anyone interested in making the needed changes. > > > > I might be able to invest some time into this so some guidance > > would be welcome ;) > > Take a look at cmGlobalVisualStudio10Generator::InitializeSystem > in recent 'master' versions. That is likely the place to hook > in to recognize the "WindowsCE" name and look up the SDK variable. > Thanks I will have a look there. Pascal From mantis at public.kitware.com Wed Sep 3 06:16:52 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 3 Sep 2014 12:16:52 +0200 Subject: [cmake-developers] [CMake 0015124]: CPack doesn't package static libraries when CPACK_RPM_COMPONENT_INSTALL is on Message-ID: <4f830978b1606f3f923284001d4ca14a@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15124 ====================================================================== Reported By: Barthelemy von Haller Assigned To: ====================================================================== Project: CMake Issue ID: 15124 Category: CPack Reproducibility: have not tried Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-03 12:16 CEST Last Modified: 2014-09-03 12:16 CEST ====================================================================== Summary: CPack doesn't package static libraries when CPACK_RPM_COMPONENT_INSTALL is on Description: When I turn on CPACK_RPM_COMPONENT_INSTALL my static library is not packaged anymore. Other files such as headers or shared libraries are packed though. If I turn off CPACK_RPM_COMPONENT_INSTALL or make the library shared then it works fine. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-03 12:16 Barthelemy von HallerNew Issue ====================================================================== From aleixpol at kde.org Wed Sep 3 06:30:21 2014 From: aleixpol at kde.org (Aleix Pol) Date: Wed, 3 Sep 2014 12:30:21 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> Message-ID: On Tue, Sep 2, 2014 at 3:58 PM, David Cole wrote: > It makes sense. But what IDE are you referring to? Eclipse? Some other > concrete example? Or just "any IDE and this feature should work everywhere > CMake works...?" > > I'm working on KDevelop, I know for a fact though, that other IDEs are looking for something similar too, such as QtCreator. Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleixpol at kde.org Wed Sep 3 06:31:12 2014 From: aleixpol at kde.org (Aleix Pol) Date: Wed, 3 Sep 2014 12:31:12 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <1508558.GIL7YTuQJT@tuxedo.neundorf.net> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> <1508558.GIL7YTuQJT@tuxedo.neundorf.net> Message-ID: On Tue, Sep 2, 2014 at 9:45 PM, Alexander Neundorf wrote: > On Tuesday, September 02, 2014 09:58:37 David Cole via cmake-developers > wrote: > > It makes sense. But what IDE are you referring to? Eclipse? Some other > > concrete example? Or just "any IDE and this feature should work > > everywhere CMake works...?" > > AFAIK it is kdevelop4, and the goal is that developers don't have to tell > cmake to run a kdevelop4 generator, but just the normal makefile generator, > and still be able to use kdevelop4 on these build trees. > > Alex > Yes, essentially. Makefile, or ninja, or whatever they use on mac and Windows and any of our supported platforms. Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Wed Sep 3 08:47:24 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 3 Sep 2014 08:47:24 -0400 Subject: [cmake-developers] [CMake 0015125]: XCode generator cannot add assetcatalog assets Message-ID: <2aa9c4c360ae3f95dc209bcd912205f0@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15125 ====================================================================== Reported By: Jan R?egg Assigned To: ====================================================================== Project: CMake Issue ID: 15125 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-03 08:47 EDT Last Modified: 2014-09-03 08:47 EDT ====================================================================== Summary: XCode generator cannot add assetcatalog assets Description: When adding resources to an XCode CMake project like this: set_target_properties(foo PROPERTIES RESOURCE example/demo_app/Images.xcassets) An entry similar to this one is created in the xcode project: 1582C9DBB34F4291A1D09CA3 /* Images.xcassets */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = folder; name = Images.xcassets; path = example/demo_app/Images.xcassets; sourceTree = SOURCE_ROOT; }; This works fine for normal folders, however I would like to use this to add an assets folder. This creates a very similar entry, however to make it work with xcode the lastKnownFileType needs to be changed from "folder" to "folder.assetcatalog", like this: 1582C9DBB34F4291A1D09CA3 /* Images.xcassets */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = folder.assetcatalog; name = Images.xcassets; path = example/demo_app/Images.xcassets; sourceTree = SOURCE_ROOT; }; In CMake 3.0.1, this is generated in the file "cmGlobalXCodeGenerator.cxx", line 874: if(cmSystemTools::FileIsDirectory(fullpath.c_str())) { fileRef->AddAttribute("lastKnownFileType", this->CreateString("folder")); } In order to make it work, it would need to be changed to read something like this (pseudocode): if(cmSystemTools::FileIsDirectory(fullpath.c_str())) { if (fileEndsWith(".xcassets")) { fileRef->AddAttribute("lastKnownFileType", this->CreateString("folder.assetcatalog")); } else { fileRef->AddAttribute("lastKnownFileType", this->CreateString("folder")); } } ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-03 08:47 Jan R?egg New Issue ====================================================================== From brad.king at kitware.com Wed Sep 3 09:35:22 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 09:35:22 -0400 Subject: [cmake-developers] VS 2013 WindowsCE support In-Reply-To: <355BE46A91031048906B695426A8D8E616ACE504@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> <5405EA2D.4070801@kitware.com> <355BE46A91031048906B695426A8D8E616ACE504@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <5407191A.8070706@kitware.com> On 09/03/2014 05:23 AM, Bach, Pascal wrote: >> elseif(CMAKE_VS_WINCE_VERSION) >> set(CMAKE_SYSTEM_NAME "WindowsCE") >> set(CMAKE_SYSTEM_VERSION "${CMAKE_VS_WINCE_VERSION}") >> set(CMAKE_SYSTEM_PROCESSOR "${MSVC_C_ARCHITECTURE_ID}") > > Do we need to preserve the current behavior? Yes, but only for the existing VS 11 WinCE-specific generator names. > CMAKE_VS_WINCE_VERSION seems to be undocumented. It is an internal implementation detail of the WinCE-specific VS generators. > The new way would be to set CMAKE_SYSTEM_NAME and > CMAKE_SYSTEM_VERSION in a toolchain file. Yes. >> is basically a mini toolchain file. A real toolchain file would >> explicitly specify the values. We would also need a new variable >> to tell the generator which SDK to use. Currently the info is >> in the internal CMAKE_VS_PLATFORM_NAME variable that corresponds >> to the platform component of the generator name. > > So do you agree that the right thing would be to add a > CMAKE_VS_PLATFORM_SDK (or CMAKE_GENERATOR_SDK ?) variable that > the user can set? Let's use a name specific to WindowsCE like "CMAKE_VS_WINCE_SDK", at least for discussion and review purposes, so I can see where the variable fits in to the generator with your changes. Then we can decide if there is a more general name to be used later. > A resulting toolchain file would look something like this: > > set(CMAKE_SYSTEM_NAME "WindowsCE") > set(CMAKE_SYSTEM_VERSION "8.0") > set(CMAKE_SYSTEM_PROCESSOR "arm" ) > set(CMAKE_GENERATOR_TOOLSET "CE800") # I still don't know if this is needed ;) > set(CMAKE_GENERATOR_SDK "MYSDK01") > > I don't understand the purpose of CMAKE_GENERATOR_TOOLSET resp. > CMAKE_VS_PLATFORM_TOOLSET. The CMAKE_GENERATOR_TOOLSET is where a user-specified choice is set/saved. The CMAKE_VS_PLATFORM_TOOLSET is the actual toolset that the generator will write in to the project file, and is provided only for reference (and internal compiler id detection). The latter may be set to a default selection that CMake VS gens pick even when no explicit CMAKE_GENERATOR_TOOLSET is set. > As far as I understand they are independent of the SDK selected? I'm not familiar enough with VS+WinCE tools to know how independent they are. -Brad From brad.king at kitware.com Wed Sep 3 09:38:18 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 09:38:18 -0400 Subject: [cmake-developers] --debug-trycompile not working as documented with the results being overwritten In-Reply-To: References: Message-ID: <540719CA.4070502@kitware.com> On 09/02/2014 03:52 PM, Alan W. Irwin wrote: > just go ahead an fix this documentation bug without > going through the normal dance of putting it on the bug tracker, Please construct a proposed patch with "git format-patch" and attach it in a message here. Thanks, -Brad From hobbes1069 at gmail.com Wed Sep 3 09:48:29 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Wed, 3 Sep 2014 08:48:29 -0500 Subject: [cmake-developers] Best practice for determining if a static library was found and other issues with FindFLTK.cmake Message-ID: I'm probably going to end up taking over the module since it seems to be un-maintained but I'm hesitant to make radical changes to it. The module has several issues but a major one is that it doesn't add the required linker flags when using static libraries instead of shared. It also doesn't check for any required C flags but that's a lesser issue. These may only be a problem for the autotools based fltk build as the module uses a ConfigFLTK for CMake based builds. I have the following config to work around the issue which I'd like to ultimately get into the module and out of my cmake config: find_package(FLTK REQUIRED) if(${FLTK_FOUND}) include_directories(${FLTK_INCLUDE_DIRS}) # Set required CXX flags. execute_process(COMMAND ${FLTK_CONFIG_SCRIPT} --cxxflags OUTPUT_VARIABLE FLTK_CXXFLAGS) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${FLTK_CXXFLAGS}") # FindFLTK does not properly handle ldflags for static libraries. get_filename_component(FLTK_LIB_EXT ${FLTK_BASE_LIBRARY} EXT) if(${FLTK_LIB_EXT} STREQUAL ${CMAKE_STATIC_LIBRARY_SUFFIX}) ^^^ Is this the best way to determine if the library found was static or shared? ^^^ message(STATUS "Using static FLTK libraries.") execute_process(COMMAND ${FLTK_CONFIG_SCRIPT} --use-images --ldstaticflags OUTPUT_VARIABLE FLTK_LDFLAGS) ^^^ The module doesn't check if the library is static, and even then it only ^^^ ^^^ runs --ldflags for the fltk images library. separate_arguments(FLTK_LDFLAGS) foreach(_FLAG ${FLTK_LDFLAGS}) string(REGEX MATCH "^-l.+" _LDFLAG ${_FLAG}) string(STRIP "${_LDFLAG}" _LDFLAG) list(APPEND FLTK_LIBRARIES ${_LDFLAG}) endforeach() list(REMOVE_DUPLICATES FLTK_LIBRARIES) ^^^ This works, but is there a better way? ^^^ endif() list(APPEND FLDIGI_LINK_LIBS ${FLTK_LIBRARIES}) So a broader question... Should we trust the output of a config program, in this case, fltk-config? The writer of the module certainly doesn't. They used the fltk-config program to find the base library, strip off the path portion and then used it as a search path to find the libraries independently. I would like to update the module to use COMPONENTS, but the current default is to find everything unless a "FLTK_SKIP_..." variable is set so I assume there's a good way to keep backward compatibility. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Sep 3 10:11:15 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 10:11:15 -0400 Subject: [cmake-developers] Best practice for determining if a static library was found and other issues with FindFLTK.cmake In-Reply-To: References: Message-ID: <54072183.5090804@kitware.com> On 09/03/2014 09:48 AM, Richard Shaw wrote: > The module has several issues but a major one is that it doesn't add > the required linker flags when using static libraries instead of shared. > > It also doesn't check for any required C flags but that's a lesser issue. > > These may only be a problem for the autotools based fltk build > as the module uses a ConfigFLTK for CMake based builds. If FLTK upstream is willing to provide FTLKConfig for CMake-based builds then they may be willing to support providing one from autotools-based builds too. It is not very hard to provide one from a non-CMake build system. Qt5 and LLVM both do it. You could go work with the FLTK devs to do it there too. Then we won't even need a FindFLTK in CMake except for compatibility. > ^^^ Is this the best way to determine if the library found was > static or shared? ^^^ It is not possible in general without platform-specific knowledge. On AIX even an archive (.a) can be a shared library, for example. On Windows a .dll's import library (.lib) looks just like a static library (.lib). Ideally information provided with the FLTK package should tell us. > So a broader question... Should we trust the output of a config > program, in this case, fltk-config? The writer of the module > certainly doesn't. They used the fltk-config program to find > the base library, strip off the path portion and then used it > as a search path to find the libraries independently. Of course the output of fltk-config should be trusted to be correct, but the info still needs to be transformed into what CMake wants. That is usually more granular than strings of command-line flags for various tools, so some parsing/searching may be needed. > I would like to update the module to use COMPONENTS, but the > current default is to find everything unless a "FLTK_SKIP_..." > variable is set so I assume there's a good way to keep > backward compatibility. The FindFLTK module was added way back in the beginning of CMake and has never really been modernized. The SKIP variables may even predate the COMPONENTS support in find_package. -Brad From mantis at public.kitware.com Wed Sep 3 10:49:43 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 3 Sep 2014 16:49:43 +0200 Subject: [cmake-developers] [CMake 0015126]: cmake issues -bundle instead of -dynamiclib when creating shared modules Message-ID: <7a93fa062db74ec174641e1510483370@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15126 ====================================================================== Reported By: Ren? J.V. Bertin Assigned To: ====================================================================== Project: CMake Issue ID: 15126 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-03 16:49 CEST Last Modified: 2014-09-03 16:49 CEST ====================================================================== Summary: cmake issues -bundle instead of -dynamiclib when creating shared modules Description: While building KDE's Calligra suite, I came across a cmake-related error causing the linker to refuse to link in 'bundle' shared objects (intended to act as plugins also) in x86_64 mode. Googling, I came across ?http://www.wireshark.org/lists/wireshark-dev/201009/msg00231.html where one reads "CMake is using -bundle rather than -dylib/-dynamiclib to build the asn1 plugin, probably so that it'll work even on versions of OS X where you can't dynamically load an MH_DYLIB." AFAIK, that's a moot point since OS X 10.3 (or at least 10.4). Finding all CMAKE_SHARED_MODULE_CREATE definitions in /opt/local/lib/cmake{,-3.0} and replacing -bundle with -dynamiclib resolves the linking problem I encountered. A patchfile is included. Additional Information: Tested on OS X 10.6.8 and 10.9.x, with cmake 2.8 and cmake 3.0 . https://trac.macports.org/ticket/42840 I thought I already filed this bug "upstream" (from MacPorts) but apparently not here ... ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-03 16:49 Ren? J.V. BertinNew Issue 2014-09-03 16:49 Ren? J.V. BertinFile Added: patch-SHARED_BUNDLE_flag.diff ====================================================================== From pascal.bach at siemens.com Wed Sep 3 10:53:46 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Wed, 3 Sep 2014 14:53:46 +0000 Subject: [cmake-developers] VS 2013 WindowsCE support In-Reply-To: <5407191A.8070706@kitware.com> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> <5405EA2D.4070801@kitware.com> <355BE46A91031048906B695426A8D8E616ACE504@DEFTHW99EH4MSX.ww902.siemens.net> <5407191A.8070706@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACE698@DEFTHW99EH4MSX.ww902.siemens.net> > -----Original Message----- > From: Brad King [mailto:brad.king at kitware.com] > Sent: Mittwoch, 3. September 2014 15:35 > To: Bach, Pascal > Cc: cmake-developers at cmake.org; Patrick Roland Gansterer > Subject: Re: VS 2013 WindowsCE support > > On 09/03/2014 05:23 AM, Bach, Pascal wrote: > >> elseif(CMAKE_VS_WINCE_VERSION) > >> set(CMAKE_SYSTEM_NAME "WindowsCE") > >> set(CMAKE_SYSTEM_VERSION "${CMAKE_VS_WINCE_VERSION}") > >> set(CMAKE_SYSTEM_PROCESSOR "${MSVC_C_ARCHITECTURE_ID}") > > > > Do we need to preserve the current behavior? > > Yes, but only for the existing VS 11 WinCE-specific generator names. > > > CMAKE_VS_WINCE_VERSION seems to be undocumented. > > It is an internal implementation detail of the WinCE-specific > VS generators. > > > The new way would be to set CMAKE_SYSTEM_NAME and > > CMAKE_SYSTEM_VERSION in a toolchain file. > > Yes. > > >> is basically a mini toolchain file. A real toolchain file would > >> explicitly specify the values. We would also need a new variable > >> to tell the generator which SDK to use. Currently the info is > >> in the internal CMAKE_VS_PLATFORM_NAME variable that corresponds > >> to the platform component of the generator name. > > > > So do you agree that the right thing would be to add a > > CMAKE_VS_PLATFORM_SDK (or CMAKE_GENERATOR_SDK ?) variable that > > the user can set? > > Let's use a name specific to WindowsCE like "CMAKE_VS_WINCE_SDK", > at least for discussion and review purposes, so I can see where > the variable fits in to the generator with your changes. Then > we can decide if there is a more general name to be used later. I'm not sure this is really Windows CE specific. There is already an internal variable CMAKE_VS_PLATFORM_NAME that is set to Win32, Win64, ARM etc. This is also the variable that gets set to the SDK name. Currently this variable is set based on the Generator used, but there is also some other magic going on for example for Itanium. Would it be desirable to be able to override this value independent of the generator used? > > A resulting toolchain file would look something like this: > > > > set(CMAKE_SYSTEM_NAME "WindowsCE") > > set(CMAKE_SYSTEM_VERSION "8.0") > > set(CMAKE_SYSTEM_PROCESSOR "arm" ) > > set(CMAKE_GENERATOR_TOOLSET "CE800") # I still don't know if this is > needed ;) > > set(CMAKE_GENERATOR_SDK "MYSDK01") > > > > I don't understand the purpose of CMAKE_GENERATOR_TOOLSET resp. > > CMAKE_VS_PLATFORM_TOOLSET. > > The CMAKE_GENERATOR_TOOLSET is where a user-specified choice is > set/saved. The CMAKE_VS_PLATFORM_TOOLSET is the actual toolset > that the generator will write in to the project file, and is > provided only for reference (and internal compiler id detection). > The latter may be set to a default selection that CMake VS gens > pick even when no explicit CMAKE_GENERATOR_TOOLSET is set. Based on your explanation and my findings above, the CMAKE_VS_PLATFORM_NAME variable should behave analogues to CMAKE_VS_PLATFORM_TOOLSET but I can't come up with a good name for a variable the user should set. One way would be to just allow setting CMAKE_VS_PLATFORM_NAME and override the whole logic if it is set. Any thoughts? > > > As far as I understand they are independent of the SDK selected? > > I'm not familiar enough with VS+WinCE tools to know how independent > they are. As far as I can tell they are, at least you can change both values in visual studio independently. If the result works is another question. Pascal From irwin at beluga.phys.uvic.ca Wed Sep 3 10:52:35 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 3 Sep 2014 07:52:35 -0700 (PDT) Subject: [cmake-developers] --debug-trycompile not working as documented with the results being overwritten In-Reply-To: <540719CA.4070502@kitware.com> References: <540719CA.4070502@kitware.com> Message-ID: On 2014-09-03 09:38-0400 Brad King wrote: > On 09/02/2014 03:52 PM, Alan W. Irwin wrote: >> just go ahead an fix this documentation bug without >> going through the normal dance of putting it on the bug tracker, > > Please construct a proposed patch with "git format-patch" and > attach it in a message here. DONE. See attached 0001-Update-documentation-of-try_compile.patch The rst format seems obvious so I was pretty sure I understood what changes I had to make in the above patch, but just to be sure I checked this patch by building the patched master version and after that, cmake --help-command try_compile gave the desired corrected results. One caveat. My experimental result was try_compile always repeats so must not have any internal "if(NOT DEFINED RESULT_VAR)" logic. Which is why I updated the try_compile documentation accordingly. However, someone with more C++ skills than I have should probably double-check the try_compile code to make sure that experimental conclusion is correct. 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 __________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Update-documentation-of-try_compile.patch Type: text/x-diff Size: 1393 bytes Desc: try_compile documentation patch URL: From mantis at public.kitware.com Wed Sep 3 11:08:10 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 3 Sep 2014 17:08:10 +0200 Subject: [cmake-developers] [CMake 0015127]: command line CXX_FLAG settings overridden by settings in system-wide .cmake files Message-ID: <6d8ec4eb13827b2e1bbc4057e5b90812@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15127 ====================================================================== Reported By: Ren? J.V. Bertin Assigned To: ====================================================================== Project: CMake Issue ID: 15127 Category: CMake Reproducibility: always Severity: tweak Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-03 17:08 CEST Last Modified: 2014-09-03 17:08 CEST ====================================================================== Summary: command line CXX_FLAG settings overridden by settings in system-wide .cmake files Description: KDE defines a number of compiler options that are (supposedly) required but that include optimisation options. These settings are defined in system-wide .cmake files like FindKDE4Internal.cmake and get applied *after* user-specified settings have been applied. They even seem to override tweaks made directly in CMakeCache.txt (to CMAKE_CXX_FLAGS_RELEASE or _RELWITHDEBINFO). Even if user-specified compiler flags do make it to the list in the generated *.make files, the KDE/system-defined options are *appended* to the list, causing -O2 to override -O3 or -g -g3. Is it possible to specify the KDE/system options in such a way that they appear at the start of the options list in the *.make files? Steps to Reproduce: N/A Additional Information: Not really a bug, more a question and possibly a feature request. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-03 17:08 Ren? J.V. BertinNew Issue ====================================================================== From brad.king at kitware.com Wed Sep 3 11:16:38 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 11:16:38 -0400 Subject: [cmake-developers] VS 2013 WindowsCE support In-Reply-To: <355BE46A91031048906B695426A8D8E616ACE698@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> <5405EA2D.4070801@kitware.com> <355BE46A91031048906B695426A8D8E616ACE504@DEFTHW99EH4MSX.ww902.siemens.net> <5407191A.8070706@kitware.com> <355BE46A91031048906B695426A8D8E616ACE698@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <540730D6.80101@kitware.com> On 09/03/2014 10:53 AM, Bach, Pascal wrote: >> Let's use a name specific to WindowsCE like "CMAKE_VS_WINCE_SDK", > > I'm not sure this is really Windows CE specific. There is already > an internal variable CMAKE_VS_PLATFORM_NAME that is set to Win32, > Win64, ARM etc. This is also the variable that gets set to the SDK > name. Currently this variable is set based on the Generator used, > but there is also some other magic going on for example for Itanium. The fact that the PlatformName corresponds to an SDK is specific to WinCE tools. Other platforms may not have such correspondence. This is why I want to use a WinCE-specific name at first. We can generalize the name before merging the changes if it makes sense when its role becomes clear. > Would it be desirable to be able to override this value independent > of the generator used? I'm not sure what this would mean because the value is for a specific field in VS project files. > Based on your explanation and my findings above, the > CMAKE_VS_PLATFORM_NAME variable should behave analogues to > CMAKE_VS_PLATFORM_TOOLSET but I can't come up with a good > name for a variable the user should set. Yes. What I'm saying is the fact that a user can select this at all might be WinCE-specific. Hence a WinCE-specific name. -Brad From brad.king at kitware.com Wed Sep 3 11:22:44 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 11:22:44 -0400 Subject: [cmake-developers] --debug-trycompile not working as documented with the results being overwritten In-Reply-To: References: <540719CA.4070502@kitware.com> Message-ID: <54073244.5010605@kitware.com> On 09/03/2014 10:52 AM, Alan W. Irwin wrote: > On 2014-09-03 09:38-0400 Brad King wrote: >> Please construct a proposed patch with "git format-patch" and >> attach it in a message here. > > DONE. See attached 0001-Update-documentation-of-try_compile.patch Applied with minor tweaks, thanks: Help: Clarify --debug-trycompile usage with try_compile http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=abbe91c5 -Brad From pascal.bach at siemens.com Wed Sep 3 11:36:13 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Wed, 3 Sep 2014 15:36:13 +0000 Subject: [cmake-developers] VS 2013 WindowsCE support In-Reply-To: <540730D6.80101@kitware.com> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> <5405EA2D.4070801@kitware.com> <355BE46A91031048906B695426A8D8E616ACE504@DEFTHW99EH4MSX.ww902.siemens.net> <5407191A.8070706@kitware.com> <355BE46A91031048906B695426A8D8E616ACE698@DEFTHW99EH4MSX.ww902.siemens.net> <540730D6.80101@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACE705@DEFTHW99EH4MSX.ww902.siemens.net> > >> Let's use a name specific to WindowsCE like "CMAKE_VS_WINCE_SDK", > > > > I'm not sure this is really Windows CE specific. There is already > > an internal variable CMAKE_VS_PLATFORM_NAME that is set to Win32, > > Win64, ARM etc. This is also the variable that gets set to the SDK > > name. Currently this variable is set based on the Generator used, > > but there is also some other magic going on for example for Itanium. > > The fact that the PlatformName corresponds to an SDK is specific to > WinCE tools. Other platforms may not have such correspondence. > This is why I want to use a WinCE-specific name at first. We can > generalize the name before merging the changes if it makes sense > when its role becomes clear. Ok I understand your reasoning, makes sense. > > Would it be desirable to be able to override this value independent > > of the generator used? > > I'm not sure what this would mean because the value is for a > specific field in VS project files. What I meant is that is you use the generator "Visual Studio 12 (2013) ARM" but set the CMAKE_VS_PLATFORM_NAME="Win64" It would compile for Win64 not arm (like calling "Visual Studio 12 (2013) Win64"), so we just override it with whatever the user provides. > > Based on your explanation and my findings above, the > > CMAKE_VS_PLATFORM_NAME variable should behave analogues to > > CMAKE_VS_PLATFORM_TOOLSET but I can't come up with a good > > name for a variable the user should set. > > Yes. What I'm saying is the fact that a user can select this > at all might be WinCE-specific. Hence a WinCE-specific name. > For my first attempt I will just stick with allowing the user overriding CMAKE_VS_PLATFORM_NAME. Pascal From brad.king at kitware.com Wed Sep 3 11:47:55 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 11:47:55 -0400 Subject: [cmake-developers] VS 2013 WindowsCE support In-Reply-To: <355BE46A91031048906B695426A8D8E616ACE705@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409230361-19916-1-git-send-email-pascal.bach@siemens.com> <5405DB83.7040605@kitware.com> <355BE46A91031048906B695426A8D8E616ACDEC5@DEFTHW99EH4MSX.ww902.siemens.net> <5405EA2D.4070801@kitware.com> <355BE46A91031048906B695426A8D8E616ACE504@DEFTHW99EH4MSX.ww902.siemens.net> <5407191A.8070706@kitware.com> <355BE46A91031048906B695426A8D8E616ACE698@DEFTHW99EH4MSX.ww902.siemens.net> <540730D6.80101@kitware.com> <355BE46A91031048906B695426A8D8E616ACE705@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <5407382B.1090702@kitware.com> On 09/03/2014 11:36 AM, Bach, Pascal wrote: > What I meant is that is you use the generator "Visual Studio 12 (2013) ARM" but set the CMAKE_VS_PLATFORM_NAME="Win64" > It would compile for Win64 not arm (like calling "Visual Studio 12 (2013) Win64"), so we just override it with whatever the user provides. I think it should be an error in that case. We should only allow the platform to be set by a variable if it is not part of the generator name. Putting it in the generator name is a way of specifying the value, so we should not support conflicting specifications. Thanks, -Brad From neundorf at kde.org Wed Sep 3 11:48:28 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Wed, 03 Sep 2014 17:48:28 +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> Message-ID: <22742143.8V0LQmVuST@tuxedo.neundorf.net> On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote: > On Tue, Sep 2, 2014 at 3:58 PM, David Cole wrote: > > It makes sense. But what IDE are you referring to? Eclipse? Some other > > concrete example? Or just "any IDE and this feature should work everywhere > > CMake works...?" > > I'm working on KDevelop, I know for a fact though, that other IDEs are > looking for something similar too, such as QtCreator. I still don't understand why this shouldn't be an additional ExtraGenerator. It will generate a special file intended to be used by KDevelop and maybe QtCreator additionally to makefiles/ninja files. Could be called "GenericJSON" or so. Other IDEs which don't support this file type but which need their own project file obviously still need their own specific generator. Alex From aleixpol at kde.org Wed Sep 3 12:12:34 2014 From: aleixpol at kde.org (Aleix Pol) Date: Wed, 3 Sep 2014 18:12:34 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <22742143.8V0LQmVuST@tuxedo.neundorf.net> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <8D194CD20D9E6FB-15CC-2147@webmail-m269.sysops.aol.com> <22742143.8V0LQmVuST@tuxedo.neundorf.net> Message-ID: On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf wrote: > On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote: > > On Tue, Sep 2, 2014 at 3:58 PM, David Cole wrote: > > > It makes sense. But what IDE are you referring to? Eclipse? Some other > > > concrete example? Or just "any IDE and this feature should work > everywhere > > > CMake works...?" > > > > I'm working on KDevelop, I know for a fact though, that other IDEs are > > looking for something similar too, such as QtCreator. > > I still don't understand why this shouldn't be an additional > ExtraGenerator. > It will generate a special file intended to be used by KDevelop and maybe > QtCreator additionally to makefiles/ninja files. Could be called > "GenericJSON" > or so. > Other IDEs which don't support this file type but which need their own > project > file obviously still need their own specific generator. > > Alex > Because it's not possible to change the generator of a build directory once it's set up. You need to nuke it and re-create it. Also because changing the generator could potentially change the interaction the user has with the build directory, we don't want to get in the way. Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascal.bach at siemens.com Wed Sep 3 13:16:11 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Wed, 3 Sep 2014 19:16:11 +0200 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio Message-ID: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> Set CMAKE_VS_WINCE_SDK to specify the SDK. --- Source/cmGlobalVisualStudio10Generator.cxx | 48 ++++++++++++++++++++++++++++ Source/cmGlobalVisualStudio10Generator.h | 7 ++++ Source/cmGlobalVisualStudio11Generator.cxx | 12 +++++++ Source/cmGlobalVisualStudio11Generator.h | 2 ++ Source/cmGlobalVisualStudio12Generator.cxx | 12 +++++++ Source/cmGlobalVisualStudio12Generator.h | 2 ++ 6 files changed, 83 insertions(+) diff --git a/Source/cmGlobalVisualStudio10Generator.cxx b/Source/cmGlobalVisualStudio10Generator.cxx index 19aa52c..5c1fd4b 100644 --- a/Source/cmGlobalVisualStudio10Generator.cxx +++ b/Source/cmGlobalVisualStudio10Generator.cxx @@ -165,6 +165,14 @@ bool cmGlobalVisualStudio10Generator::InitializeSystem(cmMakefile* mf) return false; } } + else if (this->SystemName == "WindowsCE") + { + this->SystemIsWindowsCE = true; + if (!this->InitializeWindowsCE(mf)) + { + return false; + } + } return true; } @@ -187,6 +195,46 @@ bool cmGlobalVisualStudio10Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio10Generator::InitializeWindowsCE(cmMakefile* mf) +{ + this->DefaultPlatformToolset = this->SelectWindowsCEToolset(); + if (this->DefaultPlatformToolset.empty()) + { + cmOStringStream e; + e << this->GetName() << " supports Windows CE '8.0', but not '" + << this->SystemVersion << "'. Check CMAKE_SYSTEM_VERSION."; + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); + return false; + } + + if (const char* platformName = mf->GetDefinition("CMAKE_VS_WINCE_SDK")) + { + this->PlatformName = platformName; + } + else { + cmOStringStream e; + e << this->GetName() << " for " << this->GetSystemName() << " requires an SDK. Please set CMAKE_VS_WINCE_SDK to the name of your SDK."; + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); + return false; + } + + return true; +} + +//---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio10Generator::SelectWindowsCEToolset() const +{ + if (this->SystemVersion == "8.0") + { + return "CE800"; + } + else + { + return ""; + } +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio10Generator ::AddVSPlatformToolsetDefinition(cmMakefile* mf) const { diff --git a/Source/cmGlobalVisualStudio10Generator.h b/Source/cmGlobalVisualStudio10Generator.h index 11fa954..9bceb2c 100644 --- a/Source/cmGlobalVisualStudio10Generator.h +++ b/Source/cmGlobalVisualStudio10Generator.h @@ -75,6 +75,10 @@ public: bool TargetsWindowsStore() const { return this->SystemIsWindowsStore; } + /** Return true if building for WindowsCE */ + bool TargetsWindowsCE() const + { return this->SystemIsWindowsCE; } + /** * Where does this version of Visual Studio look for macros for the * current user? Returns the empty string if this version of Visual @@ -106,8 +110,10 @@ protected: virtual bool InitializeSystem(cmMakefile* mf); virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const { return ""; } virtual std::string SelectWindowsStoreToolset() const { return ""; } + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "10.0"; } @@ -119,6 +125,7 @@ protected: std::string SystemVersion; bool SystemIsWindowsPhone; bool SystemIsWindowsStore; + bool SystemIsWindowsCE; bool ExpressEdition; bool UseFolderProperty(); diff --git a/Source/cmGlobalVisualStudio11Generator.cxx b/Source/cmGlobalVisualStudio11Generator.cxx index 39bbdc0..a71c42e 100644 --- a/Source/cmGlobalVisualStudio11Generator.cxx +++ b/Source/cmGlobalVisualStudio11Generator.cxx @@ -159,6 +159,12 @@ bool cmGlobalVisualStudio11Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio11Generator::InitializeWindowsCE(cmMakefile* mf) +{ + return cmGlobalVisualStudio10Generator::InitializeWindowsCE(mf); +} + +//---------------------------------------------------------------------------- std::string cmGlobalVisualStudio11Generator::SelectWindowsPhoneToolset() const { if(this->SystemVersion == "8.0") @@ -179,6 +185,12 @@ std::string cmGlobalVisualStudio11Generator::SelectWindowsStoreToolset() const } //---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio11Generator::SelectWindowsCEToolset() const +{ + return this->cmGlobalVisualStudio10Generator::SelectWindowsCEToolset(); +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio11Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; diff --git a/Source/cmGlobalVisualStudio11Generator.h b/Source/cmGlobalVisualStudio11Generator.h index bbd935c..9dd3271 100644 --- a/Source/cmGlobalVisualStudio11Generator.h +++ b/Source/cmGlobalVisualStudio11Generator.h @@ -36,8 +36,10 @@ public: protected: virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const; virtual std::string SelectWindowsStoreToolset() const; + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "11.0"; } bool UseFolderProperty(); static std::set GetInstalledWindowsCESDKs(); diff --git a/Source/cmGlobalVisualStudio12Generator.cxx b/Source/cmGlobalVisualStudio12Generator.cxx index 29ecfe0..c784cae 100644 --- a/Source/cmGlobalVisualStudio12Generator.cxx +++ b/Source/cmGlobalVisualStudio12Generator.cxx @@ -139,6 +139,12 @@ bool cmGlobalVisualStudio12Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio12Generator::InitializeWindowsCE(cmMakefile* mf) +{ + return cmGlobalVisualStudio11Generator::InitializeWindowsCE(mf); +} + +//---------------------------------------------------------------------------- std::string cmGlobalVisualStudio12Generator::SelectWindowsPhoneToolset() const { if(this->SystemVersion == "8.1") @@ -159,6 +165,12 @@ std::string cmGlobalVisualStudio12Generator::SelectWindowsStoreToolset() const } //---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio12Generator::SelectWindowsCEToolset() const +{ + return this->cmGlobalVisualStudio11Generator::SelectWindowsCEToolset(); +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio12Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; diff --git a/Source/cmGlobalVisualStudio12Generator.h b/Source/cmGlobalVisualStudio12Generator.h index ec85f10..5d8c125 100644 --- a/Source/cmGlobalVisualStudio12Generator.h +++ b/Source/cmGlobalVisualStudio12Generator.h @@ -41,8 +41,10 @@ public: protected: virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const; virtual std::string SelectWindowsStoreToolset() const; + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "12.0"; } private: class Factory; -- 1.7.10.4 From pascal.bach at siemens.com Wed Sep 3 13:21:15 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Wed, 3 Sep 2014 17:21:15 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> Looks like I missed the Description :( This is only a first draft and I would like to hear if I am on the right track. The patch implements the SDK selection for Windows CE. If CMAKE_SYSTEM_NAME="WindowsCE" the user has to specify an SDK using the variable: CMAKE_VS_WINCE_SDK The implementation is inspired by WindowsPhone and WindowsStore. Current limitations: - Only works with Windows CE 8.0 Pascal > -----Original Message----- > From: Pascal Bach [mailto:pascal.bach at siemens.com] > Sent: Mittwoch, 3. September 2014 19:16 > To: cmake-developers at cmake.org > Cc: Bach, Pascal > Subject: [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on > Visual Studio > > Set CMAKE_VS_WINCE_SDK to specify the SDK. > --- > Source/cmGlobalVisualStudio10Generator.cxx | 48 > ++++++++++++++++++++++++++++ > Source/cmGlobalVisualStudio10Generator.h | 7 ++++ > Source/cmGlobalVisualStudio11Generator.cxx | 12 +++++++ > Source/cmGlobalVisualStudio11Generator.h | 2 ++ > Source/cmGlobalVisualStudio12Generator.cxx | 12 +++++++ > Source/cmGlobalVisualStudio12Generator.h | 2 ++ > 6 files changed, 83 insertions(+) > > diff --git a/Source/cmGlobalVisualStudio10Generator.cxx > b/Source/cmGlobalVisualStudio10Generator.cxx > index 19aa52c..5c1fd4b 100644 > --- a/Source/cmGlobalVisualStudio10Generator.cxx > +++ b/Source/cmGlobalVisualStudio10Generator.cxx > @@ -165,6 +165,14 @@ bool > cmGlobalVisualStudio10Generator::InitializeSystem(cmMakefile* mf) > return false; > } > } > + else if (this->SystemName == "WindowsCE") > + { > + this->SystemIsWindowsCE = true; > + if (!this->InitializeWindowsCE(mf)) > + { > + return false; > + } > + } > return true; > } > > @@ -187,6 +195,46 @@ bool > cmGlobalVisualStudio10Generator::InitializeWindowsStore(cmMakefile* mf) > } > > //---------------------------------------------------------------------------- > +bool cmGlobalVisualStudio10Generator::InitializeWindowsCE(cmMakefile* > mf) > +{ > + this->DefaultPlatformToolset = this->SelectWindowsCEToolset(); > + if (this->DefaultPlatformToolset.empty()) > + { > + cmOStringStream e; > + e << this->GetName() << " supports Windows CE '8.0', but not '" > + << this->SystemVersion << "'. Check CMAKE_SYSTEM_VERSION."; > + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); > + return false; > + } > + > + if (const char* platformName = mf- > >GetDefinition("CMAKE_VS_WINCE_SDK")) > + { > + this->PlatformName = platformName; > + } > + else { > + cmOStringStream e; > + e << this->GetName() << " for " << this->GetSystemName() << " requires > an SDK. Please set CMAKE_VS_WINCE_SDK to the name of your SDK."; > + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); > + return false; > + } > + > + return true; > +} > + > +//---------------------------------------------------------------------------- > +std::string cmGlobalVisualStudio10Generator::SelectWindowsCEToolset() > const > +{ > + if (this->SystemVersion == "8.0") > + { > + return "CE800"; > + } > + else > + { > + return ""; > + } > +} > + > +//---------------------------------------------------------------------------- > void cmGlobalVisualStudio10Generator > ::AddVSPlatformToolsetDefinition(cmMakefile* mf) const > { > diff --git a/Source/cmGlobalVisualStudio10Generator.h > b/Source/cmGlobalVisualStudio10Generator.h > index 11fa954..9bceb2c 100644 > --- a/Source/cmGlobalVisualStudio10Generator.h > +++ b/Source/cmGlobalVisualStudio10Generator.h > @@ -75,6 +75,10 @@ public: > bool TargetsWindowsStore() const > { return this->SystemIsWindowsStore; } > > + /** Return true if building for WindowsCE */ > + bool TargetsWindowsCE() const > + { return this->SystemIsWindowsCE; } > + > /** > * Where does this version of Visual Studio look for macros for the > * current user? Returns the empty string if this version of Visual > @@ -106,8 +110,10 @@ protected: > virtual bool InitializeSystem(cmMakefile* mf); > virtual bool InitializeWindowsPhone(cmMakefile* mf); > virtual bool InitializeWindowsStore(cmMakefile* mf); > + virtual bool InitializeWindowsCE(cmMakefile* mf); > virtual std::string SelectWindowsPhoneToolset() const { return ""; } > virtual std::string SelectWindowsStoreToolset() const { return ""; } > + virtual std::string SelectWindowsCEToolset() const; > > virtual const char* GetIDEVersion() { return "10.0"; } > > @@ -119,6 +125,7 @@ protected: > std::string SystemVersion; > bool SystemIsWindowsPhone; > bool SystemIsWindowsStore; > + bool SystemIsWindowsCE; > bool ExpressEdition; > > bool UseFolderProperty(); > diff --git a/Source/cmGlobalVisualStudio11Generator.cxx > b/Source/cmGlobalVisualStudio11Generator.cxx > index 39bbdc0..a71c42e 100644 > --- a/Source/cmGlobalVisualStudio11Generator.cxx > +++ b/Source/cmGlobalVisualStudio11Generator.cxx > @@ -159,6 +159,12 @@ bool > cmGlobalVisualStudio11Generator::InitializeWindowsStore(cmMakefile* mf) > } > > //---------------------------------------------------------------------------- > +bool cmGlobalVisualStudio11Generator::InitializeWindowsCE(cmMakefile* > mf) > +{ > + return cmGlobalVisualStudio10Generator::InitializeWindowsCE(mf); > +} > + > +//---------------------------------------------------------------------------- > std::string > cmGlobalVisualStudio11Generator::SelectWindowsPhoneToolset() const > { > if(this->SystemVersion == "8.0") > @@ -179,6 +185,12 @@ std::string > cmGlobalVisualStudio11Generator::SelectWindowsStoreToolset() const > } > > //---------------------------------------------------------------------------- > +std::string cmGlobalVisualStudio11Generator::SelectWindowsCEToolset() > const > +{ > + return this- > >cmGlobalVisualStudio10Generator::SelectWindowsCEToolset(); > +} > + > +//---------------------------------------------------------------------------- > void cmGlobalVisualStudio11Generator::WriteSLNHeader(std::ostream& > fout) > { > fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; > diff --git a/Source/cmGlobalVisualStudio11Generator.h > b/Source/cmGlobalVisualStudio11Generator.h > index bbd935c..9dd3271 100644 > --- a/Source/cmGlobalVisualStudio11Generator.h > +++ b/Source/cmGlobalVisualStudio11Generator.h > @@ -36,8 +36,10 @@ public: > protected: > virtual bool InitializeWindowsPhone(cmMakefile* mf); > virtual bool InitializeWindowsStore(cmMakefile* mf); > + virtual bool InitializeWindowsCE(cmMakefile* mf); > virtual std::string SelectWindowsPhoneToolset() const; > virtual std::string SelectWindowsStoreToolset() const; > + virtual std::string SelectWindowsCEToolset() const; > virtual const char* GetIDEVersion() { return "11.0"; } > bool UseFolderProperty(); > static std::set GetInstalledWindowsCESDKs(); > diff --git a/Source/cmGlobalVisualStudio12Generator.cxx > b/Source/cmGlobalVisualStudio12Generator.cxx > index 29ecfe0..c784cae 100644 > --- a/Source/cmGlobalVisualStudio12Generator.cxx > +++ b/Source/cmGlobalVisualStudio12Generator.cxx > @@ -139,6 +139,12 @@ bool > cmGlobalVisualStudio12Generator::InitializeWindowsStore(cmMakefile* mf) > } > > //---------------------------------------------------------------------------- > +bool cmGlobalVisualStudio12Generator::InitializeWindowsCE(cmMakefile* > mf) > +{ > + return cmGlobalVisualStudio11Generator::InitializeWindowsCE(mf); > +} > + > +//---------------------------------------------------------------------------- > std::string > cmGlobalVisualStudio12Generator::SelectWindowsPhoneToolset() const > { > if(this->SystemVersion == "8.1") > @@ -159,6 +165,12 @@ std::string > cmGlobalVisualStudio12Generator::SelectWindowsStoreToolset() const > } > > //---------------------------------------------------------------------------- > +std::string cmGlobalVisualStudio12Generator::SelectWindowsCEToolset() > const > +{ > + return this- > >cmGlobalVisualStudio11Generator::SelectWindowsCEToolset(); > +} > + > +//---------------------------------------------------------------------------- > void cmGlobalVisualStudio12Generator::WriteSLNHeader(std::ostream& > fout) > { > fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; > diff --git a/Source/cmGlobalVisualStudio12Generator.h > b/Source/cmGlobalVisualStudio12Generator.h > index ec85f10..5d8c125 100644 > --- a/Source/cmGlobalVisualStudio12Generator.h > +++ b/Source/cmGlobalVisualStudio12Generator.h > @@ -41,8 +41,10 @@ public: > protected: > virtual bool InitializeWindowsPhone(cmMakefile* mf); > virtual bool InitializeWindowsStore(cmMakefile* mf); > + virtual bool InitializeWindowsCE(cmMakefile* mf); > virtual std::string SelectWindowsPhoneToolset() const; > virtual std::string SelectWindowsStoreToolset() const; > + virtual std::string SelectWindowsCEToolset() const; > virtual const char* GetIDEVersion() { return "12.0"; } > private: > class Factory; > -- > 1.7.10.4 From brad.king at kitware.com Wed Sep 3 14:12:57 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 14:12:57 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <54075A29.1030002@kitware.com> On 09/03/2014 01:21 PM, Bach, Pascal wrote: > This is only a first draft and I would like to hear if I am on the right track. Yes, it looks good so far. > + else if (this->SystemName == "WindowsCE") > + { > + this->SystemIsWindowsCE = true; > + if (!this->InitializeWindowsCE(mf)) At the beginning of this block you should check/reject when the generator name specified a platform name. Something like: if(this->PlatformName != "Win32") { cmOStringStream e; e << "CMAKE_SYSTEM_NAME is 'WindowsCE' but CMAKE_GENERATOR " << "specifies a platform too: '" << this->GetName() << "'"; mf->IssueMessage(cmake::FATAL_ERROR, e.str()); return false; } Thanks, -Brad From joubert.sy at gmail.com Wed Sep 3 14:44:39 2014 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Wed, 03 Sep 2014 20:44:39 +0200 Subject: [cmake-developers] [patch] Bash completion for label options of ctest Message-ID: <54076197.8070802@gmail.com> Hi, Please find attached a patch that updates the bash completion of ctest. It will now be able to complete the -L,-LE options and their long versions. Regards, Sylvain -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-bash-completion-for-label-options-of-ctest.patch Type: text/x-patch Size: 1132 bytes Desc: not available URL: From brad.king at kitware.com Wed Sep 3 14:58:30 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Sep 2014 14:58:30 -0400 Subject: [cmake-developers] [patch] Bash completion for label options of ctest In-Reply-To: <54076197.8070802@gmail.com> References: <54076197.8070802@gmail.com> Message-ID: <540764D6.7080009@kitware.com> On 09/03/2014 02:44 PM, Sylvain Joubert wrote: > Please find attached a patch that updates the bash completion of ctest. Applied, thanks: bash-completion: Complete 'ctest' label names http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2603e128 -Brad From hobbes1069 at gmail.com Wed Sep 3 16:12:07 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Wed, 3 Sep 2014 15:12:07 -0500 Subject: [cmake-developers] Best practice for determining if a static library was found and other issues with FindFLTK.cmake In-Reply-To: <54072183.5090804@kitware.com> References: <54072183.5090804@kitware.com> Message-ID: On Wed, Sep 3, 2014 at 9:11 AM, Brad King wrote: > On 09/03/2014 09:48 AM, Richard Shaw wrote: > > The module has several issues but a major one is that it doesn't add > > the required linker flags when using static libraries instead of shared. > > > > It also doesn't check for any required C flags but that's a lesser issue. > > > > These may only be a problem for the autotools based fltk build > > as the module uses a ConfigFLTK for CMake based builds. > > If FLTK upstream is willing to provide FTLKConfig for CMake-based > builds then they may be willing to support providing one from > autotools-based builds too. It is not very hard to provide one > from a non-CMake build system. Qt5 and LLVM both do it. You > could go work with the FLTK devs to do it there too. Then we > won't even need a FindFLTK in CMake except for compatibility. > I did a cmake based build for cross-compiling for win32 on Fedora because the autotools was going to be WAY too much work to get working with the rpmbuild mingw macros and took a look at the generated cmake files. It looks like it uses a bunch of imported targets rather than utilizing find_library... I'm not familiar with this method so would you just use an "include(FLTKConfig)" instead of find_library/find_package? And then I would add the imported targets to target_link_libraries? > ^^^ Is this the best way to determine if the library found was > > static or shared? ^^^ > > It is not possible in general without platform-specific knowledge. > On AIX even an archive (.a) can be a shared library, for example. > On Windows a .dll's import library (.lib) looks just like a static > library (.lib). Ideally information provided with the FLTK package > should tell us. > Hmm... no good answer here. Another reason to move away from the autotools build... more below. > > > So a broader question... Should we trust the output of a config > > program, in this case, fltk-config? The writer of the module > > certainly doesn't. They used the fltk-config program to find > > the base library, strip off the path portion and then used it > > as a search path to find the libraries independently. > > Of course the output of fltk-config should be trusted to be > correct, but the info still needs to be transformed into what > CMake wants. That is usually more granular than strings of > command-line flags for various tools, so some parsing/searching > may be needed. > Well, after a bit more research I see why he didn't trust the output of fltk-config. I only have the shared libraries on my fedora system but if I run "fltk-config --libs" the output shows a static library: $ fltk-config --libs /usr/lib64/libfltk.a > I would like to update the module to use COMPONENTS, but the > > current default is to find everything unless a "FLTK_SKIP_..." > > variable is set so I assume there's a good way to keep > > backward compatibility. > > The FindFLTK module was added way back in the beginning of CMake > and has never really been modernized. The SKIP variables may > even predate the COMPONENTS support in find_package. > Ahh... Is it possible to support that now as long as if the user doesn't specify COMPONENTS that it emulates the old behavior and tries to find everything? Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Wed Sep 3 16:23:44 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 03 Sep 2014 22:23:44 +0200 Subject: [cmake-developers] Best practice for determining if a static library was found and other issues with FindFLTK.cmake In-Reply-To: References: <54072183.5090804@kitware.com> Message-ID: <540778D0.2080603@gmail.com> On 03.09.2014 22:12, Richard Shaw wrote: > > I did a cmake based build for cross-compiling for win32 on Fedora > because the autotools was going to be WAY too much work to get working > with the rpmbuild mingw macros and took a look at the generated cmake > files. > > It looks like it uses a bunch of imported targets rather than > utilizing find_library... I'm not familiar with this method so would > you just use an "include(FLTKConfig)" instead of > find_library/find_package? And then I would add the imported targets > to target_link_libraries? You would use e.g. find_package(FLTK CONFIG). Or find_package(FLTK) if there is no FindFLTK.cmake or if FindFLTK.cmake itself looks for the package in config mode as well. For reference on packages: http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html And find_package() module and config modes: http://www.cmake.org/cmake/help/v3.0/command/find_package.html Nils From chuck.atkins at kitware.com Wed Sep 3 17:20:01 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 3 Sep 2014 17:20:01 -0400 Subject: [cmake-developers] Changing the regex used for INFO strings Message-ID: stage/use-consistent-regex-for-info-strings The change seems minor enough but the impact if it breaks something is substantial so I wanted to get a second set of eyes on this. I set out to fix the non-working ABI detection for craycc and crayCC, which turned out was because the cray compiler will often generate *lots* of "INFO:" strings itself, which were getting through the strings regex. Since all binary info strings that CMake extracts for system and compiler info should have the same format, it seemed appropriate to have a consistent regex used in all the various places that INFO: strings are extracted from compiled binaries. - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Wed Sep 3 18:30:00 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 3 Sep 2014 18:30:00 -0400 Subject: [cmake-developers] [CMake 0015128]: FindProtobuf issues Message-ID: <357614e15937f285f21c90acde92a76c@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15128 ====================================================================== Reported By: Orion E. Poplawski Assigned To: ====================================================================== Project: CMake Issue ID: 15128 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-03 18:29 EDT Last Modified: 2014-09-03 18:30 EDT ====================================================================== Summary: FindProtobuf issues Description: For the Fedora package build of ParaView, we need to use system libraries. I have been patching ParaView to use the system protobuf library (see http://www.paraview.org/Bug/view.php?id=13656) for a while now and am updating to 4.2RC1. With that I am now seeing issues with the interaction with the cmake FindProtobuf module, due to the fact that it uses the optimize/debug list convention and add -lpthread to PROTOBUF_LIBRARIES. Part of the issue is the way it looks for a debug library: find_library(${name}_LIBRARY NAMES ${filename} PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/Release) mark_as_advanced(${name}_LIBRARY) find_library(${name}_LIBRARY_DEBUG NAMES ${filename} PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/Debug) mark_as_advanced(${name}_LIBRARY_DEBUG) On Linux/Unix this generally finds the same library in the same path. Changing to: find_library(${name}_LIBRARY_DEBUG NAMES ${filename} PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/Debug NO_DEFAULT_PATH) mark_as_advanced(${name}_LIBRARY_DEBUG) helps with that. I'm not sure what to do with the addition of -lphtreads. Simply removing it may be the way to go. The paraview protobuf cmake configuration seems to add it to protobuf_LIB_DEPS. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-03 18:29 Orion E. PoplawskiNew Issue 2014-09-03 18:30 Orion E. PoplawskiFile Added: cmake-FindProtobuf.patch ====================================================================== From dlrdave at aol.com Wed Sep 3 21:27:25 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 3 Sep 2014 21:27:25 -0400 Subject: [cmake-developers] Changing the regex used for INFO strings In-Reply-To: References: Message-ID: <8D195F6846C8B49-15CC-FF14@webmail-m269.sysops.aol.com> Looks good to me. Why not merge it to 'next' for testing? Worst case, you can also revert it and merge again... D From pascal.bach at siemens.com Thu Sep 4 06:42:56 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Thu, 4 Sep 2014 10:42:56 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <54075A29.1030002@kitware.com> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> > > + else if (this->SystemName == "WindowsCE") > > + { > > + this->SystemIsWindowsCE = true; > > + if (!this->InitializeWindowsCE(mf)) > > At the beginning of this block you should check/reject when > the generator name specified a platform name. Something like: > > if(this->PlatformName != "Win32") > { > cmOStringStream e; > e << "CMAKE_SYSTEM_NAME is 'WindowsCE' but CMAKE_GENERATOR " > << "specifies a platform too: '" << this->GetName() << "'"; > mf->IssueMessage(cmake::FATAL_ERROR, e.str()); > return false; > } > This won't' work as the code gets called multiple times during a project generation, but only the first time it is set to Win32. So the code will fail the second time. I need to put the code somewhere earlier in the initialization but don't know yet where. I will submit an updated version soon. Pascal From pascal.bach at siemens.com Thu Sep 4 07:40:40 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Thu, 4 Sep 2014 13:40:40 +0200 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio Message-ID: <1409830840-3288-1-git-send-email-pascal.bach@siemens.com> - Allow setting CMAKE_VS_WINCE_SDK to specify the SDK. - The user is warned if he uses a version different Windows CE different from 8.0 and not CMAKE_PLATFORM_TOOLSET is specified. - Docuentation for WINCE and CMAKE_VS_WINCE_SDK added. --- Help/variable/CMAKE_VS_WINCE_SDK.rst | 13 +++++++ Help/variable/WINCE.rst | 5 +++ Source/cmGlobalVisualStudio10Generator.cxx | 55 ++++++++++++++++++++++++++++ Source/cmGlobalVisualStudio10Generator.h | 7 ++++ Source/cmGlobalVisualStudio11Generator.cxx | 12 ++++++ Source/cmGlobalVisualStudio11Generator.h | 2 + Source/cmGlobalVisualStudio12Generator.cxx | 12 ++++++ Source/cmGlobalVisualStudio12Generator.h | 2 + 8 files changed, 108 insertions(+) create mode 100644 Help/variable/CMAKE_VS_WINCE_SDK.rst create mode 100644 Help/variable/WINCE.rst diff --git a/Help/variable/CMAKE_VS_WINCE_SDK.rst b/Help/variable/CMAKE_VS_WINCE_SDK.rst new file mode 100644 index 0000000..ef39b84 --- /dev/null +++ b/Help/variable/CMAKE_VS_WINCE_SDK.rst @@ -0,0 +1,13 @@ +CMAKE_VS_WINCE_SDK +------------------ + +Windows CE SDK to use together with the Visual Studio 10+ generators. + +If :variable:`CMAKE_SYSTEM_NAME` is set to Windows CE, this variable +allows to specify the SDK name that should be used to build the application. + +The value of this variable should never be modified by project code. +A toolchain file specified by the :variable:`CMAKE_TOOLCHAIN_FILE` +variable may initialize ``CMAKE_VS_WINCE_SDK``. Once a given +build tree has been initialized with a particular value for this +variable, changing the value has undefined behavior. diff --git a/Help/variable/WINCE.rst b/Help/variable/WINCE.rst new file mode 100644 index 0000000..54ff7de --- /dev/null +++ b/Help/variable/WINCE.rst @@ -0,0 +1,5 @@ +WINCE +----- + +True when the :variable:`CMAKE_SYSTEM_NAME` variable is set +to ``WindowsCE``. diff --git a/Source/cmGlobalVisualStudio10Generator.cxx b/Source/cmGlobalVisualStudio10Generator.cxx index 19aa52c..81a9723 100644 --- a/Source/cmGlobalVisualStudio10Generator.cxx +++ b/Source/cmGlobalVisualStudio10Generator.cxx @@ -165,6 +165,14 @@ bool cmGlobalVisualStudio10Generator::InitializeSystem(cmMakefile* mf) return false; } } + else if (this->SystemName == "WindowsCE") + { + this->SystemIsWindowsCE = true; + if (!this->InitializeWindowsCE(mf)) + { + return false; + } + } return true; } @@ -187,6 +195,53 @@ bool cmGlobalVisualStudio10Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio10Generator::InitializeWindowsCE(cmMakefile* mf) +{ + // To preserve the old behaviour just return the DefaultPlatformToolset + // for unknown Windows CE versions, in the worst case the user has to set + // CMAKE_GENERATOR_TOOLSET manually. In that case warn the user. + std::string platformToolset = this->SelectWindowsCEToolset(); + if (!platformToolset.empty()) + { + this->DefaultPlatformToolset = platformToolset; + } + else + { + cmOStringStream e; + e << this->GetName() << " Windows CE version '" << this->SystemVersion + << "' might require CMAKE_GENERATOR_TOOLSET to be set."; + mf->IssueMessage(cmake::WARNING, e.str()); + } + + if (const char* platformName = mf->GetDefinition("CMAKE_VS_WINCE_SDK")) + { + this->PlatformName = platformName; + } + else { + cmOStringStream e; + e << this->GetName() << " for " << this->GetSystemName() << " requires an " + << "SDK. Please set CMAKE_VS_WINCE_SDK to the name of your SDK."; + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); + return false; + } + + return true; +} + +//---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio10Generator::SelectWindowsCEToolset() const +{ + if (this->SystemVersion == "8.0") + { + return "CE800"; + } + else + { + return ""; + } +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio10Generator ::AddVSPlatformToolsetDefinition(cmMakefile* mf) const { diff --git a/Source/cmGlobalVisualStudio10Generator.h b/Source/cmGlobalVisualStudio10Generator.h index 11fa954..9bceb2c 100644 --- a/Source/cmGlobalVisualStudio10Generator.h +++ b/Source/cmGlobalVisualStudio10Generator.h @@ -75,6 +75,10 @@ public: bool TargetsWindowsStore() const { return this->SystemIsWindowsStore; } + /** Return true if building for WindowsCE */ + bool TargetsWindowsCE() const + { return this->SystemIsWindowsCE; } + /** * Where does this version of Visual Studio look for macros for the * current user? Returns the empty string if this version of Visual @@ -106,8 +110,10 @@ protected: virtual bool InitializeSystem(cmMakefile* mf); virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const { return ""; } virtual std::string SelectWindowsStoreToolset() const { return ""; } + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "10.0"; } @@ -119,6 +125,7 @@ protected: std::string SystemVersion; bool SystemIsWindowsPhone; bool SystemIsWindowsStore; + bool SystemIsWindowsCE; bool ExpressEdition; bool UseFolderProperty(); diff --git a/Source/cmGlobalVisualStudio11Generator.cxx b/Source/cmGlobalVisualStudio11Generator.cxx index 39bbdc0..a71c42e 100644 --- a/Source/cmGlobalVisualStudio11Generator.cxx +++ b/Source/cmGlobalVisualStudio11Generator.cxx @@ -159,6 +159,12 @@ bool cmGlobalVisualStudio11Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio11Generator::InitializeWindowsCE(cmMakefile* mf) +{ + return cmGlobalVisualStudio10Generator::InitializeWindowsCE(mf); +} + +//---------------------------------------------------------------------------- std::string cmGlobalVisualStudio11Generator::SelectWindowsPhoneToolset() const { if(this->SystemVersion == "8.0") @@ -179,6 +185,12 @@ std::string cmGlobalVisualStudio11Generator::SelectWindowsStoreToolset() const } //---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio11Generator::SelectWindowsCEToolset() const +{ + return this->cmGlobalVisualStudio10Generator::SelectWindowsCEToolset(); +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio11Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; diff --git a/Source/cmGlobalVisualStudio11Generator.h b/Source/cmGlobalVisualStudio11Generator.h index bbd935c..9dd3271 100644 --- a/Source/cmGlobalVisualStudio11Generator.h +++ b/Source/cmGlobalVisualStudio11Generator.h @@ -36,8 +36,10 @@ public: protected: virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const; virtual std::string SelectWindowsStoreToolset() const; + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "11.0"; } bool UseFolderProperty(); static std::set GetInstalledWindowsCESDKs(); diff --git a/Source/cmGlobalVisualStudio12Generator.cxx b/Source/cmGlobalVisualStudio12Generator.cxx index 29ecfe0..c784cae 100644 --- a/Source/cmGlobalVisualStudio12Generator.cxx +++ b/Source/cmGlobalVisualStudio12Generator.cxx @@ -139,6 +139,12 @@ bool cmGlobalVisualStudio12Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio12Generator::InitializeWindowsCE(cmMakefile* mf) +{ + return cmGlobalVisualStudio11Generator::InitializeWindowsCE(mf); +} + +//---------------------------------------------------------------------------- std::string cmGlobalVisualStudio12Generator::SelectWindowsPhoneToolset() const { if(this->SystemVersion == "8.1") @@ -159,6 +165,12 @@ std::string cmGlobalVisualStudio12Generator::SelectWindowsStoreToolset() const } //---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio12Generator::SelectWindowsCEToolset() const +{ + return this->cmGlobalVisualStudio11Generator::SelectWindowsCEToolset(); +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio12Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; diff --git a/Source/cmGlobalVisualStudio12Generator.h b/Source/cmGlobalVisualStudio12Generator.h index ec85f10..5d8c125 100644 --- a/Source/cmGlobalVisualStudio12Generator.h +++ b/Source/cmGlobalVisualStudio12Generator.h @@ -41,8 +41,10 @@ public: protected: virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const; virtual std::string SelectWindowsStoreToolset() const; + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "12.0"; } private: class Factory; -- 1.7.10.4 From ono at java.pl Thu Sep 4 09:11:41 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 15:11:41 +0200 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup Message-ID: <1409836306-96543-1-git-send-email-ono@java.pl> It makes whole executable process quicker on UNIX, especially for large bundles containing many files, since using find narrows results to only files having executable flags then all further tests follow. --- Modules/BundleUtilities.cmake | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 0046c97..7e2b173 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -378,7 +378,24 @@ endfunction() function(get_bundle_all_executables bundle exes_var) set(exes "") - file(GLOB_RECURSE file_list "${bundle}/*") + if(UNIX) + find_program(find_cmd "find") + mark_as_advanced(find_cmd) + endif() + + # find command is much quicker than checking every file one by one on Unix + # which can take long time for large bundles, and since anyway we expect + # executable to have execute flag set we can narrow the list much quicker. + if(find_cmd) + execute_process(COMMAND "${find_cmd}" "${bundle}" -type f -perm +0111 + OUTPUT_VARIABLE file_list + OUTPUT_STRIP_TRAILING_WHITESPACE + ) + string(REPLACE "\n" ";" file_list ${file_list}) + else() + file(GLOB_RECURSE file_list "${bundle}/*") + endif() + foreach(f ${file_list}) is_file_executable("${f}" is_executable) if(is_executable) -- 1.9.3 (Apple Git-50) From ono at java.pl Thu Sep 4 09:11:42 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 15:11:42 +0200 Subject: [cmake-developers] [PATCH 2/6] Make sure dyld placeholders are prefixes In-Reply-To: <1409836306-96543-1-git-send-email-ono@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> Message-ID: <1409836306-96543-2-git-send-email-ono@java.pl> Mac OS X dyld placeholders should be always prefixes, otherwise this can lead to some undefined behavior. --- Modules/GetPrerequisites.cmake | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 05c2edb..49443e3 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -329,7 +329,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) endif() if(NOT resolved) - if(item MATCHES "@executable_path") + if(item MATCHES "^@executable_path") # # @executable_path references are assumed relative to exepath # @@ -347,7 +347,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) endif() if(NOT resolved) - if(item MATCHES "@loader_path") + if(item MATCHES "^@loader_path") # # @loader_path references are assumed relative to the # PATH of the given "context" (presumably another library) @@ -367,7 +367,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) endif() if(NOT resolved) - if(item MATCHES "@rpath") + if(item MATCHES "^@rpath") # # @rpath references are relative to the paths built into the binaries with -rpath # We handle this case like we do for other Unixes -- 1.9.3 (Apple Git-50) From ono at java.pl Thu Sep 4 09:11:43 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 15:11:43 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <1409836306-96543-1-git-send-email-ono@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> Message-ID: <1409836306-96543-3-git-send-email-ono@java.pl> This is done by gathering LC_RPATH commands for main bundle executable and using it for @rpath lookup in dependent frameworks. To achieve this all utility functions now take path to executable rather than path to its directory. This enabled apps using @rpath to be bundled correctly, which will be necessary for upcoming Qt 5.4 that will use @rpath for all frameworks. --- Modules/BundleUtilities.cmake | 90 +++++++++++++++++++++++++++++------------- Modules/GetPrerequisites.cmake | 47 +++++++++++----------- 2 files changed, 86 insertions(+), 51 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 7e2b173..dece0d9 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -19,6 +19,7 @@ # get_bundle_and_executable # get_bundle_all_executables # get_item_key +# get_item_rpaths # clear_bundle_keys # set_bundle_key_values # get_bundle_keys @@ -123,7 +124,7 @@ # # :: # -# SET_BUNDLE_KEY_VALUES( +# SET_BUNDLE_KEY_VALUES( # ) # # Add a key to the list (if necessary) for the given item. If added, @@ -163,7 +164,7 @@ # # :: # -# FIXUP_BUNDLE_ITEM( ) +# FIXUP_BUNDLE_ITEM( ) # # Get the direct/non-system prerequisites of the resolved embedded item. # For each prerequisite, change the way it is referenced to the value of @@ -285,7 +286,7 @@ function(get_bundle_main_executable bundle result_var) endfunction() -function(get_dotapp_dir exe dotapp_dir_var) +function(get_dotapp_dir executable dotapp_dir_var) set(s "${exe}") if(s MATCHES "/.*\\.app/") @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) endfunction() +function(get_item_rpaths item rpaths_var) + if(APPLE) + find_program(otool_cmd "otool") + mark_as_advanced(otool_cmd) + endif() + + if(otool_cmd) + execute_process( + COMMAND "${otool_cmd}" -l "${item}" + OUTPUT_VARIABLE load_cmds_ov + ) + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") + string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") + string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") + if(load_cmds_ov) + gp_append_unique(${rpaths_var} "${load_cmds_ov}") + endif() + endif() + + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) +endfunction() + + function(get_item_key item key_var) get_filename_component(item_name "${item}" NAME) if(WIN32) @@ -425,12 +449,13 @@ function(clear_bundle_keys keys_var) set(${key}_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_COPYFLAG PARENT_SCOPE) + set(${key}_RPATHS PARENT_SCOPE) endforeach() set(${keys_var} PARENT_SCOPE) endfunction() -function(set_bundle_key_values keys_var context item exepath dirs copyflag) +function(set_bundle_key_values keys_var context item executable dirs copyflag) get_filename_component(item_name "${item}" NAME) get_item_key("${item}" key) @@ -440,10 +465,17 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) list(LENGTH ${keys_var} length_after) if(NOT length_before EQUAL length_after) - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item) + # Always use the exepath of the main bundle executable for @executable_path + # replacements: + # + get_filename_component(exepath "${executable}" PATH) + + gp_resolve_item("${context}" "${item}" "${executable}" "${dirs}" resolved_item) gp_item_default_embedded_path("${item}" default_embedded_path) + get_item_rpaths("${resolved_item}" rpaths) + if(item MATCHES "[^/]+\\.framework/") # For frameworks, construct the name under the embedded path from the # opening "${item_name}.framework/" to the closing "/${item_name}": @@ -479,6 +511,7 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) set(${key}_EMBEDDED_ITEM "${embedded_item}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" PARENT_SCOPE) set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) + set(${key}_RPATHS "${rpaths}" PARENT_SCOPE) else() #message("warning: item key '${key}' already in the list, subsequent references assumed identical to first") endif() @@ -490,11 +523,6 @@ function(get_bundle_keys app libs dirs keys_var) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - # Always use the exepath of the main bundle executable for @executable_path - # replacements: - # - get_filename_component(exepath "${executable}" PATH) - # But do fixups on all executables in the bundle: # get_bundle_all_executables("${bundle}" exes) @@ -505,12 +533,12 @@ function(get_bundle_keys app libs dirs keys_var) # but that do not show up in otool -L output...) # foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -521,14 +549,14 @@ function(get_bundle_keys app libs dirs keys_var) foreach(exe ${exes}) # Add the exe itself to the keys: # - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${executable}" "${dirs}" 0) # Add each prerequisite to the keys: # set(prereqs "") - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${exe}" prereqs 1 1 "${executable}" "${dirs}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -542,6 +570,7 @@ function(get_bundle_keys app libs dirs keys_var) set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) endforeach() endif() endfunction() @@ -612,7 +641,7 @@ function(copy_resolved_framework_into_bundle resolved_item resolved_embedded_ite endfunction() -function(fixup_bundle_item resolved_embedded_item exepath dirs) +function(fixup_bundle_item resolved_embedded_item executable dirs) # This item's key is "ikey": # get_item_key("${resolved_embedded_item}" ikey) @@ -622,7 +651,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) # tree, or in other varied locations around the file system, with our call to # install_name_tool. Make sure that doesn't happen here: # - get_dotapp_dir("${exepath}" exe_dotapp_dir) + get_dotapp_dir("${executable}" exe_dotapp_dir) string(LENGTH "${exe_dotapp_dir}/" exe_dotapp_dir_length) string(LENGTH "${resolved_embedded_item}" resolved_embedded_item_length) set(path_too_short 0) @@ -648,7 +677,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) endif() set(prereqs "") - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}") + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${executable}" "${dirs}") set(changes "") @@ -668,12 +697,20 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) execute_process(COMMAND chmod u+w "${resolved_embedded_item}") endif() + foreach(rpath ${${ikey}_RPATHS}) + set(changes ${changes} -delete_rpath "${rpath}") + endforeach() + + if(${ikey}_EMBEDDED_ITEM) + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") + endif() + # Change this item's id and all of its references in one call # to install_name_tool: # - execute_process(COMMAND install_name_tool - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" - ) + if(changes) + execute_process(COMMAND install_name_tool ${changes} "${resolved_embedded_item}") + endif() endfunction() @@ -685,8 +722,6 @@ function(fixup_bundle app libs dirs) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - get_filename_component(exepath "${executable}" PATH) - message(STATUS "fixup_bundle: preparing...") get_bundle_keys("${app}" "${libs}" "${dirs}" keys) @@ -732,7 +767,7 @@ function(fixup_bundle app libs dirs) math(EXPR i ${i}+1) if(APPLE) message(STATUS "${i}/${n}: fixing up '${${key}_RESOLVED_EMBEDDED_ITEM}'") - fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${exepath}" "${dirs}") + fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${executable}" "${dirs}") else() message(STATUS "${i}/${n}: fix-up not required on this platform '${${key}_RESOLVED_EMBEDDED_ITEM}'") endif() @@ -768,13 +803,12 @@ function(verify_bundle_prerequisites bundle result_var info_var) foreach(f ${file_list}) is_file_executable("${f}" is_executable) if(is_executable) - get_filename_component(exepath "${f}" PATH) math(EXPR count "${count} + 1") message(STATUS "executable file ${count}: ${f}") set(prereqs "") - get_prerequisites("${f}" prereqs 1 1 "${exepath}" "") + get_prerequisites("${f}" prereqs 1 1 "${executable}" "") # On the Mac, # "embedded" and "system" prerequisites are fine... anything else means @@ -788,7 +822,7 @@ function(verify_bundle_prerequisites bundle result_var info_var) foreach(p ${prereqs}) set(p_type "") - gp_file_type("${f}" "${p}" p_type) + gp_file_type("${f}" "${p}" "${main_bundle_exe}" p_type) if(APPLE) if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL "system") diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 49443e3..d655f96 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -41,7 +41,7 @@ # :: # # GET_PREREQUISITES( -# ) +# ) # # Get the list of shared library files required by . The list # in the variable named should be empty on first @@ -53,7 +53,7 @@ # must be 0 or 1 indicating whether to include or # exclude "system" prerequisites. If is set to 1 all # prerequisites will be found recursively, if set to 0 only direct -# prerequisites are listed. is the path to the top level +# prerequisites are listed. is the path to the top level # executable used for @executable_path replacment on the Mac. is # a list of paths where libraries might be found: these paths are # searched first when a target without any path info is given. Then @@ -113,7 +113,7 @@ # # :: # -# GP_RESOLVE_ITEM( ) +# GP_RESOLVE_ITEM( ) # # Resolve an item into an existing full path file. # @@ -122,13 +122,13 @@ # # :: # -# GP_RESOLVED_FILE_TYPE( ) +# GP_RESOLVED_FILE_TYPE( ) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named # . # -# Use and if necessary to resolve non-absolute +# Use and if necessary to resolve non-absolute # values -- but only for non-embedded items. # # Possible types are: @@ -318,10 +318,12 @@ function(gp_item_default_embedded_path item default_embedded_path_var) endfunction() -function(gp_resolve_item context item exepath dirs resolved_item_var) +function(gp_resolve_item context item executable dirs resolved_item_var) set(resolved 0) set(resolved_item "${item}") + get_filename_component(exepath "${executable}" PATH) + # Is it already resolved? # if(IS_ABSOLUTE "${resolved_item}" AND EXISTS "${resolved_item}") @@ -331,7 +333,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) if(NOT resolved) if(item MATCHES "^@executable_path") # - # @executable_path references are assumed relative to exepath + # @executable_path references are assumed relative to executable # string(REPLACE "@executable_path" "${exepath}" ri "${item}") get_filename_component(ri "${ri}" ABSOLUTE) @@ -374,10 +376,11 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) # string(REPLACE "@rpath/" "" norpath_item "${item}") + get_item_key("${executable}" key) set(ri "ri-NOTFOUND") - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) + find_file(ri "${norpath_item}" ${dirs} ${${key}_RPATHS} NO_DEFAULT_PATH) if(ri) - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") + #message(STATUS "info: 'find_file' in exepath/rpaths/dirs (${ri})") set(resolved 1) set(resolved_item "${ri}") set(ri "ri-NOTFOUND") @@ -436,7 +439,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) # by whatever logic they choose: # if(COMMAND gp_resolve_item_override) - gp_resolve_item_override("${context}" "${item}" "${exepath}" "${dirs}" resolved_item resolved) + gp_resolve_item_override("${context}" "${item}" "${executable}" "${dirs}" resolved_item resolved) endif() if(NOT resolved) @@ -459,7 +462,7 @@ warning: cannot resolve item '${item}' # # context='${context}' # item='${item}' -# exepath='${exepath}' +# executable='${executable}' # dirs='${dirs}' # resolved_item_var='${resolved_item_var}' #****************************************************************************** @@ -470,7 +473,7 @@ warning: cannot resolve item '${item}' endfunction() -function(gp_resolved_file_type original_file file exepath dirs type_var) +function(gp_resolved_file_type original_file file executable dirs type_var) #message(STATUS "**") if(NOT IS_ABSOLUTE "${original_file}") @@ -489,7 +492,7 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) if(NOT is_embedded) if(NOT IS_ABSOLUTE "${file}") - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file) + gp_resolve_item("${original_file}" "${file}" "${executable}" "${dirs}" resolved_file) endif() string(TOLOWER "${original_file}" original_lower) @@ -595,21 +598,19 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) endfunction() -function(gp_file_type original_file file type_var) +function(gp_file_type original_file file executable type_var) if(NOT IS_ABSOLUTE "${original_file}") message(STATUS "warning: gp_file_type expects absolute full path for first arg original_file") endif() - get_filename_component(exepath "${original_file}" PATH) - set(type "") - gp_resolved_file_type("${original_file}" "${file}" "${exepath}" "" type) + gp_resolved_file_type("${original_file}" "${file}" "${executable}" "" type) set(${type_var} "${type}" PARENT_SCOPE) endfunction() -function(get_prerequisites target prerequisites_var exclude_system recurse exepath dirs) +function(get_prerequisites target prerequisites_var exclude_system recurse exe dirs) set(verbose 0) set(eol_char "E") @@ -834,7 +835,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(add_item AND ${exclude_system}) set(type "") - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type) + gp_resolved_file_type("${target}" "${item}" "${executable}" "${dirs}" type) if("${type}" STREQUAL "system") set(add_item 0) @@ -855,7 +856,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa # that the analysis tools can simply accept it as input. # if(NOT list_length_before_append EQUAL list_length_after_append) - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${target}" "${item}" "${executable}" "${dirs}" resolved_item) set(unseen_prereqs ${unseen_prereqs} "${resolved_item}") endif() endif() @@ -874,7 +875,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(${recurse}) set(more_inputs ${unseen_prereqs}) foreach(input ${more_inputs}) - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}") + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${executable}" "${dirs}") endforeach() endif() @@ -911,7 +912,7 @@ function(list_prerequisites target) get_filename_component(exepath "${target}" PATH) set(prereqs "") - get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${exepath}" "") + get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${target}" "") if(print_target) message(STATUS "File '${target}' depends on:") @@ -925,7 +926,7 @@ function(list_prerequisites target) endif() if(print_prerequisite_type) - gp_file_type("${target}" "${d}" type) + gp_file_type("${target}" "${d}" "" type) set(type_str " (${type})") endif() -- 1.9.3 (Apple Git-50) From ono at java.pl Thu Sep 4 09:11:44 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 15:11:44 +0200 Subject: [cmake-developers] [PATCH 4/6] Process executables first when scanning bundle In-Reply-To: <1409836306-96543-1-git-send-email-ono@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> Message-ID: <1409836306-96543-4-git-send-email-ono@java.pl> This makes rpaths populated (if any), so libraries containing @rpath will be resolved properly. --- Modules/BundleUtilities.cmake | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index dece0d9..5823813 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -527,21 +527,6 @@ function(get_bundle_keys app libs dirs keys_var) # get_bundle_all_executables("${bundle}" exes) - # For each extra lib, accumulate a key as well and then also accumulate - # any of its prerequisites. (Extra libs are typically dynamically loaded - # plugins: libraries that are prerequisites for full runtime functionality - # but that do not show up in otool -L output...) - # - foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) - - set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") - foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) - endforeach() - endforeach() - # For each executable found in the bundle, accumulate keys as we go. # The list of keys should be complete when all prerequisites of all # binaries in the bundle have been analyzed. @@ -560,6 +545,21 @@ function(get_bundle_keys app libs dirs keys_var) endforeach() endforeach() + # For each extra lib, accumulate a key as well and then also accumulate + # any of its prerequisites. (Extra libs are typically dynamically loaded + # plugins: libraries that are prerequisites for full runtime functionality + # but that do not show up in otool -L output...) + # + foreach(lib ${libs}) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) + + set(prereqs "") + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") + foreach(pr ${prereqs}) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) + endforeach() + endforeach() + # Propagate values to caller's scope: # set(${keys_var} ${${keys_var}} PARENT_SCOPE) -- 1.9.3 (Apple Git-50) From ono at java.pl Thu Sep 4 09:11:46 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 15:11:46 +0200 Subject: [cmake-developers] [PATCH 6/6] Make sure we bundle Qt5 Cocoa platform plugin In-Reply-To: <1409836306-96543-1-git-send-email-ono@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> Message-ID: <1409836306-96543-6-git-send-email-ono@java.pl> Otherwise CMake.app bundle will not run when using Qt5. --- Source/QtDialog/CMakeLists.txt | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt index 8da88c1..03c2fb4 100644 --- a/Source/QtDialog/CMakeLists.txt +++ b/Source/QtDialog/CMakeLists.txt @@ -35,6 +35,32 @@ if (Qt5Widgets_FOUND) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${Qt5Widgets_EXECUTABLE_COMPILE_FLAGS}") + # We need to install Cocoa platform plugin and add qt.conf for Qt5 on Mac. + # FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly + # Qt5 Mac support is missing there. + if(APPLE) + macro(install_qt5_plugin _qt_plugin_name _qt_plugins_var) + get_target_property(_qt_plugin_path "${_qt_plugin_name}" LOCATION) + if(EXISTS "${_qt_plugin_path}") + get_filename_component(_qt_plugin_file "${_qt_plugin_path}" NAME) + get_filename_component(_qt_plugin_type "${_qt_plugin_path}" PATH) + get_filename_component(_qt_plugin_type "${_qt_plugin_type}" NAME) + set(_qt_plugin_dest "${CMAKE_INSTALL_PREFIX}/PlugIns/${_qt_plugin_type}") + install(FILES "${_qt_plugin_path}" + DESTINATION "${_qt_plugin_dest}") + set(${_qt_plugins_var} + "${${_qt_plugins_var}};${_qt_plugin_dest}/${_qt_plugin_file}") + else() + message(FATAL_ERROR "QT plugin ${_qt_plugin_name} not found") + endif() + endmacro() + install_qt5_plugin("Qt5::QCocoaIntegrationPlugin" QT_PLUGINS) + file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/qt.conf" + "[Paths]\nPlugins = PlugIns\n") + install(FILES "${CMAKE_CURRENT_BINARY_DIR}/qt.conf" + DESTINATION "${CMAKE_INSTALL_PREFIX}/Resources") + endif() + if(WIN32 AND TARGET Qt5::Core) get_property(_Qt5_Core_LOCATION TARGET Qt5::Core PROPERTY LOCATION) get_filename_component(Qt_BIN_DIR "${_Qt5_Core_LOCATION}" PATH) @@ -168,7 +194,7 @@ if(APPLE OR WIN32) install(CODE " include(\"${CMake_SOURCE_DIR}/Modules/BundleUtilities.cmake\") set(BU_CHMOD_BUNDLE_ITEMS ON) - fixup_bundle(\"${fixup_exe}\" \"\" \"${QT_LIBRARY_DIR};${QT_BINARY_DIR}\") + fixup_bundle(\"${fixup_exe}\" \"${QT_PLUGINS}\" \"${QT_LIBRARY_DIR};${QT_BINARY_DIR}\") ") endif() -- 1.9.3 (Apple Git-50) From ono at java.pl Thu Sep 4 09:11:45 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 15:11:45 +0200 Subject: [cmake-developers] [PATCH 5/6] Codesign needs framework's Contents/Info.plist In-Reply-To: <1409836306-96543-1-git-send-email-ono@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> Message-ID: <1409836306-96543-5-git-send-email-ono@java.pl> Therefore we need to bundle it (if present) too when fixing Mac OS X app bundle. --- Modules/BundleUtilities.cmake | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 5823813..5759e24 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -632,6 +632,14 @@ function(copy_resolved_framework_into_bundle resolved_item resolved_embedded_ite #message(STATUS "copying COMMAND ${CMAKE_COMMAND} -E copy_directory '${resolved_resources}' '${resolved_embedded_resources}'") execute_process(COMMAND ${CMAKE_COMMAND} -E copy_directory "${resolved_resources}" "${resolved_embedded_resources}") endif() + + # And Info.plist, if it exists: + string(REGEX REPLACE "^(.*)/[^/]+/[^/]+/[^/]+$" "\\1/Contents/Info.plist" resolved_info_plist "${resolved_item}") + string(REGEX REPLACE "^(.*)/[^/]+/[^/]+/[^/]+$" "\\1/Contents/Info.plist" resolved_embedded_info_plist "${resolved_embedded_item}") + if(EXISTS "${resolved_info_plist}") + #message(STATUS "copying COMMAND ${CMAKE_COMMAND} -E copy_directory '${resolved_info_plist}' '${resolved_embedded_info_plist}'") + execute_process(COMMAND ${CMAKE_COMMAND} -E copy "${resolved_info_plist}" "${resolved_embedded_info_plist}") + endif() endif() if(UNIX AND NOT APPLE) file(RPATH_REMOVE FILE "${resolved_embedded_item}") -- 1.9.3 (Apple Git-50) From brad.king at kitware.com Thu Sep 4 09:19:34 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 09:19:34 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <540866E6.7050603@kitware.com> On 09/04/2014 06:42 AM, Bach, Pascal wrote: > This won't' work as the code gets called multiple times Right, it gets called inside try_compile projects too. Actually the SDK information will have to be propagated into those too. That means it needs to go in files like CMakeSystem.cmake or CMakeCCompiler.cmake that are configured in the build tree, or be explicitly propagated by cmMakefile::TryCompile like the GeneratorToolset is. I'd like to understand the differences among WinCE SDKs (I've never done WinCE development). What are some example names? What does each mean? What processor does each one target? Thanks, -Brad From brad.king at kitware.com Thu Sep 4 09:25:21 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 09:25:21 -0400 Subject: [cmake-developers] Changing the regex used for INFO strings In-Reply-To: References: Message-ID: <54086841.7030909@kitware.com> On 09/03/2014 05:20 PM, Chuck Atkins wrote: > stage/use-consistent-regex-for-info-strings The proposed regex is now: INFO:[A-Za-z0-9_]+\\[[^]]*\\] It looks good to me. Thanks, -Brad From pascal.bach at siemens.com Thu Sep 4 09:31:52 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Thu, 4 Sep 2014 13:31:52 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <540866E6.7050603@kitware.com> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> > > This won't' work as the code gets called multiple times > > Right, it gets called inside try_compile projects too. Actually > the SDK information will have to be propagated into those too. > That means it needs to go in files like CMakeSystem.cmake or > CMakeCCompiler.cmake that are configured in the build tree, > or be explicitly propagated by cmMakefile::TryCompile like the > GeneratorToolset is. With the current implementation I sent this seems to work and the SDK ends up in The generated vxproj files for try compile. > > I'd like to understand the differences among WinCE SDKs (I've > never done WinCE development). What are some example names? > What does each mean? What processor does each one target? I'm also quite new to the whole Windows CE development but I try to explain what I figured out until now. An example for a Windows CE 2013 (aka 8.0) SDK is the one for Ti AM335x from Adeneo [1]. Once installed it can be found under: C:\Program Files (x86)\Windows CE Tools\SDKs\SDK_AM335X_SK_WEC2013 Where SDK_AM335X_SK_WEC2013 is the SDK name. The content of SDK_AM335X_SK_WEC2013\sdk subfolder is similar in structure to a folder under: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC I don't know the exact details but it looks like it contains a complete VC compiler targeted at the specific board. If I create a Project using this SDK in visual studio the following XML snippet ends up in the resulting .vxproj file: Debug SDK_AM335X_SK_WEC2013 It seems like this is the way Windows knows what compiler to use based on the entries in: HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows CE Tools\\SDKs Where all the installed Windows CE SDKs are listed with the default key pointing to their path on the filesystem. That's all I know till now ;) Pascal [1] http://www.adeneo-embedded.com/Products/Board-Support-Packages/Texas-Instruments-Sitara From brad.king at kitware.com Thu Sep 4 10:21:07 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 10:21:07 -0400 Subject: [cmake-developers] OS X packaging updates (was: [PATCH 1/6] Use find on UNIX for fast executable lookup) In-Reply-To: <1409836306-96543-1-git-send-email-ono@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> Message-ID: <54087553.2020104@kitware.com> Hi Adam, Thanks. I've applied the series and merged to 'next' for testing: BundleUtilities: Use 'find' on UNIX for fast executable lookup http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=634b4d5a GetPrerequisites: Make sure dyld placeholders are prefixes http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4f577985 BundleUtilities: Resolve and replace @rpath placeholders http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=591380da BundleUtilities: Process executables first when scanning bundle http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=32a38bbc BundleUtilities: Codesign needs framework's Contents/Info.plist http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5361697b cmake-gui: Make sure we bundle Qt5 Cocoa platform plugin http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=da78e01c For the last change, might something like that be needed on Windows too? Thanks, -Brad From nilsgladitz at gmail.com Thu Sep 4 10:25:21 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 04 Sep 2014 16:25:21 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion Message-ID: <54087651.8010909@gmail.com> This keeps coming up and there probably have been many discussions on how this might be "fixed" as well. I am wondering if we could provide an alias for the "if" command (e.g. "safe_if") that would inherit cmIfCommand but would reimplement GetVariableOrString() without the variable lookup. This would leave if() behavior intact for compatibility but would provide an alternative with less surprising semantics. I would keep else() elseif() endif() without additional aliases and leave the behavior to the initial if variant. Nils From dlrdave at aol.com Thu Sep 4 10:32:54 2014 From: dlrdave at aol.com (David Cole) Date: Thu, 4 Sep 2014 10:32:54 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion Message-ID: <8D196643FCF71AA-15CC-1366F@webmail-m269.sysops.aol.com> Another approach might be to add STRING_EQUAL and STRING_MATCHES (or similarly unambiguous names) operators that do not do the variable lookup. The documentation would start with: if( STRING_EQUAL ) if( STRING_MATCHES ) ...i.e., not mentioning anywhere for these operators. D From brad.king at kitware.com Thu Sep 4 10:40:56 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 10:40:56 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <54087651.8010909@gmail.com> References: <54087651.8010909@gmail.com> Message-ID: <540879F8.5050200@kitware.com> On 09/04/2014 10:25 AM, Nils Gladitz wrote: > This keeps coming up and there probably have been many discussions on > how this might be "fixed" as well. As I have explained every other time it has come up there is exactly one way to fix it: a policy that makes expansion happen only for unquoted arguments. Someone just has to do it. > I am wondering if we could provide an alias for the "if" command (e.g. > "safe_if") that would inherit cmIfCommand but would reimplement > GetVariableOrString() without the variable lookup. > > This would leave if() behavior intact for compatibility but would > provide an alternative with less surprising semantics. I think a new command would ("if_noexpand") would make the "correct" code less readable than the "incorrect" code. Also the implicit-bool conversion of variables is more readable IMO; consider if(${FOO_FOUND}) versus if(FOO_FOUND) On 09/04/2014 10:32 AM, David Cole via cmake-developers wrote: > Another approach might be to add STRING_EQUAL and STRING_MATCHES (or > similarly unambiguous names) operators that do not do the variable > lookup. This is a reasonable proposal but the difference to STREQUAL and MATCHES is quite subtle. Also adding more operators this late in the game is more likely to collide with variable names people already use. -Brad From nilsgladitz at gmail.com Thu Sep 4 10:51:03 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 04 Sep 2014 16:51:03 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <540879F8.5050200@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> Message-ID: <54087C57.6060500@gmail.com> On 09/04/2014 04:40 PM, Brad King wrote: > On 09/04/2014 10:25 AM, Nils Gladitz wrote: > I think a new command would ("if_noexpand") would make the "correct" > code less readable than the "incorrect" code. Also the implicit-bool > conversion of variables is more readable IMO; consider > > if(${FOO_FOUND}) > > versus > > if(FOO_FOUND) I am rather used to "if()" as well but safe_if()/if_noexpand() might still be more readable than the workarounds that people are using now to get something close to the expected behavior with regular if() [1]. You would also still be able to use regular if() in cases where you prefer the aesthetics of implicit-bool. Nils [1] http://www.cmake.org/pipermail/cmake/2014-September/058476.html From brad.king at kitware.com Thu Sep 4 11:13:59 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 11:13:59 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <54087C57.6060500@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> Message-ID: <540881B7.9090908@kitware.com> On 09/04/2014 10:51 AM, Nils Gladitz wrote: > I am rather used to "if()" as well but safe_if()/if_noexpand() might > still be more readable than the workarounds that people are using now to > get something close to the expected behavior with regular if() [1]. If "if()" is never fixed people will still run into that and be confused. Adding another command will leave people with the decision about which one to use in what cases and be even more confused. As I have explained every other time it has come up there is exactly one way to fix it: a policy that makes expansion happen only for unquoted arguments. Someone just has to do it. -Brad From eike at sf-mail.de Thu Sep 4 11:15:55 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Thu, 04 Sep 2014 17:15:55 +0200 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup In-Reply-To: <1409836306-96543-1-git-send-email-ono@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> Message-ID: <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> Am 04.09.2014 15:11, schrieb Adam Strzelecki: > It makes whole executable process quicker on UNIX, especially for large > bundles > containing many files, since using find narrows results to only files > having > executable flags then all further tests follow. > --- > Modules/BundleUtilities.cmake | 19 ++++++++++++++++++- > 1 file changed, 18 insertions(+), 1 deletion(-) > > diff --git a/Modules/BundleUtilities.cmake > b/Modules/BundleUtilities.cmake > index 0046c97..7e2b173 100644 > --- a/Modules/BundleUtilities.cmake > +++ b/Modules/BundleUtilities.cmake > @@ -378,7 +378,24 @@ endfunction() > function(get_bundle_all_executables bundle exes_var) > set(exes "") > > - file(GLOB_RECURSE file_list "${bundle}/*") > + if(UNIX) > + find_program(find_cmd "find") > + mark_as_advanced(find_cmd) > + endif() > + > + # find command is much quicker than checking every file one by one > on Unix > + # which can take long time for large bundles, and since anyway we > expect > + # executable to have execute flag set we can narrow the list much > quicker. > + if(find_cmd) > + execute_process(COMMAND "${find_cmd}" "${bundle}" -type f -perm > +0111 > + OUTPUT_VARIABLE file_list > + OUTPUT_STRIP_TRAILING_WHITESPACE > + ) > + string(REPLACE "\n" ";" file_list ${file_list}) > + else() > + file(GLOB_RECURSE file_list "${bundle}/*") > + endif() > + > foreach(f ${file_list}) > is_file_executable("${f}" is_executable) > if(is_executable) > -- I wonder if the "right" solution would instead be to add some additional flags to GLOB/GLOB_RECURSE where one could e.g. specify that the file is executable, or is a directory. Looking at GetPrerequisites.cmake, FindDoxygen.cmake, and CMakeDetermineCompilerId.cmake this could be a good idea for other places, too. Eike From brad.king at kitware.com Thu Sep 4 11:24:43 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 11:24:43 -0400 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup In-Reply-To: <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> References: <1409836306-96543-1-git-send-email-ono@java.pl> <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> Message-ID: <5408843B.3000704@kitware.com> On 09/04/2014 11:15 AM, Rolf Eike Beer wrote: > I wonder if the "right" solution would instead be to add some additional > flags to GLOB/GLOB_RECURSE where one could e.g. specify that the file is > executable, or is a directory. That would be useful functionality regardless of this application. -Brad From nilsgladitz at gmail.com Thu Sep 4 11:41:23 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 04 Sep 2014 17:41:23 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <540881B7.9090908@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> Message-ID: <54088823.3000309@gmail.com> On 09/04/2014 05:13 PM, Brad King wrote: > As I have explained every other time it has come up there is exactly > one way to fix it: a policy that makes expansion happen only for > unquoted arguments. Someone just has to do it. > The fact that this behaviour has persisted this long and that no one has volunteered to fix it is a bit intimidating. How large scale would the required changes be? I assume the fact that arguments were quoted would have to be preserved and the implementation of all existing commands touched so that they can actually make use of that information (even if only if() would currently make use of it). Are there any major pitfalls to look out for? Nils From brad.king at kitware.com Thu Sep 4 11:53:51 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 11:53:51 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <54088823.3000309@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> Message-ID: <54088B0F.7030405@kitware.com> On 09/04/2014 11:41 AM, Nils Gladitz wrote: > I assume the fact that arguments were quoted would have to be preserved > and the implementation of all existing commands touched so that they can > actually make use of that information (even if only if() would currently > make use of it). Most commands just implement InitialPass, which gets the expanded arguments. Some implement InvokeInitialPass which gets the args before expansion. The cmIfCommand does this already, and its call to cmMakefile::ExpandArguments could be updated to request the additional information. Other commands should not need to be modified. The cmMakefile::ExpandArguments method's output will have to provide the information. I'm not sure whether all call sites need it or not, but it could simply be implemented as a second argument of type "vector* = 0" to be populated with the same number of entries as the original argument. Or, a second signature of vector could be created to pair each output argument string with its delimiter type. Then cmIfCommand could use that internally. -Brad From nilsgladitz at gmail.com Thu Sep 4 11:58:08 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 04 Sep 2014 17:58:08 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <54088B0F.7030405@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> Message-ID: <54088C10.50601@gmail.com> On 09/04/2014 05:53 PM, Brad King wrote: > Most commands just implement InitialPass, which gets the expanded > arguments. Some implement InvokeInitialPass which gets the args > before expansion. The cmIfCommand does this already, and its > call to cmMakefile::ExpandArguments could be updated to request > the additional information. Other commands should not need to > be modified. > > The cmMakefile::ExpandArguments method's output will have to provide > the information. I'm not sure whether all call sites need it or not, > but it could simply be implemented as a second argument of type > "vector* = 0" to be populated with > the same number of entries as the original argument. Or, a second > signature of vector could be created to pair each output > argument string with its delimiter type. Then cmIfCommand could use > that internally. Thanks, that actually sounds doable. I'll give it a try. Nils From brad.king at kitware.com Thu Sep 4 12:03:36 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 12:03:36 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <54088D58.70408@kitware.com> On 09/04/2014 09:31 AM, Bach, Pascal wrote: > With the current implementation I sent this seems to work and the SDK ends up in > The generated vxproj files for try compile. I don't see anything in the patch that could do that. CMakeDetermineCompilerId generates a test .vcxproj file that gets the value from CMAKE_VS_PLATFORM_NAME. That one is in the CompilerId directory. Is that the one you checked? It is not from a try_compile. -Brad From ono at java.pl Thu Sep 4 12:43:57 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 18:43:57 +0200 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup In-Reply-To: <5408843B.3000704@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> <5408843B.3000704@kitware.com> Message-ID: <5D044E05-087E-4DAE-8234-C562AD7723A6@java.pl> > On 09/04/2014 11:15 AM, Rolf Eike Beer wrote: >> I wonder if the "right" solution would instead be to add some additional >> flags to GLOB/GLOB_RECURSE where one could e.g. specify that the file is >> executable, or is a directory. > > That would be useful functionality regardless of this application. I was thinking about that. And yes it would be useful. Generally specifying UNIX mask for present/missing bits would be useful. Yet this requires changes in C++ code that's why I used "find" instead. --Adam From ono at java.pl Thu Sep 4 12:45:42 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 18:45:42 +0200 Subject: [cmake-developers] OS X packaging updates (was: [PATCH 1/6] Use find on UNIX for fast executable lookup) In-Reply-To: <54087553.2020104@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> Message-ID: > Thanks. I've applied the series and merged to 'next' for testing: Thanks! > For the last change, might something like that be needed on > Windows too? Yes, this is very likely. I can investigate that how it looks for Windows apps. --Adam From brad.king at kitware.com Thu Sep 4 12:49:01 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 12:49:01 -0400 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup In-Reply-To: <5D044E05-087E-4DAE-8234-C562AD7723A6@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> <5408843B.3000704@kitware.com> <5D044E05-087E-4DAE-8234-C562AD7723A6@java.pl> Message-ID: <540897FD.6000207@kitware.com> On 09/04/2014 12:43 PM, Adam Strzelecki wrote: > Generally specifying UNIX mask for present/missing bits Rather than trying to do this with file(GLOB), perhaps we should consider a file(FIND) command for this purpose. It could have more options, including pattern matching, and eventually supersede file(GLOB) with a better signature. > Yet this requires changes in C++ code that's why I used "find" instead. That's fine. If someone adds the functionality later then this use case can be ported to it. -Brad From bill.hoffman at kitware.com Thu Sep 4 13:26:30 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 04 Sep 2014 13:26:30 -0400 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup In-Reply-To: <540897FD.6000207@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> <5408843B.3000704@kitware.com> <5D044E05-087E-4DAE-8234-C562AD7723A6@java.pl> <540897FD.6000207@kitware.com> Message-ID: <5408A0C6.3080205@kitware.com> On 9/4/2014 12:49 PM, Brad King wrote: > On 09/04/2014 12:43 PM, Adam Strzelecki wrote: >> Generally specifying UNIX mask for present/missing bits > > Rather than trying to do this with file(GLOB), perhaps we should > consider a file(FIND) command for this purpose. It could have > more options, including pattern matching, and eventually > supersede file(GLOB) with a better signature. > >> Yet this requires changes in C++ code that's why I used "find" instead. > > That's fine. If someone adds the functionality later then this > use case can be ported to it. > > -Brad > I would be concerned with the portability of the arguments to find. How much faster is this? How hard would it be to change the c++? I have not looked into this myself at all, but the use of an external program raises some red flags for me. -Bill From ono at java.pl Thu Sep 4 13:43:16 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 19:43:16 +0200 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup In-Reply-To: <5408A0C6.3080205@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> <5408843B.3000704@kitware.com> <5D044E05-087E-4DAE-8234-C562AD7723A6@java.pl> <540897FD.6000207@kitware.com> <5408A0C6.3080205@kitware.com> Message-ID: <7D383996-160E-4E34-88BE-A51E60385A5B@java.pl> > I would be concerned with the portability of the arguments to find. find DIR -perm +FLAGS is part of POSIX/SUS http://pubs.opengroup.org/onlinepubs/007904875/utilities/find.html I guess it exists on systems dated 199x. > How much faster is this? With CMake.app build, about 50x. Really going through all files in the bundle including html docs, cmake scripts takes almost a minute. > How hard would it be to change the c++? I guess it wouldn't be hard, but we need to agree on naming. > I have not looked into this myself at all, but the use of an external program raises some red flags for me. First of all, it looks if "find" exists on system, otherwise it falls back to old (slow) behavior. So "find" is optional dependency. --Adam From bill.hoffman at kitware.com Thu Sep 4 14:36:53 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 04 Sep 2014 14:36:53 -0400 Subject: [cmake-developers] [PATCH 1/6] Use find on UNIX for fast executable lookup In-Reply-To: <7D383996-160E-4E34-88BE-A51E60385A5B@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> <22cafed9dad32784ce4f01b9bf2032c3@sf-mail.de> <5408843B.3000704@kitware.com> <5D044E05-087E-4DAE-8234-C562AD7723A6@java.pl> <540897FD.6000207@kitware.com> <5408A0C6.3080205@kitware.com> <7D383996-160E-4E34-88BE-A51E60385A5B@java.pl> Message-ID: <5408B145.6040402@kitware.com> On 9/4/2014 1:43 PM, Adam Strzelecki wrote: > First of all, it looks if "find" exists on system, otherwise it falls back to old (slow) behavior. So "find" is optional dependency. My main concern is that it finds a "find" that does not work as you expect. Also, if it were done in C++ it would automatically benefit all platforms not just the ones that have find. -Bill From brad.king at kitware.com Thu Sep 4 14:42:00 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 04 Sep 2014 14:42:00 -0400 Subject: [cmake-developers] OS X packaging updates In-Reply-To: References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> Message-ID: <5408B278.2070400@kitware.com> On 09/04/2014 12:45 PM, Adam Strzelecki wrote: >> Thanks. I've applied the series and merged to 'next' for testing: > > Thanks! I had to revert the topic because it fails the BundleUtilities test on Linux and Windows on our continuous builds: http://open.cdash.org/testDetails.php?test=278873429&build=3476297 http://open.cdash.org/testDetails.php?test=278879098&build=3476366 Please run the CMake test: ctest -C Debug -R BundleUtilities -V locally on these platforms and revise accordingly. Thanks, -Brad From mantis at public.kitware.com Thu Sep 4 14:46:09 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 4 Sep 2014 14:46:09 -0400 Subject: [cmake-developers] [CMake 0015129]: My macros are written into codeblocks project file but they can'be shown in codebloks IDE Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15129 ====================================================================== Reported By: yaoyansi Assigned To: ====================================================================== Project: CMake Issue ID: 15129 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-04 14:46 EDT Last Modified: 2014-09-04 14:46 EDT ====================================================================== Summary: My macros are written into codeblocks project file but they can'be shown in codebloks IDE Description: CodeBlocks doesn't privide binary packages for CentOS 7 x64 now. But you can get the pre-build package from this page:http://rpm.jenslody.de/, and here is my installation guide: http://www.cnblogs.com/yaoyansi/p/3946600.html I defined some macro: REQUIRE_IOSTREAM _BOOL LINUX _LINUX LINUX_6 These macros are written into the codeblocks project file. But when I open the project file with codeblocks, and open the project build option window, I can't see these macros at all. In fact, I also defined some include directories and link directories, but these directories disappeared in project build option window either. Steps to Reproduce: My cmake files and the generated codeblocks project file is attached. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-04 14:46 yaoyansi New Issue 2014-09-04 14:46 yaoyansi File Added: my_cmake.zip ====================================================================== From ono at java.pl Thu Sep 4 15:01:17 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 4 Sep 2014 21:01:17 +0200 Subject: [cmake-developers] OS X packaging updates In-Reply-To: <5408B278.2070400@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> <5408B278.2070400@kitware.com> Message-ID: <952D2C19-AD78-4E46-BAE0-B2F0F4DF7C2E@java.pl> > Please run the CMake test: > ctest -C Debug -R BundleUtilities -V > locally on these platforms and revise accordingly. Okay, will do tommorow. Thanks for follow up. --Adam From mantis at public.kitware.com Fri Sep 5 02:38:02 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 5 Sep 2014 02:38:02 -0400 Subject: [cmake-developers] [CMake 0015130]: support for generator expressions in OUTPUT_DIRECTORY Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15130 ====================================================================== Reported By: tim blechmann Assigned To: ====================================================================== Project: CMake Issue ID: 15130 Category: CMake Reproducibility: N/A Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-05 02:38 EDT Last Modified: 2014-09-05 02:38 EDT ====================================================================== Summary: support for generator expressions in OUTPUT_DIRECTORY Description: atm generator expressions in *_OUTPUT_DIRECTORY properties are not resolved. it would be great if this could be implemented. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-05 02:38 tim blechmann New Issue ====================================================================== From ono at java.pl Fri Sep 5 07:50:41 2014 From: ono at java.pl (Adam Strzelecki) Date: Fri, 5 Sep 2014 13:50:41 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <952D2C19-AD78-4E46-BAE0-B2F0F4DF7C2E@java.pl> References: <952D2C19-AD78-4E46-BAE0-B2F0F4DF7C2E@java.pl> Message-ID: <1409917844-28297-3-git-send-email-ono@java.pl> This is done by gathering LC_RPATH commands for main bundle executable and using it for @rpath lookup in dependent frameworks. To achieve this all utility functions now take path to executable rather than path to its directory. This enabled apps using @rpath to be bundled correctly, which will be necessary for upcoming Qt 5.4 that will use @rpath for all frameworks. --- Modules/BundleUtilities.cmake | 169 ++++++++++++++++++++++++----------------- Modules/GetPrerequisites.cmake | 48 ++++++------ 2 files changed, 124 insertions(+), 93 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 7e2b173..9733bc9 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -19,6 +19,7 @@ # get_bundle_and_executable # get_bundle_all_executables # get_item_key +# get_item_rpaths # clear_bundle_keys # set_bundle_key_values # get_bundle_keys @@ -75,7 +76,7 @@ # # :: # -# GET_DOTAPP_DIR( ) +# GET_DOTAPP_DIR( ) # # Returns the nearest parent dir whose name ends with ".app" given the # full path to an executable. If there is no such parent dir, then @@ -123,7 +124,7 @@ # # :: # -# SET_BUNDLE_KEY_VALUES( +# SET_BUNDLE_KEY_VALUES( # ) # # Add a key to the list (if necessary) for the given item. If added, @@ -163,7 +164,7 @@ # # :: # -# FIXUP_BUNDLE_ITEM( ) +# FIXUP_BUNDLE_ITEM( ) # # Get the direct/non-system prerequisites of the resolved embedded item. # For each prerequisite, change the way it is referenced to the value of @@ -189,11 +190,11 @@ # # :: # -# VERIFY_BUNDLE_PREREQUISITES( ) +# VERIFY_BUNDLE_PREREQUISITES( ) # # Verifies that the sum of all prerequisites of all files inside the -# bundle are contained within the bundle or are "system" libraries, -# presumed to exist everywhere. +# bundle with given main executable are contained within the bundle or are +# "system" libraries, presumed to exist everywhere. # # :: # @@ -285,8 +286,8 @@ function(get_bundle_main_executable bundle result_var) endfunction() -function(get_dotapp_dir exe dotapp_dir_var) - set(s "${exe}") +function(get_dotapp_dir executable dotapp_dir_var) + set(s "${executable}") if(s MATCHES "/.*\\.app/") # If there is a ".app" parent directory, @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) endfunction() +function(get_item_rpaths item rpaths_var) + if(APPLE) + find_program(otool_cmd "otool") + mark_as_advanced(otool_cmd) + endif() + + if(otool_cmd) + execute_process( + COMMAND "${otool_cmd}" -l "${item}" + OUTPUT_VARIABLE load_cmds_ov + ) + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") + string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") + string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") + if(load_cmds_ov) + gp_append_unique(${rpaths_var} "${load_cmds_ov}") + endif() + endif() + + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) +endfunction() + + function(get_item_key item key_var) get_filename_component(item_name "${item}" NAME) if(WIN32) @@ -425,12 +449,13 @@ function(clear_bundle_keys keys_var) set(${key}_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_COPYFLAG PARENT_SCOPE) + set(${key}_RPATHS PARENT_SCOPE) endforeach() set(${keys_var} PARENT_SCOPE) endfunction() -function(set_bundle_key_values keys_var context item exepath dirs copyflag) +function(set_bundle_key_values keys_var context item executable dirs copyflag) get_filename_component(item_name "${item}" NAME) get_item_key("${item}" key) @@ -440,10 +465,17 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) list(LENGTH ${keys_var} length_after) if(NOT length_before EQUAL length_after) - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item) + # Always use the exepath of the main bundle executable for @executable_path + # replacements: + # + get_filename_component(exepath "${executable}" PATH) + + gp_resolve_item("${context}" "${item}" "${executable}" "${dirs}" resolved_item) gp_item_default_embedded_path("${item}" default_embedded_path) + get_item_rpaths("${resolved_item}" rpaths) + if(item MATCHES "[^/]+\\.framework/") # For frameworks, construct the name under the embedded path from the # opening "${item_name}.framework/" to the closing "/${item_name}": @@ -479,6 +511,7 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) set(${key}_EMBEDDED_ITEM "${embedded_item}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" PARENT_SCOPE) set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) + set(${key}_RPATHS "${rpaths}" PARENT_SCOPE) else() #message("warning: item key '${key}' already in the list, subsequent references assumed identical to first") endif() @@ -490,14 +523,9 @@ function(get_bundle_keys app libs dirs keys_var) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - # Always use the exepath of the main bundle executable for @executable_path - # replacements: - # - get_filename_component(exepath "${executable}" PATH) - # But do fixups on all executables in the bundle: # - get_bundle_all_executables("${bundle}" exes) + get_bundle_all_executables("${bundle}" file_list) # For each extra lib, accumulate a key as well and then also accumulate # any of its prerequisites. (Extra libs are typically dynamically loaded @@ -505,12 +533,12 @@ function(get_bundle_keys app libs dirs keys_var) # but that do not show up in otool -L output...) # foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -518,17 +546,17 @@ function(get_bundle_keys app libs dirs keys_var) # The list of keys should be complete when all prerequisites of all # binaries in the bundle have been analyzed. # - foreach(exe ${exes}) + foreach(f ${file_list}) # Add the exe itself to the keys: # - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${f}" "${f}" "${executable}" "${dirs}" 0) # Add each prerequisite to the keys: # set(prereqs "") - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${f}" prereqs 1 1 "${executable}" "${dirs}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${f}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -542,6 +570,7 @@ function(get_bundle_keys app libs dirs keys_var) set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) endforeach() endif() endfunction() @@ -612,7 +641,7 @@ function(copy_resolved_framework_into_bundle resolved_item resolved_embedded_ite endfunction() -function(fixup_bundle_item resolved_embedded_item exepath dirs) +function(fixup_bundle_item resolved_embedded_item executable dirs) # This item's key is "ikey": # get_item_key("${resolved_embedded_item}" ikey) @@ -622,7 +651,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) # tree, or in other varied locations around the file system, with our call to # install_name_tool. Make sure that doesn't happen here: # - get_dotapp_dir("${exepath}" exe_dotapp_dir) + get_dotapp_dir("${executable}" exe_dotapp_dir) string(LENGTH "${exe_dotapp_dir}/" exe_dotapp_dir_length) string(LENGTH "${resolved_embedded_item}" resolved_embedded_item_length) set(path_too_short 0) @@ -648,7 +677,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) endif() set(prereqs "") - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}") + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${executable}" "${dirs}") set(changes "") @@ -668,12 +697,20 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) execute_process(COMMAND chmod u+w "${resolved_embedded_item}") endif() + foreach(rpath ${${ikey}_RPATHS}) + set(changes ${changes} -delete_rpath "${rpath}") + endforeach() + + if(${ikey}_EMBEDDED_ITEM) + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") + endif() + # Change this item's id and all of its references in one call # to install_name_tool: # - execute_process(COMMAND install_name_tool - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" - ) + if(changes) + execute_process(COMMAND install_name_tool ${changes} "${resolved_embedded_item}") + endif() endfunction() @@ -685,8 +722,6 @@ function(fixup_bundle app libs dirs) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - get_filename_component(exepath "${executable}" PATH) - message(STATUS "fixup_bundle: preparing...") get_bundle_keys("${app}" "${libs}" "${dirs}" keys) @@ -732,7 +767,7 @@ function(fixup_bundle app libs dirs) math(EXPR i ${i}+1) if(APPLE) message(STATUS "${i}/${n}: fixing up '${${key}_RESOLVED_EMBEDDED_ITEM}'") - fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${exepath}" "${dirs}") + fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${executable}" "${dirs}") else() message(STATUS "${i}/${n}: fix-up not required on this platform '${${key}_RESOLVED_EMBEDDED_ITEM}'") endif() @@ -757,55 +792,49 @@ function(copy_and_fixup_bundle src dst libs dirs) endfunction() -function(verify_bundle_prerequisites bundle result_var info_var) +function(verify_bundle_prerequisites bundle executable result_var info_var) set(result 1) set(info "") set(count 0) - get_bundle_main_executable("${bundle}" main_bundle_exe) - - file(GLOB_RECURSE file_list "${bundle}/*") + get_bundle_all_executables("${bundle}" file_list) foreach(f ${file_list}) - is_file_executable("${f}" is_executable) - if(is_executable) - get_filename_component(exepath "${f}" PATH) - math(EXPR count "${count} + 1") + math(EXPR count "${count} + 1") - message(STATUS "executable file ${count}: ${f}") + message(STATUS "executable file ${count}: ${f}") - set(prereqs "") - get_prerequisites("${f}" prereqs 1 1 "${exepath}" "") + set(prereqs "") + get_prerequisites("${f}" prereqs 1 1 "${executable}" "") - # On the Mac, - # "embedded" and "system" prerequisites are fine... anything else means - # the bundle's prerequisites are not verified (i.e., the bundle is not - # really "standalone") - # - # On Windows (and others? Linux/Unix/...?) - # "local" and "system" prereqs are fine... - # - set(external_prereqs "") + # On the Mac, + # "embedded" and "system" prerequisites are fine... anything else means + # the bundle's prerequisites are not verified (i.e., the bundle is not + # really "standalone") + # + # On Windows (and others? Linux/Unix/...?) + # "local" and "system" prereqs are fine... + # + set(external_prereqs "") - foreach(p ${prereqs}) - set(p_type "") - gp_file_type("${f}" "${p}" p_type) + foreach(p ${prereqs}) + set(p_type "") + gp_file_type("${f}" "${p}" "${executable}" p_type) - if(APPLE) - if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL "system") - set(external_prereqs ${external_prereqs} "${p}") - endif() - else() - if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL "system") - set(external_prereqs ${external_prereqs} "${p}") - endif() + if(APPLE) + if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL "system") + set(external_prereqs ${external_prereqs} "${p}") + endif() + else() + if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL "system") + set(external_prereqs ${external_prereqs} "${p}") endif() - endforeach() - - if(external_prereqs) - # Found non-system/somehow-unacceptable prerequisites: - set(result 0) - set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() + endforeach() + + if(external_prereqs) + # Found non-system/somehow-unacceptable prerequisites: + set(result 0) + set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() endforeach() @@ -845,7 +874,7 @@ function(verify_app app) # Verify that the bundle does not have any "external" prerequisites: # - verify_bundle_prerequisites("${bundle}" verified info) + verify_bundle_prerequisites("${bundle}" "${executable}" verified info) message(STATUS "verified='${verified}'") message(STATUS "info='${info}'") message(STATUS "") diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 49443e3..29a8470 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -41,7 +41,7 @@ # :: # # GET_PREREQUISITES( -# ) +# ) # # Get the list of shared library files required by . The list # in the variable named should be empty on first @@ -53,7 +53,7 @@ # must be 0 or 1 indicating whether to include or # exclude "system" prerequisites. If is set to 1 all # prerequisites will be found recursively, if set to 0 only direct -# prerequisites are listed. is the path to the top level +# prerequisites are listed. is the path to the top level # executable used for @executable_path replacment on the Mac. is # a list of paths where libraries might be found: these paths are # searched first when a target without any path info is given. Then @@ -113,7 +113,7 @@ # # :: # -# GP_RESOLVE_ITEM( ) +# GP_RESOLVE_ITEM( ) # # Resolve an item into an existing full path file. # @@ -122,13 +122,13 @@ # # :: # -# GP_RESOLVED_FILE_TYPE( ) +# GP_RESOLVED_FILE_TYPE( ) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named # . # -# Use and if necessary to resolve non-absolute +# Use and if necessary to resolve non-absolute # values -- but only for non-embedded items. # # Possible types are: @@ -318,10 +318,12 @@ function(gp_item_default_embedded_path item default_embedded_path_var) endfunction() -function(gp_resolve_item context item exepath dirs resolved_item_var) +function(gp_resolve_item context item executable dirs resolved_item_var) set(resolved 0) set(resolved_item "${item}") + get_filename_component(exepath "${executable}" PATH) + # Is it already resolved? # if(IS_ABSOLUTE "${resolved_item}" AND EXISTS "${resolved_item}") @@ -331,7 +333,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) if(NOT resolved) if(item MATCHES "^@executable_path") # - # @executable_path references are assumed relative to exepath + # @executable_path references are assumed relative to executable # string(REPLACE "@executable_path" "${exepath}" ri "${item}") get_filename_component(ri "${ri}" ABSOLUTE) @@ -374,10 +376,11 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) # string(REPLACE "@rpath/" "" norpath_item "${item}") + get_item_key("${executable}" key) set(ri "ri-NOTFOUND") - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) + find_file(ri "${norpath_item}" ${dirs} ${${key}_RPATHS} NO_DEFAULT_PATH) if(ri) - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") + #message(STATUS "info: 'find_file' in exepath/rpaths/dirs (${ri})") set(resolved 1) set(resolved_item "${ri}") set(ri "ri-NOTFOUND") @@ -436,7 +439,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) # by whatever logic they choose: # if(COMMAND gp_resolve_item_override) - gp_resolve_item_override("${context}" "${item}" "${exepath}" "${dirs}" resolved_item resolved) + gp_resolve_item_override("${context}" "${item}" "${executable}" "${dirs}" resolved_item resolved) endif() if(NOT resolved) @@ -459,7 +462,7 @@ warning: cannot resolve item '${item}' # # context='${context}' # item='${item}' -# exepath='${exepath}' +# executable='${executable}' # dirs='${dirs}' # resolved_item_var='${resolved_item_var}' #****************************************************************************** @@ -470,7 +473,7 @@ warning: cannot resolve item '${item}' endfunction() -function(gp_resolved_file_type original_file file exepath dirs type_var) +function(gp_resolved_file_type original_file file executable dirs type_var) #message(STATUS "**") if(NOT IS_ABSOLUTE "${original_file}") @@ -489,7 +492,7 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) if(NOT is_embedded) if(NOT IS_ABSOLUTE "${file}") - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file) + gp_resolve_item("${original_file}" "${file}" "${executable}" "${dirs}" resolved_file) endif() string(TOLOWER "${original_file}" original_lower) @@ -595,21 +598,19 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) endfunction() -function(gp_file_type original_file file type_var) +function(gp_file_type original_file file executable type_var) if(NOT IS_ABSOLUTE "${original_file}") message(STATUS "warning: gp_file_type expects absolute full path for first arg original_file") endif() - get_filename_component(exepath "${original_file}" PATH) - set(type "") - gp_resolved_file_type("${original_file}" "${file}" "${exepath}" "" type) + gp_resolved_file_type("${original_file}" "${file}" "${executable}" "" type) set(${type_var} "${type}" PARENT_SCOPE) endfunction() -function(get_prerequisites target prerequisites_var exclude_system recurse exepath dirs) +function(get_prerequisites target prerequisites_var exclude_system recurse executable dirs) set(verbose 0) set(eol_char "E") @@ -738,6 +739,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if("${gp_tool}" STREQUAL "ldd") set(old_ld_env "$ENV{LD_LIBRARY_PATH}") + get_filename_component(exepath "${executable}" PATH) set(new_ld_env "${exepath}") foreach(dir ${dirs}) set(new_ld_env "${new_ld_env}:${dir}") @@ -834,7 +836,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(add_item AND ${exclude_system}) set(type "") - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type) + gp_resolved_file_type("${target}" "${item}" "${executable}" "${dirs}" type) if("${type}" STREQUAL "system") set(add_item 0) @@ -855,7 +857,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa # that the analysis tools can simply accept it as input. # if(NOT list_length_before_append EQUAL list_length_after_append) - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${target}" "${item}" "${executable}" "${dirs}" resolved_item) set(unseen_prereqs ${unseen_prereqs} "${resolved_item}") endif() endif() @@ -874,7 +876,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(${recurse}) set(more_inputs ${unseen_prereqs}) foreach(input ${more_inputs}) - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}") + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${executable}" "${dirs}") endforeach() endif() @@ -911,7 +913,7 @@ function(list_prerequisites target) get_filename_component(exepath "${target}" PATH) set(prereqs "") - get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${exepath}" "") + get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${target}" "") if(print_target) message(STATUS "File '${target}' depends on:") @@ -925,7 +927,7 @@ function(list_prerequisites target) endif() if(print_prerequisite_type) - gp_file_type("${target}" "${d}" type) + gp_file_type("${target}" "${d}" "" type) set(type_str " (${type})") endif() -- 1.9.3 (Apple Git-50) From ono at java.pl Fri Sep 5 07:50:42 2014 From: ono at java.pl (Adam Strzelecki) Date: Fri, 5 Sep 2014 13:50:42 +0200 Subject: [cmake-developers] [PATCH 4/6] Process executables first when scanning bundle In-Reply-To: <952D2C19-AD78-4E46-BAE0-B2F0F4DF7C2E@java.pl> References: <952D2C19-AD78-4E46-BAE0-B2F0F4DF7C2E@java.pl> Message-ID: <1409917844-28297-4-git-send-email-ono@java.pl> This makes rpaths populated (if any), so libraries containing @rpath will be resolved properly. --- Modules/BundleUtilities.cmake | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 9733bc9..e99da9b 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -527,21 +527,6 @@ function(get_bundle_keys app libs dirs keys_var) # get_bundle_all_executables("${bundle}" file_list) - # For each extra lib, accumulate a key as well and then also accumulate - # any of its prerequisites. (Extra libs are typically dynamically loaded - # plugins: libraries that are prerequisites for full runtime functionality - # but that do not show up in otool -L output...) - # - foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) - - set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") - foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) - endforeach() - endforeach() - # For each executable found in the bundle, accumulate keys as we go. # The list of keys should be complete when all prerequisites of all # binaries in the bundle have been analyzed. @@ -560,6 +545,21 @@ function(get_bundle_keys app libs dirs keys_var) endforeach() endforeach() + # For each extra lib, accumulate a key as well and then also accumulate + # any of its prerequisites. (Extra libs are typically dynamically loaded + # plugins: libraries that are prerequisites for full runtime functionality + # but that do not show up in otool -L output...) + # + foreach(lib ${libs}) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) + + set(prereqs "") + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") + foreach(pr ${prereqs}) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) + endforeach() + endforeach() + # Propagate values to caller's scope: # set(${keys_var} ${${keys_var}} PARENT_SCOPE) -- 1.9.3 (Apple Git-50) From ono at java.pl Fri Sep 5 07:53:26 2014 From: ono at java.pl (Adam Strzelecki) Date: Fri, 5 Sep 2014 13:53:26 +0200 Subject: [cmake-developers] OS X packaging updates In-Reply-To: <5408B278.2070400@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> <5408B278.2070400@kitware.com> Message-ID: <4C094659-30A8-4304-ADBD-C62A1788C2A0@java.pl> I have sent updated 3/6 & 4/6. Rest of patches remain the same. I've tested on all 3 platforms: OSX, Windows & Linux. Tests are now running fine. Regards -- Adam From brad.king at kitware.com Fri Sep 5 08:33:04 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Sep 2014 08:33:04 -0400 Subject: [cmake-developers] OS X packaging updates In-Reply-To: <4C094659-30A8-4304-ADBD-C62A1788C2A0@java.pl> References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> <5408B278.2070400@kitware.com> <4C094659-30A8-4304-ADBD-C62A1788C2A0@java.pl> Message-ID: <5409AD80.2000303@kitware.com> On 09/05/2014 07:53 AM, Adam Strzelecki wrote: > I have sent updated 3/6 & 4/6. Rest of patches remain the same. > I've tested on all 3 platforms: OSX, Windows & Linux. Thanks. I've re-built the topic with those locally. I will merge again for testing next week when some issues caused by other topics have been resolved. -Brad From brad.king at kitware.com Fri Sep 5 08:50:06 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Sep 2014 08:50:06 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <54088C10.50601@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> Message-ID: <5409B17E.4050503@kitware.com> On 09/04/2014 11:58 AM, Nils Gladitz wrote: > Thanks, that actually sounds doable. > > I'll give it a try. Good work on the topic so far. I have a few more thoughts: - The dashboard submissions that bootstrap got many CMP0054 warnings. Most of them are the same warning repeated due to presence in a macro or loop. Please update the warning to not warn on the same line more than once. A set<> of already-emitted warning lines can be kept somewhere. - I think we can generalize the policy a bit further. Consider: set(x EXISTS) if("${x}" STREQUAL "EXISTS") Currently that will get an error because the evaluated variable spells "EXISTS" which is treated as a keyword. The policy could also make if() honor such keywords only when they are unquoted. - The new cmExpandedCommandArgument class interface could be simplified by making it derive from std::string and then just add the boolean as an extra member. - In the documentation we need to be precise about when the expansion is still allowed. The cmake-language(7) manual defines unquoted, "quoted", and [[bracket]] arguments as distinct argument types. We should use the same terminology here. You can even link back to the manual with cross-reference syntax: :ref:`Bracket Argument` :ref:`Quoted Argument` :ref:`Unquoted Argument` Also please extend the test cases for this policy to cover: - All if() command conditions that do variable-or-string. - if() inside a macro() and a function(), covering each combination of policy settings when the macro/function is recorded and when it is invoked. The policy value should be that when the macro/function was recorded. Thanks, -Brad From pascal.bach at siemens.com Fri Sep 5 09:16:53 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Fri, 5 Sep 2014 13:16:53 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <54088D58.70408@kitware.com> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> >> Right, it gets called inside try_compile projects too. Actually >> the SDK information will have to be propagated into those too. >> That means it needs to go in files like CMakeSystem.cmake or >> CMakeCCompiler.cmake that are configured in the build tree, >> or be explicitly propagated by cmMakefile::TryCompile like the >> GeneratorToolset is. > > With the current implementation I sent this seems to work and the SDK > ends up in > > The generated vxproj files for try compile. > > I don't see anything in the patch that could do that. > > CMakeDetermineCompilerId generates a test .vcxproj file that > gets the value from CMAKE_VS_PLATFORM_NAME. That one is in > the CompilerId directory. Is that the one you checked? > It is not from a try_compile. > I'm not clear what you mean. As far as I understand the solution files that do try compile are generated using the same generator that generates the final solution file. So if I change it I it also gets into try compile. Maybe I'm missing something. Pascal From pascal.bach at siemens.com Fri Sep 5 09:18:45 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Fri, 5 Sep 2014 13:18:45 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <355BE46A91031048906B695426A8D8E616ACEC1E@DEFTHW99EH4MSX.ww902.siemens.net> Here is an update version of my patchset: It also works with older versions of Windows CE but it tells the user that he might to manually se the CMAKE_PLATFORM_TOOLSET (I hope the resubmission is OK like this) >From 145c3189abf84aca046f555c5452396f0e5936eb Mon Sep 17 00:00:00 2001 From: Pascal Bach Date: Thu, 4 Sep 2014 13:32:30 +0200 Subject: [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio - Allow setting CMAKE_VS_WINCE_SDK to specify the SDK. - The user is warned if he uses a version different Windows CE different from 8.0 and not CMAKE_PLATFORM_TOOLSET is specified. - Docuentation for WINCE and CMAKE_VS_WINCE_SDK added. --- Help/variable/CMAKE_VS_WINCE_SDK.rst | 13 +++++++ Help/variable/WINCE.rst | 5 +++ Source/cmGlobalVisualStudio10Generator.cxx | 55 ++++++++++++++++++++++++++++ Source/cmGlobalVisualStudio10Generator.h | 7 ++++ Source/cmGlobalVisualStudio11Generator.cxx | 12 ++++++ Source/cmGlobalVisualStudio11Generator.h | 2 + Source/cmGlobalVisualStudio12Generator.cxx | 12 ++++++ Source/cmGlobalVisualStudio12Generator.h | 2 + 8 files changed, 108 insertions(+) create mode 100644 Help/variable/CMAKE_VS_WINCE_SDK.rst create mode 100644 Help/variable/WINCE.rst diff --git a/Help/variable/CMAKE_VS_WINCE_SDK.rst b/Help/variable/CMAKE_VS_WINCE_SDK.rst new file mode 100644 index 0000000..ef39b84 --- /dev/null +++ b/Help/variable/CMAKE_VS_WINCE_SDK.rst @@ -0,0 +1,13 @@ +CMAKE_VS_WINCE_SDK +------------------ + +Windows CE SDK to use together with the Visual Studio 10+ generators. + +If :variable:`CMAKE_SYSTEM_NAME` is set to Windows CE, this variable +allows to specify the SDK name that should be used to build the application. + +The value of this variable should never be modified by project code. +A toolchain file specified by the :variable:`CMAKE_TOOLCHAIN_FILE` +variable may initialize ``CMAKE_VS_WINCE_SDK``. Once a given +build tree has been initialized with a particular value for this +variable, changing the value has undefined behavior. diff --git a/Help/variable/WINCE.rst b/Help/variable/WINCE.rst new file mode 100644 index 0000000..54ff7de --- /dev/null +++ b/Help/variable/WINCE.rst @@ -0,0 +1,5 @@ +WINCE +----- + +True when the :variable:`CMAKE_SYSTEM_NAME` variable is set +to ``WindowsCE``. diff --git a/Source/cmGlobalVisualStudio10Generator.cxx b/Source/cmGlobalVisualStudio10Generator.cxx index 19aa52c..81a9723 100644 --- a/Source/cmGlobalVisualStudio10Generator.cxx +++ b/Source/cmGlobalVisualStudio10Generator.cxx @@ -165,6 +165,14 @@ bool cmGlobalVisualStudio10Generator::InitializeSystem(cmMakefile* mf) return false; } } + else if (this->SystemName == "WindowsCE") + { + this->SystemIsWindowsCE = true; + if (!this->InitializeWindowsCE(mf)) + { + return false; + } + } return true; } @@ -187,6 +195,53 @@ bool cmGlobalVisualStudio10Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio10Generator::InitializeWindowsCE(cmMakefile* mf) +{ + // To preserve the old behaviour just return the DefaultPlatformToolset + // for unknown Windows CE versions, in the worst case the user has to set + // CMAKE_GENERATOR_TOOLSET manually. In that case warn the user. + std::string platformToolset = this->SelectWindowsCEToolset(); + if (!platformToolset.empty()) + { + this->DefaultPlatformToolset = platformToolset; + } + else + { + cmOStringStream e; + e << this->GetName() << " Windows CE version '" << this->SystemVersion + << "' might require CMAKE_GENERATOR_TOOLSET to be set."; + mf->IssueMessage(cmake::WARNING, e.str()); + } + + if (const char* platformName = mf->GetDefinition("CMAKE_VS_WINCE_SDK")) + { + this->PlatformName = platformName; + } + else { + cmOStringStream e; + e << this->GetName() << " for " << this->GetSystemName() << " requires an " + << "SDK. Please set CMAKE_VS_WINCE_SDK to the name of your SDK."; + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); + return false; + } + + return true; +} + +//---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio10Generator::SelectWindowsCEToolset() const +{ + if (this->SystemVersion == "8.0") + { + return "CE800"; + } + else + { + return ""; + } +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio10Generator ::AddVSPlatformToolsetDefinition(cmMakefile* mf) const { diff --git a/Source/cmGlobalVisualStudio10Generator.h b/Source/cmGlobalVisualStudio10Generator.h index 11fa954..9bceb2c 100644 --- a/Source/cmGlobalVisualStudio10Generator.h +++ b/Source/cmGlobalVisualStudio10Generator.h @@ -75,6 +75,10 @@ public: bool TargetsWindowsStore() const { return this->SystemIsWindowsStore; } + /** Return true if building for WindowsCE */ + bool TargetsWindowsCE() const + { return this->SystemIsWindowsCE; } + /** * Where does this version of Visual Studio look for macros for the * current user? Returns the empty string if this version of Visual @@ -106,8 +110,10 @@ protected: virtual bool InitializeSystem(cmMakefile* mf); virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const { return ""; } virtual std::string SelectWindowsStoreToolset() const { return ""; } + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "10.0"; } @@ -119,6 +125,7 @@ protected: std::string SystemVersion; bool SystemIsWindowsPhone; bool SystemIsWindowsStore; + bool SystemIsWindowsCE; bool ExpressEdition; bool UseFolderProperty(); diff --git a/Source/cmGlobalVisualStudio11Generator.cxx b/Source/cmGlobalVisualStudio11Generator.cxx index 39bbdc0..a71c42e 100644 --- a/Source/cmGlobalVisualStudio11Generator.cxx +++ b/Source/cmGlobalVisualStudio11Generator.cxx @@ -159,6 +159,12 @@ bool cmGlobalVisualStudio11Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio11Generator::InitializeWindowsCE(cmMakefile* mf) +{ + return cmGlobalVisualStudio10Generator::InitializeWindowsCE(mf); +} + +//---------------------------------------------------------------------------- std::string cmGlobalVisualStudio11Generator::SelectWindowsPhoneToolset() const { if(this->SystemVersion == "8.0") @@ -179,6 +185,12 @@ std::string cmGlobalVisualStudio11Generator::SelectWindowsStoreToolset() const } //---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio11Generator::SelectWindowsCEToolset() const +{ + return this->cmGlobalVisualStudio10Generator::SelectWindowsCEToolset(); +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio11Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; diff --git a/Source/cmGlobalVisualStudio11Generator.h b/Source/cmGlobalVisualStudio11Generator.h index bbd935c..9dd3271 100644 --- a/Source/cmGlobalVisualStudio11Generator.h +++ b/Source/cmGlobalVisualStudio11Generator.h @@ -36,8 +36,10 @@ public: protected: virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const; virtual std::string SelectWindowsStoreToolset() const; + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "11.0"; } bool UseFolderProperty(); static std::set GetInstalledWindowsCESDKs(); diff --git a/Source/cmGlobalVisualStudio12Generator.cxx b/Source/cmGlobalVisualStudio12Generator.cxx index 29ecfe0..c784cae 100644 --- a/Source/cmGlobalVisualStudio12Generator.cxx +++ b/Source/cmGlobalVisualStudio12Generator.cxx @@ -139,6 +139,12 @@ bool cmGlobalVisualStudio12Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio12Generator::InitializeWindowsCE(cmMakefile* mf) +{ + return cmGlobalVisualStudio11Generator::InitializeWindowsCE(mf); +} + +//---------------------------------------------------------------------------- std::string cmGlobalVisualStudio12Generator::SelectWindowsPhoneToolset() const { if(this->SystemVersion == "8.1") @@ -159,6 +165,12 @@ std::string cmGlobalVisualStudio12Generator::SelectWindowsStoreToolset() const } //---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio12Generator::SelectWindowsCEToolset() const +{ + return this->cmGlobalVisualStudio11Generator::SelectWindowsCEToolset(); +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio12Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 12.00\n"; diff --git a/Source/cmGlobalVisualStudio12Generator.h b/Source/cmGlobalVisualStudio12Generator.h index ec85f10..5d8c125 100644 --- a/Source/cmGlobalVisualStudio12Generator.h +++ b/Source/cmGlobalVisualStudio12Generator.h @@ -41,8 +41,10 @@ public: protected: virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const; virtual std::string SelectWindowsStoreToolset() const; + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "12.0"; } private: class Factory; -- 1.7.10.4 From nilsgladitz at gmail.com Fri Sep 5 09:19:48 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 05 Sep 2014 15:19:48 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5409B17E.4050503@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> Message-ID: <5409B874.2060607@gmail.com> On 09/05/2014 02:50 PM, Brad King wrote: > On 09/04/2014 11:58 AM, Nils Gladitz wrote: > - The dashboard submissions that bootstrap got many CMP0054 > warnings. Most of them are the same warning repeated due > to presence in a macro or loop. Please update the warning > to not warn on the same line more than once. A set<> of > already-emitted warning lines can be kept somewhere. I'll look into it. Would it be ok to set the policy for cmcurl to OLD? I assume that makes it easier to pull changes from upstream than when I fix the code to comply with the new policy; also it isn't always clear what the intention was with the given conditionals and I am more likely to break something. > > - I think we can generalize the policy a bit further. Consider: > > set(x EXISTS) > if("${x}" STREQUAL "EXISTS") > > Currently that will get an error because the evaluated > variable spells "EXISTS" which is treated as a keyword. > The policy could also make if() honor such keywords only > when they are unquoted. > I'll look into it. > - The new cmExpandedCommandArgument class interface could > be simplified by making it derive from std::string and > then just add the boolean as an extra member. I think composition is cleaner and more future proof in this case though; I'd like to keep it unless you insist it should be changed. > - In the documentation we need to be precise about when > the expansion is still allowed. The cmake-language(7) > manual defines unquoted, "quoted", and [[bracket]] > arguments as distinct argument types. We should use the > same terminology here. You can even link back to the > manual with cross-reference syntax: > > :ref:`Bracket Argument` > :ref:`Quoted Argument` > :ref:`Unquoted Argument` I kept the distinction in cmExpandedCommandArgument at first but then generalized it so that bracketed, quoted and C++ side "0", "1" constant arguments would be subsumed. This could be expanded again if there are future use cases where they need to be distinguished. I'll document the current behavior for if(). > Also please extend the test cases for this policy to cover: > > - All if() command conditions that do variable-or-string. Will do. I was also thinking about setting up an alternative testing infrastructure parallel to RunCMake which runs cmake in script mode rather than performing configuration/generation. It would be nice to have something less granular which would allow multiple related test cases, expected outputs and exit statuses in a single file (which I think could be nicely done with the new bracket syntax). Not for this topic obviously but would this make sense in general? e.g. something similar to expect_failure( [[ if( ]], [[Parse error. Function missing ending ")". End of file reached. ]]) > - if() inside a macro() and a function(), covering each > combination of policy settings when the macro/function > is recorded and when it is invoked. The policy value > should be that when the macro/function was recorded. Is that behavior command specific? Isn't it covered by policy testing in general? Nils From brad.king at kitware.com Fri Sep 5 09:31:51 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Sep 2014 09:31:51 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5409B874.2060607@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> Message-ID: <5409BB47.3000309@kitware.com> On 09/05/2014 09:19 AM, Nils Gladitz wrote: > Would it be ok to set the policy for cmcurl to OLD? No, but the code could be fixed to not trigger the warning. See similar changes here: Check*: Allow result variables to contain regex special characters http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4f2fcce4 Alternatively, just let the warnings go for now so we can see how they look. Then we can fix the code in a follow-up change. > I kept the distinction in cmExpandedCommandArgument at first but then > generalized it so that bracketed, quoted and C++ side "0", "1" constant > arguments would be subsumed. This could be expanded again if there are > future use cases where they need to be distinguished. That's fine. I'm just talking about the documentation. Right now it says "quoted" arguments do not expand in the NEW behavior. It should say something more like "only unquoted arguments expand" since both "quoted" and [[bracket]] arguments are left alone now. > I was also thinking about setting up an alternative testing > infrastructure parallel to RunCMake which runs cmake in script mode > rather than performing configuration/generation. You can use "run_cmake_command" to run arbitrary cmake command-line signatures and still use the rest of the infrastructure. > It would be nice to have something less granular which would allow > multiple related test cases, expected outputs and exit statuses in a > single file (which I think could be nicely done with the new bracket > syntax). > > Not for this topic obviously but would this make sense in general? Yes. The existing RunCMake infrastructure could be extended with more commands that take the expected pieces directly as arguments. Then the current infrastructure could be ported to use it after reading info from the files. >> - if() inside a macro() and a function(), covering each >> combination of policy settings when the macro/function >> is recorded and when it is invoked. The policy value >> should be that when the macro/function was recorded. > > Is that behavior command specific? > Isn't it covered by policy testing in general? The policy scope is general behavior, but we need to know that the forwarding of arguments into commands when replayed from macro/function works correctly to implement this policy. Thanks, -Brad From dlrdave at aol.com Fri Sep 5 09:33:29 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 5 Sep 2014 09:33:29 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion Message-ID: <8D197251CDF9BB9-15CC-1A84C@webmail-m269.sysops.aol.com> > I was also thinking about setting up an alternative testing > infrastructure parallel to RunCMake which runs cmake in script mode > rather than performing configuration/generation. This already exists in a form in the Tests/CMakeTests/*TestScript* tests. An example: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/CMakeTests/StringTestScript.cmake;h=a562e71d38ff7db040e567f0ef9b899c2101bc9f;hb=ff1fddb0bf40b8a7170d54ccdc9420c2d7190472 Any *TestScript* file also requires a "driving" *Test.cmake.in file and an entry in Tests/CMakeTests/CMakeLists.txt, but the infrastructure is there already. Actually, there are two infrastructures in that folder, but this one is similar to the one you're proposing. HTH, David C. From nilsgladitz at gmail.com Fri Sep 5 09:50:40 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 05 Sep 2014 15:50:40 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5409BB47.3000309@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <5409BB47.3000309@kitware.com> Message-ID: <5409BFB0.1060408@gmail.com> On 09/05/2014 03:31 PM, Brad King wrote: > You can use "run_cmake_command" to run arbitrary cmake command-line > signatures and still use the rest of the infrastructure. Ok. I just thought it would be nice to distinguish tests that don't configure a project. (Headline for RunCMake is "This directory contains tests that run CMake to configure a project but do not actually build anything.") E.g. have a well defined set of tests which are generator independent as well. Nils From brad.king at kitware.com Fri Sep 5 09:59:42 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Sep 2014 09:59:42 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <5409C1CE.1010501@kitware.com> On 09/05/2014 09:16 AM, Bach, Pascal wrote: > I'm not clear what you mean. > As far as I understand the solution files that do try compile > are generated using the same generator that generates the > final solution file. A generator with the same name is used but it is not the same instance of cmGlobalGenerator. See cmMakefile::TryCompile: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmMakefile.cxx;hb=v3.0.1#l3080 It creates a new generator, but also does cm.SetIsInTryCompile(true) on the temporary try_compile cmake instance. That tells the generator's EnableLanguage method to load settings for languages from the existing files created by the outer generator. The try_compile generator is explicitly given the toolset: cm.SetGeneratorToolset(this->GetCMakeInstance()->GetGeneratorToolset()); but the rest of the information (e.g. CMAKE_SYSTEM_NAME) gets loaded from CMakeFiles//CMakeSystem.cmake and a few per-language files. The CMAKE_VS_WINCE_SDK value (or whatever more general name we choose) will have to go through here too. Since CMakeSystem.cmake loads the CMAKE_TOOLCHAIN_FILE, try_compile should use CMAKE_VS_WINCE_SDK when the value is set in the toolchain file. Is this the case when you test the changes locally? On 09/05/2014 09:18 AM, Bach, Pascal wrote: > (I hope the resubmission is OK like this) Yes, revised patch resubmissions are just right. Thanks, -Brad From nilsgladitz at gmail.com Fri Sep 5 09:59:18 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 05 Sep 2014 15:59:18 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <8D197251CDF9BB9-15CC-1A84C@webmail-m269.sysops.aol.com> References: <8D197251CDF9BB9-15CC-1A84C@webmail-m269.sysops.aol.com> Message-ID: <5409C1B6.6020102@gmail.com> On 09/05/2014 03:33 PM, David Cole wrote: >> I was also thinking about setting up an alternative testing >> infrastructure parallel to RunCMake which runs cmake in script mode >> rather than performing configuration/generation. > > This already exists in a form in the Tests/CMakeTests/*TestScript* > tests. > > An example: > http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/CMakeTests/StringTestScript.cmake;h=a562e71d38ff7db040e567f0ef9b899c2101bc9f;hb=ff1fddb0bf40b8a7170d54ccdc9420c2d7190472 > > > Any *TestScript* file also requires a "driving" *Test.cmake.in file and > an entry in Tests/CMakeTests/CMakeLists.txt, but the infrastructure is > there already. Actually, there are two infrastructures in that folder, > but this one is similar to the one you're proposing. I used the second infrastructure for the TIMESTAMP tests apparently. Those feel similar to the tests in RunCMake e.g. lots of files that I would prefer to combine into something more compact. The other infrastructure I don't think I have touched but optically it looks very noisy. Having something that takes away repetitive tasks, more compact and easier on the eye would be nice. Nils From pascal.bach at siemens.com Fri Sep 5 10:02:58 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Fri, 5 Sep 2014 14:02:58 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <5409C1CE.1010501@kitware.com> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> <5409C1CE.1010501@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACEC74@DEFTHW99EH4MSX.ww902.siemens.net> > On 09/05/2014 09:16 AM, Bach, Pascal wrote: > > I'm not clear what you mean. > > As far as I understand the solution files that do try compile > > are generated using the same generator that generates the > > final solution file. > > A generator with the same name is used but it is not the same > instance of cmGlobalGenerator. See cmMakefile::TryCompile: > > > http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmMakefile.c > xx;hb=v3.0.1#l3080 > > It creates a new generator, but also does cm.SetIsInTryCompile(true) > on the temporary try_compile cmake instance. That tells the > generator's EnableLanguage method to load settings for languages > from the existing files created by the outer generator. > > The try_compile generator is explicitly given the toolset: > > cm.SetGeneratorToolset(this->GetCMakeInstance()- > >GetGeneratorToolset()); > > but the rest of the information (e.g. CMAKE_SYSTEM_NAME) gets > loaded from CMakeFiles//CMakeSystem.cmake and a few > per-language files. The CMAKE_VS_WINCE_SDK value (or whatever more > general name we choose) will have to go through here too. Ok now I understand. > Since CMakeSystem.cmake loads the CMAKE_TOOLCHAIN_FILE, try_compile > should use CMAKE_VS_WINCE_SDK when the value is set in the toolchain > file. Is this the case when you test the changes locally? > The case I was testing was indeed with the CMAKE_VS_WINCE_SDK set inside the toolchain file. I guess to support this variable only in the toolchain file is not an option? Pascal From brad.king at kitware.com Fri Sep 5 10:04:41 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Sep 2014 10:04:41 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5409BFB0.1060408@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <5409BB47.3000309@kitware.com> <5409BFB0.1060408@gmail.com> Message-ID: <5409C2F9.30600@kitware.com> On 09/05/2014 09:50 AM, Nils Gladitz wrote: > On 09/05/2014 03:31 PM, Brad King wrote: >> You can use "run_cmake_command" to run arbitrary cmake command-line >> signatures and still use the rest of the infrastructure. > > Ok. I just thought it would be nice to distinguish tests that don't > configure a project. (Headline for RunCMake is "This directory contains > tests that run CMake to configure a project but do not actually build > anything.") > > E.g. have a well defined set of tests which are generator independent as > well. I think the description of RunCMake can just be updated. All of its tests are about running "cmake" command lines. -Brad From nilsgladitz at gmail.com Fri Sep 5 10:17:52 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 05 Sep 2014 16:17:52 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5409C2F9.30600@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <5409BB47.3000309@kitware.com> <5409BFB0.1060408@gmail.com> <5409C2F9.30600@kitware.com> Message-ID: <5409C610.8030203@gmail.com> >> On 09/05/2014 03:31 PM, Brad King wrote: > > I think the description of RunCMake can just be updated. > All of its tests are about running "cmake" command lines. So you see no advantage to having the distinction? E.g. if you consider testing a set of generators (or variants of the same generator) possibly non-native and distinct from the generator being used to build cmake itself it might make sense to run tests which perform configuration once for each of those but script mode tests would only have to be run once. Nils From clinton at elemtech.com Fri Sep 5 08:29:34 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Fri, 5 Sep 2014 06:29:34 -0600 (MDT) Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <1409917844-28297-3-git-send-email-ono@java.pl> References: <952D2C19-AD78-4E46-BAE0-B2F0F4DF7C2E@java.pl> <1409917844-28297-3-git-send-email-ono@java.pl> Message-ID: <43520581.222701.1409920174530.JavaMail.zimbra@elemtech.com> I think it would be nice to move get_item_rpaths() from BundleUtilities.cmake to gp_item_get_rpaths() in GetPrerequisites.cmake. And how does your patch or patch set handle @loader_path being used in the rpath? Also, I think the function signature should include the rpath vs runpath distinction. I realize OS X doesn't have the runpath concept, but if one were to add support for Linux, one may need that where the runpath affects only finding immediate dependencies. Below is what I have for Linux and OS X. It include rpath vs. runpath, and expands out the @loader_path variable. Does it help, or did you have something else in mind? # Get rpaths for a binary. function(get_rpaths binary rpaths run_paths) get_filename_component(binary_dir "${binary}" PATH) unset(myrpaths) unset(myrunpaths) if(APPLE) execute_process(COMMAND otool -l "${binary}" COMMAND grep -A2 LC_RPATH COMMAND grep path OUTPUT_VARIABLE paths) string(REPLACE "\n" ";" paths "${paths}") foreach(str ${paths}) string(REGEX REPLACE " path (.*) \\(offset.*" "\\1" rpath "${str}") string(STRIP "${rpath}" rpath) string(REPLACE "@loader_path" "${binary_dir}" rpath "${rpath}") list(APPEND myrpaths "${rpath}") endforeach() else() execute_process(COMMAND objdump -p "${binary}" COMMAND grep RPATH OUTPUT_VARIABLE paths) execute_process(COMMAND objdump -p "${binary}" COMMAND grep RUNPATH OUTPUT_VARIABLE paths2) string(REPLACE "\n" ";" paths "${paths}") string(REPLACE "\n" ";" paths2 "${paths2}") foreach(str ${paths}) string(REGEX REPLACE " RPATH[ ]*(.*)" "\\1" rpath "${str}") string(STRIP "${rpath}" rpath) string(REPLACE "\$ORIGIN" "${binary_dir}" rpath "${rpath}") list(APPEND myrpaths "${rpath}") endforeach() foreach(str ${paths2}) string(REGEX REPLACE " RUNPATH[ ]*(.*)" "\\1" rpath "${str}") string(STRIP "${rpath}" rpath) string(REPLACE "\$ORIGIN" "${binary_dir}" rpath "${rpath}") list(APPEND myrunpaths "${rpath}") endforeach() endif() string(REPLACE ":" ";" myrpaths "${myrpaths}") string(REPLACE ":" ";" myrunpaths "${myrunpaths}") set(${rpaths} ${myrpaths} PARENT_SCOPE) set(${run_paths} ${myrunpaths} PARENT_SCOPE) endfunction() Clint ----- Original Message ----- > This is done by gathering LC_RPATH commands for main bundle executable and > using it for @rpath lookup in dependent frameworks. > > To achieve this all utility functions now take path to executable rather than > path to its directory. > > This enabled apps using @rpath to be bundled correctly, which will be > necessary > for upcoming Qt 5.4 that will use @rpath for all frameworks. > --- > Modules/BundleUtilities.cmake | 169 > ++++++++++++++++++++++++----------------- > Modules/GetPrerequisites.cmake | 48 ++++++------ > 2 files changed, 124 insertions(+), 93 deletions(-) > > diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake > index 7e2b173..9733bc9 100644 > --- a/Modules/BundleUtilities.cmake > +++ b/Modules/BundleUtilities.cmake > @@ -19,6 +19,7 @@ > # get_bundle_and_executable > # get_bundle_all_executables > # get_item_key > +# get_item_rpaths > # clear_bundle_keys > # set_bundle_key_values > # get_bundle_keys > @@ -75,7 +76,7 @@ > # > # :: > # > -# GET_DOTAPP_DIR( ) > +# GET_DOTAPP_DIR( ) > # > # Returns the nearest parent dir whose name ends with ".app" given the > # full path to an executable. If there is no such parent dir, then > @@ -123,7 +124,7 @@ > # > # :: > # > -# SET_BUNDLE_KEY_VALUES( > +# SET_BUNDLE_KEY_VALUES( > # ) > # > # Add a key to the list (if necessary) for the given item. If added, > @@ -163,7 +164,7 @@ > # > # :: > # > -# FIXUP_BUNDLE_ITEM( ) > +# FIXUP_BUNDLE_ITEM( ) > # > # Get the direct/non-system prerequisites of the resolved embedded item. > # For each prerequisite, change the way it is referenced to the value of > @@ -189,11 +190,11 @@ > # > # :: > # > -# VERIFY_BUNDLE_PREREQUISITES( ) > +# VERIFY_BUNDLE_PREREQUISITES( > ) > # > # Verifies that the sum of all prerequisites of all files inside the > -# bundle are contained within the bundle or are "system" libraries, > -# presumed to exist everywhere. > +# bundle with given main executable are contained within the bundle or are > +# "system" libraries, presumed to exist everywhere. > # > # :: > # > @@ -285,8 +286,8 @@ function(get_bundle_main_executable bundle result_var) > endfunction() > > > -function(get_dotapp_dir exe dotapp_dir_var) > - set(s "${exe}") > +function(get_dotapp_dir executable dotapp_dir_var) > + set(s "${executable}") > > if(s MATCHES "/.*\\.app/") > # If there is a ".app" parent directory, > @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) > endfunction() > > > +function(get_item_rpaths item rpaths_var) > + if(APPLE) > + find_program(otool_cmd "otool") > + mark_as_advanced(otool_cmd) > + endif() > + > + if(otool_cmd) > + execute_process( > + COMMAND "${otool_cmd}" -l "${item}" > + OUTPUT_VARIABLE load_cmds_ov > + ) > + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) > \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") > + string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") > + string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") > + if(load_cmds_ov) > + gp_append_unique(${rpaths_var} "${load_cmds_ov}") > + endif() > + endif() > + > + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) > +endfunction() > + > + > function(get_item_key item key_var) > get_filename_component(item_name "${item}" NAME) > if(WIN32) > @@ -425,12 +449,13 @@ function(clear_bundle_keys keys_var) > set(${key}_EMBEDDED_ITEM PARENT_SCOPE) > set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) > set(${key}_COPYFLAG PARENT_SCOPE) > + set(${key}_RPATHS PARENT_SCOPE) > endforeach() > set(${keys_var} PARENT_SCOPE) > endfunction() > > > -function(set_bundle_key_values keys_var context item exepath dirs copyflag) > +function(set_bundle_key_values keys_var context item executable dirs > copyflag) > get_filename_component(item_name "${item}" NAME) > > get_item_key("${item}" key) > @@ -440,10 +465,17 @@ function(set_bundle_key_values keys_var context item > exepath dirs copyflag) > list(LENGTH ${keys_var} length_after) > > if(NOT length_before EQUAL length_after) > - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" > resolved_item) > + # Always use the exepath of the main bundle executable for > @executable_path > + # replacements: > + # > + get_filename_component(exepath "${executable}" PATH) > + > + gp_resolve_item("${context}" "${item}" "${executable}" "${dirs}" > resolved_item) > > gp_item_default_embedded_path("${item}" default_embedded_path) > > + get_item_rpaths("${resolved_item}" rpaths) > + > if(item MATCHES "[^/]+\\.framework/") > # For frameworks, construct the name under the embedded path from the > # opening "${item_name}.framework/" to the closing "/${item_name}": > @@ -479,6 +511,7 @@ function(set_bundle_key_values keys_var context item > exepath dirs copyflag) > set(${key}_EMBEDDED_ITEM "${embedded_item}" PARENT_SCOPE) > set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" > PARENT_SCOPE) > set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) > + set(${key}_RPATHS "${rpaths}" PARENT_SCOPE) > else() > #message("warning: item key '${key}' already in the list, subsequent > references assumed identical to first") > endif() > @@ -490,14 +523,9 @@ function(get_bundle_keys app libs dirs keys_var) > > get_bundle_and_executable("${app}" bundle executable valid) > if(valid) > - # Always use the exepath of the main bundle executable for > @executable_path > - # replacements: > - # > - get_filename_component(exepath "${executable}" PATH) > - > # But do fixups on all executables in the bundle: > # > - get_bundle_all_executables("${bundle}" exes) > + get_bundle_all_executables("${bundle}" file_list) > > # For each extra lib, accumulate a key as well and then also accumulate > # any of its prerequisites. (Extra libs are typically dynamically loaded > @@ -505,12 +533,12 @@ function(get_bundle_keys app libs dirs keys_var) > # but that do not show up in otool -L output...) > # > foreach(lib ${libs}) > - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" > "${dirs}" 0) > + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" > "${dirs}" 0) > > set(prereqs "") > - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") > + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") > foreach(pr ${prereqs}) > - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" > "${dirs}" 1) > + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" > "${dirs}" 1) > endforeach() > endforeach() > > @@ -518,17 +546,17 @@ function(get_bundle_keys app libs dirs keys_var) > # The list of keys should be complete when all prerequisites of all > # binaries in the bundle have been analyzed. > # > - foreach(exe ${exes}) > + foreach(f ${file_list}) > # Add the exe itself to the keys: > # > - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" > "${dirs}" 0) > + set_bundle_key_values(${keys_var} "${f}" "${f}" "${executable}" > "${dirs}" 0) > > # Add each prerequisite to the keys: > # > set(prereqs "") > - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") > + get_prerequisites("${f}" prereqs 1 1 "${executable}" "${dirs}") > foreach(pr ${prereqs}) > - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" > "${dirs}" 1) > + set_bundle_key_values(${keys_var} "${f}" "${pr}" "${executable}" > "${dirs}" 1) > endforeach() > endforeach() > > @@ -542,6 +570,7 @@ function(get_bundle_keys app libs dirs keys_var) > set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) > set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" > PARENT_SCOPE) > set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) > + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) > endforeach() > endif() > endfunction() > @@ -612,7 +641,7 @@ function(copy_resolved_framework_into_bundle > resolved_item resolved_embedded_ite > endfunction() > > > -function(fixup_bundle_item resolved_embedded_item exepath dirs) > +function(fixup_bundle_item resolved_embedded_item executable dirs) > # This item's key is "ikey": > # > get_item_key("${resolved_embedded_item}" ikey) > @@ -622,7 +651,7 @@ function(fixup_bundle_item resolved_embedded_item exepath > dirs) > # tree, or in other varied locations around the file system, with our call > to > # install_name_tool. Make sure that doesn't happen here: > # > - get_dotapp_dir("${exepath}" exe_dotapp_dir) > + get_dotapp_dir("${executable}" exe_dotapp_dir) > string(LENGTH "${exe_dotapp_dir}/" exe_dotapp_dir_length) > string(LENGTH "${resolved_embedded_item}" resolved_embedded_item_length) > set(path_too_short 0) > @@ -648,7 +677,7 @@ function(fixup_bundle_item resolved_embedded_item exepath > dirs) > endif() > > set(prereqs "") > - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" > "${dirs}") > + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${executable}" > "${dirs}") > > set(changes "") > > @@ -668,12 +697,20 @@ function(fixup_bundle_item resolved_embedded_item > exepath dirs) > execute_process(COMMAND chmod u+w "${resolved_embedded_item}") > endif() > > + foreach(rpath ${${ikey}_RPATHS}) > + set(changes ${changes} -delete_rpath "${rpath}") > + endforeach() > + > + if(${ikey}_EMBEDDED_ITEM) > + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") > + endif() > + > # Change this item's id and all of its references in one call > # to install_name_tool: > # > - execute_process(COMMAND install_name_tool > - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" > - ) > + if(changes) > + execute_process(COMMAND install_name_tool ${changes} > "${resolved_embedded_item}") > + endif() > endfunction() > > > @@ -685,8 +722,6 @@ function(fixup_bundle app libs dirs) > > get_bundle_and_executable("${app}" bundle executable valid) > if(valid) > - get_filename_component(exepath "${executable}" PATH) > - > message(STATUS "fixup_bundle: preparing...") > get_bundle_keys("${app}" "${libs}" "${dirs}" keys) > > @@ -732,7 +767,7 @@ function(fixup_bundle app libs dirs) > math(EXPR i ${i}+1) > if(APPLE) > message(STATUS "${i}/${n}: fixing up > '${${key}_RESOLVED_EMBEDDED_ITEM}'") > - fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${exepath}" > "${dirs}") > + fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${executable}" > "${dirs}") > else() > message(STATUS "${i}/${n}: fix-up not required on this platform > '${${key}_RESOLVED_EMBEDDED_ITEM}'") > endif() > @@ -757,55 +792,49 @@ function(copy_and_fixup_bundle src dst libs dirs) > endfunction() > > > -function(verify_bundle_prerequisites bundle result_var info_var) > +function(verify_bundle_prerequisites bundle executable result_var info_var) > set(result 1) > set(info "") > set(count 0) > > - get_bundle_main_executable("${bundle}" main_bundle_exe) > - > - file(GLOB_RECURSE file_list "${bundle}/*") > + get_bundle_all_executables("${bundle}" file_list) > foreach(f ${file_list}) > - is_file_executable("${f}" is_executable) > - if(is_executable) > - get_filename_component(exepath "${f}" PATH) > - math(EXPR count "${count} + 1") > + math(EXPR count "${count} + 1") > > - message(STATUS "executable file ${count}: ${f}") > + message(STATUS "executable file ${count}: ${f}") > > - set(prereqs "") > - get_prerequisites("${f}" prereqs 1 1 "${exepath}" "") > + set(prereqs "") > + get_prerequisites("${f}" prereqs 1 1 "${executable}" "") > > - # On the Mac, > - # "embedded" and "system" prerequisites are fine... anything else > means > - # the bundle's prerequisites are not verified (i.e., the bundle is not > - # really "standalone") > - # > - # On Windows (and others? Linux/Unix/...?) > - # "local" and "system" prereqs are fine... > - # > - set(external_prereqs "") > + # On the Mac, > + # "embedded" and "system" prerequisites are fine... anything else means > + # the bundle's prerequisites are not verified (i.e., the bundle is not > + # really "standalone") > + # > + # On Windows (and others? Linux/Unix/...?) > + # "local" and "system" prereqs are fine... > + # > + set(external_prereqs "") > > - foreach(p ${prereqs}) > - set(p_type "") > - gp_file_type("${f}" "${p}" p_type) > + foreach(p ${prereqs}) > + set(p_type "") > + gp_file_type("${f}" "${p}" "${executable}" p_type) > > - if(APPLE) > - if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" > STREQUAL "system") > - set(external_prereqs ${external_prereqs} "${p}") > - endif() > - else() > - if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL > "system") > - set(external_prereqs ${external_prereqs} "${p}") > - endif() > + if(APPLE) > + if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL > "system") > + set(external_prereqs ${external_prereqs} "${p}") > + endif() > + else() > + if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL > "system") > + set(external_prereqs ${external_prereqs} "${p}") > endif() > - endforeach() > - > - if(external_prereqs) > - # Found non-system/somehow-unacceptable prerequisites: > - set(result 0) > - set(info ${info} "external prerequisites > found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") > endif() > + endforeach() > + > + if(external_prereqs) > + # Found non-system/somehow-unacceptable prerequisites: > + set(result 0) > + set(info ${info} "external prerequisites > found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") > endif() > endforeach() > > @@ -845,7 +874,7 @@ function(verify_app app) > > # Verify that the bundle does not have any "external" prerequisites: > # > - verify_bundle_prerequisites("${bundle}" verified info) > + verify_bundle_prerequisites("${bundle}" "${executable}" verified info) > message(STATUS "verified='${verified}'") > message(STATUS "info='${info}'") > message(STATUS "") > diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake > index 49443e3..29a8470 100644 > --- a/Modules/GetPrerequisites.cmake > +++ b/Modules/GetPrerequisites.cmake > @@ -41,7 +41,7 @@ > # :: > # > # GET_PREREQUISITES( > > -# ) > +# ) > # > # Get the list of shared library files required by . The list > # in the variable named should be empty on first > @@ -53,7 +53,7 @@ > # must be 0 or 1 indicating whether to include or > # exclude "system" prerequisites. If is set to 1 all > # prerequisites will be found recursively, if set to 0 only direct > -# prerequisites are listed. is the path to the top level > +# prerequisites are listed. is the path to the top level > # executable used for @executable_path replacment on the Mac. is > # a list of paths where libraries might be found: these paths are > # searched first when a target without any path info is given. Then > @@ -113,7 +113,7 @@ > # > # :: > # > -# GP_RESOLVE_ITEM( ) > +# GP_RESOLVE_ITEM( > ) > # > # Resolve an item into an existing full path file. > # > @@ -122,13 +122,13 @@ > # > # :: > # > -# GP_RESOLVED_FILE_TYPE( > ) > +# GP_RESOLVED_FILE_TYPE( > ) > # > # Return the type of with respect to . String > # describing type of prerequisite is returned in variable named > # . > # > -# Use and if necessary to resolve non-absolute > +# Use and if necessary to resolve non-absolute > # values -- but only for non-embedded items. > # > # Possible types are: > @@ -318,10 +318,12 @@ function(gp_item_default_embedded_path item > default_embedded_path_var) > endfunction() > > > -function(gp_resolve_item context item exepath dirs resolved_item_var) > +function(gp_resolve_item context item executable dirs resolved_item_var) > set(resolved 0) > set(resolved_item "${item}") > > + get_filename_component(exepath "${executable}" PATH) > + > # Is it already resolved? > # > if(IS_ABSOLUTE "${resolved_item}" AND EXISTS "${resolved_item}") > @@ -331,7 +333,7 @@ function(gp_resolve_item context item exepath dirs > resolved_item_var) > if(NOT resolved) > if(item MATCHES "^@executable_path") > # > - # @executable_path references are assumed relative to exepath > + # @executable_path references are assumed relative to executable > # > string(REPLACE "@executable_path" "${exepath}" ri "${item}") > get_filename_component(ri "${ri}" ABSOLUTE) > @@ -374,10 +376,11 @@ function(gp_resolve_item context item exepath dirs > resolved_item_var) > # > string(REPLACE "@rpath/" "" norpath_item "${item}") > > + get_item_key("${executable}" key) > set(ri "ri-NOTFOUND") > - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) > + find_file(ri "${norpath_item}" ${dirs} ${${key}_RPATHS} > NO_DEFAULT_PATH) > if(ri) > - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") > + #message(STATUS "info: 'find_file' in exepath/rpaths/dirs (${ri})") > set(resolved 1) > set(resolved_item "${ri}") > set(ri "ri-NOTFOUND") > @@ -436,7 +439,7 @@ function(gp_resolve_item context item exepath dirs > resolved_item_var) > # by whatever logic they choose: > # > if(COMMAND gp_resolve_item_override) > - gp_resolve_item_override("${context}" "${item}" "${exepath}" "${dirs}" > resolved_item resolved) > + gp_resolve_item_override("${context}" "${item}" "${executable}" > "${dirs}" resolved_item resolved) > endif() > > if(NOT resolved) > @@ -459,7 +462,7 @@ warning: cannot resolve item '${item}' > # > # context='${context}' > # item='${item}' > -# exepath='${exepath}' > +# executable='${executable}' > # dirs='${dirs}' > # resolved_item_var='${resolved_item_var}' > #****************************************************************************** > @@ -470,7 +473,7 @@ warning: cannot resolve item '${item}' > endfunction() > > > -function(gp_resolved_file_type original_file file exepath dirs type_var) > +function(gp_resolved_file_type original_file file executable dirs type_var) > #message(STATUS "**") > > if(NOT IS_ABSOLUTE "${original_file}") > @@ -489,7 +492,7 @@ function(gp_resolved_file_type original_file file exepath > dirs type_var) > > if(NOT is_embedded) > if(NOT IS_ABSOLUTE "${file}") > - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" > resolved_file) > + gp_resolve_item("${original_file}" "${file}" "${executable}" "${dirs}" > resolved_file) > endif() > > string(TOLOWER "${original_file}" original_lower) > @@ -595,21 +598,19 @@ function(gp_resolved_file_type original_file file > exepath dirs type_var) > endfunction() > > > -function(gp_file_type original_file file type_var) > +function(gp_file_type original_file file executable type_var) > if(NOT IS_ABSOLUTE "${original_file}") > message(STATUS "warning: gp_file_type expects absolute full path for > first arg original_file") > endif() > > - get_filename_component(exepath "${original_file}" PATH) > - > set(type "") > - gp_resolved_file_type("${original_file}" "${file}" "${exepath}" "" type) > + gp_resolved_file_type("${original_file}" "${file}" "${executable}" "" > type) > > set(${type_var} "${type}" PARENT_SCOPE) > endfunction() > > > -function(get_prerequisites target prerequisites_var exclude_system recurse > exepath dirs) > +function(get_prerequisites target prerequisites_var exclude_system recurse > executable dirs) > set(verbose 0) > set(eol_char "E") > > @@ -738,6 +739,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa > > if("${gp_tool}" STREQUAL "ldd") > set(old_ld_env "$ENV{LD_LIBRARY_PATH}") > + get_filename_component(exepath "${executable}" PATH) > set(new_ld_env "${exepath}") > foreach(dir ${dirs}) > set(new_ld_env "${new_ld_env}:${dir}") > @@ -834,7 +836,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa > > if(add_item AND ${exclude_system}) > set(type "") > - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" > type) > + gp_resolved_file_type("${target}" "${item}" "${executable}" "${dirs}" > type) > > if("${type}" STREQUAL "system") > set(add_item 0) > @@ -855,7 +857,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa > # that the analysis tools can simply accept it as input. > # > if(NOT list_length_before_append EQUAL list_length_after_append) > - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" > resolved_item) > + gp_resolve_item("${target}" "${item}" "${executable}" "${dirs}" > resolved_item) > set(unseen_prereqs ${unseen_prereqs} "${resolved_item}") > endif() > endif() > @@ -874,7 +876,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa > if(${recurse}) > set(more_inputs ${unseen_prereqs}) > foreach(input ${more_inputs}) > - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} > ${recurse} "${exepath}" "${dirs}") > + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} > ${recurse} "${executable}" "${dirs}") > endforeach() > endif() > > @@ -911,7 +913,7 @@ function(list_prerequisites target) > get_filename_component(exepath "${target}" PATH) > > set(prereqs "") > - get_prerequisites("${target}" prereqs ${exclude_system} ${all} > "${exepath}" "") > + get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${target}" > "") > > if(print_target) > message(STATUS "File '${target}' depends on:") > @@ -925,7 +927,7 @@ function(list_prerequisites target) > endif() > > if(print_prerequisite_type) > - gp_file_type("${target}" "${d}" type) > + gp_file_type("${target}" "${d}" "" type) > set(type_str " (${type})") > endif() > > -- > 1.9.3 (Apple Git-50) > > -- > > 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 dlrdave at aol.com Fri Sep 5 11:00:14 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 5 Sep 2014 11:00:14 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion Message-ID: <8D197313BC70D02-15CC-1B293@webmail-m269.sysops.aol.com> > ...I would prefer to combine into something more compact.The other > infrastructure I don't think I have touched but optically it looks > very noisy.Having something that takes away repetitive tasks, more > compact and easier on the eye would be nice. I agree. That would be nice. Feel free to reinvent and re-factor. The ones I put in there were added in a flurry of increasing coverage a few years ago. I was just pointing it out in case you wanted to take advantage of an existing run-this-script pattern we already use. Cheers, D From brad.king at kitware.com Fri Sep 5 11:28:51 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Sep 2014 11:28:51 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5409C610.8030203@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <5409BB47.3000309@kitware.com> <5409BFB0.1060408@gmail.com> <5409C2F9.30600@kitware.com> <5409C610.8030203@gmail.com> Message-ID: <5409D6B3.8090602@kitware.com> On 09/05/2014 10:17 AM, Nils Gladitz wrote: >>> On 09/05/2014 03:31 PM, Brad King wrote: >> >> I think the description of RunCMake can just be updated. >> All of its tests are about running "cmake" command lines. > > So you see no advantage to having the distinction? > > E.g. if you consider testing a set of generators (or variants of the > same generator) possibly non-native and distinct from the generator > being used to build cmake itself it might make sense to run tests which > perform configuration once for each of those but script mode tests would > only have to be run once. RunCMake already has tests of both types, so if we want to make such a distinction then a lot more work is needed. Using CMake_TEST_EXTERNAL_CMAKE we already have a few dashboards that run the CMake test suite using a different generator/compiler than was used to build CMake. The tests that are independent of the compiler/generator tend to be very small and very fast so it does not hurt to run them again. -Brad From ono at java.pl Fri Sep 5 13:23:20 2014 From: ono at java.pl (Adam Strzelecki) Date: Fri, 5 Sep 2014 19:23:20 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <43520581.222701.1409920174530.JavaMail.zimbra@elemtech.com> References: <952D2C19-AD78-4E46-BAE0-B2F0F4DF7C2E@java.pl> <1409917844-28297-3-git-send-email-ono@java.pl> <43520581.222701.1409920174530.JavaMail.zimbra@elemtech.com> Message-ID: <83FCBB60-ECFC-4C9F-8D9A-BBB5321A096E@java.pl> > I think it would be nice to move > get_item_rpaths() from BundleUtilities.cmake to gp_item_get_rpaths() in GetPrerequisites.cmake. Well, this function is generic enough to (possible) serve other routines or even in CMakeLists.txt, so I'd leave it as it is. > And how does your patch or patch set handle @loader_path being used in the rpath? My patch doesn't change anything in this regard, this is handles as it was done previously via ${context} which is expected to be the referencing library/executable. > Also, I think the function signature should include the rpath vs runpath distinction. I realize OS X doesn't have the runpath concept, but if one were to add support for Linux, one may need that where the runpath affects only finding immediate dependencies. Well, this is fine. Can you please submit your patches once my code gets merged. It would be best to do it step by step. WDYT? > Below is what I have for Linux and OS X. > It include rpath vs. runpath, and expands out the @loader_path variable. Well I think this is incorrect, because @loader_path gets expanded to image containing LC_RPATH not image that is actually loading image, which may be different binary (library), e.g.: bin/MyApp -> @rpath/libsome.so lib/libsome.so -> @rpath/libsomeplugin.so lib/plugins/libsomeplugin.so Now let's assume bin/MyApp has following LC_RPATHs: @loader_path/plugins @loader_path/../lib Then with your script plugins/ would be resolved to be bin/plugins/ but in fact dyld will resolve it to lib/plugins/ because it is lib/libsome.so which is loader of @rpath/libsomeplugin.so. > (...) > if(APPLE) > execute_process(COMMAND otool -l "${binary}" > COMMAND grep -A2 LC_RPATH > COMMAND grep path > OUTPUT_VARIABLE paths) > string(REPLACE "\n" ";" paths "${paths}") > foreach(str ${paths}) > string(REGEX REPLACE " path (.*) \\(offset.*" "\\1" rpath "${str}") > string(STRIP "${rpath}" rpath) > string(REPLACE "@loader_path" "${binary_dir}" rpath "${rpath}") > list(APPEND myrpaths "${rpath}") > endforeach() > (...) Current implementation with my patches doesn't do @loader|executable_path substitution in LC_RPATH because of simple reason. If your binary has LC_RPATHs with these then in 99% cases the dependencies are already in the bundle. So only LC_RPATH with absolute paths will cause copy. --Adam From brad.king at kitware.com Fri Sep 5 15:53:06 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 05 Sep 2014 15:53:06 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <355BE46A91031048906B695426A8D8E616ACEC74@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> <5409C1CE.1010501@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC74@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <540A14A2.30904@kitware.com> On 09/05/2014 10:02 AM, Bach, Pascal wrote: >> On 09/05/2014 09:16 AM, Bach, Pascal wrote: >> Since CMakeSystem.cmake loads the CMAKE_TOOLCHAIN_FILE, try_compile >> should use CMAKE_VS_WINCE_SDK when the value is set in the toolchain >> file. Is this the case when you test the changes locally? > > The case I was testing was indeed with the CMAKE_VS_WINCE_SDK set inside the toolchain file. > I guess to support this variable only in the toolchain file is not an option? It would be acceptable for purposes of the initial contribution. How this is best done in the long run may depend on how we choose to generalize (or not) the CMAKE_VS_WINCE_SDK value. Therefore we need to choose that now. If one were compiling for WinCE using a Makefile or Ninja generator, then one would need to have the current environment configured for the proper SDK already. Then the CMake generator would not need to be aware of the SDK or even its name. This is why there are "Win64" and "ARM" variants of the VS generators but not of other generators. This setting is specific to Visual Studio generators, just as the setting for CMAKE_GENERATOR_TOOLSET is generator-specific (though that one is meaningful to the Xcode generator too). Although WinCE uses it to choose the SDK, from the VS generator point of view it is just the value. The value does for exactly what CMAKE_GENERATOR_TOOLSET does for . I think "CMAKE_GENERATOR_PLATFORM" may be a suitable name. Ideally this setting should be added as a general-purpose replacement for putting "ARM" or "Win64" in the generator name. The changes for that are more sweeping than I'd like to ask of you just for WinCE support, so I drafted them myself. Please fetch as: git fetch https://github.com/bradking/CMake vs-generator-platform and rebase your topic on that to try it out. Of course there is no need to send my part as patches, just your revised patch(es). Thanks, -Brad From aleixpol at kde.org Sat Sep 6 09:38:09 2014 From: aleixpol at kde.org (Aleix Pol) Date: Sat, 6 Sep 2014 15:38: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> Message-ID: On Wed, Sep 3, 2014 at 6:12 PM, Aleix Pol wrote: > On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf > wrote: > >> On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote: >> > On Tue, Sep 2, 2014 at 3:58 PM, David Cole wrote: >> > > It makes sense. But what IDE are you referring to? Eclipse? Some other >> > > concrete example? Or just "any IDE and this feature should work >> everywhere >> > > CMake works...?" >> > >> > I'm working on KDevelop, I know for a fact though, that other IDEs are >> > looking for something similar too, such as QtCreator. >> >> I still don't understand why this shouldn't be an additional >> ExtraGenerator. >> It will generate a special file intended to be used by KDevelop and maybe >> QtCreator additionally to makefiles/ninja files. Could be called >> "GenericJSON" >> or so. >> Other IDEs which don't support this file type but which need their own >> project >> file obviously still need their own specific generator. >> >> Alex >> > > Because it's not possible to change the generator of a build directory > once it's set up. You need to nuke it and re-create it. > Also because changing the generator could potentially change the > interaction the user has with the build directory, we don't want to get in > the way. > > Aleix > Bump! Can I get some pointers about how to proceed? Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sat Sep 6 15:19:44 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 6 Sep 2014 15:19:44 -0400 Subject: [cmake-developers] [CMake 0015131]: "trace.c", line 219: error: identifier redeclared: trace_strbuf Message-ID: <942d07000c38acb3b147babc14f976de@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15131 ====================================================================== Reported By: dev Assigned To: ====================================================================== Project: CMake Issue ID: 15131 Category: CMake Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-06 15:19 EDT Last Modified: 2014-09-06 15:19 EDT ====================================================================== Summary: "trace.c", line 219: error: identifier redeclared: trace_strbuf Description: Build on Solaris 10 fails thus : CC tag.o CC trace.o "trace.c", line 219: error: identifier redeclared: trace_strbuf current : function(pointer to const char, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void previous: function(pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1}, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void : "trace.h", line 33 "trace.c", line 221: warning: argument http://public.kitware.com/Bug/view.php?id=3 is incompatible with prototype: prototype: pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1} : "trace.c", line 160 argument : pointer to const char "trace.c", line 390: error: reference to static identifier "offset" in extern inline function "trace.c", line 392: error: reference to static identifier "offset" in extern inline function "trace.c", line 393: error: reference to static identifier "offset" in extern inline function "trace.c", line 401: error: reference to static identifier "offset" in extern inline function "trace.c", line 403: error: reference to static identifier "offset" in extern inline function cc: acomp failed for trace.c gmake: *** [trace.o] Error 2 Steps to Reproduce: extracted the tarball and did the following : $ gmake CFLAGS="$CFLAGS" LDFLAGS="$LD_OPTIONS" NEEDS_LIBICONV=Yes \ > SHELL_PATH=/usr/local/bin/bash \ > SANE_TOOL_PATH=/usr/local/bin \ > USE_LIBPCRE=1 LIBPCREDIR=/usr/local CURLDIR=/usr/local \ > EXPATDIR=/usr/local NEEDS_LIBINTL_BEFORE_LIBICONV=1 \ > NEEDS_SOCKET=1 NEEDS_RESOLV=1 USE_NSEC=1 \ > PERL_PATH=/usr/local/bin/perl \ > TAR=/usr/bin/tar \ > NO_PYTHON=1 DEFAULT_PAGER=/usr/xpg4/bin/more \ > DEFAULT_EDITOR=/usr/local/bin/vim DEFAULT_HELP_FORMAT=man \ > prefix=/usr/local GIT_VERSION = 2.1.0 * new build flags CC credential-store.o * new link flags CC abspath.o CC advice.o CC alias.o CC alloc.o CC archive.o CC archive-tar.o CC archive-zip.o CC argv-array.o * new prefix flags CC attr.o CC base85.o CC bisect.o CC blob.o CC branch.o CC bulk-checkin.o CC bundle.o CC cache-tree.o CC color.o CC column.o CC combine-diff.o CC commit.o CC compat/obstack.o CC compat/terminal.o CC config.o CC connect.o CC connected.o CC convert.o CC copy.o CC credential.o CC csum-file.o CC ctype.o "ctype.c", line 50: warning: initializer does not fit or is out of range: 128 "ctype.c", line 50: warning: initializer does not fit or is out of range: 129 "ctype.c", line 50: warning: initializer does not fit or is out of range: 130 "ctype.c", line 50: warning: initializer does not fit or is out of range: 131 "ctype.c", line 50: warning: initializer does not fit or is out of range: 132 "ctype.c", line 50: warning: initializer does not fit or is out of range: 133 "ctype.c", line 50: warning: initializer does not fit or is out of range: 134 "ctype.c", line 50: warning: initializer does not fit or is out of range: 135 "ctype.c", line 51: warning: initializer does not fit or is out of range: 136 "ctype.c", line 51: warning: initializer does not fit or is out of range: 137 "ctype.c", line 51: warning: initializer does not fit or is out of range: 138 "ctype.c", line 51: warning: initializer does not fit or is out of range: 139 "ctype.c", line 51: warning: initializer does not fit or is out of range: 140 "ctype.c", line 51: warning: initializer does not fit or is out of range: 141 "ctype.c", line 51: warning: initializer does not fit or is out of range: 142 "ctype.c", line 51: warning: initializer does not fit or is out of range: 143 "ctype.c", line 52: warning: initializer does not fit or is out of range: 144 "ctype.c", line 52: warning: initializer does not fit or is out of range: 145 "ctype.c", line 52: warning: initializer does not fit or is out of range: 146 "ctype.c", line 52: warning: initializer does not fit or is out of range: 147 "ctype.c", line 52: warning: initializer does not fit or is out of range: 148 "ctype.c", line 52: warning: initializer does not fit or is out of range: 149 "ctype.c", line 52: warning: initializer does not fit or is out of range: 150 "ctype.c", line 52: warning: initializer does not fit or is out of range: 151 "ctype.c", line 53: warning: initializer does not fit or is out of range: 152 "ctype.c", line 53: warning: initializer does not fit or is out of range: 153 "ctype.c", line 53: warning: initializer does not fit or is out of range: 154 "ctype.c", line 53: warning: initializer does not fit or is out of range: 155 "ctype.c", line 53: warning: initializer does not fit or is out of range: 156 "ctype.c", line 53: warning: initializer does not fit or is out of range: 157 "ctype.c", line 53: warning: initializer does not fit or is out of range: 158 "ctype.c", line 53: warning: initializer does not fit or is out of range: 159 "ctype.c", line 54: warning: initializer does not fit or is out of range: 160 "ctype.c", line 54: warning: initializer does not fit or is out of range: 161 "ctype.c", line 54: warning: initializer does not fit or is out of range: 162 "ctype.c", line 54: warning: initializer does not fit or is out of range: 163 "ctype.c", line 54: warning: initializer does not fit or is out of range: 164 "ctype.c", line 54: warning: initializer does not fit or is out of range: 165 "ctype.c", line 54: warning: initializer does not fit or is out of range: 166 "ctype.c", line 54: warning: initializer does not fit or is out of range: 167 "ctype.c", line 55: warning: initializer does not fit or is out of range: 168 "ctype.c", line 55: warning: initializer does not fit or is out of range: 169 "ctype.c", line 55: warning: initializer does not fit or is out of range: 170 "ctype.c", line 55: warning: initializer does not fit or is out of range: 171 "ctype.c", line 55: warning: initializer does not fit or is out of range: 172 "ctype.c", line 55: warning: initializer does not fit or is out of range: 173 "ctype.c", line 55: warning: initializer does not fit or is out of range: 174 "ctype.c", line 55: warning: initializer does not fit or is out of range: 175 "ctype.c", line 56: warning: initializer does not fit or is out of range: 176 "ctype.c", line 56: warning: initializer does not fit or is out of range: 177 "ctype.c", line 56: warning: initializer does not fit or is out of range: 178 "ctype.c", line 56: warning: initializer does not fit or is out of range: 179 "ctype.c", line 56: warning: initializer does not fit or is out of range: 180 "ctype.c", line 56: warning: initializer does not fit or is out of range: 181 "ctype.c", line 56: warning: initializer does not fit or is out of range: 182 "ctype.c", line 56: warning: initializer does not fit or is out of range: 183 "ctype.c", line 57: warning: initializer does not fit or is out of range: 184 "ctype.c", line 57: warning: initializer does not fit or is out of range: 185 "ctype.c", line 57: warning: initializer does not fit or is out of range: 186 "ctype.c", line 57: warning: initializer does not fit or is out of range: 187 "ctype.c", line 57: warning: initializer does not fit or is out of range: 188 "ctype.c", line 57: warning: initializer does not fit or is out of range: 189 "ctype.c", line 57: warning: initializer does not fit or is out of range: 190 "ctype.c", line 57: warning: initializer does not fit or is out of range: 191 "ctype.c", line 58: warning: initializer does not fit or is out of range: 192 "ctype.c", line 58: warning: initializer does not fit or is out of range: 193 "ctype.c", line 58: warning: initializer does not fit or is out of range: 194 "ctype.c", line 58: warning: initializer does not fit or is out of range: 195 "ctype.c", line 58: warning: initializer does not fit or is out of range: 196 "ctype.c", line 58: warning: initializer does not fit or is out of range: 197 "ctype.c", line 58: warning: initializer does not fit or is out of range: 198 "ctype.c", line 58: warning: initializer does not fit or is out of range: 199 "ctype.c", line 59: warning: initializer does not fit or is out of range: 200 "ctype.c", line 59: warning: initializer does not fit or is out of range: 201 "ctype.c", line 59: warning: initializer does not fit or is out of range: 202 "ctype.c", line 59: warning: initializer does not fit or is out of range: 203 "ctype.c", line 59: warning: initializer does not fit or is out of range: 204 "ctype.c", line 59: warning: initializer does not fit or is out of range: 205 "ctype.c", line 59: warning: initializer does not fit or is out of range: 206 "ctype.c", line 59: warning: initializer does not fit or is out of range: 207 "ctype.c", line 60: warning: initializer does not fit or is out of range: 208 "ctype.c", line 60: warning: initializer does not fit or is out of range: 209 "ctype.c", line 60: warning: initializer does not fit or is out of range: 210 "ctype.c", line 60: warning: initializer does not fit or is out of range: 211 "ctype.c", line 60: warning: initializer does not fit or is out of range: 212 "ctype.c", line 60: warning: initializer does not fit or is out of range: 213 "ctype.c", line 60: warning: initializer does not fit or is out of range: 214 "ctype.c", line 60: warning: initializer does not fit or is out of range: 215 "ctype.c", line 61: warning: initializer does not fit or is out of range: 216 "ctype.c", line 61: warning: initializer does not fit or is out of range: 217 "ctype.c", line 61: warning: initializer does not fit or is out of range: 218 "ctype.c", line 61: warning: initializer does not fit or is out of range: 219 "ctype.c", line 61: warning: initializer does not fit or is out of range: 220 "ctype.c", line 61: warning: initializer does not fit or is out of range: 221 "ctype.c", line 61: warning: initializer does not fit or is out of range: 222 "ctype.c", line 61: warning: initializer does not fit or is out of range: 223 "ctype.c", line 62: warning: initializer does not fit or is out of range: 224 "ctype.c", line 62: warning: initializer does not fit or is out of range: 225 "ctype.c", line 62: warning: initializer does not fit or is out of range: 226 "ctype.c", line 62: warning: initializer does not fit or is out of range: 227 "ctype.c", line 62: warning: initializer does not fit or is out of range: 228 "ctype.c", line 62: warning: initializer does not fit or is out of range: 229 "ctype.c", line 62: warning: initializer does not fit or is out of range: 230 "ctype.c", line 62: warning: initializer does not fit or is out of range: 231 "ctype.c", line 63: warning: initializer does not fit or is out of range: 232 "ctype.c", line 63: warning: initializer does not fit or is out of range: 233 "ctype.c", line 63: warning: initializer does not fit or is out of range: 234 "ctype.c", line 63: warning: initializer does not fit or is out of range: 235 "ctype.c", line 63: warning: initializer does not fit or is out of range: 236 "ctype.c", line 63: warning: initializer does not fit or is out of range: 237 "ctype.c", line 63: warning: initializer does not fit or is out of range: 238 "ctype.c", line 63: warning: initializer does not fit or is out of range: 239 "ctype.c", line 64: warning: initializer does not fit or is out of range: 240 "ctype.c", line 64: warning: initializer does not fit or is out of range: 241 "ctype.c", line 64: warning: initializer does not fit or is out of range: 242 "ctype.c", line 64: warning: initializer does not fit or is out of range: 243 "ctype.c", line 64: warning: initializer does not fit or is out of range: 244 "ctype.c", line 64: warning: initializer does not fit or is out of range: 245 "ctype.c", line 64: warning: initializer does not fit or is out of range: 246 "ctype.c", line 64: warning: initializer does not fit or is out of range: 247 "ctype.c", line 65: warning: initializer does not fit or is out of range: 248 "ctype.c", line 65: warning: initializer does not fit or is out of range: 249 "ctype.c", line 65: warning: initializer does not fit or is out of range: 250 "ctype.c", line 65: warning: initializer does not fit or is out of range: 251 "ctype.c", line 65: warning: initializer does not fit or is out of range: 252 "ctype.c", line 65: warning: initializer does not fit or is out of range: 253 "ctype.c", line 65: warning: initializer does not fit or is out of range: 254 "ctype.c", line 65: warning: initializer does not fit or is out of range: 255 CC date.o CC decorate.o CC diffcore-break.o CC diffcore-delta.o CC diffcore-order.o CC diffcore-pickaxe.o CC diffcore-rename.o CC diff-delta.o CC diff-lib.o CC diff-no-index.o CC diff.o CC dir.o CC editor.o CC entry.o CC environment.o CC ewah/bitmap.o CC ewah/ewah_bitmap.o CC ewah/ewah_io.o CC ewah/ewah_rlw.o CC exec_cmd.o CC fetch-pack.o CC fsck.o CC gettext.o CC gpg-interface.o CC graph.o CC grep.o CC hashmap.o GEN common-cmds.h CC help.o CC hex.o CC ident.o CC kwset.o CC levenshtein.o CC line-log.o CC line-range.o CC list-objects.o CC ll-merge.o CC lockfile.o CC log-tree.o CC mailmap.o CC match-trees.o CC merge.o CC merge-blobs.o CC merge-recursive.o CC mergesort.o CC name-hash.o CC notes.o CC notes-cache.o CC notes-merge.o CC notes-utils.o CC object.o CC pack-bitmap.o CC pack-bitmap-write.o CC pack-check.o CC pack-objects.o CC pack-revindex.o CC pack-write.o CC pager.o CC parse-options.o CC parse-options-cb.o CC patch-delta.o CC patch-ids.o CC path.o CC pathspec.o CC pkt-line.o CC preload-index.o CC pretty.o CC prio-queue.o CC progress.o CC prompt.o CC quote.o CC reachable.o CC read-cache.o "read-cache.c", line 799: warning: statement not reached CC reflog-walk.o CC refs.o CC remote.o CC replace_object.o CC rerere.o CC resolve-undo.o CC revision.o CC run-command.o CC send-pack.o CC sequencer.o CC server-info.o CC setup.o CC sha1-array.o CC sha1-lookup.o CC sha1_file.o CC sha1_name.o CC shallow.o CC sideband.o CC sigchain.o CC split-index.o CC strbuf.o CC streaming.o CC string-list.o CC submodule.o CC symlinks.o CC tag.o CC trace.o "trace.c", line 219: error: identifier redeclared: trace_strbuf current : function(pointer to const char, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void previous: function(pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1}, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void : "trace.h", line 33 "trace.c", line 221: warning: argument http://public.kitware.com/Bug/view.php?id=3 is incompatible with prototype: prototype: pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1} : "trace.c", line 160 argument : pointer to const char "trace.c", line 390: error: reference to static identifier "offset" in extern inline function "trace.c", line 392: error: reference to static identifier "offset" in extern inline function "trace.c", line 393: error: reference to static identifier "offset" in extern inline function "trace.c", line 401: error: reference to static identifier "offset" in extern inline function "trace.c", line 403: error: reference to static identifier "offset" in extern inline function cc: acomp failed for trace.c gmake: *** [trace.o] Error 2 Additional Information: Solaris 10 with Oracle Studio 12.3 compiler tools. A lengthy maillist discussion last week sorted out the previous release of git just fine however this release fails to build. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-06 15:19 dev New Issue ====================================================================== From dev at cor0.com Sat Sep 6 15:21:48 2014 From: dev at cor0.com (dev) Date: Sat, 6 Sep 2014 15:21:48 -0400 (EDT) Subject: [cmake-developers] [CMake 0015131]: "trace.c", line 219: error: identifier redeclared: trace_strbuf In-Reply-To: <942d07000c38acb3b147babc14f976de@public.kitware.com> References: <942d07000c38acb3b147babc14f976de@public.kitware.com> Message-ID: <1768689012.24006.1410031308041.JavaMail.vpopmail@webmail2.networksolutionsemail.com> well this is a new one on me ... totally wrong mantis site .. nice bug report however. someone delete this and taser me :-( -------------------------------------------- On September 6, 2014 at 3:19 PM Mantis Bug Tracker wrote: > > The following issue has been SUBMITTED. > ====================================================================== > http://public.kitware.com/Bug/view.php?id=15131 > ====================================================================== From mantis at public.kitware.com Sat Sep 6 15:26:04 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 6 Sep 2014 15:26:04 -0400 Subject: [cmake-developers] [CMake 0015132]: find_library retrieves libraries from $PATH even when they can be found in the proper locations. Message-ID: <4590972ae35b81079cbb00e02ee9d99a@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15132 ====================================================================== Reported By: Greg Jung Assigned To: ====================================================================== Project: CMake Issue ID: 15132 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-06 15:26 EDT Last Modified: 2014-09-06 15:26 EDT ====================================================================== Summary: find_library retrieves libraries from $PATH even when they can be found in the proper locations. Description: Contrary to documentation, find_library usurps my intention when it has an apparent match from $ENV{PATH}. This also occurs if I specify the preference explicitly via CMAKE_PREFIX_PATH: if the library is found in program path, it picks those up for linkage instead of the specified preference. In the folowing example, I happen to have only one of the libraries fftw3, fftw3f in my /local32/lib. So the FFTWDIR is set to pick up libraries as in FindFFTW.cmake: CMakeLists.txt: set(CMAKE_PREFIX_PATH ${FFTWDIR}) find_package(FFTW QUIET) FindFFTW.cmake: find_library(FFTW_LIBRARY NAMES fftw3) message(STATUS " FFTW_LIBRARY: ${FFTW_LIBRARY}") find_library(FFTWF_LIBRARY NAMES fftw3f) message(STATUS " FFTWF_LIBRARY: ${FFTWF_LIBRARY}") set(FFTW_LIBRARIES ${FFTW_LIBRARY} ${FFTWF_LIBRARY}) find_path(FFTW_INCLUDE_DIR NAMES fftw3.h) result: CMakeCache.txt //GDL: Specifiy the FFTW directory tree FFTWDIR:PATH=D:/programs/win32libs //Path to a library. FFTWF_LIBRARY:FILEPATH=D:/programs/win32libs/lib/libfftw3f.a //Path to a file. FFTW_INCLUDE_DIR:PATH=E:/mingw/local32/include //Path to a library. FFTW_LIBRARY:FILEPATH=E:/mingw/local32/lib/libfftw3.a Steps to Reproduce: put an acceptable library file in your %PATH%, run cmake: SET(CMAKE_PREFIX_PATH "c:/proper/lib") find_library(WRONG libname) Additional Information: In cygwin, I set LDFLAGS="-L/opt/local/lib -L/usr/local/lib" which are ingested, with my modified Platform/UnixPaths.cmake, into CMAKE_SYSTEM_LIBRARY_PATH and into CMAKE_SYSTEM_INCLUDE_PATH. inspecting LDFLAGS: -L/opt/local/lib -L/usr/local/lib adding system library path: /opt/local/lib adding system library path: /usr/local/lib so according to the docs, CMAKE_SYSTEM_LIBRARY_PATH and CMAKE_SYSTEM_INCLUDE_PATH will be utilized in find_library and in find_path, respectively. Instead I get Junk from the mingw side bleeding into it because I have an application directory in %PATH%: PLPLOT_LIBRARY: /cygdrive/d/programs/libplplotd.dll.a FindPlplot> PLPLOT_LIBRARY_DIR: /cygdrive/d/programs PLPLOT_INCLUDE=? /cygdrive/d/programs/../include Found PLPLOT: /cygdrive/d/programs/libplplotd.dll.a;/cygdrive/d/programs/libplplotcxxd.dll.a (errors due to bad linkage) Looking for c_plslabelfunc in /cygdrive/d/programs/libplplotd.dll.a;/cygdrive/d/programs/libplplotcxxd.dll.a Looking for c_plslabelfunc in /cygdrive/d/programs/libplplotd.dll.a;/cygdrive/d/programs/libplplotcxxd.dll.a - not found Of course, I reset my $PATH for the cygwin to run right, but the find_library behavior is wrong. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-06 15:26 Greg Jung New Issue 2014-09-06 15:26 Greg Jung File Added: cmakebug ====================================================================== From mantis at public.kitware.com Sat Sep 6 16:12:22 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 6 Sep 2014 16:12:22 -0400 Subject: [cmake-developers] [CMake 0015131]: "trace.c", line 219: error: identifier redeclared: trace_strbuf In-Reply-To: <942d07000c38acb3b147babc14f976de@public.kitware.com> Message-ID: The following issue has been DELETED. ====================================================================== Reported By: dev Assigned To: ====================================================================== Project: CMake Issue ID: 15131 Category: CMake Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-06 15:19 EDT Last Modified: 2014-09-06 15:22 EDT ====================================================================== Summary: "trace.c", line 219: error: identifier redeclared: trace_strbuf Description: Build on Solaris 10 fails thus : CC tag.o CC trace.o "trace.c", line 219: error: identifier redeclared: trace_strbuf current : function(pointer to const char, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void previous: function(pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1}, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void : "trace.h", line 33 "trace.c", line 221: warning: argument http://public.kitware.com/Bug/view.php?id=3 is incompatible with prototype: prototype: pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1} : "trace.c", line 160 argument : pointer to const char "trace.c", line 390: error: reference to static identifier "offset" in extern inline function "trace.c", line 392: error: reference to static identifier "offset" in extern inline function "trace.c", line 393: error: reference to static identifier "offset" in extern inline function "trace.c", line 401: error: reference to static identifier "offset" in extern inline function "trace.c", line 403: error: reference to static identifier "offset" in extern inline function cc: acomp failed for trace.c gmake: *** [trace.o] Error 2 Steps to Reproduce: extracted the tarball and did the following : $ gmake CFLAGS="$CFLAGS" LDFLAGS="$LD_OPTIONS" NEEDS_LIBICONV=Yes \ > SHELL_PATH=/usr/local/bin/bash \ > SANE_TOOL_PATH=/usr/local/bin \ > USE_LIBPCRE=1 LIBPCREDIR=/usr/local CURLDIR=/usr/local \ > EXPATDIR=/usr/local NEEDS_LIBINTL_BEFORE_LIBICONV=1 \ > NEEDS_SOCKET=1 NEEDS_RESOLV=1 USE_NSEC=1 \ > PERL_PATH=/usr/local/bin/perl \ > TAR=/usr/bin/tar \ > NO_PYTHON=1 DEFAULT_PAGER=/usr/xpg4/bin/more \ > DEFAULT_EDITOR=/usr/local/bin/vim DEFAULT_HELP_FORMAT=man \ > prefix=/usr/local GIT_VERSION = 2.1.0 * new build flags CC credential-store.o * new link flags CC abspath.o CC advice.o CC alias.o CC alloc.o CC archive.o CC archive-tar.o CC archive-zip.o CC argv-array.o * new prefix flags CC attr.o CC base85.o CC bisect.o CC blob.o CC branch.o CC bulk-checkin.o CC bundle.o CC cache-tree.o CC color.o CC column.o CC combine-diff.o CC commit.o CC compat/obstack.o CC compat/terminal.o CC config.o CC connect.o CC connected.o CC convert.o CC copy.o CC credential.o CC csum-file.o CC ctype.o "ctype.c", line 50: warning: initializer does not fit or is out of range: 128 "ctype.c", line 50: warning: initializer does not fit or is out of range: 129 "ctype.c", line 50: warning: initializer does not fit or is out of range: 130 "ctype.c", line 50: warning: initializer does not fit or is out of range: 131 "ctype.c", line 50: warning: initializer does not fit or is out of range: 132 "ctype.c", line 50: warning: initializer does not fit or is out of range: 133 "ctype.c", line 50: warning: initializer does not fit or is out of range: 134 "ctype.c", line 50: warning: initializer does not fit or is out of range: 135 "ctype.c", line 51: warning: initializer does not fit or is out of range: 136 "ctype.c", line 51: warning: initializer does not fit or is out of range: 137 "ctype.c", line 51: warning: initializer does not fit or is out of range: 138 "ctype.c", line 51: warning: initializer does not fit or is out of range: 139 "ctype.c", line 51: warning: initializer does not fit or is out of range: 140 "ctype.c", line 51: warning: initializer does not fit or is out of range: 141 "ctype.c", line 51: warning: initializer does not fit or is out of range: 142 "ctype.c", line 51: warning: initializer does not fit or is out of range: 143 "ctype.c", line 52: warning: initializer does not fit or is out of range: 144 "ctype.c", line 52: warning: initializer does not fit or is out of range: 145 "ctype.c", line 52: warning: initializer does not fit or is out of range: 146 "ctype.c", line 52: warning: initializer does not fit or is out of range: 147 "ctype.c", line 52: warning: initializer does not fit or is out of range: 148 "ctype.c", line 52: warning: initializer does not fit or is out of range: 149 "ctype.c", line 52: warning: initializer does not fit or is out of range: 150 "ctype.c", line 52: warning: initializer does not fit or is out of range: 151 "ctype.c", line 53: warning: initializer does not fit or is out of range: 152 "ctype.c", line 53: warning: initializer does not fit or is out of range: 153 "ctype.c", line 53: warning: initializer does not fit or is out of range: 154 "ctype.c", line 53: warning: initializer does not fit or is out of range: 155 "ctype.c", line 53: warning: initializer does not fit or is out of range: 156 "ctype.c", line 53: warning: initializer does not fit or is out of range: 157 "ctype.c", line 53: warning: initializer does not fit or is out of range: 158 "ctype.c", line 53: warning: initializer does not fit or is out of range: 159 "ctype.c", line 54: warning: initializer does not fit or is out of range: 160 "ctype.c", line 54: warning: initializer does not fit or is out of range: 161 "ctype.c", line 54: warning: initializer does not fit or is out of range: 162 "ctype.c", line 54: warning: initializer does not fit or is out of range: 163 "ctype.c", line 54: warning: initializer does not fit or is out of range: 164 "ctype.c", line 54: warning: initializer does not fit or is out of range: 165 "ctype.c", line 54: warning: initializer does not fit or is out of range: 166 "ctype.c", line 54: warning: initializer does not fit or is out of range: 167 "ctype.c", line 55: warning: initializer does not fit or is out of range: 168 "ctype.c", line 55: warning: initializer does not fit or is out of range: 169 "ctype.c", line 55: warning: initializer does not fit or is out of range: 170 "ctype.c", line 55: warning: initializer does not fit or is out of range: 171 "ctype.c", line 55: warning: initializer does not fit or is out of range: 172 "ctype.c", line 55: warning: initializer does not fit or is out of range: 173 "ctype.c", line 55: warning: initializer does not fit or is out of range: 174 "ctype.c", line 55: warning: initializer does not fit or is out of range: 175 "ctype.c", line 56: warning: initializer does not fit or is out of range: 176 "ctype.c", line 56: warning: initializer does not fit or is out of range: 177 "ctype.c", line 56: warning: initializer does not fit or is out of range: 178 "ctype.c", line 56: warning: initializer does not fit or is out of range: 179 "ctype.c", line 56: warning: initializer does not fit or is out of range: 180 "ctype.c", line 56: warning: initializer does not fit or is out of range: 181 "ctype.c", line 56: warning: initializer does not fit or is out of range: 182 "ctype.c", line 56: warning: initializer does not fit or is out of range: 183 "ctype.c", line 57: warning: initializer does not fit or is out of range: 184 "ctype.c", line 57: warning: initializer does not fit or is out of range: 185 "ctype.c", line 57: warning: initializer does not fit or is out of range: 186 "ctype.c", line 57: warning: initializer does not fit or is out of range: 187 "ctype.c", line 57: warning: initializer does not fit or is out of range: 188 "ctype.c", line 57: warning: initializer does not fit or is out of range: 189 "ctype.c", line 57: warning: initializer does not fit or is out of range: 190 "ctype.c", line 57: warning: initializer does not fit or is out of range: 191 "ctype.c", line 58: warning: initializer does not fit or is out of range: 192 "ctype.c", line 58: warning: initializer does not fit or is out of range: 193 "ctype.c", line 58: warning: initializer does not fit or is out of range: 194 "ctype.c", line 58: warning: initializer does not fit or is out of range: 195 "ctype.c", line 58: warning: initializer does not fit or is out of range: 196 "ctype.c", line 58: warning: initializer does not fit or is out of range: 197 "ctype.c", line 58: warning: initializer does not fit or is out of range: 198 "ctype.c", line 58: warning: initializer does not fit or is out of range: 199 "ctype.c", line 59: warning: initializer does not fit or is out of range: 200 "ctype.c", line 59: warning: initializer does not fit or is out of range: 201 "ctype.c", line 59: warning: initializer does not fit or is out of range: 202 "ctype.c", line 59: warning: initializer does not fit or is out of range: 203 "ctype.c", line 59: warning: initializer does not fit or is out of range: 204 "ctype.c", line 59: warning: initializer does not fit or is out of range: 205 "ctype.c", line 59: warning: initializer does not fit or is out of range: 206 "ctype.c", line 59: warning: initializer does not fit or is out of range: 207 "ctype.c", line 60: warning: initializer does not fit or is out of range: 208 "ctype.c", line 60: warning: initializer does not fit or is out of range: 209 "ctype.c", line 60: warning: initializer does not fit or is out of range: 210 "ctype.c", line 60: warning: initializer does not fit or is out of range: 211 "ctype.c", line 60: warning: initializer does not fit or is out of range: 212 "ctype.c", line 60: warning: initializer does not fit or is out of range: 213 "ctype.c", line 60: warning: initializer does not fit or is out of range: 214 "ctype.c", line 60: warning: initializer does not fit or is out of range: 215 "ctype.c", line 61: warning: initializer does not fit or is out of range: 216 "ctype.c", line 61: warning: initializer does not fit or is out of range: 217 "ctype.c", line 61: warning: initializer does not fit or is out of range: 218 "ctype.c", line 61: warning: initializer does not fit or is out of range: 219 "ctype.c", line 61: warning: initializer does not fit or is out of range: 220 "ctype.c", line 61: warning: initializer does not fit or is out of range: 221 "ctype.c", line 61: warning: initializer does not fit or is out of range: 222 "ctype.c", line 61: warning: initializer does not fit or is out of range: 223 "ctype.c", line 62: warning: initializer does not fit or is out of range: 224 "ctype.c", line 62: warning: initializer does not fit or is out of range: 225 "ctype.c", line 62: warning: initializer does not fit or is out of range: 226 "ctype.c", line 62: warning: initializer does not fit or is out of range: 227 "ctype.c", line 62: warning: initializer does not fit or is out of range: 228 "ctype.c", line 62: warning: initializer does not fit or is out of range: 229 "ctype.c", line 62: warning: initializer does not fit or is out of range: 230 "ctype.c", line 62: warning: initializer does not fit or is out of range: 231 "ctype.c", line 63: warning: initializer does not fit or is out of range: 232 "ctype.c", line 63: warning: initializer does not fit or is out of range: 233 "ctype.c", line 63: warning: initializer does not fit or is out of range: 234 "ctype.c", line 63: warning: initializer does not fit or is out of range: 235 "ctype.c", line 63: warning: initializer does not fit or is out of range: 236 "ctype.c", line 63: warning: initializer does not fit or is out of range: 237 "ctype.c", line 63: warning: initializer does not fit or is out of range: 238 "ctype.c", line 63: warning: initializer does not fit or is out of range: 239 "ctype.c", line 64: warning: initializer does not fit or is out of range: 240 "ctype.c", line 64: warning: initializer does not fit or is out of range: 241 "ctype.c", line 64: warning: initializer does not fit or is out of range: 242 "ctype.c", line 64: warning: initializer does not fit or is out of range: 243 "ctype.c", line 64: warning: initializer does not fit or is out of range: 244 "ctype.c", line 64: warning: initializer does not fit or is out of range: 245 "ctype.c", line 64: warning: initializer does not fit or is out of range: 246 "ctype.c", line 64: warning: initializer does not fit or is out of range: 247 "ctype.c", line 65: warning: initializer does not fit or is out of range: 248 "ctype.c", line 65: warning: initializer does not fit or is out of range: 249 "ctype.c", line 65: warning: initializer does not fit or is out of range: 250 "ctype.c", line 65: warning: initializer does not fit or is out of range: 251 "ctype.c", line 65: warning: initializer does not fit or is out of range: 252 "ctype.c", line 65: warning: initializer does not fit or is out of range: 253 "ctype.c", line 65: warning: initializer does not fit or is out of range: 254 "ctype.c", line 65: warning: initializer does not fit or is out of range: 255 CC date.o CC decorate.o CC diffcore-break.o CC diffcore-delta.o CC diffcore-order.o CC diffcore-pickaxe.o CC diffcore-rename.o CC diff-delta.o CC diff-lib.o CC diff-no-index.o CC diff.o CC dir.o CC editor.o CC entry.o CC environment.o CC ewah/bitmap.o CC ewah/ewah_bitmap.o CC ewah/ewah_io.o CC ewah/ewah_rlw.o CC exec_cmd.o CC fetch-pack.o CC fsck.o CC gettext.o CC gpg-interface.o CC graph.o CC grep.o CC hashmap.o GEN common-cmds.h CC help.o CC hex.o CC ident.o CC kwset.o CC levenshtein.o CC line-log.o CC line-range.o CC list-objects.o CC ll-merge.o CC lockfile.o CC log-tree.o CC mailmap.o CC match-trees.o CC merge.o CC merge-blobs.o CC merge-recursive.o CC mergesort.o CC name-hash.o CC notes.o CC notes-cache.o CC notes-merge.o CC notes-utils.o CC object.o CC pack-bitmap.o CC pack-bitmap-write.o CC pack-check.o CC pack-objects.o CC pack-revindex.o CC pack-write.o CC pager.o CC parse-options.o CC parse-options-cb.o CC patch-delta.o CC patch-ids.o CC path.o CC pathspec.o CC pkt-line.o CC preload-index.o CC pretty.o CC prio-queue.o CC progress.o CC prompt.o CC quote.o CC reachable.o CC read-cache.o "read-cache.c", line 799: warning: statement not reached CC reflog-walk.o CC refs.o CC remote.o CC replace_object.o CC rerere.o CC resolve-undo.o CC revision.o CC run-command.o CC send-pack.o CC sequencer.o CC server-info.o CC setup.o CC sha1-array.o CC sha1-lookup.o CC sha1_file.o CC sha1_name.o CC shallow.o CC sideband.o CC sigchain.o CC split-index.o CC strbuf.o CC streaming.o CC string-list.o CC submodule.o CC symlinks.o CC tag.o CC trace.o "trace.c", line 219: error: identifier redeclared: trace_strbuf current : function(pointer to const char, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void previous: function(pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1}, pointer to const struct strbuf {unsigned long alloc, unsigned long len, pointer to char buf}) returning void : "trace.h", line 33 "trace.c", line 221: warning: argument http://public.kitware.com/Bug/view.php?id=3 is incompatible with prototype: prototype: pointer to struct trace_key {const pointer to const char key, int fd, unsigned int initialized :1, unsigned int need_close :1} : "trace.c", line 160 argument : pointer to const char "trace.c", line 390: error: reference to static identifier "offset" in extern inline function "trace.c", line 392: error: reference to static identifier "offset" in extern inline function "trace.c", line 393: error: reference to static identifier "offset" in extern inline function "trace.c", line 401: error: reference to static identifier "offset" in extern inline function "trace.c", line 403: error: reference to static identifier "offset" in extern inline function cc: acomp failed for trace.c gmake: *** [trace.o] Error 2 Additional Information: Solaris 10 with Oracle Studio 12.3 compiler tools. A lengthy maillist discussion last week sorted out the previous release of git just fine however this release fails to build. ====================================================================== ---------------------------------------------------------------------- (0036735) dev (reporter) - 2014-09-06 15:22 http://public.kitware.com/Bug/view.php?id=15131#c36735 ---------------------------------------------------------------------- Someone delete this before it grows legs and tasers me. Wrong mantis site entirely. Issue History Date Modified Username Field Change ====================================================================== 2014-09-06 15:19 dev New Issue 2014-09-06 15:22 dev Note Added: 0036735 2014-09-06 16:12 Rolf Eike Beer Issue Deleted: 0015131 ====================================================================== From dev at cor0.com Sat Sep 6 16:16:52 2014 From: dev at cor0.com (dev) Date: Sat, 6 Sep 2014 16:16:52 -0400 (EDT) Subject: [cmake-developers] [CMake 0015131] DELETED. Message-ID: <570885624.24704.1410034612900.JavaMail.vpopmail@webmail2.networksolutionsemail.com> thank you ... I clearly have too many software tasks going on here ---------- Original Message ---------- From: Mantis Bug Tracker To: cmake-developers at cmake.org Date: September 6, 2014 at 4:12 PM Subject: [cmake-developers] [CMake 0015131]: "trace.c", line 219: error: identifier redeclared: trace_strbuf The following issue has been DELETED. From mantis at public.kitware.com Sat Sep 6 21:27:36 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 6 Sep 2014 21:27:36 -0400 Subject: [cmake-developers] [CMake 0015133]: CMake 3.0.1 shows Segmentation Fault after installation under Cygwin64 on Windows7 Message-ID: <687f02c370ed272c92e83707620355c2@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15133 ====================================================================== Reported By: N. Thompson Assigned To: ====================================================================== Project: CMake Issue ID: 15133 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-06 21:27 EDT Last Modified: 2014-09-06 21:27 EDT ====================================================================== Summary: CMake 3.0.1 shows Segmentation Fault after installation under Cygwin64 on Windows7 Description: The CMake 3.0.1 source was downloaded (cmake-3.0.1.tar.gz with LF line endings), compiled and installed following the instructions on the CMake web site. Everything worked normally as the attached log file shows. When CMake was subsequently run to show the version number using cmake -version, a segmentation fault occurred (see log file). Steps to Reproduce: 1, Delete all previous remnants of cygwin from system 2. Download and run http://cygwin.com/setup-x86_64.exe to install 64-bit cygwin 3. When asked, selected the option to install everything 4. From cygwin terminal window run "cmake -version" to confirm version is 2.8 5. Download and decompress cmake-3.0.1.tar.gz (version with LF line endings) 6. Run "tar -xzvf cmake-3.0.1.tar.gz" to decompress and extract cmake 7. Change to cmake-3.0.1 directory created by previous step. 8. Run "./configure" 9. Run "make" 10. Run "make install" 11. Reboot system 12. Run "cmake -version" from a cywgin terminal window 13. The segmentation fault will occur Additional Information: The system is running Windows X64 Ultimate. Since a 64-bit version of cygwin was needed, the 32-bit version of cygwin that was originally installed on this system was removed. All remnants of cygwin were deleted from the system including the directories and desktop icons and start-menu entries. A new 64-bit was installed successfully without any failures. Every application in the cygwin package was installed. After cygwin64 was installed, cmake was run to show the version of cmake that came with the cygwin installer. It ran successfully and showed something like 2.8.11. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-06 21:27 N. Thompson New Issue 2014-09-06 21:27 N. Thompson File Added: cmake-3.0.1-cygwin64-failed-install-log-20140906.log ====================================================================== From mantis at public.kitware.com Mon Sep 8 02:47:25 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 8 Sep 2014 02:47:25 -0400 Subject: [cmake-developers] [CMake 0015134]: add_subdirectory() fails when CMakeLists.txt in drive root Message-ID: <4a1f8d8ec76a951efdc0128041cb830f@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15134 ====================================================================== Reported By: Mattes D Assigned To: ====================================================================== Project: CMake Issue ID: 15134 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-08 02:47 EDT Last Modified: 2014-09-08 02:47 EDT ====================================================================== Summary: add_subdirectory() fails when CMakeLists.txt in drive root Description: I'm using the "subst" command on windows to make my build folder the root of a separate drive. Thus, the cmake file being processed is called "N:\CMakeLists.txt". CMake then fails to process the file, with several errors, all following the pattern: CMake Error at N://CMakeLists.txt:66 (add_subdirectory): add_subdirectory not given a binary directory but the given source directory "N:/lib/jsoncpp" is not a subdirectory of "N:/". When specifying an out-of-tree source a binary directory must be explicitly specified. CMake Error at N://CMakeLists.txt:76 (get_property): get_property DIRECTORY scope provided but requested directory was not found. This could be because the directory argument was invalid or, it is valid but has not been processed yet. The very same cmake file, when used in a subfolder, works without a problem. For your reference, the CMakeLists.txt file being used is this one: https://github.com/mc-server/MCServer/blob/562b2d1d1de7438bc763d778b56b0743affd1b5b/CMakeLists.txt Cmake is being called as: cmake -G "Visual Studio 9 2008" . Steps to Reproduce: Use subst to map a folder containing a project to a separate drive letter. Then use CMake in that drive's root to configure the project. CMake fails with the specified error. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-08 02:47 Mattes D New Issue ====================================================================== From pascal.bach at siemens.com Mon Sep 8 05:35:02 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Mon, 8 Sep 2014 11:35:02 +0200 Subject: [cmake-developers] [PATCH 1/3] WINCE: Document the WINCE variable In-Reply-To: <540A14A2.30904@kitware.com> References: <540A14A2.30904@kitware.com> Message-ID: <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> From: Pascal Bach --- Help/manual/cmake-variables.7.rst | 1 + Help/variable/WINCE.rst | 5 +++++ 2 files changed, 6 insertions(+) create mode 100644 Help/variable/WINCE.rst diff --git a/Help/manual/cmake-variables.7.rst b/Help/manual/cmake-variables.7.rst index 149e4ac..b00c16e 100644 --- a/Help/manual/cmake-variables.7.rst +++ b/Help/manual/cmake-variables.7.rst @@ -192,6 +192,7 @@ Variables that Describe the System /variable/MSVC_VERSION /variable/UNIX /variable/WIN32 + /variable/WINCE /variable/WINDOWS_PHONE /variable/WINDOWS_STORE /variable/XCODE_VERSION diff --git a/Help/variable/WINCE.rst b/Help/variable/WINCE.rst new file mode 100644 index 0000000..54ff7de --- /dev/null +++ b/Help/variable/WINCE.rst @@ -0,0 +1,5 @@ +WINCE +----- + +True when the :variable:`CMAKE_SYSTEM_NAME` variable is set +to ``WindowsCE``. -- 1.7.10.4 From pascal.bach at siemens.com Mon Sep 8 05:35:04 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Mon, 8 Sep 2014 11:35:04 +0200 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> Message-ID: <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> Currently the mapping from flags to XML elements in the Visual Studio generator is case sensitive. It only handles upper case flags so we should pass them as upper case. Even better would be to make the search case insensitive. --- Modules/Platform/Windows-MSVC.cmake | 36 +++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/Modules/Platform/Windows-MSVC.cmake b/Modules/Platform/Windows-MSVC.cmake index a72f946..236328e 100644 --- a/Modules/Platform/Windows-MSVC.cmake +++ b/Modules/Platform/Windows-MSVC.cmake @@ -33,16 +33,16 @@ endif() if(CMAKE_VERBOSE_MAKEFILE) set(CMAKE_CL_NOLOGO) else() - set(CMAKE_CL_NOLOGO "/nologo") + set(CMAKE_CL_NOLOGO "/NOLOGO") endif() if(CMAKE_SYSTEM_NAME STREQUAL "WindowsCE") - set(CMAKE_CREATE_WIN32_EXE "/entry:WinMainCRTStartup") - set(CMAKE_CREATE_CONSOLE_EXE "/entry:mainACRTStartup") - set(_PLATFORM_LINK_FLAGS " /subsystem:windowsce") + set(CMAKE_CREATE_WIN32_EXE "/SUBSYSTEM:WINDOWSCE /ENTRY:WinMainCRTStartup") + set(CMAKE_CREATE_CONSOLE_EXE "/SUBSYSTEM:WINDOWSCE /ENTRY:mainACRTStartup") + set(_PLATFORM_LINK_FLAGS "") else() - set(CMAKE_CREATE_WIN32_EXE "/subsystem:windows") - set(CMAKE_CREATE_CONSOLE_EXE "/subsystem:console") + set(CMAKE_CREATE_WIN32_EXE "/SUBSYSTEM:WINDOWS") + set(CMAKE_CREATE_CONSOLE_EXE "/SUBSYSTEM:CONSOLE") set(_PLATFORM_LINK_FLAGS "") endif() @@ -55,7 +55,7 @@ endif() # make sure to enable languages after setting configuration types enable_language(RC) -set(CMAKE_COMPILE_RESOURCE "rc /fo ") +set(CMAKE_COMPILE_RESOURCE "rc /Fo ") if("${CMAKE_GENERATOR}" MATCHES "Visual Studio") set(MSVC_IDE 1) @@ -200,16 +200,16 @@ set(CMAKE_CXX_STANDARD_LIBRARIES_INIT "${CMAKE_C_STANDARD_LIBRARIES_INIT}") set (CMAKE_LINK_DEF_FILE_FLAG "/DEF:") # set the machine type if(MSVC_C_ARCHITECTURE_ID) - set(_MACHINE_ARCH_FLAG "/machine:${MSVC_C_ARCHITECTURE_ID}") + set(_MACHINE_ARCH_FLAG "/MACHINE:${MSVC_C_ARCHITECTURE_ID}") elseif(MSVC_CXX_ARCHITECTURE_ID) - set(_MACHINE_ARCH_FLAG "/machine:${MSVC_CXX_ARCHITECTURE_ID}") + set(_MACHINE_ARCH_FLAG "/MACHINE:${MSVC_CXX_ARCHITECTURE_ID}") elseif(MSVC_Fortran_ARCHITECTURE_ID) - set(_MACHINE_ARCH_FLAG "/machine:${MSVC_Fortran_ARCHITECTURE_ID}") + set(_MACHINE_ARCH_FLAG "/MACHINE:${MSVC_Fortran_ARCHITECTURE_ID}") endif() set(CMAKE_EXE_LINKER_FLAGS_INIT "${CMAKE_EXE_LINKER_FLAGS_INIT} ${_MACHINE_ARCH_FLAG}") unset(_MACHINE_ARCH_FLAG) -# add /debug and /INCREMENTAL:YES to DEBUG and RELWITHDEBINFO also add pdbtype +# add /DEBUG and /INCREMENTAL:YES to DEBUG and RELWITHDEBINFO also add PDBTYPE # on versions that support it set( MSVC_INCREMENTAL_YES_FLAG "") if(NOT WINDOWS_PHONE AND NOT WINDOWS_STORE) @@ -221,11 +221,11 @@ if(NOT WINDOWS_PHONE AND NOT WINDOWS_STORE) endif() if (CMAKE_COMPILER_SUPPORTS_PDBTYPE) - set (CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "/debug /pdbtype:sept ${MSVC_INCREMENTAL_YES_FLAG}") - set (CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO_INIT "/debug /pdbtype:sept ${MSVC_INCREMENTAL_YES_FLAG}") + set (CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "/DEBUG /PDBTYPE:sept ${MSVC_INCREMENTAL_YES_FLAG}") + set (CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO_INIT "/DEBUG /PDBTYPE:sept ${MSVC_INCREMENTAL_YES_FLAG}") else () - set (CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "/debug ${MSVC_INCREMENTAL_YES_FLAG}") - set (CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO_INIT "/debug ${MSVC_INCREMENTAL_YES_FLAG}") + set (CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "/DEBUG ${MSVC_INCREMENTAL_YES_FLAG}") + set (CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO_INIT "/DEBUG ${MSVC_INCREMENTAL_YES_FLAG}") endif () # for release and minsize release default to no incremental linking set(CMAKE_EXE_LINKER_FLAGS_MINSIZEREL_INIT "/INCREMENTAL:NO") @@ -252,10 +252,10 @@ macro(__windows_compiler_msvc lang) set(_CMAKE_VS_LINK_EXE " -E vs_link_exe ") endif() set(CMAKE_${lang}_CREATE_SHARED_LIBRARY - "${_CMAKE_VS_LINK_DLL} ${CMAKE_CL_NOLOGO} ${CMAKE_START_TEMP_FILE} /out: /implib: /pdb: /dll /version:.${_PLATFORM_LINK_FLAGS} ${CMAKE_END_TEMP_FILE}") + "${_CMAKE_VS_LINK_DLL} ${CMAKE_CL_NOLOGO} ${CMAKE_START_TEMP_FILE} /OUT: /IMPLIB: /PDB: /DLL /VERSION:.${_PLATFORM_LINK_FLAGS} ${CMAKE_END_TEMP_FILE}") set(CMAKE_${lang}_CREATE_SHARED_MODULE ${CMAKE_${lang}_CREATE_SHARED_LIBRARY}) - set(CMAKE_${lang}_CREATE_STATIC_LIBRARY " /lib ${CMAKE_CL_NOLOGO} /out: ") + set(CMAKE_${lang}_CREATE_STATIC_LIBRARY " /LIB ${CMAKE_CL_NOLOGO} /OUT: ") set(CMAKE_${lang}_COMPILE_OBJECT " ${CMAKE_START_TEMP_FILE} ${CMAKE_CL_NOLOGO}${_COMPILE_${lang}} /Fo /Fd${_FS_${lang}} -c ${CMAKE_END_TEMP_FILE}") @@ -266,7 +266,7 @@ macro(__windows_compiler_msvc lang) set(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_OBJECTS 1) set(CMAKE_${lang}_LINK_EXECUTABLE - "${_CMAKE_VS_LINK_EXE} ${CMAKE_CL_NOLOGO} ${CMAKE_START_TEMP_FILE} /out: /implib: /pdb: /version:.${_PLATFORM_LINK_FLAGS} ${CMAKE_END_TEMP_FILE}") + "${_CMAKE_VS_LINK_EXE} ${CMAKE_CL_NOLOGO} ${CMAKE_START_TEMP_FILE} /OUT: /implib: /PDB: /version:.${_PLATFORM_LINK_FLAGS} ${CMAKE_END_TEMP_FILE}") set(CMAKE_${lang}_FLAGS_INIT "${_PLATFORM_DEFINES}${_PLATFORM_DEFINES_${lang}} /D_WINDOWS /W3${_FLAGS_${lang}}") set(CMAKE_${lang}_FLAGS_DEBUG_INIT "/D_DEBUG /MDd /Zi /Ob0 /Od ${_RTC1}") -- 1.7.10.4 From pascal.bach at siemens.com Mon Sep 8 05:35:03 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Mon, 8 Sep 2014 11:35:03 +0200 Subject: [cmake-developers] [PATCH 2/3] WINCE, VS: Propagate Subsystem and Entry point to generated solution In-Reply-To: <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> Message-ID: <1410168904-7228-2-git-send-email-pascal.bach@siemens.com> The flags /SUBSYSTEM and /ENTRY are set by Windows-MSVC.cmake depending on the system. Howver these values never ended up in the resulting VS solution. This is fixed by reading the values of CMAKE_CREATE_WIN32_EXE and CMAKE_CREATE_CONSOLE_EXE and propagates theses to the resulting XML. --- Source/cmVS11LinkFlagTable.h | 2 ++ Source/cmVS12LinkFlagTable.h | 2 ++ Source/cmVS14LinkFlagTable.h | 2 ++ Source/cmVisualStudio10TargetGenerator.cxx | 19 ++++++++++--------- 4 files changed, 16 insertions(+), 9 deletions(-) diff --git a/Source/cmVS11LinkFlagTable.h b/Source/cmVS11LinkFlagTable.h index 0f641e4..765dbcf 100644 --- a/Source/cmVS11LinkFlagTable.h +++ b/Source/cmVS11LinkFlagTable.h @@ -56,6 +56,8 @@ static cmVS7FlagTable cmVS11LinkFlagTable[] = "EFI ROM", "EFI ROM", 0}, {"SubSystem", "SUBSYSTEM:EFI_RUNTIME_DRIVER", "EFI Runtime", "EFI Runtime", 0}, + {"SubSystem", "SUBSYSTEM:WINDOWSCE", + "WindowsCE", "WindowsCE", 0}, {"SubSystem", "SUBSYSTEM:POSIX", "POSIX", "POSIX", 0}, diff --git a/Source/cmVS12LinkFlagTable.h b/Source/cmVS12LinkFlagTable.h index e5a570e..ca68c7e 100644 --- a/Source/cmVS12LinkFlagTable.h +++ b/Source/cmVS12LinkFlagTable.h @@ -56,6 +56,8 @@ static cmVS7FlagTable cmVS12LinkFlagTable[] = "EFI ROM", "EFI ROM", 0}, {"SubSystem", "SUBSYSTEM:EFI_RUNTIME_DRIVER", "EFI Runtime", "EFI Runtime", 0}, + {"SubSystem", "SUBSYSTEM:WINDOWSCE", + "WindowsCE", "WindowsCE", 0}, {"SubSystem", "SUBSYSTEM:POSIX", "POSIX", "POSIX", 0}, diff --git a/Source/cmVS14LinkFlagTable.h b/Source/cmVS14LinkFlagTable.h index 6d81d12..67ddbe3 100644 --- a/Source/cmVS14LinkFlagTable.h +++ b/Source/cmVS14LinkFlagTable.h @@ -56,6 +56,8 @@ static cmVS7FlagTable cmVS14LinkFlagTable[] = "EFI ROM", "EFI ROM", 0}, {"SubSystem", "SUBSYSTEM:EFI_RUNTIME_DRIVER", "EFI Runtime", "EFI Runtime", 0}, + {"SubSystem", "SUBSYSTEM:WINDOWSCE", + "WindowsCE", "WindowsCE", 0}, {"SubSystem", "SUBSYSTEM:POSIX", "POSIX", "POSIX", 0}, diff --git a/Source/cmVisualStudio10TargetGenerator.cxx b/Source/cmVisualStudio10TargetGenerator.cxx index c525b7c..1c2a7be 100644 --- a/Source/cmVisualStudio10TargetGenerator.cxx +++ b/Source/cmVisualStudio10TargetGenerator.cxx @@ -2041,6 +2041,16 @@ cmVisualStudio10TargetGenerator::ComputeLinkOptions(std::string const& config) flags += " "; flags += flagsConfig; } + if (this->Target->GetPropertyAsBool("WIN32_EXECUTABLE")) + { + flags += " "; + flags += this->Target->GetMakefile()->GetSafeDefinition("CMAKE_CREATE_WIN32_EXE"); + } + else + { + flags += " "; + flags += this->Target->GetMakefile()->GetSafeDefinition("CMAKE_CREATE_CONSOLE_EXE"); + } std::string standardLibsVar = "CMAKE_"; standardLibsVar += linkLanguage; standardLibsVar += "_STANDARD_LIBRARIES"; @@ -2113,15 +2123,6 @@ cmVisualStudio10TargetGenerator::ComputeLinkOptions(std::string const& config) { linkOptions.AddFlag("Version", ""); - if ( this->Target->GetPropertyAsBool("WIN32_EXECUTABLE") ) - { - linkOptions.AddFlag("SubSystem", "Windows"); - } - else - { - linkOptions.AddFlag("SubSystem", "Console"); - } - if(const char* stackVal = this->Makefile->GetDefinition("CMAKE_"+linkLanguage+"_STACK_SIZE")) { -- 1.7.10.4 From mantis at public.kitware.com Mon Sep 8 05:45:46 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 8 Sep 2014 05:45:46 -0400 Subject: [cmake-developers] [CMake 0015135]: Allow properties on installed directories Message-ID: <9e6914bc9cfabd7ad51fdd375d7943e9@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15135 ====================================================================== Reported By: Richard Ulrich Assigned To: ====================================================================== Project: CMake Issue ID: 15135 Category: CPack Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-08 05:45 EDT Last Modified: 2014-09-08 05:45 EDT ====================================================================== Summary: Allow properties on installed directories Description: Since cmake 3 (I think) we can set properties on installed files. This is great, but it would be even better, if we could also set these properties on installed directories. Steps to Reproduce: INSTALL(DIRECTORY source/ DESTINATION "/" COMPONENT app PATTERN "Database/*.zip" EXCLUDE ) SET_PROPERTY(INSTALL "/" PROPERTY CPACK_WIX_ACL "Everyone=GenericAll" ) Additional Information: Since the install properties are part of cmInstalledFile, it's not just a WiX issue. WiX in turn supports these properties on directories. http://wixtoolset.org/documentation/manual/v3/xsd/wix/createfolder.html At the moment I sole it with a custom action, but it would be really great if I didn't have to do that. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-08 05:45 Richard Ulrich New Issue ====================================================================== From brad.king at kitware.com Mon Sep 8 08:51:43 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 08 Sep 2014 08:51:43 -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> Message-ID: <540DA65F.4030501@kitware.com> On 09/03/2014 12:12 PM, Aleix Pol wrote: > On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf wrote: >> I still don't understand why this shouldn't be an additional ExtraGenerator. > > Because it's not possible to change the generator of a build directory > once it's set up. You need to nuke it and re-create it. [snip] On 09/01/2014 07:27 PM, Aleix Pol wrote: > Ok, how does it sound if we have a variable, such as CMAKE_EXPORT_COMPILE_COMMANDS? > Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. A control variable like that sounds good to me. The purpose looks very similar to CMAKE_EXPORT_COMPILE_COMMANDS, but is distinct enough to have its own control. Thanks, -Brad From mantis at public.kitware.com Mon Sep 8 10:11:38 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 8 Sep 2014 10:11:38 -0400 Subject: [cmake-developers] [CMake 0015137]: find_package(LAPACK) reports incorrect syntax in FindLAPACK.cmake Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15137 ====================================================================== Reported By: Eugene Shalygin Assigned To: ====================================================================== Project: CMake Issue ID: 15137 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-08 10:11 EDT Last Modified: 2014-09-08 10:11 EDT ====================================================================== Summary: find_package(LAPACK) reports incorrect syntax in FindLAPACK.cmake Description: Part of the cmake output log: -- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") -- checking for module 'blas' -- found blas, version 3.2.1 -- Found BLAS: /usr/lib64/libeigen_blas.so -- checking for module 'lapack' -- found lapack, version 3.4.2 CMake Error at /usr/share/cmake/Modules/FindLAPACK.cmake:190 (check_lapack_libraries): A logical block opening on the line /usr/share/cmake/Modules/FindLAPACK.cmake:84 (if) is not closed. Steps to Reproduce: $ cat << EOF > CMakeLists.txt project(test) find_package(LAPACK) EOF $ mkdir -p build & cd build & cmake .. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-08 10:11 Eugene ShalyginNew Issue ====================================================================== From brad.king at kitware.com Mon Sep 8 10:44:42 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 08 Sep 2014 10:44:42 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5409B874.2060607@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> Message-ID: <540DC0DA.5010409@kitware.com> On 09/05/2014 09:19 AM, Nils Gladitz wrote: > On 09/05/2014 02:50 PM, Brad King wrote: >> On 09/04/2014 11:58 AM, Nils Gladitz wrote: >> - The dashboard submissions that bootstrap got many CMP0054 >> warnings. Most of them are the same warning repeated due >> to presence in a macro or loop. Please update the warning >> to not warn on the same line more than once. A set<> of >> already-emitted warning lines can be kept somewhere. > > I'll look into it. Good work on the revisions. In the warning message: Quoted variables like 'SOME_VAR' are no longer dereferenced. I think the 'single quoting' may be confusing since it looks like an example of the quoting that is no longer dereferenced. Instead use double-quotes: Quoted variables like "SOME_VAR" are no longer dereferenced. I tested this on a few projects and found that the warning is repeated in cases like: macro(foo VAR) if("${VAR}" MATCHES "^${VAR}$") endmacro() because each call has a different quoted variable name after macro expansion. Since if() does not even get the arguments until after the macro execution has substituted for ${VAR}, it is hard to eliminate this unless we take out the variable name from the dedup set key. I think perhaps we should do that even though it could suppress cases with multiple separate problems in a single if() command. The goal of dedup is to reduce the number of warnings that show up. Once a developer sits down to resolve the warnings, s/he will repeat running CMake until all the warnings are gone anyway. Thanks, -Brad From nilsgladitz at gmail.com Mon Sep 8 11:35:27 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 08 Sep 2014 17:35:27 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <540DC0DA.5010409@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> Message-ID: <540DCCBF.6010002@gmail.com> On 09/08/2014 04:44 PM, Brad King wrote: > Good work on the revisions. Thanks. I updated the topic, squished and merged. Nils From brad.king at kitware.com Mon Sep 8 13:07:55 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 08 Sep 2014 13:07:55 -0400 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> Message-ID: <540DE26B.20005@kitware.com> On 09/08/2014 05:35 AM, Pascal Bach wrote: > Even better would be to make the search case insensitive. How do we know which flags are sensitive to case? > - set(CMAKE_CREATE_WIN32_EXE "/entry:WinMainCRTStartup") > - set(CMAKE_CREATE_CONSOLE_EXE "/entry:mainACRTStartup") > - set(_PLATFORM_LINK_FLAGS " /subsystem:windowsce") > + set(CMAKE_CREATE_WIN32_EXE "/SUBSYSTEM:WINDOWSCE /ENTRY:WinMainCRTStartup") > + set(CMAKE_CREATE_CONSOLE_EXE "/SUBSYSTEM:WINDOWSCE /ENTRY:mainACRTStartup") > + set(_PLATFORM_LINK_FLAGS "") That appears to un-do this recent fix: MSVC: Fix linking of DLLs on WinCE (#15013) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e1283e4 http://www.cmake.org/Bug/view.php?id=15013 that introduced _PLATFORM_LINK_FLAGS in the first place. -Brad From brad.king at kitware.com Mon Sep 8 13:17:19 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 08 Sep 2014 13:17:19 -0400 Subject: [cmake-developers] OS X packaging updates In-Reply-To: <5409AD80.2000303@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> <5408B278.2070400@kitware.com> <4C094659-30A8-4304-ADBD-C62A1788C2A0@java.pl> <5409AD80.2000303@kitware.com> Message-ID: <540DE49F.8090508@kitware.com> On 09/05/2014 08:33 AM, Brad King wrote: > Thanks. I've re-built the topic with those locally. I've merged to 'next' for testing: BundleUtilities: Use 'find' on UNIX for fast executable lookup http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=02dfaa31 GetPrerequisites: Make sure dyld placeholders are prefixes http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=195ec6b3 BundleUtilities: Resolve & replace @rpath placeholders http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7747b13e BundleUtilities: Process executables first when scanning bundle http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea9e35be BundleUtilities: Codesign needs framework's Contents/Info.plist http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd67c3ea cmake-gui: Make sure we bundle Qt5 Cocoa platform plugin http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c106311f -Brad From mantis at public.kitware.com Mon Sep 8 14:20:19 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 8 Sep 2014 14:20:19 -0400 Subject: [cmake-developers] [CMake 0015142]: Cannot set different INTERFACE_COMPILE_DEFINITIONS for different IMPORTED_CONFIGURATIONS Message-ID: <27d0080f1ae79d4de63f46cbbf63f288@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15142 ====================================================================== Reported By: Daniele E. Domenichelli Assigned To: ====================================================================== Project: CMake Issue ID: 15142 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-08 14:20 EDT Last Modified: 2014-09-08 14:20 EDT ====================================================================== Summary: Cannot set different INTERFACE_COMPILE_DEFINITIONS for different IMPORTED_CONFIGURATIONS Description: The INTERFACE_COMPILE_DEFINITIONS target property does not have an IMPORTED_CONFIGURATIONS_ analogue. This means that it is not possible for imported libraries to use different definitions depending on the configuration of the library being used. Steps to Reproduce: In my opinion it should be possible to do something like this: add_library(FOO::FOO IMPORTED UNKNOWN) set_property(TARGET FOO::FOO PROPERTY INTERFACE_INCLUDE_DIRECTORIES "${FOO_INCLUDE_DIRS}") if(FOO_LIBRARY_RELEASE) set_property(TARGET FOO::FOO APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE) set_property(TARGET FOO::FOO PROPERTY IMPORTED_LOCATION_RELEASE "${FOO_LIBRARY_RELEASE}") set_property(TARGET FOO::FOO APPEND PROPERTY INTERFACE_COMPILE_DEFINITIONS_RELEASE FOO_RELEASE) endif() if(FOO_LIBRARY_DEBUG) set_property(TARGET FOO::FOO APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG) set_property(TARGET FOO::FOO PROPERTY IMPORTED_LOCATION_DEBUG "${FOO_LIBRARY_DEBUG}") set_property(TARGET FOO::FOO APPEND PROPERTY INTERFACE_COMPILE_DEFINITIONS_DEBUG FOO_DEBUG) endif() And depending on the configuration of the library being used, it should automatically add -DFOO_RELEASE or -DFOO_DEBUG. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-08 14:20 Daniele E. DomenichelliNew Issue ====================================================================== From irwin at beluga.phys.uvic.ca Mon Sep 8 15:52:09 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 8 Sep 2014 12:52:09 -0700 (PDT) Subject: [cmake-developers] [PATCH] Fix infinite loop in file downloads if hash value not a match Message-ID: I was caught by this infinite loop issue when attempting to build Qt5.3.1 using ExternalProject.cmake. I used an MD5 sum value given by BLFS for the Qt5.3.1 tar.gz download which happened to be the wrong value. In my case the consequences were not too bad because I was "downloading" from a local disk drive "URL". However, this infinite loop could be construed as a denial-of-service attack on some open-source project if an actual download keeps getting repeated indefinitely. Note this bad retries logic in the downloads was introduced after CMake-2.8.12.2, and a search of the bug tracker for "infinite" shows nothing relevant. See attached patch in "git format-patch" form that fixes the problem for the CMake master branch. 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 __________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-infinite-loop-in-file-downloads-if-hash-value-no.patch Type: text/x-diff Size: 841 bytes Desc: Fix for ExternalProject.cmake URL: From brad.king at kitware.com Mon Sep 8 16:11:24 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 08 Sep 2014 16:11:24 -0400 Subject: [cmake-developers] OS X packaging updates In-Reply-To: <540DE49F.8090508@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> <5408B278.2070400@kitware.com> <4C094659-30A8-4304-ADBD-C62A1788C2A0@java.pl> <5409AD80.2000303@kitware.com> <540DE49F.8090508@kitware.com> Message-ID: <540E0D6C.2010402@kitware.com> On 09/08/2014 01:17 PM, Brad King wrote: > On 09/05/2014 08:33 AM, Brad King wrote: >> Thanks. I've re-built the topic with those locally. > > I've merged to 'next' for testing: I had to revert again because it causes the Qt4Deploy to fail. The topic changes the signature of gp_file_type. User projects could be calling that, so we can't change it. In this case it is the Modules/DeployQt4.cmake file that was calling it. -Brad From brad.king at kitware.com Mon Sep 8 16:38:36 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 08 Sep 2014 16:38:36 -0400 Subject: [cmake-developers] [PATCH] Fix infinite loop in file downloads if hash value not a match In-Reply-To: References: Message-ID: <540E13CC.60209@kitware.com> On 09/08/2014 03:52 PM, Alan W. Irwin wrote: > I was caught by this infinite loop issue when attempting to build > Qt5.3.1 using ExternalProject.cmake. Applied, thanks: ExternalProject: Avoid infinite loop on file download hash mismatch http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f49ac3d I based it on a commit old enough to merge to a 3.0.x bugfix release. Thanks, -Brad From pascal.bach at siemens.com Tue Sep 9 05:31:15 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 9 Sep 2014 09:31:15 +0000 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <540DE26B.20005@kitware.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> > On 09/08/2014 05:35 AM, Pascal Bach wrote: > > Even better would be to make the search case insensitive. > > How do we know which flags are sensitive to case? It has nothing to do with Visual Studio as it doesn't care about the casing. The problem is in the CMake generator. The tables in (eg. Source/cmVS10LinkFlagTable.h) map from linker flags to XML elements in the resulting .vcxproj file. One such example is the entry: {"SubSystem", "SUBSYSTEM:WINDOWSCE", "WindowsCE", "WindowsCE", 0}, This maps a flag /SUBSYSTEM:WINDOWSCE to WindowsCE As you can see the entries in the table are in upper case. And the mapping does only work if the flags are uppercase to. Maybe a better solution would be to do this matching in a case in sensitive way, this way it would work in any case even with user passed flags in lower case. > > > - set(CMAKE_CREATE_WIN32_EXE "/entry:WinMainCRTStartup") > > - set(CMAKE_CREATE_CONSOLE_EXE "/entry:mainACRTStartup") > > - set(_PLATFORM_LINK_FLAGS " /subsystem:windowsce") > > + set(CMAKE_CREATE_WIN32_EXE "/SUBSYSTEM:WINDOWSCE > /ENTRY:WinMainCRTStartup") > > + set(CMAKE_CREATE_CONSOLE_EXE "/SUBSYSTEM:WINDOWSCE > /ENTRY:mainACRTStartup") > > + set(_PLATFORM_LINK_FLAGS "") > > That appears to un-do this recent fix: > > MSVC: Fix linking of DLLs on WinCE (#15013) > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e1283e4 > http://www.cmake.org/Bug/view.php?id=15013 > > that introduced _PLATFORM_LINK_FLAGS in the first place. Rith I think I had a too simplistic view here. But even the old fix doesn't seem to work with VS. I think the /ENTRY point also needs to be set for the DLLs, I will try if I can find out how to set this. Pascal PS: Forgot to add the mailinglist. From brad.king at kitware.com Tue Sep 9 08:29:53 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Sep 2014 08:29:53 -0400 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <540EF2C1.8050701@kitware.com> On 09/09/2014 05:31 AM, Bach, Pascal wrote: > Maybe a better solution would be to do this matching in a case insensitive way, > this way it would work in any case even with user passed flags in lower case. I'm saying that some flags are case sensitive and others are not. We cannot blindly match all "cl" flags insensitive to case, for example. Anyway, I think just matching the case is good enough for now. Thanks, -Brad From pascal.bach at siemens.com Tue Sep 9 09:48:06 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 9 Sep 2014 13:48:06 +0000 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <540EF2C1.8050701@kitware.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> <540EF2C1.8050701@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> > > Maybe a better solution would be to do this matching in a case insensitive > way, > > this way it would work in any case even with user passed flags in lower > case. > > I'm saying that some flags are case sensitive and others are not. > We cannot blindly match all "cl" flags insensitive to case, for > example. Anyway, I think just matching the case is good enough > for now. Ok I didn't know that cl does care about casing for some flags. > > - set(CMAKE_CREATE_WIN32_EXE "/entry:WinMainCRTStartup") > > - set(CMAKE_CREATE_CONSOLE_EXE "/entry:mainACRTStartup") > > - set(_PLATFORM_LINK_FLAGS " /subsystem:windowsce") > > + set(CMAKE_CREATE_WIN32_EXE "/SUBSYSTEM:WINDOWSCE > /ENTRY:WinMainCRTStartup") > > + set(CMAKE_CREATE_CONSOLE_EXE "/SUBSYSTEM:WINDOWSCE > /ENTRY:mainACRTStartup") > > + set(_PLATFORM_LINK_FLAGS "") > > That appears to un-do this recent fix: > > MSVC: Fix linking of DLLs on WinCE (#15013) > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e1283e4 > http://www.cmake.org/Bug/view.php?id=15013 > > that introduced _PLATFORM_LINK_FLAGS in the first place. The values added to _PLATFORM_LINK_FLAGS do never end up in the .vcxproj file. The go into CMAKE_${lang}_CREATE_SHARED_LIBRARY [1] and CMAKE_${lang}_LINK_EXECUTABLE [2] However I can't see how this variables should end up in the VS generator. Any ideas? [1] https://github.com/Kitware/CMake/blob/6ae98ee18f6c35b93556a66dc0ce909d84aec18b/Modules/Platform/Windows-MSVC.cmake#L242 [2] https://github.com/Kitware/CMake/blob/6ae98ee18f6c35b93556a66dc0ce909d84aec18b/Modules/Platform/Windows-MSVC.cmake#L256 From brad.king at kitware.com Tue Sep 9 09:53:27 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Sep 2014 09:53:27 -0400 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> <540EF2C1.8050701@kitware.com> <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <540F0657.1010606@kitware.com> On 09/09/2014 09:48 AM, Bach, Pascal wrote: > The values added to _PLATFORM_LINK_FLAGS do never end up in the .vcxproj file. > The go into CMAKE_${lang}_CREATE_SHARED_LIBRARY [1] and CMAKE_${lang}_LINK_EXECUTABLE [2] > However I can't see how this variables should end up in the VS generator. > > Any ideas? Those are all for the Makefile and Ninja generators, as are CMAKE_CREATE_WIN32_EXE and CMAKE_CREATE_CONSOLE_EXE. For VS generators the knowledge has always been hard-coded, with a special case for Windows CE: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalVisualStudio7Generator.cxx;hb=v3.0.1#l1122 The cmVisualStudio10TargetGenerator could be taught this similarly. -Brad From pascal.bach at siemens.com Tue Sep 9 10:19:47 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 9 Sep 2014 14:19:47 +0000 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <540F0657.1010606@kitware.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> <540EF2C1.8050701@kitware.com> <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> <540F0657.1010606@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACF2F9@DEFTHW99EH4MSX.ww902.siemens.net> > Those are all for the Makefile and Ninja generators, as are > CMAKE_CREATE_WIN32_EXE and CMAKE_CREATE_CONSOLE_EXE. For VS > generators the knowledge has always been hard-coded, with a > special case for Windows CE: > > > http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalVisual > Studio7Generator.cxx;hb=v3.0.1#l1122 > > The cmVisualStudio10TargetGenerator could be taught this > similarly. Wouldn't it make sense to use the same variables in the VS10+ Generator too? It seems redundant to have the same information again. What's the reason it is hardcoded? Pascal From brad.king at kitware.com Tue Sep 9 10:27:45 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Sep 2014 10:27:45 -0400 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <355BE46A91031048906B695426A8D8E616ACF2F9@DEFTHW99EH4MSX.ww902.siemens.net> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> <540EF2C1.8050701@kitware.com> <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> <540F0657.1010606@kitware.com> <355BE46A91031048906B695426A8D8E616ACF2F9@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <540F0E61.6080605@kitware.com> On 09/09/2014 10:19 AM, Bach, Pascal wrote: > Wouldn't it make sense to use the same variables in the VS10+ Generator too? > It seems redundant to have the same information again. What's the reason it is hardcoded? That's just the way it was written. The rule variables like CMAKE_${lang}_CREATE_SHARED_LIBRARY contain command lines in which the Makefile and Ninja generators substitute for some placeholders. The VS generators do not have a command line because they just put the declarative information into the project file and let VS build the command line. If you want to refactor things to create more independent flag-holding variables that are used to construct CMAKE_${lang}_CREATE_SHARED_LIBRARY and also read by the VS generators and sent through the flag map, that's fine with me. Please also update the VS 7-9 generators to use the same information variables if possible. -Brad From pascal.bach at siemens.com Tue Sep 9 11:02:03 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 9 Sep 2014 15:02:03 +0000 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <540F0E61.6080605@kitware.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> <540EF2C1.8050701@kitware.com> <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> <540F0657.1010606@kitware.com> <355BE46A91031048906B695426A8D8E616ACF2F9@DEFTHW99EH4MSX.ww902.siemens.net> <540F0E61.6080605@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACF34D@DEFTHW99EH4MSX.ww902.siemens.net> > On 09/09/2014 10:19 AM, Bach, Pascal wrote: > > Wouldn't it make sense to use the same variables in the VS10+ Generator > too? > > It seems redundant to have the same information again. What's the reason > it is hardcoded? > > That's just the way it was written. The rule variables like > CMAKE_${lang}_CREATE_SHARED_LIBRARY contain command lines in > which the Makefile and Ninja generators substitute for some > placeholders. The VS generators do not have a command line > because they just put the declarative information into the > project file and let VS build the command line. I don't understand the purpose of the flag tables [1]. Aren't they there to map from command line to XML files? At first I tought the way things work was: Windows-MSVC.cmake and Co construct a commandline with the required flags. ==> The VS generator parses this command line and uses the cmVS7FlagTable to translate the known flags to XML elements. (Unknown arguments get passed as additional arguments). But it might be that this doesn't work because multi configuration or something else. [1] https://github.com/Kitware/CMake/blob/6ae98ee18f6c35b93556a66dc0ce909d84aec18b/Source/cmVS10LinkFlagTable.h > > If you want to refactor things to create more independent > flag-holding variables that are used to construct > CMAKE_${lang}_CREATE_SHARED_LIBRARY and also read by the > VS generators and sent through the flag map, that's fine > with me. Please also update the VS 7-9 generators to use > the same information variables if possible. If I refactor I would change it to the way described above. Pascal From brad.king at kitware.com Tue Sep 9 11:11:45 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Sep 2014 11:11:45 -0400 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <355BE46A91031048906B695426A8D8E616ACF34D@DEFTHW99EH4MSX.ww902.siemens.net> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> <540EF2C1.8050701@kitware.com> <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> <540F0657.1010606@kitware.com> <355BE46A91031048906B695426A8D8E616ACF2F9@DEFTHW99EH4MSX.ww902.siemens.net> <540F0E61.6080605@kitware.com> <355BE46A91031048906B695426A8D8E616ACF34D@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <540F18B1.5090806@kitware.com> On 09/09/2014 11:02 AM, Bach, Pascal wrote: > I don't understand the purpose of the flag tables [1]. > Aren't they there to map from command line to XML files? Yes, but they were created originally to support flags specified by users in CMAKE_C_FLAGS and a few other places. > At first I tought the way things work was: > Windows-MSVC.cmake and Co construct a commandline with the required flags. > The VS generator parses this command line and uses the cmVS7FlagTable to > translate the known flags to XML elements. > (Unknown arguments get passed as additional arguments). This is done for a subset of the sources of flags, specifically those settable by users and project code. We can't use a complete command line like that in CMAKE_${lang}_CREATE_SHARED_LIBRARY because that will contain a lot of pieces besides the flags. Also multi-configuration is an issue as you point out. You would need to create new variables in Windows-MSVC to hold the flags to be scanned by the VS generators. Then re-use the flags in constructing the other rule variables with command-lines used by the Makefile and Ninja generators. -Brad From rleigh at codelibre.net Tue Sep 9 11:35:07 2014 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 9 Sep 2014 16:35:07 +0100 Subject: [cmake-developers] [PATCH] FindIce: Remove unneeded search path modification Message-ID: <20140909153507.GO7997@codelibre.net> Hi, I have attached a minor fix to the FindIce module added a couple of weeks back. This can override the user's intended search path and was made unnecessary by the changes you requested prior to merging (the paths being added are already added as fallbacks via the list(APPEND ice_roots "/opt/Ice-${ice_version}") line earlier in the script), so the removal simply makes the behaviour consistent. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindIce-Remove-unneeded-search-path-modification.patch Type: text/x-diff Size: 912 bytes Desc: not available URL: From brad.king at kitware.com Tue Sep 9 11:48:53 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Sep 2014 11:48:53 -0400 Subject: [cmake-developers] [PATCH] FindIce: Remove unneeded search path modification In-Reply-To: <20140909153507.GO7997@codelibre.net> References: <20140909153507.GO7997@codelibre.net> Message-ID: <540F2165.6090909@kitware.com> On 09/09/2014 11:35 AM, Roger Leigh wrote: > I have attached a minor fix to the FindIce module added a couple of > weeks back. Applied, thanks: FindIce: Remove unneeded search path modification http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d5047ca1 While reviewing I noticed that there are some message(STATUS) calls not protected by if(Ice_DEBUG) or checks of Ice_FIND_QUIETLY. The latter is needed to honor the QUIET option of find_package. Please revise in a follow-up patch. Thanks, -Brad From pascal.bach at siemens.com Tue Sep 9 11:52:38 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Tue, 9 Sep 2014 15:52:38 +0000 Subject: [cmake-developers] [PATCH 3/3] VS: Pass MSVC compiler flags in upper case In-Reply-To: <540F18B1.5090806@kitware.com> References: <540A14A2.30904@kitware.com> <1410168904-7228-1-git-send-email-pascal.bach@siemens.com> <1410168904-7228-3-git-send-email-pascal.bach@siemens.com> <540DE26B.20005@kitware.com> <355BE46A91031048906B695426A8D8E616ACF039@DEFTHW99EH4MSX.ww902.siemens.net> <540EF2C1.8050701@kitware.com> <355BE46A91031048906B695426A8D8E616ACF259@DEFTHW99EH4MSX.ww902.siemens.net> <540F0657.1010606@kitware.com> <355BE46A91031048906B695426A8D8E616ACF2F9@DEFTHW99EH4MSX.ww902.siemens.net> <540F0E61.6080605@kitware.com> <355BE46A91031048906B695426A8D8E616ACF34D@DEFTHW99EH4MSX.ww902.siemens.net> <540F18B1.5090806@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616ACF3A5@DEFTHW99EH4MSX.ww902.siemens.net> > > At first I tought the way things work was: > > Windows-MSVC.cmake and Co construct a commandline with the required > flags. > > The VS generator parses this command line and uses the cmVS7FlagTable > to > > translate the known flags to XML elements. > > (Unknown arguments get passed as additional arguments). > > This is done for a subset of the sources of flags, specifically > those settable by users and project code. We can't use a complete > command line like that in CMAKE_${lang}_CREATE_SHARED_LIBRARY > because that will contain a lot of pieces besides the flags. > Also multi-configuration is an issue as you point out. > > You would need to create new variables in Windows-MSVC to hold > the flags to be scanned by the VS generators. Then re-use the > flags in constructing the other rule variables with command-lines > used by the Makefile and Ninja generators. Looks like a bigger refactoring would be needed. Maybe for the moment it is better to implement it analogous to WindowsPhone and then later refactor the whole thing. Pascal From mantis at public.kitware.com Tue Sep 9 12:58:02 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 9 Sep 2014 12:58:02 -0400 Subject: [cmake-developers] [CMake 0015144]: CMake is unable to locate FreeType within the XQuartz installation Message-ID: <5d0c945159d5052152b35f4fd8afafa9@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15144 ====================================================================== Reported By: Sergey Kosarevsky Assigned To: ====================================================================== Project: CMake Issue ID: 15144 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-09 12:58 EDT Last Modified: 2014-09-09 12:58 EDT ====================================================================== Summary: CMake is unable to locate FreeType within the XQuartz installation Description: XQuartz-2.7.7.dmg is installed. The FreeType library is located in /opt/X11/include/freetype2 The CMake output is on the attached screenshot. Steps to Reproduce: CMakeLists.txt: IF(WITH_FREETYPE) FIND_PACKAGE(Freetype REQUIRED) ADD_DEFINITIONS(-DUSEFREETYPE) INCLUDE_DIRECTORIES(${FREETYPE_INCLUDE_DIRS}) SET(wcm_LIBS ${wcm_LIBS} ${FREETYPE_LIBRARIES}) ENDIF(WITH_FREETYPE) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-09 12:58 Sergey KosarevskyNew Issue 2014-09-09 12:58 Sergey KosarevskyFile Added: 29efc2ec-37b0-11e4-9a95-e78996c79ba3.jpg ====================================================================== From hobbes1069 at gmail.com Tue Sep 9 14:21:54 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Tue, 9 Sep 2014 13:21:54 -0500 Subject: [cmake-developers] include(...) or find_package(...) within another Find module Message-ID: I'm working on trying to modernize the FindFLTK module but also stuck with making sure I don't break the established behavior. The problems with the module are extensive so I'm breaking them up into individual emails where possible. The part I'm questioning in this email is: Should this be include(FindX11) as it shows or find_package(X11)? if(UNIX) include(FindX11) find_library(FLTK_MATH_LIBRARY m) set(FLTK_PLATFORM_DEPENDENT_LIBS ${X11_LIBRARIES} ${FLTK_MATH_LIBRARY}) endif() Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Tue Sep 9 14:56:56 2014 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 9 Sep 2014 19:56:56 +0100 Subject: [cmake-developers] [PATCH] FindIce: Remove unneeded search path modification In-Reply-To: <540F2165.6090909@kitware.com> References: <20140909153507.GO7997@codelibre.net> <540F2165.6090909@kitware.com> Message-ID: <20140909185656.GP7997@codelibre.net> On Tue, Sep 09, 2014 at 11:48:53AM -0400, Brad King wrote: > On 09/09/2014 11:35 AM, Roger Leigh wrote: > > I have attached a minor fix to the FindIce module added a couple of > > weeks back. > > Applied, thanks: > > FindIce: Remove unneeded search path modification > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d5047ca1 > > While reviewing I noticed that there are some message(STATUS) calls > not protected by if(Ice_DEBUG) or checks of Ice_FIND_QUIETLY. The > latter is needed to honor the QUIET option of find_package. Please > revise in a follow-up patch. I have attached a patch to do this. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-FindIce-Respect-Ice_FIND_QUIETLY-when-printing-messa.patch Type: text/x-diff Size: 1870 bytes Desc: not available URL: From brad.king at kitware.com Tue Sep 9 15:22:16 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Sep 2014 15:22:16 -0400 Subject: [cmake-developers] include(...) or find_package(...) within another Find module In-Reply-To: References: Message-ID: <540F5368.3090509@kitware.com> On 09/09/2014 02:21 PM, Richard Shaw wrote: > Should this be include(FindX11) as it shows or find_package(X11)? > > if(UNIX) > include(FindX11) > find_library(FLTK_MATH_LIBRARY m) > set(FLTK_PLATFORM_DEPENDENT_LIBS ${X11_LIBRARIES} ${FLTK_MATH_LIBRARY}) > endif() It should be find_package(X11). Thanks, -Brad From brad.king at kitware.com Tue Sep 9 15:22:22 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Sep 2014 15:22:22 -0400 Subject: [cmake-developers] [PATCH] FindIce: Remove unneeded search path modification In-Reply-To: <20140909185656.GP7997@codelibre.net> References: <20140909153507.GO7997@codelibre.net> <540F2165.6090909@kitware.com> <20140909185656.GP7997@codelibre.net> Message-ID: <540F536E.8040301@kitware.com> On 09/09/2014 02:56 PM, Roger Leigh wrote: > I have attached a patch to do this. Thanks, applied: FindIce: Respect Ice_FIND_QUIETLY when printing messages http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2131aedd -Brad From hobbes1069 at gmail.com Tue Sep 9 16:38:14 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Tue, 9 Sep 2014 15:38:14 -0500 Subject: [cmake-developers] Gold standard find module? Message-ID: Everyone has been really helpful but I don't want to be a pest. Is there a specific find package module that one could point to that would be consider the gold standard of getting it right? One with sufficient complexity (not like the wiki example). Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Tue Sep 9 18:32:16 2014 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 10 Sep 2014 00:32:16 +0200 Subject: [cmake-developers] Modern cross-platform buildsystem design requirements Message-ID: Hi, I saw the addition of the VS_WINRT_COMPONENT property. This seems to be an attribute to mark an executable specially so that it is built with appropriate flags for the WinRT platform. This reminds me of this thread: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9728 Building executables as libraries (2014-03-21) and I wonder again if a generic solution would be possible to design. I wonder what a cmake-based buildsystem would look like for a collection of executables/targets which should be built for multiple of these 'modern, extra attribute-requiring' platforms. Until a few years ago, add_library(foo foo.cpp) add_executable(myexe main.cpp) target_link_libraries(myexe foo) was all that was needed for what we then called 'cross-platform' - it is a sufficient description to generate buildsystems to generate a working library and executable on first-class targets Windows/Linux/Mac and also cross-compiling, given an appropriate toolchain file. Today, I think 'cross-platform' includes a few mobile platforms as first- class targets, and cross-compiling is part of what cross-platform means. So, I wonder what a cross-platform buildsystem necessarily looks like today, and whether it can be done better/abstracted with more first class features. I guess in addition to the above, there would need to be something like a wrapper macro around add_executable to set the appropriate target properties, and possibly use a platform-specific condition for whether to actually create an executable or a PIC shared library (as described in the above thread). Is there any known real-world project aiming to build for those varieties of platforms so we can see what abstraction is needed? According to http://www.cmake.org/Wiki/CMake_Cross_Compiling#FAQ.2FPotential_Problems "If you build software for PS3, you build software for two architectures, for the PowerPC and for the cells." That information seems to come from: http://www.cmake.org/pipermail/cmake/2008-January/018937.html I was reminded of the above by http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/50389 I don't know how common it is to use cmake in those industries/environments, but if multiple toolchains are needed, I'm reminded of the previous proposal for multiple toolchain use. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272 Partly that discussion was aborted because we already had the large topic of designing and implementing usage-requirements to deal with. As that is now complete as designed, it might be worthwhile to re-consider and discuss/design how multiple toolchains could be used at once, whether that would require or benefit from a new language for cmake (another orthogoal known possible future-direction for cmake) etc. [ The manual at Help/manual/cmake-toolchains.7.rst contains several sample toolchain files for Unix. It would be good to have some sample toolchain files using the new WinRT stuff, setting the toolset and CMAKE_GENERATOR_PLATFORM to see how that all fits together now with VisualStudio. ] Thanks, Steve. From daniel at pfeifer-mail.de Wed Sep 10 04:19:19 2014 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Wed, 10 Sep 2014 10:19:19 +0200 Subject: [cmake-developers] Modern cross-platform buildsystem design requirements In-Reply-To: References: Message-ID: Hi Steve, 2014-09-10 0:32 GMT+02:00 Stephen Kelly : > > > I wonder what a cmake-based buildsystem would look like for a collection of > executables/targets which should be built for multiple ... > I would generalize even more and finish the sentence with "options at once". This includes Debug/Release, Shared/Static, PlatformA/PlatformB, etc. With usage-requirements we now can propagate properties from dependees to dependents. What about the other direction? Imagine this: add_library(foo STATIC foo.cpp) add_library(bar SHARED bar.cpp) target_link_libraries(bar foo) add_executable(myexe main.cpp) target_link_libraries(myexe foo) A static library foo is used both in a shared library and in an executable. Depending on the platform it should be build twice: once with PIC, once without. Another example: We sometimes run code generators as custom buildsteps. add_library(foo foo.cpp) add_executable(codegen codegen.cpp) # set_target_properties(codegen PROPERTIES BUILD_FOR_HOST 1) target_link_libraries(codegen foo) add_custom_command(OUTPUT source.cpp COMMAND codegen) add_executable(myexe source.cpp) target_link_libraries(myexe foo) When crosscompiling, we need the codegenerator for the host platform (This would need some target property). But more interestingly, the library foo should be built for both the host and the target(s). Thank you for starting that discussion! -- Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Wed Sep 10 05:52:07 2014 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 10 Sep 2014 11:52:07 +0200 Subject: [cmake-developers] Gold standard find module? References: Message-ID: Richard Shaw wrote: > Everyone has been really helpful but I don't want to be a pest. > > Is there a specific find package module that one could point to that would > be consider the gold standard of getting it right? One with sufficient > complexity (not like the wiki example). Have you looked at http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#a-sample-find-module too? Thanks, Steve. From dlrdave at aol.com Wed Sep 10 06:29:13 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 10 Sep 2014 06:29:13 -0400 Subject: [cmake-developers] Gold standard find module? In-Reply-To: References: Message-ID: <8D19AF9334FB0D6-1768-38A20@webmail-m244.sysops.aol.com> I would say there are no "gold standard" find modules. The gold standard is a project config file, like Qt5 has. From http://www.cmake.org/cmake/help/v3.0/manual/cmake-qt.7.html : "the Qt 5 libraries are found using "Config-file Packages" shipped with Qt 5" Also, search this page for "Config mode": http://www.cmake.org/cmake/help/v3.0/command/find_package.html Find modules in CMake should be the last resort option, when it is simply impossible to add a project config mode file to a project. On the other hand, if the intent behind your question is to make the existing find modules all follow a given standard..... that's quite an ambitious goal. Let's see if anybody else names actual names for the "gold standard." Just my opinion, David C. From mantis at public.kitware.com Wed Sep 10 06:58:40 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 10 Sep 2014 06:58:40 -0400 Subject: [cmake-developers] [CMake 0015146]: MANIFESTUAC-Link flag results in vcxproj errors Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15146 ====================================================================== Reported By: Soeren Textor Assigned To: ====================================================================== Project: CMake Issue ID: 15146 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2014-09-10 06:58 EDT Last Modified: 2014-09-10 06:58 EDT ====================================================================== Summary: MANIFESTUAC-Link flag results in vcxproj errors Description: Adding the UAC flag like set_target_properties( XXX PROPERTIES LINK_FLAGS_DEBUG "MANIFESTUAC:\"level='requireAdministrator' uiAccess='false'\"" ) Therefore we obtain inside the vcxproj: true level='requireAdministrator' uiAccess='false' Instead of: true false RequireAdministrator what results in link errors Steps to Reproduce: Adding the UAC flag like set_target_properties( XXX PROPERTIES LINK_FLAGS_DEBUG "MANIFESTUAC:\"level='requireAdministrator' uiAccess='false'\"" ) and build a VS2013 project file Additional Information: I know there is antoher wa of adding link flags since 3.0, but we also use camke 2.8 and there it's teh same problem ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-10 06:58 Soeren Textor New Issue ====================================================================== From hobbes1069 at gmail.com Wed Sep 10 07:50:57 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Wed, 10 Sep 2014 06:50:57 -0500 Subject: [cmake-developers] Gold standard find module? In-Reply-To: References: Message-ID: On Wed, Sep 10, 2014 at 4:52 AM, Stephen Kelly wrote: > Richard Shaw wrote: > > > Everyone has been really helpful but I don't want to be a pest. > > > > Is there a specific find package module that one could point to that > would > > be consider the gold standard of getting it right? One with sufficient > > complexity (not like the wiki example). > > Have you looked at > > > http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#a-sample-find-module > > too? Thanks, that has a little more detail, but the module I'm trying to clean up is this one: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindFLTK.cmake;hb=HEAD It does a lot of questionable things, I think much of it due to the fact it's been unmaintained for so long and some of the newer commands were probably not available when it was written. One wrinkle is that you can't trust the 'fltk-config' program. If you specify "--libs" it will give you the static library location even if only shared libraries were built, so it only uses that to get the library location, not the library itself. The actual reason I took over the module is that it doesn't add the correct flags (--ldstaticflags) if you ARE actually using static libraries, but after some investigation, it really need a lot of cleanup/modernization work and I'm not sure I'm completely qualified to be the one to do it :) Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From hobbes1069 at gmail.com Wed Sep 10 07:55:55 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Wed, 10 Sep 2014 06:55:55 -0500 Subject: [cmake-developers] Gold standard find module? In-Reply-To: <8D19AF9334FB0D6-1768-38A20@webmail-m244.sysops.aol.com> References: <8D19AF9334FB0D6-1768-38A20@webmail-m244.sysops.aol.com> Message-ID: On Wed, Sep 10, 2014 at 5:29 AM, David Cole via cmake-developers < cmake-developers at cmake.org> wrote: > I would say there are no "gold standard" find modules. > > The gold standard is a project config file, like Qt5 has. > > From http://www.cmake.org/cmake/help/v3.0/manual/cmake-qt.7.html : > > "the Qt 5 libraries are found using "Config-file Packages" shipped with Qt > 5" > > Also, search this page for "Config mode": > > http://www.cmake.org/cmake/help/v3.0/command/find_package.html > > Find modules in CMake should be the last resort option, when it is simply > impossible to add a project config mode file to a project. > Yes, in fact cmake builds of FLTK actually do provide a config file and the find module tries to locate it, but as I mentioned to Stephen, I'm just trying to improve the current module at this point. > On the other hand, if the intent behind your question is to make the > existing find modules all follow a given standard..... that's quite an > ambitious goal. Let's see if anybody else names actual names for the "gold > standard." In this case just the one. I'm not that ambitious as I'm just volunteering my time to various FOSS projects and still have to maintain a day job to pay the bills! Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Wed Sep 10 08:18:54 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 10 Sep 2014 08:18:54 -0400 Subject: [cmake-developers] Gold standard find module? Message-ID: <8D19B0885668016-1768-3927B@webmail-m244.sysops.aol.com> > In this case just the one. I'm not that ambitious as I'm just > volunteering my time to various FOSS projects and still have to > maintain a day job to pay the bills! :-) In that case, I would recommend just getting it into shape so that it works best for you. (But then, that's the way we've ended up with so many ways of doing things in the find modules we do have....) As you submit changes for review, though, hopefully the reviewers will catch anything that is not recommended and ask you to revise it before pushing it into 'master'. I think asking specific questions when you have something you're not sure of is better than trying to identify a gold standard find module on which to model your contributions. HTH, David C. From mantis at public.kitware.com Wed Sep 10 08:55:04 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 10 Sep 2014 08:55:04 -0400 Subject: [cmake-developers] [CMake 0015147]: CMAKE_HOST_SYSTEM_PROCESSOR not detected on GNU/Hurd Message-ID: <2a5df639666b613c41568059de1bd383@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15147 ====================================================================== Reported By: Felix Geyer Assigned To: ====================================================================== Project: CMake Issue ID: 15147 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-10 08:55 EDT Last Modified: 2014-09-10 08:55 EDT ====================================================================== Summary: CMAKE_HOST_SYSTEM_PROCESSOR not detected on GNU/Hurd Description: CMAKE_HOST_SYSTEM_NAME is "unknown" on Debian GNU/Hurd as uname -p prints "unknown". "uname -m" works and returns i686-AT386. I guess it's usually expected to be i[3-6]86 on x86 but changing what the OS reports doesn't seem like the right thing to do. Attached is a patch that switches the uname call to "-m" like it does for Linux. I opted for an exact match for "GNU" because there is also a Debian "GNU/kFreeBSD" architecture. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-10 08:55 Felix Geyer New Issue 2014-09-10 08:55 Felix Geyer File Added: host_system_processor_gnu.diff ====================================================================== From brad.king at kitware.com Wed Sep 10 10:02:58 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 10 Sep 2014 10:02:58 -0400 Subject: [cmake-developers] Modern cross-platform buildsystem design requirements In-Reply-To: References: Message-ID: <54105A12.6070805@kitware.com> On 09/09/2014 06:32 PM, Stephen Kelly wrote: > I saw the addition of the VS_WINRT_COMPONENT property. This seems to be an > attribute to mark an executable specially so that it is built with > appropriate flags for the WinRT platform. Yes. It is similar to the WIN32_EXECUTABLE target property. > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9728 > Building executables as libraries (2014-03-21) FYI, in my Github fork you can see a WIP branch adding support for NVIDIA's Nsight Tegra Visual Studio Edition. It links executables as shared libraries unless they are marked with an ANDROID_GUI target property. The property activates creation of a .apk. > Today, I think 'cross-platform' includes a few mobile platforms as first- > class targets, and cross-compiling is part of what cross-platform means. So, > I wonder what a cross-platform buildsystem necessarily looks like today, and > whether it can be done better/abstracted with more first class features. Good question. I think support for each mobile target will have to be added on an incremental basis. If some common themes emerge over time then perhaps we can identify some abstractions. However, each of these platforms requires some kind of app manifest, and that is a different file/format for each target platform. Projects will at least have to add such manifest files for each platform they want to support. > I'm reminded of the previous proposal for multiple toolchain use. > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272 > > Partly that discussion was aborted because we already had the large topic of > designing and implementing usage-requirements to deal with. As that is now > complete as designed, it might be worthwhile to re-consider and > discuss/design how multiple toolchains could be used at once, whether that > would require or benefit from a new language for cmake (another orthogoal > known possible future-direction for cmake) etc. The main challenge here is that CMake exposes a lot of information about "the one" toolchain per language selected during configuration in the CMake language as variables. Your "toolchain scope" proposal would provide a context for code that will see the toolchain information for each enabled target toolchain. However, perhaps it would be better in the long run to consider something more declarative and with a new language. When cross-compiling it is common to build some tools for the host system to be used during the build itself. There is always exactly one host platform, so perhaps we can design a new mode of support for cross-compiling that configures "the one" toolchain for the *host* system only. Then provide some kind of declarative or delayed-until- generate-time specification, perhaps using a new language, for the cross-compiled pieces. Eventually that spec could be used for the host system too. -Brad From mantis at public.kitware.com Wed Sep 10 11:01:59 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 10 Sep 2014 11:01:59 -0400 Subject: [cmake-developers] [CMake 0015148]: CMAKE_FORCE_C_COMPILER requests full path to cl.exe Message-ID: <494adc7d1ee9b4aa83c57394fd77b502@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15148 ====================================================================== Reported By: a.grudin Assigned To: ====================================================================== Project: CMake Issue ID: 15148 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-10 11:01 EDT Last Modified: 2014-09-10 11:01 EDT ====================================================================== Summary: CMAKE_FORCE_C_COMPILER requests full path to cl.exe Description: The CMake version 2.8 requires just relative path to cl.exe. Like: include(CMakeForceCompiler) CMAKE_FORCE_C_COMPILER("cl.exe" "ARM") And it was convinient. But for new one the options requires to be absolute path. CMAKE_FORCE_C_COMPILER("C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/WPSDK/WP80/bin/cl.exe" "ARM") Steps to Reproduce: Command line: cmake -G "Visual Studio 11 2012 ARM" -T"v110_wp80" ../Project CMakeLists.txt: include(CMakeForceCompiler) CMAKE_FORCE_C_COMPILER("cl.exe" "ARM") CMAKE_FORCE_CXX_COMPILER("cl.exe" "ARM") endif() project(SE) Additional Information: Also check system files when warning about unused and uninitialized variables. CMake Error at CMakeLists.txt:385 (project): The CMAKE_C_COMPILER: cl.exe is not a full path and was not found in the PATH. -- Configuring incomplete, errors occurred! ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-10 11:01 a.grudin New Issue ====================================================================== From brad.king at kitware.com Wed Sep 10 11:33:07 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 10 Sep 2014 11:33:07 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <540DCCBF.6010002@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> Message-ID: <54106F33.3040504@kitware.com> On 09/08/2014 11:35 AM, Nils Gladitz wrote: > I updated the topic, squished and merged. Thanks. I've updated the topic to include all the actual fixes for CMP0054 warnings within CMake's own code that I've found so far. I have a few more changes to request that you add to the topic: * The wording of the warning says what the change in behavior is, but does not inform the user that the old behavior is being used for compatibility. Currently without reading the policy documentation one might think from the messages that the logic is being executed differently than before. * In cmIfCommand we should avoid doing the lookups when the policy is NEW. Instead of calling mf->GetPolicyStatus on every step of the way, call it once at the beginning of the if() command execution and save the result in a member. Then in cmIfCommand::GetDefinitionIfUnquoted, check for quoting and the policy status before even trying to do the lookup. That should make processing of quoted arguments much faster because we won't have to check for a definition with every string value. * The CMP0054-keywords-NEW test does not cover "(" and ")". (Good catch on implementing those, BTW.) * The tests need to cover if() inside while() and foreach() as well as macro() and function(). Also add nested if() for completeness. Thanks, -Brad From hobbes1069 at gmail.com Wed Sep 10 11:38:44 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Wed, 10 Sep 2014 10:38:44 -0500 Subject: [cmake-developers] Gold standard find module? In-Reply-To: <8D19B0885668016-1768-3927B@webmail-m244.sysops.aol.com> References: <8D19B0885668016-1768-3927B@webmail-m244.sysops.aol.com> Message-ID: On Wed, Sep 10, 2014 at 7:18 AM, David Cole wrote: > > In this case just the one. I'm not that ambitious as I'm just > > volunteering my time to various FOSS projects and still have to > > maintain a day job to pay the bills! > > In that case, I would recommend just getting it into shape so that it > works best for you. (But then, that's the way we've ended up with so > many ways of doing things in the find modules we do have....) As you > submit changes for review, though, hopefully the reviewers will catch > anything that is not recommended and ask you to revise it before > pushing it into 'master'. > That's kinda what I was thinking as well but some of the problem I'm trying to fix are requiring some significant changes that looking at a simple diff may not really be helpful... > I think asking specific questions when you have something you're not > sure of is better than trying to identify a gold standard find module > on which to model your contributions. I'm sure I'll still have plenty of questions, I was just hoping to have a really good example to go by to catch the easy stuff. Although, thinking about it now I haven't found a whole lot in my googling so perhaps the discussions here we help other future CMake users/developers. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Wed Sep 10 11:49:54 2014 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 10 Sep 2014 17:49:54 +0200 Subject: [cmake-developers] Modern cross-platform buildsystem design requirements References: <54105A12.6070805@kitware.com> Message-ID: Brad King wrote: > On 09/09/2014 06:32 PM, Stephen Kelly wrote: >> I saw the addition of the VS_WINRT_COMPONENT property. This seems to be >> an attribute to mark an executable specially so that it is built with >> appropriate flags for the WinRT platform. > > Yes. It is similar to the WIN32_EXECUTABLE target property. > >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9728 >> Building executables as libraries (2014-03-21) > > FYI, in my Github fork you can see a WIP branch adding support for > NVIDIA's Nsight Tegra Visual Studio Edition. It links executables > as shared libraries unless they are marked with an ANDROID_GUI target > property. I notice there is also a ANDROID_API target property. Presumably that allows things like foreach(api 16 19) add_library(mylib-android-${api} mylib.cpp) set_property(TARGET mylib-android-${api} PROPERTY ANDROID_API ${api}) endforeach() I wonder if it would instead make sense to provide some INTERFACE targets with INTERFACE_ANDROID_API set and then target_link_libraries(mylib cmake::android-16) for example. This has the disadvantage of requiring the android-${api} targets to be predefined, but maybe a use-story of set(CMAKE_ANDROID_APIS 16 19) include(CMakeAndroidTargets) would avoid a need to hardcode them. The INTERFACE_ANDROID_API, along with compatibility requirements, would prevent mistakes (?) like add_library(lib1 ...) add_library(lib2 ...) set_property(TARGET lib1 PROPERTY ANDROID_API 16) set_property(TARGET lib1 PROPERTY ANDROID_API 19) target_link_libraries(lib1 lib2) # Not the same API version. > The property activates creation of a .apk. The approach I prototyped for BB10 .bar packages was to generate them with cpack. https://gitorious.org/cmake/steveires-cmake/commit/c7715486 This has the effect that the description of build-targets and their dependencies etc is mostly 'normal' and free from BB10-specific stuff, and there is a list of cpack/BAR-related variables in the cpack section of the CMakeLists (where there could also be a list of cpack/android-related variables). Should there be some merging of functionality from cpack into cmake? > >> Today, I think 'cross-platform' includes a few mobile platforms as first- >> class targets, and cross-compiling is part of what cross-platform means. >> So, I wonder what a cross-platform buildsystem necessarily looks like >> today, and whether it can be done better/abstracted with more first class >> features. > > Good question. I think support for each mobile target will have to be > added on an incremental basis. If some common themes emerge over time > then perhaps we can identify some abstractions. It seems that with these changes, a project aiming to be 'cross-platform' would end up writing a macro like macro(set_properties_for_platform tgt) if (CROSS_COMPILING) if (ANDROID) set_property(TARGET ${tgt} ...) elseif (BLACKBERRY) set_property(TARGET ${tgt} ...) elseif (WinRT) set_property(TARGET ${tgt} ...) endif() endif() endmacro() # This now looks 'normal' and 'cross platform' add_executable(hello_world main.cpp) # Call this for each target: set_properties_for_platform(hello_world) That's assuming such a macro has all the information it would need to set the appropriate properties... > However, each of these > platforms requires some kind of app manifest, and that is a different > file/format for each target platform. Projects will at least have to > add such manifest files for each platform they want to support. Do each such files have the same or similar content? Author, url, siging key etc? That might be a good avenue to explore for a cross-platform abstraction. > >> I'm reminded of the previous proposal for multiple toolchain use. >> >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272 >> >> Partly that discussion was aborted because we already had the large topic >> of designing and implementing usage-requirements to deal with. As that is >> now complete as designed, it might be worthwhile to re-consider and >> discuss/design how multiple toolchains could be used at once, whether >> that would require or benefit from a new language for cmake (another >> orthogoal known possible future-direction for cmake) etc. > > The main challenge here is that CMake exposes a lot of information about > "the one" toolchain per language selected during configuration in the > CMake language as variables. Your "toolchain scope" proposal would > provide a context for code that will see the toolchain information > for each enabled target toolchain. However, perhaps it would be better > in the long run to consider something more declarative and with a > new language. Yes, perhaps. A new language creates a lot of sunk-cost for people porting and learning it though of course. There would need to be enough justification for doing it. This could be designed to be part of that justification. I think there may be other justifications for designing a new language too. Are you still thinking of a 'pure'-Lua-based (not via CMakeLists which loads Lua somehow) system as an end-goal? I believe part of the motivation for qbs (the next Qt build tool) is multiple architecture support, which I believe is preferred by some to create Android APKs targeting multiple architectures http://blog.qt.digia.com/blog/2014/03/26/qt-weekly-3-qt-for-android-tips-and-tricks/#comment-1193255 So, that's at least how this stuff in this thread fits together and can be considered together. I don't understand the motivation to put multiple architectures into one package (everyone downloading the package gets N-1 times the amount of stuff they need), but so it is. Anyway the above problem is not solved with the suggestion below. > When cross-compiling it is common to build some tools for the host > system to be used during the build itself. There is always exactly > one host platform, so perhaps we can design a new mode of support for > cross-compiling that configures "the one" toolchain for the *host* > system only. Then provide some kind of declarative or delayed-until- > generate-time specification, perhaps using a new language, for the > cross-compiled pieces. Eventually that spec could be used for the > host system too. Yes, that would be a good intermediate goal. There are many interesting design requirements even for that, such as the example from Daniel of building a library for both host and target, and whether find_package would need multiple modes of operation etc. For example, in a single cmake buildsystem I would need two Qt5Core packages - one host used by a generator and one target. Currently there is only one cache and one possible Qt5Core_DIR etc. When you refer to 'a new language' here, do you mean in the same sense of how generator expressions were a new language (without a departure from the current cmake language as a whole), or do you mean something different? Thanks, Steve. From nilsgladitz at gmail.com Wed Sep 10 15:42:12 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 10 Sep 2014 21:42:12 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <54106F33.3040504@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> Message-ID: <5410A994.1040805@gmail.com> On 09/10/2014 05:33 PM, Brad King wrote: > Thanks. I've updated the topic to include all the actual fixes > for CMP0054 warnings within CMake's own code that I've found so > far. Thanks! > I have a few more changes to request that you add to the topic: > > * The wording of the warning says what the change in behavior > is, but does not inform the user that the old behavior is > being used for compatibility. Currently without reading the > policy documentation one might think from the messages that > the logic is being executed differently than before. Done. > * In cmIfCommand we should avoid doing the lookups when the > policy is NEW. Instead of calling mf->GetPolicyStatus on > every step of the way, call it once at the beginning of the > if() command execution and save the result in a member. > Then in cmIfCommand::GetDefinitionIfUnquoted, check for > quoting and the policy status before even trying to do the > lookup. That should make processing of quoted arguments > much faster because we won't have to check for a definition > with every string value. The functions for condition evaluation were global or static (I assume so they could be shared with while()) and I would have had to pass through the policy state as extra parameters. This was also done with CMP0012 but I figured I might just as well extract everything into its own class "cmConditionEvaluator" and have it keep everything that was being passed around as members instead. > * The CMP0054-keywords-NEW test does not cover "(" and ")". > (Good catch on implementing those, BTW.) > > * The tests need to cover if() inside while() and foreach() > as well as macro() and function(). Also add nested if() > for completeness. I added tests but specifically for the loops I am not entirely sure what to cover given that the context of recording and replaying is basically the same (unlike with functions/macros)? I wouldn't mind some extra scrutiny to make sure they cover what you had in mind. Thanks. Nils From neundorf at kde.org Wed Sep 10 16:30:09 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Wed, 10 Sep 2014 22:30:09 +0200 Subject: [cmake-developers] Gold standard find module? In-Reply-To: References: <8D19B0885668016-1768-3927B@webmail-m244.sysops.aol.com> Message-ID: <8109727.83lFbJIXnr@tuxedo.neundorf.net> On Wednesday, September 10, 2014 10:38:44 Richard Shaw wrote: > On Wed, Sep 10, 2014 at 7:18 AM, David Cole wrote: > > > In this case just the one. I'm not that ambitious as I'm just > > > volunteering my time to various FOSS projects and still have to > > > maintain a day job to pay the bills! > > > > In that case, I would recommend just getting it into shape so that it > > works best for you. (But then, that's the way we've ended up with so > > many ways of doing things in the find modules we do have....) As you > > submit changes for review, though, hopefully the reviewers will catch > > anything that is not recommended and ask you to revise it before > > pushing it into 'master'. > > That's kinda what I was thinking as well but some of the problem I'm trying > to fix are requiring some significant changes that looking at a simple diff > may not really be helpful... > > > I think asking specific questions when you have something you're not > > sure of is better than trying to identify a gold standard find module > > on which to model your contributions. > > I'm sure I'll still have plenty of questions, I was just hoping to have a > really good example to go by to catch the easy stuff. Just a few things: - variables should be named ExactCaseName_SOMETHING - try to detect the version number - use find_package_handle_standard_args() in the new mode - make sure it works also on systems without pkg-config Alex From mantis at public.kitware.com Wed Sep 10 18:50:18 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 11 Sep 2014 00:50:18 +0200 Subject: [cmake-developers] [CMake 0015149]: Document that the CHECK_* macros create cache variables Message-ID: <8e001ca2a2f25c387785e60555bce7e9@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15149 ====================================================================== Reported By: sleske Assigned To: ====================================================================== Project: CMake Issue ID: 15149 Category: Documentation Reproducibility: N/A Severity: text Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-11 00:50 CEST Last Modified: 2014-09-11 00:50 CEST ====================================================================== Summary: Document that the CHECK_* macros create cache variables Description: The various CHECK_* macros (CHECK_C_COMPILER_FLAG, CHECK_FORTRAN_FUNCTION_EXISTS Etc.) set a result variable whose name is specified as a parameter. However, the macros do not document that the result variable is created as a cache variable. While this is probaby obvious to experienced CMake users, it can be confusing for newbies. For example, calling multiple CHECK_* macros with the same result variable will not work as expected, because the variable is only set once. This should be documented. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-11 00:50 sleske New Issue ====================================================================== From pascal.bach at siemens.com Thu Sep 11 05:07:35 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Thu, 11 Sep 2014 11:07:35 +0200 Subject: [cmake-developers] [PATCH] WINCE: Document the WINCE variable Message-ID: <1410426455-18272-1-git-send-email-pascal.bach@siemens.com> --- Help/manual/cmake-variables.7.rst | 1 + Help/variable/WINCE.rst | 5 +++++ 2 files changed, 6 insertions(+) create mode 100644 Help/variable/WINCE.rst diff --git a/Help/manual/cmake-variables.7.rst b/Help/manual/cmake-variables.7.rst index 149e4ac..b00c16e 100644 --- a/Help/manual/cmake-variables.7.rst +++ b/Help/manual/cmake-variables.7.rst @@ -192,6 +192,7 @@ Variables that Describe the System /variable/MSVC_VERSION /variable/UNIX /variable/WIN32 + /variable/WINCE /variable/WINDOWS_PHONE /variable/WINDOWS_STORE /variable/XCODE_VERSION diff --git a/Help/variable/WINCE.rst b/Help/variable/WINCE.rst new file mode 100644 index 0000000..54ff7de --- /dev/null +++ b/Help/variable/WINCE.rst @@ -0,0 +1,5 @@ +WINCE +----- + +True when the :variable:`CMAKE_SYSTEM_NAME` variable is set +to ``WindowsCE``. -- 1.7.10.4 From mantis at public.kitware.com Thu Sep 11 05:29:48 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 11 Sep 2014 05:29:48 -0400 Subject: [cmake-developers] [CMake 0015150]: Eclipse generator produces very bad symbol browsing quality for plain C, due to __cplusplus being set unconditionally Message-ID: <564073d666d3a5d8c8b3973113295f3a@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15150 ====================================================================== Reported By: Martin Oberhuber Assigned To: ====================================================================== Project: CMake Issue ID: 15150 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-11 05:29 EDT Last Modified: 2014-09-11 05:29 EDT ====================================================================== Summary: Eclipse generator produces very bad symbol browsing quality for plain C, due to __cplusplus being set unconditionally Description: When I import my plain C project generated with the "Eclipse CDT4 - Unix Makefiles" generator into Eclipse, I see very bad symbol quality: Indexed 'myproject at linux64' (365 sources, 800 headers) in 24.2 sec: 81,605 declarations; 665,941 references; 54 unresolved inclusions; 3,708 syntax errors; 107,398 unresolved names (13%) Note the 13% unresolved names, which means that the calltree (referenced-by) will fail 13% of the time ! This is way too unreliable. Investigation showed that the main problem is cmake generating "__cplusplus=1" unconditionally into the Project Properties > C/C++ Include Paths. When deleting the incorrect __cplusplus setting I get almost perfect symbol quality: Indexed 'myproject at linux64' (365 sources, 800 headers) in 23.2 sec: 98,095 declarations; 785,956 references; 54 unresolved inclusions; 2,230 syntax errors; 4,732 unresolved names (0.53%) --> Note only 0.53% unresolved names now (in this case due to some Windows headers). Also note that a __cplusplus macro will be added automatically by Eclipse CDT when looking at any *.cpp / *.cxx / *.cc files. So that macro really should not be set hard-coded by the project generator ! Steps to Reproduce: cmake -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_ECLIPSE_VERSION=4.4 ../myproject make # Now import the generated project into Eclipse for C/C++ 4.4 Additional Information: Workaround: After importing the generated project, right-click > C/C++ Include Paths and manually delete the __cplusplus macro setting. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-11 05:29 Martin OberhuberNew Issue ====================================================================== From brad.king at kitware.com Thu Sep 11 08:48:39 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 08:48:39 -0400 Subject: [cmake-developers] [PATCH] WINCE: Document the WINCE variable In-Reply-To: <1410426455-18272-1-git-send-email-pascal.bach@siemens.com> References: <1410426455-18272-1-git-send-email-pascal.bach@siemens.com> Message-ID: <54119A27.2080905@kitware.com> On 09/11/2014 05:07 AM, Pascal Bach wrote: > Help/manual/cmake-variables.7.rst | 1 + > Help/variable/WINCE.rst | 5 +++++ Applied, thanks: Help: Document the WINCE variable http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4b4555de -Brad From brad.king at kitware.com Thu Sep 11 09:04:18 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 09:04:18 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5410A994.1040805@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> Message-ID: <54119DD2.4080606@kitware.com> On 09/10/2014 03:42 PM, Nils Gladitz wrote: > extract everything into its own class "cmConditionEvaluator" and have it > keep everything that was being passed around as members instead. Good work. I think the net change is now in good shape. To make it easier to review now and bisect in the future, please rewrite the topic to start with refactoring cmIfCommand to split out the cmConditionEvaluator, and then add the rest of the changes. Thanks, -Brad From nilsgladitz at gmail.com Thu Sep 11 09:20:10 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 11 Sep 2014 15:20:10 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <54119DD2.4080606@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> Message-ID: <5411A18A.7060106@gmail.com> On 11.09.2014 15:04, Brad King wrote: > Good work. I think the net change is now in good shape. To make it > easier to review now and bisect in the future, please rewrite the > topic to start with refactoring cmIfCommand to split out the > cmConditionEvaluator, and then add the rest of the changes. Thanks. Is there a trick to recreate the history in that order or would I have to start from scratch? Nils From brad.king at kitware.com Thu Sep 11 09:28:28 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 09:28:28 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411A18A.7060106@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> Message-ID: <5411A37C.1070101@kitware.com> On 09/11/2014 09:20 AM, Nils Gladitz wrote: > Is there a trick to recreate the history in that order or > would I have to start from scratch? First rewrite the branch to squash your updates back into the first commit, leaving all my CMP0054 warning commits later in the topic. Then start a new branch from the squashed commit containing only your part of the changes. Note the sha1 of this commit, say a01b2c3. Then edit it to *remove* the changes besides the refactoring and amend the commit. The result should be just one commit with the refactoring parts. Then you can use the "git commit-tree" plumbing to create a commit with the tree object of your original change but set its parent as the edited commit. This will manufacture a commit that makes the changes on top of the refactoring: commit=$(git commit-tree a01b2c3^{tree} -p HEAD) git merge $commit git commit --amend -C a01b2c3 Finally, rebase the rest of the topic back onto that. The tip of the resulting topic should look identical to what is on the stage now. Thanks, -Brad From nilsgladitz at gmail.com Thu Sep 11 11:35:42 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 11 Sep 2014 17:35:42 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411A37C.1070101@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> Message-ID: <5411C14E.7000207@gmail.com> On 11.09.2014 15:28, Brad King wrote: > First rewrite the branch to squash your updates back into > the first commit, leaving all my CMP0054 warning commits > later in the topic. Then start a new branch from the > squashed commit containing only your part of the changes. > Note the sha1 of this commit, say a01b2c3. Then edit it > to *remove* the changes besides the refactoring Thanks for the walk through. I am a bit stuck on removing the CMP0054 changes from cmConditionEvaluator.cxx part given that file is new and didn't exist without the changes. I'll redo the refactoring part manually from scratch if I can't figure out something better. Might take me a bit; I haven't had much experience with those git aspects yet. Nils From brad.king at kitware.com Thu Sep 11 11:39:17 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 11:39:17 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411C14E.7000207@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> Message-ID: <5411C225.7020706@kitware.com> On 09/11/2014 11:35 AM, Nils Gladitz wrote: > Thanks for the walk through. > > I am a bit stuck on removing the CMP0054 changes from > cmConditionEvaluator.cxx part given that file is new and didn't exist > without the changes. The file should exist, just remove the CMP0054 parts from it and amend the commit. > I'll redo the refactoring part manually from scratch if I can't figure > out something better. > > Might take me a bit; I haven't had much experience with those git > aspects yet. If it takes too much time, don't bother doing this part unless you are really interested in using it as a learning opportunity. Let me know either way, please. Thanks, -Brad From brad.king at kitware.com Thu Sep 11 11:47:37 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 11:47:37 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <540A14A2.30904@kitware.com> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> <5409C1CE.1010501@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC74@DEFTHW99EH4MSX.ww902.siemens.net> <540A14A2.30904@kitware.com> Message-ID: <5411C419.6060201@kitware.com> On 09/05/2014 03:53 PM, Brad King wrote: > I think "CMAKE_GENERATOR_PLATFORM" may be a suitable name. Ideally > this setting should be added as a general-purpose replacement for > putting "ARM" or "Win64" in the generator name. The changes for > that are more sweeping than I'd like to ask of you just for WinCE > support, so I drafted them myself. This is now in 'master'. On 09/04/2014 06:42 AM, Bach, Pascal wrote: >> At the beginning of this block you should check/reject when >> the generator name specified a platform name. Something like: >> >> if(this->PlatformName != "Win32") >> { >> cmOStringStream e; >> e << "CMAKE_SYSTEM_NAME is 'WindowsCE' but CMAKE_GENERATOR " >> << "specifies a platform too: '" << this->GetName() << "'"; >> mf->IssueMessage(cmake::FATAL_ERROR, e.str()); >> return false; >> } > > This won't' work as the code gets called multiple times Along with the above changes I also made SetSystemName not get called more than once. The "PlatformName" member is now "DefaultPlatformName". Initially it corresponds to the default based on the generator name, so you should be able to check it as shown above. SetSystemName can modify DefaultPlatformName for specific systems to have a different default in case CMAKE_GENERATOR_PLATFORM is not set. The value of that setting is then processed by SetGeneratorPlatform. -Brad From nilsgladitz at gmail.com Thu Sep 11 11:52:10 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 11 Sep 2014 17:52:10 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411C225.7020706@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> Message-ID: <5411C52A.7020801@gmail.com> On 11.09.2014 17:39, Brad King wrote: > On 09/11/2014 11:35 AM, Nils Gladitz wrote: >> Thanks for the walk through. >> >> I am a bit stuck on removing the CMP0054 changes from >> cmConditionEvaluator.cxx part given that file is new and didn't exist >> without the changes. > The file should exist, just remove the CMP0054 parts from it > and amend the commit. I might be missing something obvious. cmConditionEvaluator.cxx doesn't exist without the CMP0054 changes because I created it after I did most of the CMP0054 changes. Since most of the changes are replacements rather than plain additions *removing* those changes would mean having to restore those code parts which however used to be in cmIf.cxx rather than cmConditionEvaluator.cxx. Nils From robert.maynard at kitware.com Thu Sep 11 12:26:14 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 11 Sep 2014 12:26:14 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.0.2 Released Message-ID: We are pleased to announce that CMake 3.0.2 is now available for download. Please use the latest release from our download page: http://www.cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.0.2 since 3.0.1: Alan W. Irwin (1): ExternalProject: Avoid infinite loop on file download hash mismatch Brad King (6): CMP0047: Fix CMAKE_COMPILER_IS_GNU(CC|CXX) in OLD behavior CMP0022: Fix version documented to support LINK_PUBLIC/LINK_PRIVATE cmListFileLexer: Fix lexing of single '[' character (#15092) Xcode: Generate per-target file references (#15111) Fix finding binutils when cross-compiling with Clang CMake 3.0.2 Christian Svensson (2): KWIML: Teach ABI.h about OpenRISC 1000 KWSys CPU: Add support for OpenRISC 1000 Stephen Kelly (2): QtAutogen: Use the basename for resource files. QtAutogen: Fix use of multiple ui files in a single target. Tim Blechmann (1): BundleUtilities: Allow Info.plist files which use CR line endings From brad.king at kitware.com Thu Sep 11 12:53:13 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 12:53:13 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411C52A.7020801@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> Message-ID: <5411D379.1060807@kitware.com> On 09/11/2014 11:52 AM, Nils Gladitz wrote: > cmConditionEvaluator.cxx doesn't exist without the CMP0054 changes > because I created it after I did most of the CMP0054 changes. > Since most of the changes are replacements rather than plain additions > *removing* those changes would mean having to restore those code parts > which however used to be in cmIf.cxx rather than cmConditionEvaluator.cxx. I think you missed the part about squashing your changes together into the first commit of the topic. I just rewrote the topic to do that. Now you can start working from commit 5922fc2c: git checkout -b tmp 5922fc2c git rm Help/policy/CMP0054.rst Help/release/dev/if-sanity.rst git checkout HEAD~1 -- Help git rm -rf Tests/RunCMake/CMP0054 git checkout HEAD~1 -- Tests/RunCMake/CMakeLists.txt git commit --amend Then keep editing the files and amending the commit to leave behind only the refactoring pieces. Amend the commit message accordingly too. Then do: commit=$(git commit-tree 5922fc2c^{tree} -p HEAD) git merge $commit git commit --amend -C 5922fc2c to restore the rest of the commit's changes. Then rebase the rest of the topic to get the warning cleanups. -Brad From nilsgladitz at gmail.com Thu Sep 11 12:57:03 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 11 Sep 2014 18:57:03 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411D379.1060807@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> <5411D379.1060807@kitware.com> Message-ID: <5411D45F.5040504@gmail.com> On 11.09.2014 18:53, Brad King wrote: > On 09/11/2014 11:52 AM, Nils Gladitz wrote: >> cmConditionEvaluator.cxx doesn't exist without the CMP0054 changes >> because I created it after I did most of the CMP0054 changes. >> Since most of the changes are replacements rather than plain additions >> *removing* those changes would mean having to restore those code parts >> which however used to be in cmIf.cxx rather than cmConditionEvaluator.cxx. > I think you missed the part about squashing your changes together > into the first commit of the topic. I just rewrote the topic > to do that. Now you can start working from commit 5922fc2c: No I did that as well. > git checkout -b tmp 5922fc2c > git rm Help/policy/CMP0054.rst Help/release/dev/if-sanity.rst > git checkout HEAD~1 -- Help > git rm -rf Tests/RunCMake/CMP0054 > git checkout HEAD~1 -- Tests/RunCMake/CMakeLists.txt > git commit --amend I think I did all that too. > Then keep editing the files and amending the commit to leave > behind only the refactoring pieces. That is the part I was stuck at. Nils From brad.king at kitware.com Thu Sep 11 12:59:05 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 12:59:05 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411D45F.5040504@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> <5411D379.1060807@kitware.com> <5411D45F.5040504@gmail.com> Message-ID: <5411D4D9.50004@kitware.com> On 09/11/2014 12:57 PM, Nils Gladitz wrote: >> Then keep editing the files and amending the commit to leave >> behind only the refactoring pieces. > > That is the part I was stuck at. At this point cmConditionEvaluator.cxx exists in the source tree. What is the problem? -Brad From nilsgladitz at gmail.com Thu Sep 11 13:07:13 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 11 Sep 2014 19:07:13 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411D4D9.50004@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> <5411D379.1060807@kitware.com> <5411D45F.5040504@gmail.com> <5411D4D9.50004@kitware.com> Message-ID: <5411D6C1.2080200@gmail.com> On 11.09.2014 18:59, Brad King wrote: > At this point cmConditionEvaluator.cxx exists in the source tree. > What is the problem? I can not create a CMP0054 free version of cmConditionEvaluator.cxx by simply removing content from the file (or the patch). I would have to add back lines to cmConditionEvaluator.cxx which where removed while they were still in cmIfCommand.cxx. The problem is that I am not sure how to do that properly. Nils From brad.king at kitware.com Thu Sep 11 13:14:53 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Sep 2014 13:14:53 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411D6C1.2080200@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> <5411D379.1060807@kitware.com> <5411D45F.5040504@gmail.com> <5411D4D9.50004@kitware.com> <5411D6C1.2080200@gmail.com> Message-ID: <5411D88D.2080404@kitware.com> On 09/11/2014 01:07 PM, Nils Gladitz wrote: > I would have to add back lines to cmConditionEvaluator.cxx which where > removed while they were still in cmIfCommand.cxx. Look at the diff in commit 5922fc2c and you will see all those lines as removed from cmIfCommand. You can put them all in cmConditionEvaluator. Some of the work is manual. Effectively you are re-doing the refactoring from scratch without the CMP0054 pieces. The use of Git up to this point is just to help get close. The reason I'm asking for this is that the refactoring done to create cmConditionEvaluator is more intrusive than the original CMP0054 change. It will be much easier to convince myself that the whole thing is correct if I can see the refactoring done first and independently. Thanks, -Brad From nilsgladitz at gmail.com Thu Sep 11 13:24:11 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 11 Sep 2014 19:24:11 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411D88D.2080404@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> <5411D379.1060807@kitware.com> <5411D45F.5040504@gmail.com> <5411D4D9.50004@kitware.com> <5411D6C1.2080200@gmail.com> <5411D88D.2080404@kitware.com> Message-ID: <5411DABB.7050303@gmail.com> On 11.09.2014 19:14, Brad King wrote: > On 09/11/2014 01:07 PM, Nils Gladitz wrote: >> I would have to add back lines to cmConditionEvaluator.cxx which where >> removed while they were still in cmIfCommand.cxx. > Look at the diff in commit 5922fc2c and you will see all those lines as > removed from cmIfCommand. You can put them all in cmConditionEvaluator. > Some of the work is manual. Effectively you are re-doing the refactoring > from scratch without the CMP0054 pieces. The use of Git up to this point > is just to help get close. > > The reason I'm asking for this is that the refactoring done to create > cmConditionEvaluator is more intrusive than the original CMP0054 change. > It will be much easier to convince myself that the whole thing is correct > if I can see the refactoring done first and independently. Certainly, I don't argue against the change itself. It sounded like there might have been some sort of git magic that would have made it less manual. Thanks. Nils From nilsgladitz at gmail.com Thu Sep 11 15:40:17 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 11 Sep 2014 21:40:17 +0200 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411D88D.2080404@kitware.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> <5411D379.1060807@kitware.com> <5411D45F.5040504@gmail.com> <5411D4D9.50004@kitware.com> <5411D6C1.2080200@gmail.com> <5411D88D.2080404@kitware.com> Message-ID: <5411FAA1.4050805@gmail.com> I think I've got it rewritten properly but I didn't know what half the git commands I ran did most of the time so I am not entirely secure with the result. Would have probably not figured this out without your help. Thanks again! Nils From pascal.bach at siemens.com Fri Sep 12 03:42:35 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Fri, 12 Sep 2014 07:42:35 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <5411C419.6060201@kitware.com> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> <5409C1CE.1010501@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC74@DEFTHW99EH4MSX.ww902.siemens.net> <540A14A2.30904@kitware.com> <5411C419.6060201@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616AD0228@DEFTHW99EH4MSX.ww902.siemens.net> > On 09/05/2014 03:53 PM, Brad King wrote: > > I think "CMAKE_GENERATOR_PLATFORM" may be a suitable name. Ideally > > this setting should be added as a general-purpose replacement for > > putting "ARM" or "Win64" in the generator name. The changes for > > that are more sweeping than I'd like to ask of you just for WinCE > > support, so I drafted them myself. > > This is now in 'master'. > I tried master and the Platform selections works great. Thanks. Now in order to have it fully working on WindowsCE the following issues remain: 1. The subsystem for EXE and DLL currently it is set to Console or Windows depending on the WIN32_EXECUTABLE property of the target. For WinCE the subsystem needs to be always set to WindowsCE and the entry point needs to change based on the WIN32_EXECUTABLE property. 2. The Toolset variable needs to be set manually using CMAKE_GENERATOR_TOOLSET and it needs to match the selected Windows CE version. I'm updating my earlier patch to address this issue and I hope I can send it in today. Pascal From brad.king at kitware.com Fri Sep 12 08:23:22 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 12 Sep 2014 08:23:22 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Allow selecting an SDK for Windows CE on Visual Studio In-Reply-To: <355BE46A91031048906B695426A8D8E616AD0228@DEFTHW99EH4MSX.ww902.siemens.net> References: <1409764571-17403-1-git-send-email-pascal.bach@siemens.com> <355BE46A91031048906B695426A8D8E616ACE737@DEFTHW99EH4MSX.ww902.siemens.net> <54075A29.1030002@kitware.com> <355BE46A91031048906B695426A8D8E616ACE826@DEFTHW99EH4MSX.ww902.siemens.net> <540866E6.7050603@kitware.com> <355BE46A91031048906B695426A8D8E616ACE91B@DEFTHW99EH4MSX.ww902.siemens.net> <54088D58.70408@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC0B@DEFTHW99EH4MSX.ww902.siemens.net> <5409C1CE.1010501@kitware.com> <355BE46A91031048906B695426A8D8E616ACEC74@DEFTHW99EH4MSX.ww902.siemens.net> <540A14A2.30904@kitware.com> <5411C419.6060201@kitware.com> <355BE46A91031048906B695426A8D8E616AD0228@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <5412E5BA.1070708@kitware.com> On 09/12/2014 03:42 AM, Bach, Pascal wrote: > Now in order to have it fully working on WindowsCE the following issues remain: > 1. The subsystem for EXE and DLL currently it is set to Console or Windows depending on the WIN32_EXECUTABLE property of the target. For WinCE the subsystem needs to be always set to WindowsCE and the entry point needs to change based on the WIN32_EXECUTABLE property. FYI, I would be happy with hard-coding knowledge of this in the C++ generator implementation for now. Refactoring things to use the flag parser as we discussed before can be done later. Of course if you already have that well underway then it would be fine too ;) Thanks, -Brad From brad.king at kitware.com Fri Sep 12 08:24:03 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 12 Sep 2014 08:24:03 -0400 Subject: [cmake-developers] Alternate if() without implicit variable expansion In-Reply-To: <5411FAA1.4050805@gmail.com> References: <54087651.8010909@gmail.com> <540879F8.5050200@kitware.com> <54087C57.6060500@gmail.com> <540881B7.9090908@kitware.com> <54088823.3000309@gmail.com> <54088B0F.7030405@kitware.com> <54088C10.50601@gmail.com> <5409B17E.4050503@kitware.com> <5409B874.2060607@gmail.com> <540DC0DA.5010409@kitware.com> <540DCCBF.6010002@gmail.com> <54106F33.3040504@kitware.com> <5410A994.1040805@gmail.com> <54119DD2.4080606@kitware.com> <5411A18A.7060106@gmail.com> <5411A37C.1070101@kitware.com> <5411C14E.7000207@gmail.com> <5411C225.7020706@kitware.com> <5411C52A.7020801@gmail.com> <5411D379.1060807@kitware.com> <5411D45F.5040504@gmail.com> <5411D4D9.50004@kitware.com> <5411D6C1.2080200@gmail.com> <5411D88D.2080404@kitware.com> <5411FAA1.4050805@gmail.com> Message-ID: <5412E5E3.2060005@kitware.com> On 09/11/2014 03:40 PM, Nils Gladitz wrote: > I think I've got it rewritten properly Yes, it looks good! Thanks, -Brad From pascal.bach at siemens.com Fri Sep 12 08:47:06 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Fri, 12 Sep 2014 14:47:06 +0200 Subject: [cmake-developers] [PATCH] WINCE, VS: Make the Visual Studio 10+ generator Windows CE In-Reply-To: <5412E5BA.1070708@kitware.com> References: <5412E5BA.1070708@kitware.com> Message-ID: <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> - If Windows CE is targeted set the Subsystem and EntryPointSymbol accordingly - For Windows CE 2013 (8.0) set the toolset to C800 by default --- Source/cmGlobalVisualStudio10Generator.cxx | 40 ++++++++++++++++++++++++++++ Source/cmGlobalVisualStudio10Generator.h | 7 +++++ Source/cmVisualStudio10TargetGenerator.cxx | 20 ++++++++++++-- 3 files changed, 65 insertions(+), 2 deletions(-) diff --git a/Source/cmGlobalVisualStudio10Generator.cxx b/Source/cmGlobalVisualStudio10Generator.cxx index e2d4645..e87a69f 100644 --- a/Source/cmGlobalVisualStudio10Generator.cxx +++ b/Source/cmGlobalVisualStudio10Generator.cxx @@ -179,6 +179,14 @@ bool cmGlobalVisualStudio10Generator::InitializeSystem(cmMakefile* mf) return false; } } + else if (this->SystemName == "WindowsCE") + { + this->SystemIsWindowsCE = true; + if (!this->InitializeWindowsCE(mf)) + { + return false; + } + } return true; } @@ -201,6 +209,38 @@ bool cmGlobalVisualStudio10Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio10Generator::InitializeWindowsCE(cmMakefile* mf) + { + // To preserve the old behaviour just keep the DefaultPlatformToolset + // for unknown Windows CE versions, in the worst case the user has to set + // CMAKE_GENERATOR_TOOLSET manually. In that case warn the user. + std::string platformToolset = this->SelectWindowsCEToolset(); + if (!platformToolset.empty()) + { + this->DefaultPlatformToolset = platformToolset; + } + else + { + cmOStringStream e; + e << this->GetName() << " Windows CE version '" << this->SystemVersion + << "' might require CMAKE_GENERATOR_TOOLSET to be set."; + mf->IssueMessage(cmake::WARNING, e.str()); + } + + return true; + } + +//---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio10Generator::SelectWindowsCEToolset() const + { + if (this->SystemVersion == "8.0") + { + return "CE800"; + } + return ""; + } + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio10Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 11.00\n"; diff --git a/Source/cmGlobalVisualStudio10Generator.h b/Source/cmGlobalVisualStudio10Generator.h index f1ff9a4..a80222f 100644 --- a/Source/cmGlobalVisualStudio10Generator.h +++ b/Source/cmGlobalVisualStudio10Generator.h @@ -76,6 +76,10 @@ public: bool TargetsWindowsStore() const { return this->SystemIsWindowsStore; } + /** Return true if building for WindowsCE */ + bool TargetsWindowsCE() const + { return this->SystemIsWindowsCE; } + /** * Where does this version of Visual Studio look for macros for the * current user? Returns the empty string if this version of Visual @@ -107,8 +111,10 @@ protected: virtual bool InitializeSystem(cmMakefile* mf); virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const { return ""; } virtual std::string SelectWindowsStoreToolset() const { return ""; } + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "10.0"; } @@ -120,6 +126,7 @@ protected: std::string SystemVersion; bool SystemIsWindowsPhone; bool SystemIsWindowsStore; + bool SystemIsWindowsCE; bool ExpressEdition; bool UseFolderProperty(); diff --git a/Source/cmVisualStudio10TargetGenerator.cxx b/Source/cmVisualStudio10TargetGenerator.cxx index c525b7c..681b8c7 100644 --- a/Source/cmVisualStudio10TargetGenerator.cxx +++ b/Source/cmVisualStudio10TargetGenerator.cxx @@ -2115,11 +2115,27 @@ cmVisualStudio10TargetGenerator::ComputeLinkOptions(std::string const& config) if ( this->Target->GetPropertyAsBool("WIN32_EXECUTABLE") ) { - linkOptions.AddFlag("SubSystem", "Windows"); + if (this->GlobalGenerator->TargetsWindowsCE()) + { + linkOptions.AddFlag("SubSystem", "WindowsCE"); + linkOptions.AddFlag("EntryPointSymbol", "WinMainCRTStartup"); + } + else + { + linkOptions.AddFlag("SubSystem", "Windows"); + } } else { - linkOptions.AddFlag("SubSystem", "Console"); + if (this->GlobalGenerator->TargetsWindowsCE()) + { + linkOptions.AddFlag("SubSystem", "WindowsCE"); + linkOptions.AddFlag("EntryPointSymbol", "mainACRTStartup"); + } + else + { + linkOptions.AddFlag("SubSystem", "Console"); + }; } if(const char* stackVal = -- 1.7.10.4 From brad.king at kitware.com Fri Sep 12 09:04:22 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 12 Sep 2014 09:04:22 -0400 Subject: [cmake-developers] Modern cross-platform buildsystem design requirements In-Reply-To: References: <54105A12.6070805@kitware.com> Message-ID: <5412EF56.2040804@kitware.com> On 09/10/2014 11:49 AM, Stephen Kelly wrote: > target_link_libraries(mylib cmake::android-16) Interesting idea. These could be predefined in the Platform/Android.cmake module. However, I do not think the current ANDROID_API property will be outdated by such a design, so I think we can keep it as-is for now and consider an INTERFACE feature when things have matured somewhat. >> The property activates creation of a .apk. > > The approach I prototyped for BB10 .bar packages was to generate them with > cpack. In the current work, the goal is to let Nsight Tegra handle everything from the generated .vcxproj file. > macro(set_properties_for_platform tgt) > if (CROSS_COMPILING) > if (ANDROID) > set_property(TARGET ${tgt} ...) > elseif (BLACKBERRY) > set_property(TARGET ${tgt} ...) > elseif (WinRT) > set_property(TARGET ${tgt} ...) > endif() > endif() > endmacro() I don't see any reason the properties could not just always be set by the project. The ones not relevant to the current cross-compiling target would simply be ignored. >> However, each of these platforms requires some kind of app manifest > > Do each such files have the same or similar content? Author, url, siging key > etc? That might be a good avenue to explore for a cross-platform > abstraction. Perhaps, but not for a while. Authors targeting mobile devices will need very specific control over the manifest files, packaging, and signing. Only when we see lots of duplication across manifests for different targets should we consider such abstraction. > Are you still thinking of a 'pure'-Lua-based (not via > CMakeLists which loads Lua somehow) system as an end-goal? No, but I wouldn't rule it out forever. > I believe part of the motivation for qbs (the next Qt build tool) is > multiple architecture support, which I believe is preferred by some to > create Android APKs targeting multiple architectures [snip] > whether find_package would need multiple modes of operation etc. The fundamental problem with supporting multiple architectures is that pretty much all of CMake is designed to support one architecture at a time. Modules/*, CMakeCache.txt, etc. are all built around only finding, using, and building one artifact per library (OS X universal binaries work with multiple architectures because they are still only one file). I think even your "toolchain scope" approach would end up being used in practice to wrap the entire CMakeLists.txt file. The only approach I can think of that solves this without being a complete rewrite is to support multiple separate configuration passes, with separate CMakeCache.txt and everything as now, but that all feed in to a single generation step. (Note the separate config passes could be independent and perhaps run in threads.) > When you refer to 'a new language' here, do you mean in the same sense of > how generator expressions were a new language (without a departure from the > current cmake language as a whole), or do you mean something different? I don't mean anything in particular except that we should not constrain ourselves to solving the problem with the current CMake language only. -Brad From brad.king at kitware.com Fri Sep 12 09:36:59 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 12 Sep 2014 09:36:59 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Make the Visual Studio 10+ generator Windows CE In-Reply-To: <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> References: <5412E5BA.1070708@kitware.com> <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> Message-ID: <5412F6FB.3030005@kitware.com> On 09/12/2014 08:47 AM, Pascal Bach wrote: > - If Windows CE is targeted set the Subsystem and EntryPointSymbol accordingly > - For Windows CE 2013 (8.0) set the toolset to C800 by default Great, thanks. > +bool cmGlobalVisualStudio10Generator::InitializeWindowsCE(cmMakefile* mf) > + { Here please add this check: if(this->DefaultPlatformName != "Win32") { cmOStringStream e; e << "CMAKE_SYSTEM_NAME is 'WindowsCE' but CMAKE_GENERATOR " << "specifies a platform too: '" << this->GetName() << "'"; mf->IssueMessage(cmake::FATAL_ERROR, e.str()); return false; } This code should no longer be called multiple times so it is safe to check here now. > + // To preserve the old behaviour just keep the DefaultPlatformToolset > + // for unknown Windows CE versions, in the worst case the user has to set > + // CMAKE_GENERATOR_TOOLSET manually. In that case warn the user. > + std::string platformToolset = this->SelectWindowsCEToolset(); > + if (!platformToolset.empty()) > + { > + this->DefaultPlatformToolset = platformToolset; > + } > + else > + { > + cmOStringStream e; > + e << this->GetName() << " Windows CE version '" << this->SystemVersion > + << "' might require CMAKE_GENERATOR_TOOLSET to be set."; > + mf->IssueMessage(cmake::WARNING, e.str()); > + } I think this will always warn when CMAKE_SYSTEM_VERSION != 8.0 even if the user has set a CMAKE_GENERATOR_TOOLSET. Instead, cmGlobalVisualStudio10Generator::SetGeneratorToolset should implement the warning: * Have InitializeWindowsCE always do this->DefaultPlatformToolset = this->SelectWindowsCEToolset() even when it is empty. * Teach SetGeneratorToolset to check for SystemIsWindowsCE *and* ts.empty() *and* DefaultPlatformToolset.empty(). If this is all true, then generate an error asking the user to specify the toolset, or perhaps just a warning if the toolset is not always required. Thanks, -Brad From andy.bauer at kitware.com Fri Sep 12 11:27:23 2014 From: andy.bauer at kitware.com (Andy Bauer) Date: Fri, 12 Sep 2014 11:27:23 -0400 Subject: [cmake-developers] documentation patch Message-ID: Hi, Attached is a patch for a documentation correction for setting test properties. Can someone check on this and merge it into CMake if it's acceptable? Thanks, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Help-Fixing-set_test_properties-documentation.patch Type: text/x-patch Size: 844 bytes Desc: not available URL: From brad.king at kitware.com Fri Sep 12 11:34:29 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 12 Sep 2014 11:34:29 -0400 Subject: [cmake-developers] documentation patch In-Reply-To: References: Message-ID: <54131285.6080302@kitware.com> On 09/12/2014 11:27 AM, Andy Bauer wrote: > Attached is a patch for a documentation correction Applied, thanks: Help: Fix set_tests_properties documentation typo http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d8054987 -Brad From mantis at public.kitware.com Fri Sep 12 12:23:46 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 12 Sep 2014 12:23:46 -0400 Subject: [cmake-developers] [CMake 0015154]: Ninja complains about missing rule Message-ID: <30b65c403293279aa0ef858a9aa11749@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15154 ====================================================================== Reported By: Clinton Stimpson Assigned To: ====================================================================== Project: CMake Issue ID: 15154 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-12 12:23 EDT Last Modified: 2014-09-12 12:23 EDT ====================================================================== Summary: Ninja complains about missing rule Description: With the attached example project, Ninja will complain with an error saying "ninja: error: 'lib/libmylib.a', needed by 'myapp', missing and no known rule to make it" I'm using ExternalProject_Add() and then using imported library targets. I then set the imported target to depend on the ExternalProject to make sure it is up to date. This works fine with Visual Studio, NMake, Make, Xcode, etc.... Steps to Reproduce: See attached project. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-12 12:23 Clinton StimpsonNew Issue 2014-09-12 12:23 Clinton StimpsonFile Added: test-ninja-external-build.tar.gz ====================================================================== From mantis at public.kitware.com Sun Sep 14 00:37:03 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 14 Sep 2014 00:37:03 -0400 Subject: [cmake-developers] [CMake 0015155]: cmlistfilecache: error can not open file Message-ID: <2fa8e986ed5bd1b85b4fa4eef90b1ee2@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15155 ====================================================================== Reported By: David Zemon Assigned To: ====================================================================== Project: CMake Issue ID: 15155 Category: CMake Reproducibility: always Severity: block Priority: high Status: new ====================================================================== Date Submitted: 2014-09-14 00:37 EDT Last Modified: 2014-09-14 00:37 EDT ====================================================================== Summary: cmlistfilecache: error can not open file Description: Upon generating the Makefiles for my project, CMake prings the following two lines for each new language that I enable: CMake Error: cmListFileCache: error can not open file C:/Users/David/Documents/GitHub/PropWare CMake Error: Could not find cmake module file: No other errors are reported. No extra text comes afterward (not even a single space after the semicolon). The path in the first line is the root of my project - not a file. Two lines are printed at the very bottom saying that I can look at the CMakeOutput.log and CMakeError.log files, but they do not seem to provide any useful information. Steps to Reproduce: The PropWare project should exist on in a user-writable path. A version of GCC ported for the Parallax Propeller is required to build my project. The environment variable "PROPWARE_PATH" must be set to the project root directory. All files from /CMakeModules should be copied into the CMake installation directory. All of the above requirements can be most easily satisfied by downloading the release-2.0-nightly branch of PropWare from github (https://github.com/DavidZemon/PropWare/tree/release-2.0-nightly) and running INSTALL.py from within the `util` directory. This will download PropGCC and CMake 3.0.2 (if a version of CMake >= 3.0 is not in the PATH) and copy over the necessary files into your CMake installation directory as well as setting a couple environment variables. If you choose to run INSTALL.py, it will attempt to build the PropWare libraries and will fail with the above errors. If you choose to configure everything manually, the error will appear as soon as you try to configure the makefiles for the project. I use 'cmake -G "Unix Makefiles" ..' from within a child directory of the root (GNU Make is distributed with the Windows release of PropGCC). I found the same error occurs when I use the default Makefile generator of Visual Studio. Attempting to use MinGW Makefiles throws lots of different errors (can't find the compiler). Additional Information: PropWare is ready to be released to the public as an easy-to-use build-system for the Parallax Propeller, but without windows compatibility, the whole project is nearly useless. Probably 95% of my potential users are on Windows, so until I either find the problem or get a work around, my project isn't worth squat. Sorry if the "severity" and "priority" are set too strong or wrong. I'm not sure what to compare it with - but it is a blocking problem for me and I have not been able to find a way around it. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-14 00:37 David Zemon New Issue ====================================================================== From mantis at public.kitware.com Sun Sep 14 08:33:04 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 14 Sep 2014 08:33:04 -0400 Subject: [cmake-developers] [CMake 0015156]: Sometime, CMake can't find clang/clang++ Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15156 ====================================================================== Reported By: Meng-Yuan Huang Assigned To: ====================================================================== Project: CMake Issue ID: 15156 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-14 08:33 EDT Last Modified: 2014-09-14 08:33 EDT ====================================================================== Summary: Sometime, CMake can't find clang/clang++ Description: I have a CMake C++ project, test. I want to build it by clang/clang++ on CentOS 6.5. I run cmake by this command line: cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ . Unfortunately, sometime, cmake said it can't find clang/clang++. Strangely, if I run the command line again, it becomes to able to find them. Strangely again, if run the command line again, it becomes to not able to find them. ... If cmake can find clang/clang++, then running make will invoke clang/clang++. Otherwise, if cmake can't find clang/clang++, then running make will invoke gcc/g++. I recorded a video to show the problem: http://1drv.ms/1uwXVek Please fix this problem. CMake 3.0.2 also has a similar but different problem as 2.8.12. Steps to Reproduce: 1. Download the attached test project, test.tar.gz and extract it. 2. Run cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ . for several times and inspect the cmake output messages. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-14 08:33 Meng-Yuan HuangNew Issue 2014-09-14 08:33 Meng-Yuan HuangFile Added: test.tar.gz ====================================================================== From mantis at public.kitware.com Sun Sep 14 12:39:11 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 14 Sep 2014 12:39:11 -0400 Subject: [cmake-developers] [CMake 0015157]: FindCUDA.cmake: separate compilation not working as expected Message-ID: <8fdf61d573320138789338d3e12fd843@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15157 ====================================================================== Reported By: bchretien Assigned To: ====================================================================== Project: CMake Issue ID: 15157 Category: Modules Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2014-09-14 12:39 EDT Last Modified: 2014-09-14 12:39 EDT ====================================================================== Summary: FindCUDA.cmake: separate compilation not working as expected Description: I tried using separate compilation for CUDA with CMake, but I had the issue described by someone else on Stack Overflow: https://stackoverflow.com/questions/22540783/nvlink-error-when-linking-cuda-code-against-cuda-static-library-cmake In the CUDA SDK samples, there's a "simpleSeparateCompilation" sample that uses a Makefile to build a device static library and link it to the executable. I tried to adapt it to CMake, but the same CUDA linker error arises. If this is simply because this should be done some other way, then I guess the documentation in FindCUDA.cmake should be completed. Else, this may be an error in the module. Steps to Reproduce: Add the enclosed CMakeLists to $CUDA_HOME/samples/0_Simple/simpleSeparateCompilation. $ mkdir /tmp/test && cd /tmp/test $ cmake $CUDA_HOME/samples/0_Simple/simpleSeparateCompilation $ make ... [100%] Building NVCC intermediate link file CMakeFiles/simpleSeparateCompilation.dir/./simpleSeparateCompilation_intermediate_link.o nvlink error : Undefined reference to '_Z13multiplyByTwof' in '/tmp/test/CMakeFiles/simpleSeparateCompilation.dir//./simpleSeparateCompilation_generated_simpleSeparateCompilation.cu.o' nvlink error : Undefined reference to '_Z11divideByTwof' in '/tmp/test/CMakeFiles/simpleSeparateCompilation.dir//./simpleSeparateCompilation_generated_simpleSeparateCompilation.cu.o' CMakeFiles/simpleSeparateCompilation.dir/build.make:61: recipe for target 'CMakeFiles/simpleSeparateCompilation.dir/./simpleSeparateCompilation_intermediate_link.o' failed Additional Information: I tested this on Arch Linux with CUDA 6.5 and CMake 3.0.2. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-14 12:39 bchretien New Issue 2014-09-14 12:39 bchretien File Added: CMakeLists.txt ====================================================================== From i-love-spam at yandex.ru Sun Sep 14 14:15:55 2014 From: i-love-spam at yandex.ru (i-love-spam) Date: Sun, 14 Sep 2014 22:15:55 +0400 Subject: [cmake-developers] alternative gui for CMAKE (webgui) Message-ID: <5550691410718555@web17o.yandex.ru> Hello Cmake, in our project we develop for most of the platforms (android, ios, macos, WinRT, Win32, blackbery-qnx etc). We are starting to switch more and more projects to Cmake. For most of the stuff that we build we use buildservers to make release, and the buildservers are totally hand written code. Cmake-gui basically interprets all the options from cmake files and dynamically generates gui to be displayed for the user. Is there something already exist that generates html gui instead? Is it easy to add that kind of option so that we could have familiar cmake style web gui in our buildservers? For now, if add some kind of option, somebody has to go and modify php code to present and handle that option on the web and pass it to cmake or some other build system. What I'm looking for is to skip that step and directly generate html from cmake files the way cmake-gui generates gui with all the available options. From daniel at pfeifer-mail.de Sun Sep 14 15:48:18 2014 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Sun, 14 Sep 2014 21:48:18 +0200 Subject: [cmake-developers] alternative gui for CMAKE (webgui) In-Reply-To: <5550691410718555@web17o.yandex.ru> References: <5550691410718555@web17o.yandex.ru> Message-ID: 2014-09-14 20:15 GMT+02:00 i-love-spam : > Hello Cmake, > > in our project we develop for most of the platforms (android, ios, macos, > WinRT, Win32, blackbery-qnx etc). We are starting to switch more and more > projects to Cmake. > For most of the stuff that we build we use buildservers to make release, > and the buildservers are totally hand written code. > Cmake-gui basically interprets all the options from cmake filesand > dynamically generates gui to be displayed for the user. Hi Yandex, cmake-gui and ccmake are "cache editors". They generate a GUI from the CMake cache, which is generated from the cmake files. You find the CMake cache in the file CMakeCache.txt in your build directory. It is rather easy to parse. It should be straight-forward to build a cache manager in PHP. For a start, have a look at the file https://github.com/Kitware/CMake/blob/master/Source/cmCacheManager.cxx Cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascal.bach at siemens.com Mon Sep 15 09:51:50 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Mon, 15 Sep 2014 13:51:50 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Make the Visual Studio 10+ generator Windows CE In-Reply-To: <5412F6FB.3030005@kitware.com> References: <5412E5BA.1070708@kitware.com> <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> <5412F6FB.3030005@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616AD17EA@DEFTHW99EH4MSX.ww902.siemens.net> > Here please add this check: > > if(this->DefaultPlatformName != "Win32") > { > cmOStringStream e; > e << "CMAKE_SYSTEM_NAME is 'WindowsCE' but CMAKE_GENERATOR " > << "specifies a platform too: '" << this->GetName() << "'"; > mf->IssueMessage(cmake::FATAL_ERROR, e.str()); > return false; > } > > This code should no longer be called multiple times so it is safe to > check here now. Done check is added. > > > + // To preserve the old behaviour just keep the DefaultPlatformToolset > > + // for unknown Windows CE versions, in the worst case the user has to > set > > + // CMAKE_GENERATOR_TOOLSET manually. In that case warn the user. > > + std::string platformToolset = this->SelectWindowsCEToolset(); > > + if (!platformToolset.empty()) > > + { > > + this->DefaultPlatformToolset = platformToolset; > > + } > > + else > > + { > > + cmOStringStream e; > > + e << this->GetName() << " Windows CE version '" << this- > >SystemVersion > > + << "' might require CMAKE_GENERATOR_TOOLSET to be set."; > > + mf->IssueMessage(cmake::WARNING, e.str()); > > + } > > I think this will always warn when CMAKE_SYSTEM_VERSION != 8.0 > even if the user has set a CMAKE_GENERATOR_TOOLSET. Instead, > cmGlobalVisualStudio10Generator::SetGeneratorToolset should > implement the warning: I'm not sure if it is always required for older versions. I just assume it is and print an error if not set. I think the user knows what toolset to use when compiling for WindowCE. Here is the updated patch: >From 1599834a97200511feede2c3a69b33bbf66560b6 Mon Sep 17 00:00:00 2001 From: Pascal Bach Date: Mon, 15 Sep 2014 15:46:43 +0200 Subject: [PATCH] WINCE, VS: Make the Visual Studio 10+ generator Windows CE - If Windows CE is targeted set the Subsystem and EntryPointSymbol accordingly - For Windows CE 2013 (8.0) set the toolset to C800 by default --- Source/cmGlobalVisualStudio10Generator.cxx | 44 ++++++++++++++++++++++++++++ Source/cmGlobalVisualStudio10Generator.h | 7 +++++ Source/cmVisualStudio10TargetGenerator.cxx | 20 +++++++++++-- 3 files changed, 69 insertions(+), 2 deletions(-) diff --git a/Source/cmGlobalVisualStudio10Generator.cxx b/Source/cmGlobalVisualStudio10Generator.cxx index e2d4645..5fef79c 100644 --- a/Source/cmGlobalVisualStudio10Generator.cxx +++ b/Source/cmGlobalVisualStudio10Generator.cxx @@ -152,6 +152,15 @@ bool cmGlobalVisualStudio10Generator::SetGeneratorToolset(std::string const& ts, cmMakefile* mf) { +if (this->SystemIsWindowsCE && ts.empty() && this->DefaultPlatformToolset.empty()) + { + cmOStringStream e; + e << this->GetName() << " Windows CE version '" << this->SystemVersion + << "' requires CMAKE_GENERATOR_TOOLSET to be set."; + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); + return false; + } + this->GeneratorToolset = ts; if(const char* toolset = this->GetPlatformToolset()) { @@ -179,6 +188,14 @@ bool cmGlobalVisualStudio10Generator::InitializeSystem(cmMakefile* mf) return false; } } + else if (this->SystemName == "WindowsCE") + { + this->SystemIsWindowsCE = true; + if (!this->InitializeWindowsCE(mf)) + { + return false; + } + } return true; } @@ -201,6 +218,33 @@ bool cmGlobalVisualStudio10Generator::InitializeWindowsStore(cmMakefile* mf) } //---------------------------------------------------------------------------- +bool cmGlobalVisualStudio10Generator::InitializeWindowsCE(cmMakefile* mf) +{ + if (this->DefaultPlatformName != "Win32") + { + cmOStringStream e; + e << "CMAKE_SYSTEM_NAME is 'WindowsCE' but CMAKE_GENERATOR " + << "specifies a platform too: '" << this->GetName() << "'"; + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); + return false; + } + + this->DefaultPlatformToolset = this->SelectWindowsCEToolset(); + + return true; +} + +//---------------------------------------------------------------------------- +std::string cmGlobalVisualStudio10Generator::SelectWindowsCEToolset() const +{ + if (this->SystemVersion == "8.0") + { + return "CE800"; + } + return ""; +} + +//---------------------------------------------------------------------------- void cmGlobalVisualStudio10Generator::WriteSLNHeader(std::ostream& fout) { fout << "Microsoft Visual Studio Solution File, Format Version 11.00\n"; diff --git a/Source/cmGlobalVisualStudio10Generator.h b/Source/cmGlobalVisualStudio10Generator.h index f1ff9a4..a80222f 100644 --- a/Source/cmGlobalVisualStudio10Generator.h +++ b/Source/cmGlobalVisualStudio10Generator.h @@ -76,6 +76,10 @@ public: bool TargetsWindowsStore() const { return this->SystemIsWindowsStore; } + /** Return true if building for WindowsCE */ + bool TargetsWindowsCE() const + { return this->SystemIsWindowsCE; } + /** * Where does this version of Visual Studio look for macros for the * current user? Returns the empty string if this version of Visual @@ -107,8 +111,10 @@ protected: virtual bool InitializeSystem(cmMakefile* mf); virtual bool InitializeWindowsPhone(cmMakefile* mf); virtual bool InitializeWindowsStore(cmMakefile* mf); + virtual bool InitializeWindowsCE(cmMakefile* mf); virtual std::string SelectWindowsPhoneToolset() const { return ""; } virtual std::string SelectWindowsStoreToolset() const { return ""; } + virtual std::string SelectWindowsCEToolset() const; virtual const char* GetIDEVersion() { return "10.0"; } @@ -120,6 +126,7 @@ protected: std::string SystemVersion; bool SystemIsWindowsPhone; bool SystemIsWindowsStore; + bool SystemIsWindowsCE; bool ExpressEdition; bool UseFolderProperty(); diff --git a/Source/cmVisualStudio10TargetGenerator.cxx b/Source/cmVisualStudio10TargetGenerator.cxx index c525b7c..681b8c7 100644 --- a/Source/cmVisualStudio10TargetGenerator.cxx +++ b/Source/cmVisualStudio10TargetGenerator.cxx @@ -2115,11 +2115,27 @@ cmVisualStudio10TargetGenerator::ComputeLinkOptions(std::string const& config) if ( this->Target->GetPropertyAsBool("WIN32_EXECUTABLE") ) { - linkOptions.AddFlag("SubSystem", "Windows"); + if (this->GlobalGenerator->TargetsWindowsCE()) + { + linkOptions.AddFlag("SubSystem", "WindowsCE"); + linkOptions.AddFlag("EntryPointSymbol", "WinMainCRTStartup"); + } + else + { + linkOptions.AddFlag("SubSystem", "Windows"); + } } else { - linkOptions.AddFlag("SubSystem", "Console"); + if (this->GlobalGenerator->TargetsWindowsCE()) + { + linkOptions.AddFlag("SubSystem", "WindowsCE"); + linkOptions.AddFlag("EntryPointSymbol", "mainACRTStartup"); + } + else + { + linkOptions.AddFlag("SubSystem", "Console"); + }; } if(const char* stackVal = -- 1.7.10.4 From brad.king at kitware.com Mon Sep 15 11:02:42 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Sep 2014 11:02:42 -0400 Subject: [cmake-developers] [PATCH] WINCE, VS: Make the Visual Studio 10+ generator Windows CE In-Reply-To: <355BE46A91031048906B695426A8D8E616AD17EA@DEFTHW99EH4MSX.ww902.siemens.net> References: <5412E5BA.1070708@kitware.com> <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> <5412F6FB.3030005@kitware.com> <355BE46A91031048906B695426A8D8E616AD17EA@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <5416FF92.9050206@kitware.com> On 09/15/2014 09:51 AM, Bach, Pascal wrote: > Here is the updated patch: Thanks! I've applied it with minor modifications to order the methods lexicographically and wrap a long line. The only functional change is that I added a missing initialization of SystemIsWindowsCE in the constructor. See: VS: Teach VS >= 10 generator about Windows CE http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3298f77 -Brad From pascal.bach at siemens.com Mon Sep 15 11:46:09 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Mon, 15 Sep 2014 15:46:09 +0000 Subject: [cmake-developers] [PATCH] WINCE, VS: Make the Visual Studio 10+ generator Windows CE In-Reply-To: <5416FF92.9050206@kitware.com> References: <5412E5BA.1070708@kitware.com> <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> <5412F6FB.3030005@kitware.com> <355BE46A91031048906B695426A8D8E616AD17EA@DEFTHW99EH4MSX.ww902.siemens.net> <5416FF92.9050206@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616AD1854@DEFTHW99EH4MSX.ww902.siemens.net> > On 09/15/2014 09:51 AM, Bach, Pascal wrote: > > Here is the updated patch: > > Thanks! I've applied it with minor modifications to order the > methods lexicographically and wrap a long line. The only > functional change is that I added a missing initialization of > SystemIsWindowsCE in the constructor. See: Thanks looks like I missed that. > > VS: Teach VS >= 10 generator about Windows CE > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3298f77 > So I think we can close: http://public.kitware.com/Bug/view.php?id=15115 But I don't see an option to do that. Pascal From brad.king at kitware.com Mon Sep 15 11:50:12 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Sep 2014 11:50:12 -0400 Subject: [cmake-developers] VS 10 Windows CE support (was: WINCE, VS: Make the Visual Studio 10+ generator Windows CE) In-Reply-To: <355BE46A91031048906B695426A8D8E616AD1854@DEFTHW99EH4MSX.ww902.siemens.net> References: <5412E5BA.1070708@kitware.com> <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> <5412F6FB.3030005@kitware.com> <355BE46A91031048906B695426A8D8E616AD17EA@DEFTHW99EH4MSX.ww902.siemens.net> <5416FF92.9050206@kitware.com> <355BE46A91031048906B695426A8D8E616AD1854@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <54170AB4.8040409@kitware.com> On 09/15/2014 11:46 AM, Bach, Pascal wrote: > So I think we can close: http://public.kitware.com/Bug/view.php?id=15115 Done. Thanks for your work on this! In order to keep things working, we will need nightly testing. Would you be able to run it? Take a look at Tests/CMakeLists.txt for mention of VSWinStorePhone. Something like that should be created for WindowsCE too. Then one will need to set up nightly testing on a machine with the proper toolchain installed for this. Thanks, -Brad From pascal.bach at siemens.com Mon Sep 15 12:23:39 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Mon, 15 Sep 2014 16:23:39 +0000 Subject: [cmake-developers] VS 10 Windows CE support (was: WINCE, VS: Make the Visual Studio 10+ generator Windows CE) In-Reply-To: <54170AB4.8040409@kitware.com> References: <5412E5BA.1070708@kitware.com> <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> <5412F6FB.3030005@kitware.com> <355BE46A91031048906B695426A8D8E616AD17EA@DEFTHW99EH4MSX.ww902.siemens.net> <5416FF92.9050206@kitware.com> <355BE46A91031048906B695426A8D8E616AD1854@DEFTHW99EH4MSX.ww902.siemens.net> <54170AB4.8040409@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616AD1888@DEFTHW99EH4MSX.ww902.siemens.net> > Done. Thanks for your work on this! > > In order to keep things working, we will need nightly testing. > Would you be able to run it? We already have a build machine running. http://open.cdash.org/viewSite.php?siteid=10948&project=1¤ttime=1410742800 Currently we are just building CMake Nightly using VS12. But it's the only machine with VS12 that I see until now. My goal is to extend this to also run some more tests, especially for WindowsCE. > > Take a look at Tests/CMakeLists.txt for mention of VSWinStorePhone. > Something like that should be created for WindowsCE too. Then one > will need to set up nightly testing on a machine with the proper > toolchain installed for this. > Ok I will have a look at that. Pascal From brad.king at kitware.com Mon Sep 15 14:22:40 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Sep 2014 14:22:40 -0400 Subject: [cmake-developers] VS 10 Windows CE support In-Reply-To: <355BE46A91031048906B695426A8D8E616AD1888@DEFTHW99EH4MSX.ww902.siemens.net> References: <5412E5BA.1070708@kitware.com> <1410526026-15146-1-git-send-email-pascal.bach@siemens.com> <5412F6FB.3030005@kitware.com> <355BE46A91031048906B695426A8D8E616AD17EA@DEFTHW99EH4MSX.ww902.siemens.net> <5416FF92.9050206@kitware.com> <355BE46A91031048906B695426A8D8E616AD1854@DEFTHW99EH4MSX.ww902.siemens.net> <54170AB4.8040409@kitware.com> <355BE46A91031048906B695426A8D8E616AD1888@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <54172E70.4070307@kitware.com> On 09/15/2014 12:23 PM, Bach, Pascal wrote: >> In order to keep things working, we will need nightly testing. >> Would you be able to run it? > > We already have a build machine running. > http://open.cdash.org/viewSite.php?siteid=10948&project=1¤ttime=1410742800 > > Currently we are just building CMake Nightly using VS12. > But it's the only machine with VS12 that I see until now. Great. I moved those submissions to the "Nightly Expected" section. Thanks! -Brad From steveire at gmail.com Mon Sep 15 19:04:00 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 16 Sep 2014 01:04 +0200 Subject: [cmake-developers] Modern cross-platform buildsystem design requirements References: <54105A12.6070805@kitware.com> <5412EF56.2040804@kitware.com> Message-ID: Brad King wrote: > On 09/10/2014 11:49 AM, Stephen Kelly wrote: >> target_link_libraries(mylib cmake::android-16) > > Interesting idea. These could be predefined in the Platform/Android.cmake > module. However, I do not think the current ANDROID_API property will be > outdated by such a design Indeed. However, validation of allowed values might be worthwhile even now. >> macro(set_properties_for_platform tgt) >> if (CROSS_COMPILING) >> if (ANDROID) >> set_property(TARGET ${tgt} ...) >> elseif (BLACKBERRY) >> set_property(TARGET ${tgt} ...) >> elseif (WinRT) >> set_property(TARGET ${tgt} ...) >> endif() >> endif() >> endmacro() > > I don't see any reason the properties could not just always be set by > the project. The ones not relevant to the current cross-compiling > target would simply be ignored. Right. That's probably true in most cases. Relatedly, I can imagine a macro like the above experiencing scope-creep though, which is a reason to not want to need it :). > I think even your "toolchain scope" approach would end > up being used in practice to wrap the entire CMakeLists.txt file. > > The only approach I can think of that solves this without being a > complete rewrite is to support multiple separate configuration > passes, with separate CMakeCache.txt and everything as now, but that > all feed in to a single generation step. (Note the separate config > passes could be independent and perhaps run in threads.) Interesting idea. I'm not certain the resulting CMakeLists files would look much different to the "toolchain scope" approach though. You would still need conditionals with your approach: if(CONFIG_PASS_HOST) # CMake could set CONFIG_PASS_HOST in the normal case to avoid # the need to check if we are cross-compiling add_executable(host_tool main.cpp) endif() add_library(mylib foo.cpp) if(CONFIG_PASS_ARMv7) # Add extra source for the config pass named ARMv7 target_sources(mylib PRIVATE foo_embedded.cpp) endif() But what is cleaner with your approach is that a find_package could be outside of any conditional if needed in all configuration passes. >> When you refer to 'a new language' here, do you mean in the same sense of >> how generator expressions were a new language (without a departure from >> the current cmake language as a whole), or do you mean something >> different? > > I don't mean anything in particular except that we should not constrain > ourselves to solving the problem with the current CMake language only. Ok. When you wrote > However, perhaps it would be better > in the long run to consider something more declarative and with a > new language. I thought you might have had something more-concrete in mind. Thanks, Steve. From mantis at public.kitware.com Tue Sep 16 09:52:28 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 16 Sep 2014 09:52:28 -0400 Subject: [cmake-developers] [CMake 0015158]: MemCheck: Valgrind with multiple supressions files Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15158 ====================================================================== Reported By: trsystran Assigned To: ====================================================================== Project: CMake Issue ID: 15158 Category: CTest Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-16 09:52 EDT Last Modified: 2014-09-16 09:52 EDT ====================================================================== Summary: MemCheck: Valgrind with multiple supressions files Description: Currently CMake only accepts one valgrind suppressions file using the "CTEST_MEMORYCHECK_SUPPRESSIONS_FILE" variable. >From Valgrind man "You may use up to 100 extra suppression files.". It would be useful to be able to set a list of suppression files instead of just one. Currently I have to generate a new suppressions files by concatenating multiple files into one, and feed this to ctest. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-16 09:52 trsystran New Issue ====================================================================== From brad.king at kitware.com Tue Sep 16 10:05:35 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Sep 2014 10:05:35 -0400 Subject: [cmake-developers] vs-nsight-tegra-generator topic Message-ID: <541843AF.5060906@kitware.com> Hi Folks, This topic introduces support for generating VS project files for the NVIDIA Nsight Tegra Visual Studio Edition, which then builds for Android. I've merged it to 'next' for testing: Merge topic 'vs-nsight-tegra-generator' into next http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=24035687 Please take a look if you are interested in Android development. Although this topic is for Nsight Tegra builds, it does add some infrastructure that could be re-used later for more Android support in other generators. Thanks, -Brad From brad.king at kitware.com Tue Sep 16 10:08:44 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Sep 2014 10:08:44 -0400 Subject: [cmake-developers] vs-nsight-tegra-generator topic In-Reply-To: <541843AF.5060906@kitware.com> References: <541843AF.5060906@kitware.com> Message-ID: <5418446C.60508@kitware.com> On 09/16/2014 10:05 AM, Brad King wrote: > Please take a look if you are interested in Android development. [snip] On 09/15/2014 07:04 PM, Stephen Kelly wrote: > Brad King wrote: >> On 09/10/2014 11:49 AM, Stephen Kelly wrote: >>> target_link_libraries(mylib cmake::android-16) >> >> Interesting idea. These could be predefined in the Platform/Android.cmake >> module. However, I do not think the current ANDROID_API property will be >> outdated by such a design > > Indeed. However, validation of allowed values might be worthwhile even now. Steve, what validation should be done for ANDROID_API? Just that it is a decimal integer value? I think we will also need an ANDROID_ARCH and ANDROID_STL property. How should these be validated? Thanks, -Brad From steveire at gmail.com Tue Sep 16 10:44:09 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 16 Sep 2014 16:44:09 +0200 Subject: [cmake-developers] vs-nsight-tegra-generator topic References: <541843AF.5060906@kitware.com> <5418446C.60508@kitware.com> Message-ID: Brad King wrote: > On 09/16/2014 10:05 AM, Brad King wrote: >> Please take a look if you are interested in Android development. > [snip] > On 09/15/2014 07:04 PM, Stephen Kelly wrote: >> Brad King wrote: >>> On 09/10/2014 11:49 AM, Stephen Kelly wrote: >>>> target_link_libraries(mylib cmake::android-16) >>> >>> Interesting idea. These could be predefined in the >>> Platform/Android.cmake >>> module. However, I do not think the current ANDROID_API property will >>> be outdated by such a design >> >> Indeed. However, validation of allowed values might be worthwhile even >> now. > > Steve, what validation should be done for ANDROID_API? Just that it > is a decimal integer value? Apparently, yes: http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels Are there any restrictions on how old an android API the tegra system works with? I think the SDK has changes significantly at least once during the android lifetime. Setting an upper limit on the allowed value might also make sense, may not be necessary? > I think we will also need an ANDROID_ARCH and ANDROID_STL property. > How should these be validated? I don't know much about the _ARCH variable. That effectively determines the particular sysroot in the NDK to use, right? If you require that the path to the NDK be known, then you can validate that the directory exists to validate it. The _STL one I would like to see be generic at least. On any machine I don't want to compile my library with libc++ and link it with my executable compiled with libstdc++. I'd also want an abstraction for specifying the - stdlib= option for clang and the 'expanded' -I and -L/-l for GCC. I think this came up several times during the compile-features http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5813 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9729 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7671 but it was an orthogonal feature. I guess an interface of CMAKE_{,CXX_STDLIB} variable/property could pass standard values (libc++ and libstdc++) to the -stdlib option of clang and the user could define variables like CMAKE_CXX_STDLIB__OPTIONS_ such as CMAKE_CXX_STDLIB_COMPILE_OPTIONS_stlport CMAKE_CXX_STDLIB_LINK_OPTIONS_stlport in a toolchain file to make it possible to use another stl, or for use with GNU. However, I suspect with your Tegra system one only has to specify the stl and you're going to want to solve only that problem with a ANDROID_STL property, right :)? Thanks, Steve. From mantis at public.kitware.com Tue Sep 16 10:47:19 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 16 Sep 2014 10:47:19 -0400 Subject: [cmake-developers] [CMake 0015159]: MemCheck & CDash: timeout reported as "failed" instead of "timeout" Message-ID: <0ebc2163582c53adbb07fa08bdb340b2@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15159 ====================================================================== Reported By: trsystran Assigned To: ====================================================================== Project: CMake Issue ID: 15159 Category: CTest Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-16 10:47 EDT Last Modified: 2014-09-16 10:47 EDT ====================================================================== Summary: MemCheck & CDash: timeout reported as "failed" instead of "timeout" Description: When running a MemCheck in CTest, some tests fail because of timeout limits. In such case the information is available in the ctest stdout/err: 240/1445 MemCheck http://www.cmake.org/Bug/view.php?id=146: some_test ....................................***Timeout 65.92 sec But it is not reported in the DynamicAnalysis.xml sent to CDash: some_test/Name> xxx/Path> some_test /usr/bin/valgrind xxx blah This information would be useful in CDash, like it's already done for normal tests. In CDash we only get "failed" status and we don't know why it has failed. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-16 10:47 trsystran New Issue ====================================================================== From gereon.kremer at cs.rwth-aachen.de Tue Sep 16 10:52:41 2014 From: gereon.kremer at cs.rwth-aachen.de (Gereon Kremer) Date: Tue, 16 Sep 2014 16:52:41 +0200 Subject: [cmake-developers] Exporting a library shared and static Message-ID: <54184EB9.4060701@cs.rwth-aachen.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I have a project that consists of a library and an application that are developed as two separated projects (different repos, separate cmake setups, etc.). Let's call them "lib" and "app". The app exports itself to ~/.cmake/ and creates a appTargets.cmake, the app simply does find_package(lib). For several reasons, we must be able to build the app dynamically and statically. Our current approach is based on a flag "STATICLIB_SWITCH" that exists in the lib and in the app. Based on it's value, we build the library as .a or .so and link the app statically or dynamically. However, there are a few drawbacks: The value of the switch has to be consistent for the lib and the app and we didn't quite manage to correctly search for all libs: The linker command line is cluttered with lots of -rdynamic etc, which also occasionally breaks down and is very hard to debug when it does. So I spent some time on this and it seems that this is meant to be done differently. My new setup looks like this: The lib has two targets, for a shared object and for a static object, that are always built and exported. The app includes whatever it needs. This would remove the switch from the lib, which would be very nice. However, it seems that the app always includes the "shared target", no matter what I do. Also, I have not been able to provide the target with the list of libraries necessary: I simply collect all libraries in a variable that are found by other find_package calls, but find_package will only find either the shared or the static versions... So basically my question is: How is this supposed to be done? (I somehow get the feeling, that both attempts are wrong :-) ) How can I use a library in another application and switch (fairly) easily between static and dynamic linking? Thanks for any hints on this! Gereon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUGE65AAoJEIQ2nMX673HfLL0H/RcCrNRKdLVQaaIfJnICKCiw 5RaE6t8PXxCjD+XPBgQOmdDVOKXAy/f/t7gV1T6yRDvvbgbUyQnTpRoWUL0Qjlos J+qob54Lcm90DTglNkpnImbfdBRv3XPDS34AGA20kgkmSDVsTdhg1fjDf5Cb10f7 UlGySIQqiIWSuygiq5uawswxqQuh6VuL98/vY+vxCkjNbLnWzuvCAT5x692qaFH3 M7JI4P/SWii637z/7sMh9e+mHue6MBynrcff2PUhDNCyIiG9MiQbZfzsvcQoKYSO jDZLTvSvmy8FUPXPH+15Z8MyfjqjksErLX4UbOBFeEQ5FJwtA+G9TRYHzlDS9vc= =AfDK -----END PGP SIGNATURE----- From mantis at public.kitware.com Tue Sep 16 12:03:05 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 16 Sep 2014 12:03:05 -0400 Subject: [cmake-developers] [CMake 0015160]: Different timeout for test and memcheck Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15160 ====================================================================== Reported By: trsystran Assigned To: ====================================================================== Project: CMake Issue ID: 15160 Category: CTest Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-16 12:03 EDT Last Modified: 2014-09-16 12:03 EDT ====================================================================== Summary: Different timeout for test and memcheck Description: Currently memcheck uses the same timeout (global or test-local) as for normal ctest_test() run. This is an issue since valgrind has a slowdown factor between 5 to 100 (according to them): the normal timeouts are not relevant for memcheck runs. Possible solutions with existing code: 1/ always calibrate the test timeout for valgrind. Drawback: this value is too large for normal test runs. 2/ never use test-local timeout and only rely on global timeout: then change the CTEST_TEST_TIMEOUT before calling ctest_memcheck(). Drawback: test-local timeout are really useful so stopping using them is an issue. Possible solutions with patches: Create a new test property MEMCHECK_TIMEOUT, a new global default memcheck timeout, that only apply for memcheck runs. Default value: either their non memcheck counterpart; or use a global slowdown factor and apply it from non memcheck timeout values. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-16 12:03 trsystran New Issue ====================================================================== From ono at java.pl Tue Sep 16 12:32:20 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 18:32:20 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <1409917844-28297-3-git-send-email-ono@java.pl> References: <1409917844-28297-3-git-send-email-ono@java.pl> Message-ID: <1410885143-87513-3-git-send-email-ono@java.pl> This is done by gathering LC_RPATH commands for main bundle executable and using it for @rpath lookup in dependent frameworks. To achieve this all utility functions now take path to executable rather than path to its directory. This enabled apps using @rpath to be bundled correctly, which will be necessary for upcoming Qt 5.4 that will use @rpath for all frameworks. --- Modules/BundleUtilities.cmake | 171 +++++++++++++++++++++++++---------------- Modules/GetPrerequisites.cmake | 51 ++++++------ 2 files changed, 131 insertions(+), 91 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 7e2b173..817ac78 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -19,6 +19,7 @@ # get_bundle_and_executable # get_bundle_all_executables # get_item_key +# get_item_rpaths # clear_bundle_keys # set_bundle_key_values # get_bundle_keys @@ -75,7 +76,7 @@ # # :: # -# GET_DOTAPP_DIR( ) +# GET_DOTAPP_DIR( ) # # Returns the nearest parent dir whose name ends with ".app" given the # full path to an executable. If there is no such parent dir, then @@ -123,7 +124,7 @@ # # :: # -# SET_BUNDLE_KEY_VALUES( +# SET_BUNDLE_KEY_VALUES( # ) # # Add a key to the list (if necessary) for the given item. If added, @@ -163,7 +164,7 @@ # # :: # -# FIXUP_BUNDLE_ITEM( ) +# FIXUP_BUNDLE_ITEM( ) # # Get the direct/non-system prerequisites of the resolved embedded item. # For each prerequisite, change the way it is referenced to the value of @@ -189,11 +190,11 @@ # # :: # -# VERIFY_BUNDLE_PREREQUISITES( ) +# VERIFY_BUNDLE_PREREQUISITES( []) # # Verifies that the sum of all prerequisites of all files inside the -# bundle are contained within the bundle or are "system" libraries, -# presumed to exist everywhere. +# bundle with given optional main executable location are contained within the +# bundle or are "system" libraries, presumed to exist everywhere. # # :: # @@ -285,8 +286,8 @@ function(get_bundle_main_executable bundle result_var) endfunction() -function(get_dotapp_dir exe dotapp_dir_var) - set(s "${exe}") +function(get_dotapp_dir executable dotapp_dir_var) + set(s "${executable}") if(s MATCHES "/.*\\.app/") # If there is a ".app" parent directory, @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) endfunction() +function(get_item_rpaths item rpaths_var) + if(APPLE) + find_program(otool_cmd "otool") + mark_as_advanced(otool_cmd) + endif() + + if(otool_cmd) + execute_process( + COMMAND "${otool_cmd}" -l "${item}" + OUTPUT_VARIABLE load_cmds_ov + ) + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") + string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") + string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") + if(load_cmds_ov) + gp_append_unique(${rpaths_var} "${load_cmds_ov}") + endif() + endif() + + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) +endfunction() + + function(get_item_key item key_var) get_filename_component(item_name "${item}" NAME) if(WIN32) @@ -425,12 +449,13 @@ function(clear_bundle_keys keys_var) set(${key}_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_COPYFLAG PARENT_SCOPE) + set(${key}_RPATHS PARENT_SCOPE) endforeach() set(${keys_var} PARENT_SCOPE) endfunction() -function(set_bundle_key_values keys_var context item exepath dirs copyflag) +function(set_bundle_key_values keys_var context item executable dirs copyflag) get_filename_component(item_name "${item}" NAME) get_item_key("${item}" key) @@ -440,10 +465,17 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) list(LENGTH ${keys_var} length_after) if(NOT length_before EQUAL length_after) - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item) + # Always use the exepath of the main bundle executable for @executable_path + # replacements: + # + get_filename_component(exepath "${executable}" PATH) + + gp_resolve_item("${context}" "${item}" "${executable}" "${dirs}" resolved_item) gp_item_default_embedded_path("${item}" default_embedded_path) + get_item_rpaths("${resolved_item}" rpaths) + if(item MATCHES "[^/]+\\.framework/") # For frameworks, construct the name under the embedded path from the # opening "${item_name}.framework/" to the closing "/${item_name}": @@ -479,6 +511,7 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) set(${key}_EMBEDDED_ITEM "${embedded_item}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" PARENT_SCOPE) set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) + set(${key}_RPATHS "${rpaths}" PARENT_SCOPE) else() #message("warning: item key '${key}' already in the list, subsequent references assumed identical to first") endif() @@ -490,14 +523,9 @@ function(get_bundle_keys app libs dirs keys_var) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - # Always use the exepath of the main bundle executable for @executable_path - # replacements: - # - get_filename_component(exepath "${executable}" PATH) - # But do fixups on all executables in the bundle: # - get_bundle_all_executables("${bundle}" exes) + get_bundle_all_executables("${bundle}" file_list) # For each extra lib, accumulate a key as well and then also accumulate # any of its prerequisites. (Extra libs are typically dynamically loaded @@ -505,12 +533,12 @@ function(get_bundle_keys app libs dirs keys_var) # but that do not show up in otool -L output...) # foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -518,17 +546,17 @@ function(get_bundle_keys app libs dirs keys_var) # The list of keys should be complete when all prerequisites of all # binaries in the bundle have been analyzed. # - foreach(exe ${exes}) + foreach(f ${file_list}) # Add the exe itself to the keys: # - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${f}" "${f}" "${executable}" "${dirs}" 0) # Add each prerequisite to the keys: # set(prereqs "") - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${f}" prereqs 1 1 "${executable}" "${dirs}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${f}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -542,6 +570,7 @@ function(get_bundle_keys app libs dirs keys_var) set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) endforeach() endif() endfunction() @@ -612,7 +641,7 @@ function(copy_resolved_framework_into_bundle resolved_item resolved_embedded_ite endfunction() -function(fixup_bundle_item resolved_embedded_item exepath dirs) +function(fixup_bundle_item resolved_embedded_item executable dirs) # This item's key is "ikey": # get_item_key("${resolved_embedded_item}" ikey) @@ -622,7 +651,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) # tree, or in other varied locations around the file system, with our call to # install_name_tool. Make sure that doesn't happen here: # - get_dotapp_dir("${exepath}" exe_dotapp_dir) + get_dotapp_dir("${executable}" exe_dotapp_dir) string(LENGTH "${exe_dotapp_dir}/" exe_dotapp_dir_length) string(LENGTH "${resolved_embedded_item}" resolved_embedded_item_length) set(path_too_short 0) @@ -648,7 +677,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) endif() set(prereqs "") - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}") + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${executable}" "${dirs}") set(changes "") @@ -668,12 +697,20 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) execute_process(COMMAND chmod u+w "${resolved_embedded_item}") endif() + foreach(rpath ${${ikey}_RPATHS}) + set(changes ${changes} -delete_rpath "${rpath}") + endforeach() + + if(${ikey}_EMBEDDED_ITEM) + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") + endif() + # Change this item's id and all of its references in one call # to install_name_tool: # - execute_process(COMMAND install_name_tool - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" - ) + if(changes) + execute_process(COMMAND install_name_tool ${changes} "${resolved_embedded_item}") + endif() endfunction() @@ -685,8 +722,6 @@ function(fixup_bundle app libs dirs) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - get_filename_component(exepath "${executable}" PATH) - message(STATUS "fixup_bundle: preparing...") get_bundle_keys("${app}" "${libs}" "${dirs}" keys) @@ -732,7 +767,7 @@ function(fixup_bundle app libs dirs) math(EXPR i ${i}+1) if(APPLE) message(STATUS "${i}/${n}: fixing up '${${key}_RESOLVED_EMBEDDED_ITEM}'") - fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${exepath}" "${dirs}") + fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${executable}" "${dirs}") else() message(STATUS "${i}/${n}: fix-up not required on this platform '${${key}_RESOLVED_EMBEDDED_ITEM}'") endif() @@ -762,50 +797,50 @@ function(verify_bundle_prerequisites bundle result_var info_var) set(info "") set(count 0) - get_bundle_main_executable("${bundle}" main_bundle_exe) + if(ARGC GREATER 0) + set(executable "${ARGV0}") + else() + get_bundle_main_executable("${bundle}" executable) + endif() - file(GLOB_RECURSE file_list "${bundle}/*") + get_bundle_all_executables("${bundle}" file_list) foreach(f ${file_list}) - is_file_executable("${f}" is_executable) - if(is_executable) - get_filename_component(exepath "${f}" PATH) - math(EXPR count "${count} + 1") + math(EXPR count "${count} + 1") - message(STATUS "executable file ${count}: ${f}") + message(STATUS "executable file ${count}: ${f}") - set(prereqs "") - get_prerequisites("${f}" prereqs 1 1 "${exepath}" "") + set(prereqs "") + get_prerequisites("${f}" prereqs 1 1 "${executable}" "") - # On the Mac, - # "embedded" and "system" prerequisites are fine... anything else means - # the bundle's prerequisites are not verified (i.e., the bundle is not - # really "standalone") - # - # On Windows (and others? Linux/Unix/...?) - # "local" and "system" prereqs are fine... - # - set(external_prereqs "") + # On the Mac, + # "embedded" and "system" prerequisites are fine... anything else means + # the bundle's prerequisites are not verified (i.e., the bundle is not + # really "standalone") + # + # On Windows (and others? Linux/Unix/...?) + # "local" and "system" prereqs are fine... + # + set(external_prereqs "") - foreach(p ${prereqs}) - set(p_type "") - gp_file_type("${f}" "${p}" p_type) + foreach(p ${prereqs}) + set(p_type "") + gp_file_type("${f}" "${p}" p_type "${executable}") - if(APPLE) - if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL "system") - set(external_prereqs ${external_prereqs} "${p}") - endif() - else() - if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL "system") - set(external_prereqs ${external_prereqs} "${p}") - endif() + if(APPLE) + if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL "system") + set(external_prereqs ${external_prereqs} "${p}") + endif() + else() + if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL "system") + set(external_prereqs ${external_prereqs} "${p}") endif() - endforeach() - - if(external_prereqs) - # Found non-system/somehow-unacceptable prerequisites: - set(result 0) - set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() + endforeach() + + if(external_prereqs) + # Found non-system/somehow-unacceptable prerequisites: + set(result 0) + set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() endforeach() @@ -845,7 +880,7 @@ function(verify_app app) # Verify that the bundle does not have any "external" prerequisites: # - verify_bundle_prerequisites("${bundle}" verified info) + verify_bundle_prerequisites("${bundle}" verified info "${executable}") message(STATUS "verified='${verified}'") message(STATUS "info='${info}'") message(STATUS "") diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 49443e3..439cc10 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -41,7 +41,7 @@ # :: # # GET_PREREQUISITES( -# ) +# ) # # Get the list of shared library files required by . The list # in the variable named should be empty on first @@ -53,7 +53,7 @@ # must be 0 or 1 indicating whether to include or # exclude "system" prerequisites. If is set to 1 all # prerequisites will be found recursively, if set to 0 only direct -# prerequisites are listed. is the path to the top level +# prerequisites are listed. is the path to the top level # executable used for @executable_path replacment on the Mac. is # a list of paths where libraries might be found: these paths are # searched first when a target without any path info is given. Then @@ -113,7 +113,7 @@ # # :: # -# GP_RESOLVE_ITEM( ) +# GP_RESOLVE_ITEM( ) # # Resolve an item into an existing full path file. # @@ -122,13 +122,13 @@ # # :: # -# GP_RESOLVED_FILE_TYPE( ) +# GP_RESOLVED_FILE_TYPE( ) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named # . # -# Use and if necessary to resolve non-absolute +# Use and if necessary to resolve non-absolute # values -- but only for non-embedded items. # # Possible types are: @@ -145,11 +145,12 @@ # # :: # -# GP_FILE_TYPE( ) +# GP_FILE_TYPE( []) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named -# . +# . Optional executable is used to resolve executable relative +# library locations. # # Possible types are: # @@ -318,10 +319,12 @@ function(gp_item_default_embedded_path item default_embedded_path_var) endfunction() -function(gp_resolve_item context item exepath dirs resolved_item_var) +function(gp_resolve_item context item executable dirs resolved_item_var) set(resolved 0) set(resolved_item "${item}") + get_filename_component(exepath "${executable}" PATH) + # Is it already resolved? # if(IS_ABSOLUTE "${resolved_item}" AND EXISTS "${resolved_item}") @@ -331,7 +334,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) if(NOT resolved) if(item MATCHES "^@executable_path") # - # @executable_path references are assumed relative to exepath + # @executable_path references are assumed relative to executable # string(REPLACE "@executable_path" "${exepath}" ri "${item}") get_filename_component(ri "${ri}" ABSOLUTE) @@ -374,10 +377,11 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) # string(REPLACE "@rpath/" "" norpath_item "${item}") + get_item_key("${executable}" key) set(ri "ri-NOTFOUND") - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) + find_file(ri "${norpath_item}" ${dirs} ${${key}_RPATHS} NO_DEFAULT_PATH) if(ri) - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") + #message(STATUS "info: 'find_file' in exepath/rpaths/dirs (${ri})") set(resolved 1) set(resolved_item "${ri}") set(ri "ri-NOTFOUND") @@ -436,7 +440,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) # by whatever logic they choose: # if(COMMAND gp_resolve_item_override) - gp_resolve_item_override("${context}" "${item}" "${exepath}" "${dirs}" resolved_item resolved) + gp_resolve_item_override("${context}" "${item}" "${executable}" "${dirs}" resolved_item resolved) endif() if(NOT resolved) @@ -459,7 +463,7 @@ warning: cannot resolve item '${item}' # # context='${context}' # item='${item}' -# exepath='${exepath}' +# executable='${executable}' # dirs='${dirs}' # resolved_item_var='${resolved_item_var}' #****************************************************************************** @@ -470,7 +474,7 @@ warning: cannot resolve item '${item}' endfunction() -function(gp_resolved_file_type original_file file exepath dirs type_var) +function(gp_resolved_file_type original_file file executable dirs type_var) #message(STATUS "**") if(NOT IS_ABSOLUTE "${original_file}") @@ -489,7 +493,7 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) if(NOT is_embedded) if(NOT IS_ABSOLUTE "${file}") - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file) + gp_resolve_item("${original_file}" "${file}" "${executable}" "${dirs}" resolved_file) endif() string(TOLOWER "${original_file}" original_lower) @@ -596,20 +600,20 @@ endfunction() function(gp_file_type original_file file type_var) + set(executable "${ARGV0}") + if(NOT IS_ABSOLUTE "${original_file}") message(STATUS "warning: gp_file_type expects absolute full path for first arg original_file") endif() - get_filename_component(exepath "${original_file}" PATH) - set(type "") - gp_resolved_file_type("${original_file}" "${file}" "${exepath}" "" type) + gp_resolved_file_type("${original_file}" "${file}" "${executable}" "" type) set(${type_var} "${type}" PARENT_SCOPE) endfunction() -function(get_prerequisites target prerequisites_var exclude_system recurse exepath dirs) +function(get_prerequisites target prerequisites_var exclude_system recurse executable dirs) set(verbose 0) set(eol_char "E") @@ -738,6 +742,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if("${gp_tool}" STREQUAL "ldd") set(old_ld_env "$ENV{LD_LIBRARY_PATH}") + get_filename_component(exepath "${executable}" PATH) set(new_ld_env "${exepath}") foreach(dir ${dirs}) set(new_ld_env "${new_ld_env}:${dir}") @@ -834,7 +839,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(add_item AND ${exclude_system}) set(type "") - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type) + gp_resolved_file_type("${target}" "${item}" "${executable}" "${dirs}" type) if("${type}" STREQUAL "system") set(add_item 0) @@ -855,7 +860,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa # that the analysis tools can simply accept it as input. # if(NOT list_length_before_append EQUAL list_length_after_append) - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${target}" "${item}" "${executable}" "${dirs}" resolved_item) set(unseen_prereqs ${unseen_prereqs} "${resolved_item}") endif() endif() @@ -874,7 +879,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(${recurse}) set(more_inputs ${unseen_prereqs}) foreach(input ${more_inputs}) - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}") + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${executable}" "${dirs}") endforeach() endif() @@ -911,7 +916,7 @@ function(list_prerequisites target) get_filename_component(exepath "${target}" PATH) set(prereqs "") - get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${exepath}" "") + get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${target}" "") if(print_target) message(STATUS "File '${target}' depends on:") -- 1.9.3 (Apple Git-50) From ono at java.pl Tue Sep 16 12:35:28 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 18:35:28 +0200 Subject: [cmake-developers] OS X packaging updates In-Reply-To: <540E0D6C.2010402@kitware.com> References: <1409836306-96543-1-git-send-email-ono@java.pl> <54087553.2020104@kitware.com> <5408B278.2070400@kitware.com> <4C094659-30A8-4304-ADBD-C62A1788C2A0@java.pl> <5409AD80.2000303@kitware.com> <540DE49F.8090508@kitware.com> <540E0D6C.2010402@kitware.com> Message-ID: <08C314C6-9A9C-4445-9342-66FA64080BEB@java.pl> > I had to revert again because it causes the Qt4Deploy to > fail. The topic changes the signature of gp_file_type. > User projects could be calling that, so we can't change it. > In this case it is the Modules/DeployQt4.cmake file that > was calling it. Thanks for spotting that. I've send updated 3/6 patch that now takes executable as an optional argument so we don't change any existing function signatures. --Adam From clinton at elemtech.com Tue Sep 16 12:55:41 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Tue, 16 Sep 2014 10:55:41 -0600 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <1410885143-87513-3-git-send-email-ono@java.pl> References: <1409917844-28297-3-git-send-email-ono@java.pl> <1410885143-87513-3-git-send-email-ono@java.pl> Message-ID: <2787116.mGKEBQAYYv@stryke> This patch has problems. You are calling BundleUtilities::get_item_key() from GetPrerequisites::gp_resolve_item(). There are users, including myself, which sometimes use GetPrerequisites.cmake but don't use BundleUtilities.cmake. So you cannot call BundleUtilities functions from GetPrerequisites. You also modified the signature of the gp_resolve_item_override() function which is defined by some users. There are a few others which were modified as well. Instead of taking an exepath, your patch changes them to take a executable. Instead, can you extract rpaths for a binary in BundleUtilities and pass that into gp_resolve_item via the existing dirs argument? Clint On Tuesday, September 16, 2014 06:32:20 PM Adam Strzelecki wrote: > This is done by gathering LC_RPATH commands for main bundle executable and > using it for @rpath lookup in dependent frameworks. > > To achieve this all utility functions now take path to executable rather > than path to its directory. > > This enabled apps using @rpath to be bundled correctly, which will be > necessary for upcoming Qt 5.4 that will use @rpath for all frameworks. > --- > Modules/BundleUtilities.cmake | 171 > +++++++++++++++++++++++++---------------- Modules/GetPrerequisites.cmake | > 51 ++++++------ > 2 files changed, 131 insertions(+), 91 deletions(-) > > diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake > index 7e2b173..817ac78 100644 > --- a/Modules/BundleUtilities.cmake > +++ b/Modules/BundleUtilities.cmake > @@ -19,6 +19,7 @@ > # get_bundle_and_executable > # get_bundle_all_executables > # get_item_key > +# get_item_rpaths > # clear_bundle_keys > # set_bundle_key_values > # get_bundle_keys > @@ -75,7 +76,7 @@ > # > # :: > # > -# GET_DOTAPP_DIR( ) > +# GET_DOTAPP_DIR( ) > # > # Returns the nearest parent dir whose name ends with ".app" given the > # full path to an executable. If there is no such parent dir, then > @@ -123,7 +124,7 @@ > # > # :: > # > -# SET_BUNDLE_KEY_VALUES( > +# SET_BUNDLE_KEY_VALUES( > # ) > # > # Add a key to the list (if necessary) for the given item. If added, > @@ -163,7 +164,7 @@ > # > # :: > # > -# FIXUP_BUNDLE_ITEM( ) > +# FIXUP_BUNDLE_ITEM( ) > # > # Get the direct/non-system prerequisites of the resolved embedded item. > # For each prerequisite, change the way it is referenced to the value of > @@ -189,11 +190,11 @@ > # > # :: > # > -# VERIFY_BUNDLE_PREREQUISITES( ) > +# VERIFY_BUNDLE_PREREQUISITES( > []) # > # Verifies that the sum of all prerequisites of all files inside the > -# bundle are contained within the bundle or are "system" libraries, > -# presumed to exist everywhere. > +# bundle with given optional main executable location are contained within > the +# bundle or are "system" libraries, presumed to exist everywhere. # > # :: > # > @@ -285,8 +286,8 @@ function(get_bundle_main_executable bundle result_var) > endfunction() > > > -function(get_dotapp_dir exe dotapp_dir_var) > - set(s "${exe}") > +function(get_dotapp_dir executable dotapp_dir_var) > + set(s "${executable}") > > if(s MATCHES "/.*\\.app/") > # If there is a ".app" parent directory, > @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) > endfunction() > > > +function(get_item_rpaths item rpaths_var) > + if(APPLE) > + find_program(otool_cmd "otool") > + mark_as_advanced(otool_cmd) > + endif() > + > + if(otool_cmd) > + execute_process( > + COMMAND "${otool_cmd}" -l "${item}" > + OUTPUT_VARIABLE load_cmds_ov > + ) > + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) > \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") + > string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") + > string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") + > if(load_cmds_ov) > + gp_append_unique(${rpaths_var} "${load_cmds_ov}") > + endif() > + endif() > + > + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) > +endfunction() > + > + > function(get_item_key item key_var) > get_filename_component(item_name "${item}" NAME) > if(WIN32) > @@ -425,12 +449,13 @@ function(clear_bundle_keys keys_var) > set(${key}_EMBEDDED_ITEM PARENT_SCOPE) > set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) > set(${key}_COPYFLAG PARENT_SCOPE) > + set(${key}_RPATHS PARENT_SCOPE) > endforeach() > set(${keys_var} PARENT_SCOPE) > endfunction() > > > -function(set_bundle_key_values keys_var context item exepath dirs copyflag) > +function(set_bundle_key_values keys_var context item executable dirs > copyflag) get_filename_component(item_name "${item}" NAME) > > get_item_key("${item}" key) > @@ -440,10 +465,17 @@ function(set_bundle_key_values keys_var context item > exepath dirs copyflag) list(LENGTH ${keys_var} length_after) > > if(NOT length_before EQUAL length_after) > - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" > resolved_item) + # Always use the exepath of the main bundle executable > for @executable_path + # replacements: > + # > + get_filename_component(exepath "${executable}" PATH) > + > + gp_resolve_item("${context}" "${item}" "${executable}" "${dirs}" > resolved_item) > > gp_item_default_embedded_path("${item}" default_embedded_path) > > + get_item_rpaths("${resolved_item}" rpaths) > + > if(item MATCHES "[^/]+\\.framework/") > # For frameworks, construct the name under the embedded path from the > # opening "${item_name}.framework/" to the closing "/${item_name}": @@ > -479,6 +511,7 @@ function(set_bundle_key_values keys_var context item > exepath dirs copyflag) set(${key}_EMBEDDED_ITEM "${embedded_item}" > PARENT_SCOPE) > set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" > PARENT_SCOPE) set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) > + set(${key}_RPATHS "${rpaths}" PARENT_SCOPE) > else() > #message("warning: item key '${key}' already in the list, subsequent > references assumed identical to first") endif() > @@ -490,14 +523,9 @@ function(get_bundle_keys app libs dirs keys_var) > > get_bundle_and_executable("${app}" bundle executable valid) > if(valid) > - # Always use the exepath of the main bundle executable for > @executable_path - # replacements: > - # > - get_filename_component(exepath "${executable}" PATH) > - > # But do fixups on all executables in the bundle: > # > - get_bundle_all_executables("${bundle}" exes) > + get_bundle_all_executables("${bundle}" file_list) > > # For each extra lib, accumulate a key as well and then also accumulate > # any of its prerequisites. (Extra libs are typically dynamically loaded @@ > -505,12 +533,12 @@ function(get_bundle_keys app libs dirs keys_var) # but > that do not show up in otool -L output...) > # > foreach(lib ${libs}) > - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" > "${dirs}" 0) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" > "${executable}" "${dirs}" 0) > > set(prereqs "") > - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") > + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") > foreach(pr ${prereqs}) > - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" > "${dirs}" 1) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" > "${executable}" "${dirs}" 1) endforeach() > endforeach() > > @@ -518,17 +546,17 @@ function(get_bundle_keys app libs dirs keys_var) > # The list of keys should be complete when all prerequisites of all > # binaries in the bundle have been analyzed. > # > - foreach(exe ${exes}) > + foreach(f ${file_list}) > # Add the exe itself to the keys: > # > - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" > "${dirs}" 0) + set_bundle_key_values(${keys_var} "${f}" "${f}" > "${executable}" "${dirs}" 0) > > # Add each prerequisite to the keys: > # > set(prereqs "") > - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") > + get_prerequisites("${f}" prereqs 1 1 "${executable}" "${dirs}") > foreach(pr ${prereqs}) > - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" > "${dirs}" 1) + set_bundle_key_values(${keys_var} "${f}" "${pr}" > "${executable}" "${dirs}" 1) endforeach() > endforeach() > > @@ -542,6 +570,7 @@ function(get_bundle_keys app libs dirs keys_var) > set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) > set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" > PARENT_SCOPE) set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) > + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) > endforeach() > endif() > endfunction() > @@ -612,7 +641,7 @@ function(copy_resolved_framework_into_bundle > resolved_item resolved_embedded_ite endfunction() > > > -function(fixup_bundle_item resolved_embedded_item exepath dirs) > +function(fixup_bundle_item resolved_embedded_item executable dirs) > # This item's key is "ikey": > # > get_item_key("${resolved_embedded_item}" ikey) > @@ -622,7 +651,7 @@ function(fixup_bundle_item resolved_embedded_item > exepath dirs) # tree, or in other varied locations around the file system, > with our call to # install_name_tool. Make sure that doesn't happen here: > # > - get_dotapp_dir("${exepath}" exe_dotapp_dir) > + get_dotapp_dir("${executable}" exe_dotapp_dir) > string(LENGTH "${exe_dotapp_dir}/" exe_dotapp_dir_length) > string(LENGTH "${resolved_embedded_item}" resolved_embedded_item_length) > set(path_too_short 0) > @@ -648,7 +677,7 @@ function(fixup_bundle_item resolved_embedded_item > exepath dirs) endif() > > set(prereqs "") > - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" > "${dirs}") + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 > "${executable}" "${dirs}") > > set(changes "") > > @@ -668,12 +697,20 @@ function(fixup_bundle_item resolved_embedded_item > exepath dirs) execute_process(COMMAND chmod u+w > "${resolved_embedded_item}") endif() > > + foreach(rpath ${${ikey}_RPATHS}) > + set(changes ${changes} -delete_rpath "${rpath}") > + endforeach() > + > + if(${ikey}_EMBEDDED_ITEM) > + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") > + endif() > + > # Change this item's id and all of its references in one call > # to install_name_tool: > # > - execute_process(COMMAND install_name_tool > - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" > - ) > + if(changes) > + execute_process(COMMAND install_name_tool ${changes} > "${resolved_embedded_item}") + endif() > endfunction() > > > @@ -685,8 +722,6 @@ function(fixup_bundle app libs dirs) > > get_bundle_and_executable("${app}" bundle executable valid) > if(valid) > - get_filename_component(exepath "${executable}" PATH) > - > message(STATUS "fixup_bundle: preparing...") > get_bundle_keys("${app}" "${libs}" "${dirs}" keys) > > @@ -732,7 +767,7 @@ function(fixup_bundle app libs dirs) > math(EXPR i ${i}+1) > if(APPLE) > message(STATUS "${i}/${n}: fixing up > '${${key}_RESOLVED_EMBEDDED_ITEM}'") - > fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${exepath}" > "${dirs}") + fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" > "${executable}" "${dirs}") else() > message(STATUS "${i}/${n}: fix-up not required on this platform > '${${key}_RESOLVED_EMBEDDED_ITEM}'") endif() > @@ -762,50 +797,50 @@ function(verify_bundle_prerequisites bundle result_var > info_var) set(info "") > set(count 0) > > - get_bundle_main_executable("${bundle}" main_bundle_exe) > + if(ARGC GREATER 0) > + set(executable "${ARGV0}") > + else() > + get_bundle_main_executable("${bundle}" executable) > + endif() > > - file(GLOB_RECURSE file_list "${bundle}/*") > + get_bundle_all_executables("${bundle}" file_list) > foreach(f ${file_list}) > - is_file_executable("${f}" is_executable) > - if(is_executable) > - get_filename_component(exepath "${f}" PATH) > - math(EXPR count "${count} + 1") > + math(EXPR count "${count} + 1") > > - message(STATUS "executable file ${count}: ${f}") > + message(STATUS "executable file ${count}: ${f}") > > - set(prereqs "") > - get_prerequisites("${f}" prereqs 1 1 "${exepath}" "") > + set(prereqs "") > + get_prerequisites("${f}" prereqs 1 1 "${executable}" "") > > - # On the Mac, > - # "embedded" and "system" prerequisites are fine... anything else > means - # the bundle's prerequisites are not verified (i.e., the > bundle is not - # really "standalone") > - # > - # On Windows (and others? Linux/Unix/...?) > - # "local" and "system" prereqs are fine... > - # > - set(external_prereqs "") > + # On the Mac, > + # "embedded" and "system" prerequisites are fine... anything else means > + # the bundle's prerequisites are not verified (i.e., the bundle is not > + # really "standalone") > + # > + # On Windows (and others? Linux/Unix/...?) > + # "local" and "system" prereqs are fine... > + # > + set(external_prereqs "") > > - foreach(p ${prereqs}) > - set(p_type "") > - gp_file_type("${f}" "${p}" p_type) > + foreach(p ${prereqs}) > + set(p_type "") > + gp_file_type("${f}" "${p}" p_type "${executable}") > > - if(APPLE) > - if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" > STREQUAL "system") - set(external_prereqs ${external_prereqs} > "${p}") > - endif() > - else() > - if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL > "system") - set(external_prereqs ${external_prereqs} "${p}") > - endif() > + if(APPLE) > + if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL > "system") + set(external_prereqs ${external_prereqs} "${p}") > + endif() > + else() > + if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL > "system") + set(external_prereqs ${external_prereqs} "${p}") > endif() > - endforeach() > - > - if(external_prereqs) > - # Found non-system/somehow-unacceptable prerequisites: > - set(result 0) > - set(info ${info} "external prerequisites > found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() > + endforeach() > + > + if(external_prereqs) > + # Found non-system/somehow-unacceptable prerequisites: > + set(result 0) > + set(info ${info} "external prerequisites > found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() > endforeach() > > @@ -845,7 +880,7 @@ function(verify_app app) > > # Verify that the bundle does not have any "external" prerequisites: > # > - verify_bundle_prerequisites("${bundle}" verified info) > + verify_bundle_prerequisites("${bundle}" verified info "${executable}") > message(STATUS "verified='${verified}'") > message(STATUS "info='${info}'") > message(STATUS "") > diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake > index 49443e3..439cc10 100644 > --- a/Modules/GetPrerequisites.cmake > +++ b/Modules/GetPrerequisites.cmake > @@ -41,7 +41,7 @@ > # :: > # > # GET_PREREQUISITES( > -# ) > +# ) > # > # Get the list of shared library files required by . The list > # in the variable named should be empty on first > @@ -53,7 +53,7 @@ > # must be 0 or 1 indicating whether to include or > # exclude "system" prerequisites. If is set to 1 all > # prerequisites will be found recursively, if set to 0 only direct > -# prerequisites are listed. is the path to the top level > +# prerequisites are listed. is the path to the top level > # executable used for @executable_path replacment on the Mac. is > # a list of paths where libraries might be found: these paths are > # searched first when a target without any path info is given. Then > @@ -113,7 +113,7 @@ > # > # :: > # > -# GP_RESOLVE_ITEM( ) > +# GP_RESOLVE_ITEM( > ) # > # Resolve an item into an existing full path file. > # > @@ -122,13 +122,13 @@ > # > # :: > # > -# GP_RESOLVED_FILE_TYPE( > ) +# GP_RESOLVED_FILE_TYPE( > ) # > # Return the type of with respect to . String > # describing type of prerequisite is returned in variable named > # . > # > -# Use and if necessary to resolve non-absolute > +# Use and if necessary to resolve non-absolute > # values -- but only for non-embedded items. > # > # Possible types are: > @@ -145,11 +145,12 @@ > # > # :: > # > -# GP_FILE_TYPE( ) > +# GP_FILE_TYPE( []) > # > # Return the type of with respect to . String > # describing type of prerequisite is returned in variable named > -# . > +# . Optional executable is used to resolve executable relative > +# library locations. > # > # Possible types are: > # > @@ -318,10 +319,12 @@ function(gp_item_default_embedded_path item > default_embedded_path_var) endfunction() > > > -function(gp_resolve_item context item exepath dirs resolved_item_var) > +function(gp_resolve_item context item executable dirs resolved_item_var) > set(resolved 0) > set(resolved_item "${item}") > > + get_filename_component(exepath "${executable}" PATH) > + > # Is it already resolved? > # > if(IS_ABSOLUTE "${resolved_item}" AND EXISTS "${resolved_item}") > @@ -331,7 +334,7 @@ function(gp_resolve_item context item exepath dirs > resolved_item_var) if(NOT resolved) > if(item MATCHES "^@executable_path") > # > - # @executable_path references are assumed relative to exepath > + # @executable_path references are assumed relative to executable > # > string(REPLACE "@executable_path" "${exepath}" ri "${item}") > get_filename_component(ri "${ri}" ABSOLUTE) > @@ -374,10 +377,11 @@ function(gp_resolve_item context item exepath dirs > resolved_item_var) # > string(REPLACE "@rpath/" "" norpath_item "${item}") > > + get_item_key("${executable}" key) > set(ri "ri-NOTFOUND") > - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) > + find_file(ri "${norpath_item}" ${dirs} ${${key}_RPATHS} > NO_DEFAULT_PATH) if(ri) > - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") > + #message(STATUS "info: 'find_file' in exepath/rpaths/dirs (${ri})") > set(resolved 1) > set(resolved_item "${ri}") > set(ri "ri-NOTFOUND") > @@ -436,7 +440,7 @@ function(gp_resolve_item context item exepath dirs > resolved_item_var) # by whatever logic they choose: > # > if(COMMAND gp_resolve_item_override) > - gp_resolve_item_override("${context}" "${item}" "${exepath}" "${dirs}" > resolved_item resolved) + gp_resolve_item_override("${context}" > "${item}" "${executable}" "${dirs}" resolved_item resolved) endif() > > if(NOT resolved) > @@ -459,7 +463,7 @@ warning: cannot resolve item '${item}' > # > # context='${context}' > # item='${item}' > -# exepath='${exepath}' > +# executable='${executable}' > # dirs='${dirs}' > # resolved_item_var='${resolved_item_var}' > #************************************************************************** > **** @@ -470,7 +474,7 @@ warning: cannot resolve item '${item}' > endfunction() > > > -function(gp_resolved_file_type original_file file exepath dirs type_var) > +function(gp_resolved_file_type original_file file executable dirs type_var) > #message(STATUS "**") > > if(NOT IS_ABSOLUTE "${original_file}") > @@ -489,7 +493,7 @@ function(gp_resolved_file_type original_file file > exepath dirs type_var) > > if(NOT is_embedded) > if(NOT IS_ABSOLUTE "${file}") > - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" > resolved_file) + gp_resolve_item("${original_file}" "${file}" > "${executable}" "${dirs}" resolved_file) endif() > > string(TOLOWER "${original_file}" original_lower) > @@ -596,20 +600,20 @@ endfunction() > > > function(gp_file_type original_file file type_var) > + set(executable "${ARGV0}") > + > if(NOT IS_ABSOLUTE "${original_file}") > message(STATUS "warning: gp_file_type expects absolute full path for > first arg original_file") endif() > > - get_filename_component(exepath "${original_file}" PATH) > - > set(type "") > - gp_resolved_file_type("${original_file}" "${file}" "${exepath}" "" type) > + gp_resolved_file_type("${original_file}" "${file}" "${executable}" "" > type) > > set(${type_var} "${type}" PARENT_SCOPE) > endfunction() > > > -function(get_prerequisites target prerequisites_var exclude_system recurse > exepath dirs) +function(get_prerequisites target prerequisites_var > exclude_system recurse executable dirs) set(verbose 0) > set(eol_char "E") > > @@ -738,6 +742,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa > > if("${gp_tool}" STREQUAL "ldd") > set(old_ld_env "$ENV{LD_LIBRARY_PATH}") > + get_filename_component(exepath "${executable}" PATH) > set(new_ld_env "${exepath}") > foreach(dir ${dirs}) > set(new_ld_env "${new_ld_env}:${dir}") > @@ -834,7 +839,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa > > if(add_item AND ${exclude_system}) > set(type "") > - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" > type) + gp_resolved_file_type("${target}" "${item}" "${executable}" > "${dirs}" type) > > if("${type}" STREQUAL "system") > set(add_item 0) > @@ -855,7 +860,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa # that the analysis tools can simply accept it > as input. > # > if(NOT list_length_before_append EQUAL list_length_after_append) > - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" > resolved_item) + gp_resolve_item("${target}" "${item}" > "${executable}" "${dirs}" resolved_item) set(unseen_prereqs > ${unseen_prereqs} "${resolved_item}") endif() > endif() > @@ -874,7 +879,7 @@ function(get_prerequisites target prerequisites_var > exclude_system recurse exepa if(${recurse}) > set(more_inputs ${unseen_prereqs}) > foreach(input ${more_inputs}) > - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} > ${recurse} "${exepath}" "${dirs}") + get_prerequisites("${input}" > ${prerequisites_var} ${exclude_system} ${recurse} "${executable}" > "${dirs}") endforeach() > endif() > > @@ -911,7 +916,7 @@ function(list_prerequisites target) > get_filename_component(exepath "${target}" PATH) > > set(prereqs "") > - get_prerequisites("${target}" prereqs ${exclude_system} ${all} > "${exepath}" "") + get_prerequisites("${target}" prereqs ${exclude_system} > ${all} "${target}" "") > > if(print_target) > message(STATUS "File '${target}' depends on:") -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com From ono at java.pl Tue Sep 16 14:44:35 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 20:44:35 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <1410885143-87513-3-git-send-email-ono@java.pl> References: <1410885143-87513-3-git-send-email-ono@java.pl> Message-ID: <1410893078-92177-3-git-send-email-ono@java.pl> This is done by gathering LC_RPATH commands for main bundle executable and using it for @rpath lookup in dependent frameworks. To achieve this all utility functions now take path to executable rather than path to its directory. This enabled apps using @rpath to be bundled correctly, which will be necessary for upcoming Qt 5.4 that will use @rpath for all frameworks. --- Modules/BundleUtilities.cmake | 174 +++++++++++++++++++++++++---------------- Modules/GetPrerequisites.cmake | 55 +++++++------ 2 files changed, 137 insertions(+), 92 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 7e2b173..ab26157 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -19,6 +19,7 @@ # get_bundle_and_executable # get_bundle_all_executables # get_item_key +# get_item_rpaths # clear_bundle_keys # set_bundle_key_values # get_bundle_keys @@ -75,7 +76,7 @@ # # :: # -# GET_DOTAPP_DIR( ) +# GET_DOTAPP_DIR( ) # # Returns the nearest parent dir whose name ends with ".app" given the # full path to an executable. If there is no such parent dir, then @@ -123,7 +124,7 @@ # # :: # -# SET_BUNDLE_KEY_VALUES( +# SET_BUNDLE_KEY_VALUES( # ) # # Add a key to the list (if necessary) for the given item. If added, @@ -163,7 +164,7 @@ # # :: # -# FIXUP_BUNDLE_ITEM( ) +# FIXUP_BUNDLE_ITEM( ) # # Get the direct/non-system prerequisites of the resolved embedded item. # For each prerequisite, change the way it is referenced to the value of @@ -189,11 +190,11 @@ # # :: # -# VERIFY_BUNDLE_PREREQUISITES( ) +# VERIFY_BUNDLE_PREREQUISITES( []) # # Verifies that the sum of all prerequisites of all files inside the -# bundle are contained within the bundle or are "system" libraries, -# presumed to exist everywhere. +# bundle with given optional main executable location are contained within the +# bundle or are "system" libraries, presumed to exist everywhere. # # :: # @@ -285,8 +286,8 @@ function(get_bundle_main_executable bundle result_var) endfunction() -function(get_dotapp_dir exe dotapp_dir_var) - set(s "${exe}") +function(get_dotapp_dir executable dotapp_dir_var) + set(s "${executable}") if(s MATCHES "/.*\\.app/") # If there is a ".app" parent directory, @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) endfunction() +function(get_item_rpaths item rpaths_var) + if(APPLE) + find_program(otool_cmd "otool") + mark_as_advanced(otool_cmd) + endif() + + if(otool_cmd) + execute_process( + COMMAND "${otool_cmd}" -l "${item}" + OUTPUT_VARIABLE load_cmds_ov + ) + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") + string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") + string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") + if(load_cmds_ov) + gp_append_unique(${rpaths_var} "${load_cmds_ov}") + endif() + endif() + + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) +endfunction() + + function(get_item_key item key_var) get_filename_component(item_name "${item}" NAME) if(WIN32) @@ -425,12 +449,13 @@ function(clear_bundle_keys keys_var) set(${key}_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_COPYFLAG PARENT_SCOPE) + set(${key}_RPATHS PARENT_SCOPE) endforeach() set(${keys_var} PARENT_SCOPE) endfunction() -function(set_bundle_key_values keys_var context item exepath dirs copyflag) +function(set_bundle_key_values keys_var context item executable dirs copyflag) get_filename_component(item_name "${item}" NAME) get_item_key("${item}" key) @@ -440,10 +465,19 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) list(LENGTH ${keys_var} length_after) if(NOT length_before EQUAL length_after) - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item) + # Always use the exepath of the main bundle executable for @executable_path + # replacements: + # + get_filename_component(exepath "${executable}" PATH) + + get_item_key("${executable}" executable_key) + + gp_resolve_item("${context}" "${item}" "${executable}" "${dirs}" resolved_item "${${executable_key}_RPATHS}") gp_item_default_embedded_path("${item}" default_embedded_path) + get_item_rpaths("${resolved_item}" rpaths) + if(item MATCHES "[^/]+\\.framework/") # For frameworks, construct the name under the embedded path from the # opening "${item_name}.framework/" to the closing "/${item_name}": @@ -479,6 +513,7 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) set(${key}_EMBEDDED_ITEM "${embedded_item}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" PARENT_SCOPE) set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) + set(${key}_RPATHS "${rpaths}" PARENT_SCOPE) else() #message("warning: item key '${key}' already in the list, subsequent references assumed identical to first") endif() @@ -490,14 +525,9 @@ function(get_bundle_keys app libs dirs keys_var) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - # Always use the exepath of the main bundle executable for @executable_path - # replacements: - # - get_filename_component(exepath "${executable}" PATH) - # But do fixups on all executables in the bundle: # - get_bundle_all_executables("${bundle}" exes) + get_bundle_all_executables("${bundle}" file_list) # For each extra lib, accumulate a key as well and then also accumulate # any of its prerequisites. (Extra libs are typically dynamically loaded @@ -505,12 +535,12 @@ function(get_bundle_keys app libs dirs keys_var) # but that do not show up in otool -L output...) # foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -518,17 +548,19 @@ function(get_bundle_keys app libs dirs keys_var) # The list of keys should be complete when all prerequisites of all # binaries in the bundle have been analyzed. # - foreach(exe ${exes}) + foreach(f ${file_list}) # Add the exe itself to the keys: # - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${f}" "${f}" "${executable}" "${dirs}" 0) + + get_item_key("${executable}" executable_key) # Add each prerequisite to the keys: # set(prereqs "") - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${f}" prereqs 1 1 "${executable}" "${dirs}" "${${executable_key}_RPATHS}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${f}" "${pr}" "${executable}" "${dirs}" 1) endforeach() endforeach() @@ -542,6 +574,7 @@ function(get_bundle_keys app libs dirs keys_var) set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) endforeach() endif() endfunction() @@ -612,7 +645,7 @@ function(copy_resolved_framework_into_bundle resolved_item resolved_embedded_ite endfunction() -function(fixup_bundle_item resolved_embedded_item exepath dirs) +function(fixup_bundle_item resolved_embedded_item executable dirs) # This item's key is "ikey": # get_item_key("${resolved_embedded_item}" ikey) @@ -622,7 +655,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) # tree, or in other varied locations around the file system, with our call to # install_name_tool. Make sure that doesn't happen here: # - get_dotapp_dir("${exepath}" exe_dotapp_dir) + get_dotapp_dir("${executable}" exe_dotapp_dir) string(LENGTH "${exe_dotapp_dir}/" exe_dotapp_dir_length) string(LENGTH "${resolved_embedded_item}" resolved_embedded_item_length) set(path_too_short 0) @@ -647,8 +680,10 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) message(FATAL_ERROR "cannot fixup an item that is not in the bundle...") endif() + get_item_key("${executable}" executable_key) + set(prereqs "") - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}") + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${executable}" "${dirs}" "${${executable_key}_RPATHS}") set(changes "") @@ -668,12 +703,20 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) execute_process(COMMAND chmod u+w "${resolved_embedded_item}") endif() + foreach(rpath ${${ikey}_RPATHS}) + set(changes ${changes} -delete_rpath "${rpath}") + endforeach() + + if(${ikey}_EMBEDDED_ITEM) + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") + endif() + # Change this item's id and all of its references in one call # to install_name_tool: # - execute_process(COMMAND install_name_tool - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" - ) + if(changes) + execute_process(COMMAND install_name_tool ${changes} "${resolved_embedded_item}") + endif() endfunction() @@ -685,8 +728,6 @@ function(fixup_bundle app libs dirs) get_bundle_and_executable("${app}" bundle executable valid) if(valid) - get_filename_component(exepath "${executable}" PATH) - message(STATUS "fixup_bundle: preparing...") get_bundle_keys("${app}" "${libs}" "${dirs}" keys) @@ -732,7 +773,7 @@ function(fixup_bundle app libs dirs) math(EXPR i ${i}+1) if(APPLE) message(STATUS "${i}/${n}: fixing up '${${key}_RESOLVED_EMBEDDED_ITEM}'") - fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${exepath}" "${dirs}") + fixup_bundle_item("${${key}_RESOLVED_EMBEDDED_ITEM}" "${executable}" "${dirs}") else() message(STATUS "${i}/${n}: fix-up not required on this platform '${${key}_RESOLVED_EMBEDDED_ITEM}'") endif() @@ -761,51 +802,46 @@ function(verify_bundle_prerequisites bundle result_var info_var) set(result 1) set(info "") set(count 0) + set(executable "${ARGV3}") - get_bundle_main_executable("${bundle}" main_bundle_exe) - - file(GLOB_RECURSE file_list "${bundle}/*") + get_bundle_all_executables("${bundle}" file_list) foreach(f ${file_list}) - is_file_executable("${f}" is_executable) - if(is_executable) - get_filename_component(exepath "${f}" PATH) - math(EXPR count "${count} + 1") + math(EXPR count "${count} + 1") - message(STATUS "executable file ${count}: ${f}") + message(STATUS "executable file ${count}: ${f}") - set(prereqs "") - get_prerequisites("${f}" prereqs 1 1 "${exepath}" "") + set(prereqs "") + get_prerequisites("${f}" prereqs 1 1 "${executable}" "") - # On the Mac, - # "embedded" and "system" prerequisites are fine... anything else means - # the bundle's prerequisites are not verified (i.e., the bundle is not - # really "standalone") - # - # On Windows (and others? Linux/Unix/...?) - # "local" and "system" prereqs are fine... - # - set(external_prereqs "") + # On the Mac, + # "embedded" and "system" prerequisites are fine... anything else means + # the bundle's prerequisites are not verified (i.e., the bundle is not + # really "standalone") + # + # On Windows (and others? Linux/Unix/...?) + # "local" and "system" prereqs are fine... + # + set(external_prereqs "") - foreach(p ${prereqs}) - set(p_type "") - gp_file_type("${f}" "${p}" p_type) + foreach(p ${prereqs}) + set(p_type "") + gp_file_type("${f}" "${p}" p_type "${executable}") - if(APPLE) - if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL "system") - set(external_prereqs ${external_prereqs} "${p}") - endif() - else() - if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL "system") - set(external_prereqs ${external_prereqs} "${p}") - endif() + if(APPLE) + if(NOT "${p_type}" STREQUAL "embedded" AND NOT "${p_type}" STREQUAL "system") + set(external_prereqs ${external_prereqs} "${p}") + endif() + else() + if(NOT "${p_type}" STREQUAL "local" AND NOT "${p_type}" STREQUAL "system") + set(external_prereqs ${external_prereqs} "${p}") endif() - endforeach() - - if(external_prereqs) - # Found non-system/somehow-unacceptable prerequisites: - set(result 0) - set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() + endforeach() + + if(external_prereqs) + # Found non-system/somehow-unacceptable prerequisites: + set(result 0) + set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() endforeach() @@ -845,7 +881,7 @@ function(verify_app app) # Verify that the bundle does not have any "external" prerequisites: # - verify_bundle_prerequisites("${bundle}" verified info) + verify_bundle_prerequisites("${bundle}" verified info "${executable}") message(STATUS "verified='${verified}'") message(STATUS "info='${info}'") message(STATUS "") diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 49443e3..0684f12 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -41,7 +41,7 @@ # :: # # GET_PREREQUISITES( -# ) +# []) # # Get the list of shared library files required by . The list # in the variable named should be empty on first @@ -53,7 +53,7 @@ # must be 0 or 1 indicating whether to include or # exclude "system" prerequisites. If is set to 1 all # prerequisites will be found recursively, if set to 0 only direct -# prerequisites are listed. is the path to the top level +# prerequisites are listed. is the path to the top level # executable used for @executable_path replacment on the Mac. is # a list of paths where libraries might be found: these paths are # searched first when a target without any path info is given. Then @@ -113,7 +113,8 @@ # # :: # -# GP_RESOLVE_ITEM( ) +# GP_RESOLVE_ITEM( +# []) # # Resolve an item into an existing full path file. # @@ -122,13 +123,14 @@ # # :: # -# GP_RESOLVED_FILE_TYPE( ) +# GP_RESOLVED_FILE_TYPE( +# []) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named # . # -# Use and if necessary to resolve non-absolute +# Use and if necessary to resolve non-absolute # values -- but only for non-embedded items. # # Possible types are: @@ -145,11 +147,12 @@ # # :: # -# GP_FILE_TYPE( ) +# GP_FILE_TYPE( []) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named -# . +# . Optional executable is used to resolve executable relative +# library locations. # # Possible types are: # @@ -318,9 +321,12 @@ function(gp_item_default_embedded_path item default_embedded_path_var) endfunction() -function(gp_resolve_item context item exepath dirs resolved_item_var) +function(gp_resolve_item context item executable dirs resolved_item_var) set(resolved 0) set(resolved_item "${item}") + set(rpaths "${ARGV5}") + + get_filename_component(exepath "${executable}" PATH) # Is it already resolved? # @@ -331,7 +337,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) if(NOT resolved) if(item MATCHES "^@executable_path") # - # @executable_path references are assumed relative to exepath + # @executable_path references are assumed relative to executable # string(REPLACE "@executable_path" "${exepath}" ri "${item}") get_filename_component(ri "${ri}" ABSOLUTE) @@ -375,9 +381,9 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) string(REPLACE "@rpath/" "" norpath_item "${item}") set(ri "ri-NOTFOUND") - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) + find_file(ri "${norpath_item}" ${dirs} ${rpaths} NO_DEFAULT_PATH) if(ri) - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") + #message(STATUS "info: 'find_file' in exepath/rpaths/dirs (${ri})") set(resolved 1) set(resolved_item "${ri}") set(ri "ri-NOTFOUND") @@ -436,7 +442,7 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) # by whatever logic they choose: # if(COMMAND gp_resolve_item_override) - gp_resolve_item_override("${context}" "${item}" "${exepath}" "${dirs}" resolved_item resolved) + gp_resolve_item_override("${context}" "${item}" "${executable}" "${dirs}" resolved_item resolved) endif() if(NOT resolved) @@ -459,7 +465,7 @@ warning: cannot resolve item '${item}' # # context='${context}' # item='${item}' -# exepath='${exepath}' +# executable='${executable}' # dirs='${dirs}' # resolved_item_var='${resolved_item_var}' #****************************************************************************** @@ -470,7 +476,8 @@ warning: cannot resolve item '${item}' endfunction() -function(gp_resolved_file_type original_file file exepath dirs type_var) +function(gp_resolved_file_type original_file file executable dirs type_var) + set(rpaths "${ARGV5}") #message(STATUS "**") if(NOT IS_ABSOLUTE "${original_file}") @@ -489,7 +496,7 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) if(NOT is_embedded) if(NOT IS_ABSOLUTE "${file}") - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file) + gp_resolve_item("${original_file}" "${file}" "${executable}" "${dirs}" resolved_file "${rpaths}") endif() string(TOLOWER "${original_file}" original_lower) @@ -596,22 +603,23 @@ endfunction() function(gp_file_type original_file file type_var) + set(executable "${ARGV3}") + if(NOT IS_ABSOLUTE "${original_file}") message(STATUS "warning: gp_file_type expects absolute full path for first arg original_file") endif() - get_filename_component(exepath "${original_file}" PATH) - set(type "") - gp_resolved_file_type("${original_file}" "${file}" "${exepath}" "" type) + gp_resolved_file_type("${original_file}" "${file}" "${executable}" "" type) set(${type_var} "${type}" PARENT_SCOPE) endfunction() -function(get_prerequisites target prerequisites_var exclude_system recurse exepath dirs) +function(get_prerequisites target prerequisites_var exclude_system recurse executable dirs) set(verbose 0) set(eol_char "E") + set(rpaths "${ARGV6}") if(NOT IS_ABSOLUTE "${target}") message("warning: target '${target}' is not absolute...") @@ -738,6 +746,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if("${gp_tool}" STREQUAL "ldd") set(old_ld_env "$ENV{LD_LIBRARY_PATH}") + get_filename_component(exepath "${executable}" PATH) set(new_ld_env "${exepath}") foreach(dir ${dirs}) set(new_ld_env "${new_ld_env}:${dir}") @@ -834,7 +843,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(add_item AND ${exclude_system}) set(type "") - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type) + gp_resolved_file_type("${target}" "${item}" "${executable}" "${dirs}" type "${rpaths}") if("${type}" STREQUAL "system") set(add_item 0) @@ -855,7 +864,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa # that the analysis tools can simply accept it as input. # if(NOT list_length_before_append EQUAL list_length_after_append) - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${target}" "${item}" "${executable}" "${dirs}" resolved_item "${rpaths}") set(unseen_prereqs ${unseen_prereqs} "${resolved_item}") endif() endif() @@ -874,7 +883,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(${recurse}) set(more_inputs ${unseen_prereqs}) foreach(input ${more_inputs}) - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}") + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${executable}" "${dirs}" "${rpaths}") endforeach() endif() @@ -911,7 +920,7 @@ function(list_prerequisites target) get_filename_component(exepath "${target}" PATH) set(prereqs "") - get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${exepath}" "") + get_prerequisites("${target}" prereqs ${exclude_system} ${all} "${target}" "") if(print_target) message(STATUS "File '${target}' depends on:") -- 1.9.3 (Apple Git-50) From ono at java.pl Tue Sep 16 14:44:36 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 20:44:36 +0200 Subject: [cmake-developers] [PATCH 4/6] Process executables first when scanning bundle In-Reply-To: <1410885143-87513-3-git-send-email-ono@java.pl> References: <1410885143-87513-3-git-send-email-ono@java.pl> Message-ID: <1410893078-92177-4-git-send-email-ono@java.pl> This makes rpaths populated (if any), so libraries containing @rpath will be resolved properly. --- Modules/BundleUtilities.cmake | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index ab26157..ea2d924 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -529,21 +529,6 @@ function(get_bundle_keys app libs dirs keys_var) # get_bundle_all_executables("${bundle}" file_list) - # For each extra lib, accumulate a key as well and then also accumulate - # any of its prerequisites. (Extra libs are typically dynamically loaded - # plugins: libraries that are prerequisites for full runtime functionality - # but that do not show up in otool -L output...) - # - foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) - - set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}") - foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) - endforeach() - endforeach() - # For each executable found in the bundle, accumulate keys as we go. # The list of keys should be complete when all prerequisites of all # binaries in the bundle have been analyzed. @@ -564,6 +549,21 @@ function(get_bundle_keys app libs dirs keys_var) endforeach() endforeach() + # For each extra lib, accumulate a key as well and then also accumulate + # any of its prerequisites. (Extra libs are typically dynamically loaded + # plugins: libraries that are prerequisites for full runtime functionality + # but that do not show up in otool -L output...) + # + foreach(lib ${libs}) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${executable}" "${dirs}" 0) + + set(prereqs "") + get_prerequisites("${lib}" prereqs 1 1 "${executable}" "${dirs}" "${${executable_key}_RPATHS}") + foreach(pr ${prereqs}) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${executable}" "${dirs}" 1) + endforeach() + endforeach() + # Propagate values to caller's scope: # set(${keys_var} ${${keys_var}} PARENT_SCOPE) -- 1.9.3 (Apple Git-50) From ono at java.pl Tue Sep 16 14:48:31 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 20:48:31 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <2787116.mGKEBQAYYv@stryke> References: <1409917844-28297-3-git-send-email-ono@java.pl> <1410885143-87513-3-git-send-email-ono@java.pl> <2787116.mGKEBQAYYv@stryke> Message-ID: > Instead, can you extract rpaths for a binary in BundleUtilities and pass that > into gp_resolve_item via the existing dirs argument? Okay, fixed this in the new 3/6 + 4/6 patches, attached to previous patch post. FYI I cannot use existing dirs arguments because other replacements search paths shouldn't look into rpath, only @rpath replacements. So instead I added extra optional rpaths argument to all GetPrerequisites functions that somewhere call gp_resolve_item so need to carry rpaths. WDYT? --Adam From clinton at elemtech.com Tue Sep 16 15:12:04 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Tue, 16 Sep 2014 13:12:04 -0600 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: References: <1409917844-28297-3-git-send-email-ono@java.pl> <2787116.mGKEBQAYYv@stryke> Message-ID: <128289242.dS4VVThf2B@stryke> On Tuesday, September 16, 2014 08:48:31 PM Adam Strzelecki wrote: > > Instead, can you extract rpaths for a binary in BundleUtilities and pass > > that into gp_resolve_item via the existing dirs argument? > > Okay, fixed this in the new 3/6 + 4/6 patches, attached to previous patch > post. > > FYI I cannot use existing dirs arguments because other replacements search > paths shouldn't look into rpath, only @rpath replacements. Sure, but the caller can also check for @rpath and in that case add the rpaths to the existing dirs argument. Yes, there are other find_file() searches in there, that could potentially mess up if the actual filename had "@rpath" in it. But I would also argue that the general fallback find_file(ri "${item}" ${exepath} ${dirs} /usr/lib) can undesirably be affected by other variables such as CMAKE_INCLUDE_PATH. > > So instead I added extra optional rpaths argument to all GetPrerequisites > functions that somewhere call gp_resolve_item so need to carry rpaths. > > WDYT? > > --Adam Can you explain the "exepath" to "executable" change in the function signatures? I have the impression you changed the signature of several functions to accept "/path/to/executable" instead of "/path/to/" No? These functions are called by other codes and we can't just change the meaning of the arguments. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com From ono at java.pl Tue Sep 16 15:25:16 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 21:25:16 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <128289242.dS4VVThf2B@stryke> References: <1409917844-28297-3-git-send-email-ono@java.pl> <2787116.mGKEBQAYYv@stryke> <128289242.dS4VVThf2B@stryke> Message-ID: > No? These functions are called by other codes and we can't just change the > meaning of the arguments. You are completely right. I am changing all stuff back, once I pass rpath as optional argument we can have exepath everywhere. Thanks for your feedback. Regards, -- Adam From ono at java.pl Tue Sep 16 16:43:33 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 22:43:33 +0200 Subject: [cmake-developers] [PATCH 3/5] Resolve & replace @rpath placeholders In-Reply-To: <1410885143-87513-3-git-send-email-ono@java.pl> References: <1410885143-87513-3-git-send-email-ono@java.pl> Message-ID: <1410900215-99370-3-git-send-email-ono@java.pl> This is done by gathering LC_RPATH commands for main bundle executable and using it for @rpath lookup in dependent frameworks. All functions that need to carry rpaths to now take optional argument. This enabled apps using @rpath to be bundled correctly, which will be necessary for upcoming Qt 5.4 that will use @rpath for all frameworks. --- Modules/BundleUtilities.cmake | 93 ++++++++++++++++++++++++++++++++++-------- Modules/GetPrerequisites.cmake | 36 ++++++++++------ 2 files changed, 99 insertions(+), 30 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 7e2b173..cc27310 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -19,6 +19,7 @@ # get_bundle_and_executable # get_bundle_all_executables # get_item_key +# get_item_rpaths # clear_bundle_keys # set_bundle_key_values # get_bundle_keys @@ -124,7 +125,7 @@ # :: # # SET_BUNDLE_KEY_VALUES( -# ) +# []) # # Add a key to the list (if necessary) for the given item. If added, # also set all the variables associated with that key. @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) endfunction() +function(get_item_rpaths item rpaths_var) + if(APPLE) + find_program(otool_cmd "otool") + mark_as_advanced(otool_cmd) + endif() + + if(otool_cmd) + execute_process( + COMMAND "${otool_cmd}" -l "${item}" + OUTPUT_VARIABLE load_cmds_ov + ) + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") + string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") + string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") + if(load_cmds_ov) + gp_append_unique(${rpaths_var} "${load_cmds_ov}") + endif() + endif() + + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) +endfunction() + + function(get_item_key item key_var) get_filename_component(item_name "${item}" NAME) if(WIN32) @@ -425,12 +449,14 @@ function(clear_bundle_keys keys_var) set(${key}_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_COPYFLAG PARENT_SCOPE) + set(${key}_RPATHS PARENT_SCOPE) endforeach() set(${keys_var} PARENT_SCOPE) endfunction() function(set_bundle_key_values keys_var context item exepath dirs copyflag) + set(rpaths "${ARGV6}") get_filename_component(item_name "${item}" NAME) get_item_key("${item}" key) @@ -440,10 +466,12 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) list(LENGTH ${keys_var} length_after) if(NOT length_before EQUAL length_after) - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item "${rpaths}") gp_item_default_embedded_path("${item}" default_embedded_path) + get_item_rpaths("${resolved_item}" item_rpaths) + if(item MATCHES "[^/]+\\.framework/") # For frameworks, construct the name under the embedded path from the # opening "${item_name}.framework/" to the closing "/${item_name}": @@ -479,6 +507,8 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) set(${key}_EMBEDDED_ITEM "${embedded_item}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" PARENT_SCOPE) set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) + set(${key}_RPATHS "${item_rpaths}" PARENT_SCOPE) + set(${key}_RDEP_RPATHS "${rpaths}" PARENT_SCOPE) else() #message("warning: item key '${key}' already in the list, subsequent references assumed identical to first") endif() @@ -499,18 +529,27 @@ function(get_bundle_keys app libs dirs keys_var) # get_bundle_all_executables("${bundle}" exes) + # Set keys for main executable first: + # + set_bundle_key_values(${keys_var} "${executable}" "${executable}" "${exepath}" "${dirs}" 0) + + # Get rpaths specified by main executable: + # + get_item_key("${executable}" executable_key) + set(main_rpaths "${${executable_key}_RPATHS}") + # For each extra lib, accumulate a key as well and then also accumulate # any of its prerequisites. (Extra libs are typically dynamically loaded # plugins: libraries that are prerequisites for full runtime functionality # but that do not show up in otool -L output...) # foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0 "${main_rpaths}") set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}" "${main_rpaths}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1 "${main_rpaths}") endforeach() endforeach() @@ -519,16 +558,27 @@ function(get_bundle_keys app libs dirs keys_var) # binaries in the bundle have been analyzed. # foreach(exe ${exes}) - # Add the exe itself to the keys: + # Main executable is scanned first above: # - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0) + if(NOT "${exe}" STREQUAL "${executable}") + # Add the exe itself to the keys: + # + set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0 "${main_rpaths}") + + # Get rpaths specified by executable: + # + get_item_key("${exe}" exe_key) + set(exe_rpaths "${main_rpaths}" "${${exe_key}_RPATHS}") + else() + set(exe_rpaths "${main_rpaths}") + endif() # Add each prerequisite to the keys: # set(prereqs "") - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}" "${exe_rpaths}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1 "${exe_rpaths}") endforeach() endforeach() @@ -542,6 +592,8 @@ function(get_bundle_keys app libs dirs keys_var) set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) + set(${key}_RDEP_RPATHS "${${key}_RDEP_RPATHS}" PARENT_SCOPE) endforeach() endif() endfunction() @@ -647,8 +699,10 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) message(FATAL_ERROR "cannot fixup an item that is not in the bundle...") endif() + set(rpaths "${${ikey}_RPATHS}" "${${ikey}_RDEP_RPATHS}") + set(prereqs "") - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}") + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}" "${rpaths}") set(changes "") @@ -668,12 +722,20 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) execute_process(COMMAND chmod u+w "${resolved_embedded_item}") endif() + foreach(rpath ${${ikey}_RPATHS}) + set(changes ${changes} -delete_rpath "${rpath}") + endforeach() + + if(${ikey}_EMBEDDED_ITEM) + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") + endif() + # Change this item's id and all of its references in one call # to install_name_tool: # - execute_process(COMMAND install_name_tool - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" - ) + if(changes) + execute_process(COMMAND install_name_tool ${changes} "${resolved_embedded_item}") + endif() endfunction() @@ -764,10 +826,8 @@ function(verify_bundle_prerequisites bundle result_var info_var) get_bundle_main_executable("${bundle}" main_bundle_exe) - file(GLOB_RECURSE file_list "${bundle}/*") + get_bundle_all_executables("${bundle}" file_list) foreach(f ${file_list}) - is_file_executable("${f}" is_executable) - if(is_executable) get_filename_component(exepath "${f}" PATH) math(EXPR count "${count} + 1") @@ -806,7 +866,6 @@ function(verify_bundle_prerequisites bundle result_var info_var) set(result 0) set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() - endif() endforeach() if(result) diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 49443e3..f8e1492 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -41,7 +41,7 @@ # :: # # GET_PREREQUISITES( -# ) +# []) # # Get the list of shared library files required by . The list # in the variable named should be empty on first @@ -113,7 +113,8 @@ # # :: # -# GP_RESOLVE_ITEM( ) +# GP_RESOLVE_ITEM( +# []) # # Resolve an item into an existing full path file. # @@ -122,7 +123,8 @@ # # :: # -# GP_RESOLVED_FILE_TYPE( ) +# GP_RESOLVED_FILE_TYPE( +# []) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named @@ -145,11 +147,12 @@ # # :: # -# GP_FILE_TYPE( ) +# GP_FILE_TYPE( []) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named -# . +# . Optional exepath is used to resolve executable relative +# library locations. # # Possible types are: # @@ -321,6 +324,7 @@ endfunction() function(gp_resolve_item context item exepath dirs resolved_item_var) set(resolved 0) set(resolved_item "${item}") + set(rpaths "${ARGV5}") # Is it already resolved? # @@ -375,9 +379,9 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) string(REPLACE "@rpath/" "" norpath_item "${item}") set(ri "ri-NOTFOUND") - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) + find_file(ri "${norpath_item}" ${exepath} ${dirs} ${rpaths} NO_DEFAULT_PATH) if(ri) - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") + #message(STATUS "info: 'find_file' in exepath/dirs/rpaths (${ri})") set(resolved 1) set(resolved_item "${ri}") set(ri "ri-NOTFOUND") @@ -471,6 +475,7 @@ endfunction() function(gp_resolved_file_type original_file file exepath dirs type_var) + set(rpaths "${ARGV5}") #message(STATUS "**") if(NOT IS_ABSOLUTE "${original_file}") @@ -489,7 +494,7 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) if(NOT is_embedded) if(NOT IS_ABSOLUTE "${file}") - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file) + gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file "${rpaths}") endif() string(TOLOWER "${original_file}" original_lower) @@ -596,12 +601,16 @@ endfunction() function(gp_file_type original_file file type_var) + if("${ARGV3}" STREQUAL "") + get_filename_component(exepath "${original_file}" PATH) + else() + set(exepath "${ARGV3}") + endif() + if(NOT IS_ABSOLUTE "${original_file}") message(STATUS "warning: gp_file_type expects absolute full path for first arg original_file") endif() - get_filename_component(exepath "${original_file}" PATH) - set(type "") gp_resolved_file_type("${original_file}" "${file}" "${exepath}" "" type) @@ -612,6 +621,7 @@ endfunction() function(get_prerequisites target prerequisites_var exclude_system recurse exepath dirs) set(verbose 0) set(eol_char "E") + set(rpaths "${ARGV6}") if(NOT IS_ABSOLUTE "${target}") message("warning: target '${target}' is not absolute...") @@ -834,7 +844,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(add_item AND ${exclude_system}) set(type "") - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type) + gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type "${rpaths}") if("${type}" STREQUAL "system") set(add_item 0) @@ -855,7 +865,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa # that the analysis tools can simply accept it as input. # if(NOT list_length_before_append EQUAL list_length_after_append) - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item "${rpaths}") set(unseen_prereqs ${unseen_prereqs} "${resolved_item}") endif() endif() @@ -874,7 +884,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(${recurse}) set(more_inputs ${unseen_prereqs}) foreach(input ${more_inputs}) - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}") + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}" "${rpaths}") endforeach() endif() -- 1.9.3 (Apple Git-50) From ono at java.pl Tue Sep 16 16:53:14 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 22:53:14 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <128289242.dS4VVThf2B@stryke> References: <1409917844-28297-3-git-send-email-ono@java.pl> <2787116.mGKEBQAYYv@stryke> <128289242.dS4VVThf2B@stryke> Message-ID: <92C864E8-9E7D-493C-BDE3-73F60D8C7FD5@java.pl> I have sent [PATCH 3/5] Resolve & replace @rpath placeholders which replaces previous 3/6 and obsoletes 4/6. Since it is getting messy like checking & fixing maybe stage account and topic branch would be more accurate. --Adam From clinton at elemtech.com Tue Sep 16 16:57:20 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Tue, 16 Sep 2014 14:57:20 -0600 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <92C864E8-9E7D-493C-BDE3-73F60D8C7FD5@java.pl> References: <1409917844-28297-3-git-send-email-ono@java.pl> <128289242.dS4VVThf2B@stryke> <92C864E8-9E7D-493C-BDE3-73F60D8C7FD5@java.pl> Message-ID: <12402410.NXmEnSXjYD@stryke> On Tuesday, September 16, 2014 10:53:14 PM Adam Strzelecki wrote: > I have sent [PATCH 3/5] Resolve & replace @rpath placeholders which replaces > previous 3/6 and obsoletes 4/6. > > Since it is getting messy like checking & fixing maybe stage account and > topic branch would be more accurate. > > --Adam Yes, it would be easier to review on stage or on github. Thanks. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com From ono at java.pl Tue Sep 16 17:01:33 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 16 Sep 2014 23:01:33 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <12402410.NXmEnSXjYD@stryke> References: <1409917844-28297-3-git-send-email-ono@java.pl> <128289242.dS4VVThf2B@stryke> <92C864E8-9E7D-493C-BDE3-73F60D8C7FD5@java.pl> <12402410.NXmEnSXjYD@stryke> Message-ID: <6D2F3ECF-7F51-4458-9586-2FB028445878@java.pl> > Yes, it would be easier to review on stage or on github. Thanks. Here it is: https://github.com/nanoant/CMake/commits/fix-bundle-rpaths I would love to get stage access though ;) Cheers, -- Adam From bouffa at gmail.com Tue Sep 16 18:11:24 2014 From: bouffa at gmail.com (Mourad Boufarguine) Date: Wed, 17 Sep 2014 00:11:24 +0200 Subject: [cmake-developers] vs-nsight-tegra-generator topic Message-ID: On Tue, Sep 16, 2014 at 4:05 PM, Brad King wrote: > Hi Folks, > > This topic introduces support for generating VS project files > for the NVIDIA Nsight Tegra Visual Studio Edition, which then > builds for Android. I've merged it to 'next' for testing: > Hi Brad, I am really excited to see Nsight Tegra VS support being added to CMake, it will certainly help me (and others for sure) save so much some configuring manually my Android projects. Actually, few days ago I gave the patches you sent to the developer list back in July [1] a try. I had to make some dirty tweaks into the CMake code to make it build an Android application (java + native). So, today I tried the next branch with the new NSight stuff. It seems more accomplished than [1], but still doesn't work for me out of the box: I get an error when trying to link to an android "system" library (like GLESv1_CM , android, etc..). To reproduce the problem : target_link_libraries(myAndroidProject GLESv1_CM) I get this error when trying to build my Android application : 1> (...)/arm-linux-androideabi/bin/ld.bfd.exe: cannot find -l-lGLESv1_CM Please note the double "-l" in front of the library name. I took a look to the VS project properties, and found that in Linker>Input tab, in the "Additional Dependencies" the library name is prefixed by '-l' : -lGLESv1_CM Obviously, removing the leading '-l' in the VS project property window solves the problem (until the project gets generated again by CMake). Minor considerations: By comparing the generated vcxproj files with the manually configured ones I noticed these minor differences (I can't tell whether these have any consequences on the build) * Java files are declared using JCompile xml tags instead of None tags (using cmake) * some special files are declared using AndroidBuild xml tags (AndroidManifest.xml, build.xml, project.properties, proguard.cfg, res\values\strings.xml ...) My 2 cents, keep up the good work. Mourad [1] http://public.kitware.com/pipermail/cmake-developers/2014-July/010811.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton at elemtech.com Tue Sep 16 18:54:52 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Tue, 16 Sep 2014 16:54:52 -0600 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <6D2F3ECF-7F51-4458-9586-2FB028445878@java.pl> References: <1409917844-28297-3-git-send-email-ono@java.pl> <12402410.NXmEnSXjYD@stryke> <6D2F3ECF-7F51-4458-9586-2FB028445878@java.pl> Message-ID: <1579949.fFJZQIyjfv@stryke> On Tuesday, September 16, 2014 11:01:33 PM Adam Strzelecki wrote: > > Yes, it would be easier to review on stage or on github. Thanks. > > Here it is: > https://github.com/nanoant/CMake/commits/fix-bundle-rpaths > > I would love to get stage access though ;) > > Cheers, What is the new optional parameter to gp_file_type() used for? I don't see any code in your branch calling that function with the new parameter. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com From ono at java.pl Tue Sep 16 19:10:01 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 17 Sep 2014 01:10:01 +0200 Subject: [cmake-developers] Nice DMG layout for CMake OSX builds Message-ID: Hi, I've made simple background: https://dl.dropboxusercontent.com/u/64748870/CMakeDMGBackground.tif And together with my shell script for creating dmg with custom layout at: https://gist.github.com/nanoant/89237ad368d333795fc0 I have created installer that looks like that: So feel free to take & modify script above and TIFF file. Cheers, -- Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Test 4.png Type: image/png Size: 45986 bytes Desc: not available URL: From ono at java.pl Tue Sep 16 19:13:45 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 17 Sep 2014 01:13:45 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <1579949.fFJZQIyjfv@stryke> References: <1409917844-28297-3-git-send-email-ono@java.pl> <12402410.NXmEnSXjYD@stryke> <6D2F3ECF-7F51-4458-9586-2FB028445878@java.pl> <1579949.fFJZQIyjfv@stryke> Message-ID: > What is the new optional parameter to gp_file_type() used for? My intention was to pass exepath rather than take it from the path of original_file. But this is in fact not necessary. > I don't see any code in your branch calling that function with the new > parameter. You are right, I am not using that. So I can drop that change. --Adam From mantis at public.kitware.com Wed Sep 17 00:20:16 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 17 Sep 2014 00:20:16 -0400 Subject: [cmake-developers] [CMake 0015161]: FindProtobuf: Generated source not regenerated on library update Message-ID: <4aa62792b6ba296e93eb510cd0358549@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15161 ====================================================================== Reported By: hansmi Assigned To: ====================================================================== Project: CMake Issue ID: 15161 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-17 00:20 EDT Last Modified: 2014-09-17 00:20 EDT ====================================================================== Summary: FindProtobuf: Generated source not regenerated on library update Description: After updating from Protocol Buffers 2.5.0 to 2.6.0 compilation of the generated source failed: ?This file was generated by an older version of protoc which is incompatible with your Protocol Buffer headers. Please regenerate this file with a newer version of protoc.?. Turns out the source and headers generated by way of FindProtobuf.cmake:PROTOBUF_GENERATE_CPP aren't updated. Adding a dependency on the compiler executable fixes this issue. Proposed patch: $ diff -u FindProtobuf.cmake.orig FindProtobuf.cmake --- FindProtobuf.cmake.orig 2014-09-17 06:11:10.282377650 +0200 +++ FindProtobuf.cmake 2014-09-17 06:11:10.282377650 +0200 @@ -118,7 +118,7 @@ "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.h" COMMAND ${PROTOBUF_PROTOC_EXECUTABLE} ARGS --cpp_out ${CMAKE_CURRENT_BINARY_DIR} ${_protobuf_include_path} ${ABS_FIL} - DEPENDS ${ABS_FIL} + DEPENDS ${ABS_FIL} ${PROTOBUF_PROTOC_EXECUTABLE} COMMENT "Running C++ protocol buffer compiler on ${FIL}" VERBATIM ) endforeach() Steps to Reproduce: 1. Install Protocol Buffers 2.5.0 2. Generate source and header using 2.5.0's protoc binary 3. Install Protocol Buffers 2.6.0 4. Re-build source Additional Information: Workaround in case someone's affected by this and can't modify FindProtobuf.cmake in their environment: foreach(i ${PROTO_SRCS} ${PROTO_HDRS}) add_custom_command(OUTPUT ${i} DEPENDS ${PROTOBUF_PROTOC_EXECUTABLE} APPEND) endforeach() ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-17 00:20 hansmi New Issue ====================================================================== From helsing72 at gmail.com Wed Sep 17 02:42:27 2014 From: helsing72 at gmail.com (Mattias Helsing) Date: Wed, 17 Sep 2014 08:42:27 +0200 Subject: [cmake-developers] Suggest to not add libosgUI-NOTFOUND to OSG_INCLUDE_DIR if it wasn't required Message-ID: Hi all, I'm building against OpenScenGraph-3.0.1 AND OpenSceneGraph-3.3.3. While the latter have osgUI the former does not. My cmake scripts for the 3.0.1 build fail because the OPENSCENEGRAPH_INCLUDE_DIR gets populated with OSGUI_INCLUDE_DIR-NOTFOUND. I can solve this with for loops (remove all item containing NOTFOUND) but it's awkward. If I'm not requiring osgUI it shouldn't break my build. cheers Mattias -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Don-t-add-unfound-OSG-libs-if-they-weren-t-required.patch Type: text/x-patch Size: 1232 bytes Desc: not available URL: From ono at java.pl Wed Sep 17 07:54:29 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 17 Sep 2014 13:54:29 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison Message-ID: <1410954869-25450-1-git-send-email-ono@java.pl> This silents possible CMP0054 related warnings. --- Modules/FindCUDA.cmake | 14 +++++++------- Modules/FindCUDA/run_nvcc.cmake | 2 +- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake index 9348aa5..2e2b21c 100644 --- a/Modules/FindCUDA.cmake +++ b/Modules/FindCUDA.cmake @@ -894,15 +894,15 @@ macro(CUDA_GET_SOURCES_AND_OPTIONS _sources _cmake_options _options) set( ${_options} ) set( _found_options FALSE ) foreach(arg ${ARGN}) - if(arg STREQUAL "OPTIONS") + if("x${arg}" STREQUAL "xOPTIONS") set( _found_options TRUE ) elseif( - arg STREQUAL "WIN32" OR - arg STREQUAL "MACOSX_BUNDLE" OR - arg STREQUAL "EXCLUDE_FROM_ALL" OR - arg STREQUAL "STATIC" OR - arg STREQUAL "SHARED" OR - arg STREQUAL "MODULE" + "x${arg}" STREQUAL "xWIN32" OR + "x${arg}" STREQUAL "xMACOSX_BUNDLE" OR + "x${arg}" STREQUAL "xEXCLUDE_FROM_ALL" OR + "x${arg}" STREQUAL "xSTATIC" OR + "x${arg}" STREQUAL "xSHARED" OR + "x${arg}" STREQUAL "xMODULE" ) list(APPEND ${_cmake_options} ${arg}) else() diff --git a/Modules/FindCUDA/run_nvcc.cmake b/Modules/FindCUDA/run_nvcc.cmake index 58e0d31..abdd307 100644 --- a/Modules/FindCUDA/run_nvcc.cmake +++ b/Modules/FindCUDA/run_nvcc.cmake @@ -126,7 +126,7 @@ endif() # and other return variables are present after executing the process. macro(cuda_execute_process status command) set(_command ${command}) - if(NOT _command STREQUAL "COMMAND") + if(NOT "x${_command}" STREQUAL "xCOMMAND") message(FATAL_ERROR "Malformed call to cuda_execute_process. Missing COMMAND as second argument. (command = ${command})") endif() if(verbose) -- 1.9.3 (Apple Git-50) From eike at sf-mail.de Wed Sep 17 08:37:30 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 17 Sep 2014 14:37:30 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <1410954869-25450-1-git-send-email-ono@java.pl> References: <1410954869-25450-1-git-send-email-ono@java.pl> Message-ID: <7bb8ed244092eac42595b61f9686d874@sf-mail.de> Am 17.09.2014 13:54, schrieb Adam Strzelecki: > This silents possible CMP0054 related warnings. > --- > Modules/FindCUDA.cmake | 14 +++++++------- > Modules/FindCUDA/run_nvcc.cmake | 2 +- > 2 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake > index 9348aa5..2e2b21c 100644 > --- a/Modules/FindCUDA.cmake > +++ b/Modules/FindCUDA.cmake > @@ -894,15 +894,15 @@ macro(CUDA_GET_SOURCES_AND_OPTIONS _sources > _cmake_options _options) > set( ${_options} ) > set( _found_options FALSE ) > foreach(arg ${ARGN}) > - if(arg STREQUAL "OPTIONS") > + if("x${arg}" STREQUAL "xOPTIONS") [...] Wait, what? This is actually the opposite of what that policy is for, no? Adam, I don't blame you, just to get that said first. The question is: does this policy warning trigger far too often? What one actually wants is to write if(arg STREQUAL "OPTIONS") i.e. arg will get expanded, "OPTIONS" not. Changing everything away from that pattern will in fact make things worse, and will not help you if I introduce an xOPTION variable now. So, is this warning too noisy or are we doing something fundamentally wrong? Eike From nilsgladitz at gmail.com Wed Sep 17 08:48:19 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 17 Sep 2014 14:48:19 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <7bb8ed244092eac42595b61f9686d874@sf-mail.de> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> Message-ID: <54198313.5000001@gmail.com> On 09/17/2014 02:37 PM, Rolf Eike Beer wrote: > What one actually wants is to write > > if(arg STREQUAL "OPTIONS") > > i.e. arg will get expanded, "OPTIONS" not. Changing everything away from > that pattern will in fact make things worse, and will not help you if I > introduce an xOPTION variable now. So, is this warning too noisy or are > we doing something fundamentally wrong? One obvious case where it probably warns is if(arg STREQUAL "WIN32") Because WIN32 is also a variable with the value "1" on windows this check probably didn't actually do what it was intended to do with the old behavior. Maybe modules loaded from the cmake installation itself should implicitly have their policy version set to the current cmake version? Nils From robert.maynard at kitware.com Wed Sep 17 08:58:37 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 17 Sep 2014 08:58:37 -0400 Subject: [cmake-developers] Nice DMG layout for CMake OSX builds In-Reply-To: References: Message-ID: This looks amazing, thanks for the work. On Tue, Sep 16, 2014 at 7:10 PM, Adam Strzelecki wrote: > Hi, > > I've made simple background: > > https://dl.dropboxusercontent.com/u/64748870/CMakeDMGBackground.tif > > And together with my shell script for creating dmg with custom layout at: > > https://gist.github.com/nanoant/89237ad368d333795fc0 > > I have created installer that looks like that: > > > So feel free to take & modify script above and TIFF file. > > Cheers, > -- > Adam > > > > -- > > 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: Test 4.png Type: image/png Size: 45986 bytes Desc: not available URL: From ono at java.pl Wed Sep 17 09:24:46 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 17 Sep 2014 15:24:46 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <7bb8ed244092eac42595b61f9686d874@sf-mail.de> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> Message-ID: > Wait, what? This is actually the opposite of what that policy is for, no? Adam, I don't blame you, just to get that said first. The question is: does this policy warning trigger far too often? Yes, you are absolutely right. But the problem is that internal modules run in whatever policy is currently set. Few of them conditionally change policy for some short scopes. I was more less following how Brad has been fixing this issues on other modules, i.e.: e177e7affb10fc25b71d4c9d9796c9df7fcdb800 Honestly I would expect that all internal modules run in latest policy by default, or at least declare their policy in file header, but this is not a case. --Adam From ono at java.pl Wed Sep 17 09:27:18 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 17 Sep 2014 15:27:18 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <54198313.5000001@gmail.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> <54198313.5000001@gmail.com> Message-ID: <09A01904-0B0C-460B-87E7-23339ED9CE28@java.pl> > Maybe modules loaded from the cmake installation itself should implicitly have their policy version set to the current cmake version? Yes, this is what I was going to suggest too. All cmake files inside CMake's own Modules should have implicit latest policy. Although I'd recommend to have some (maybe hidden option) to override this implicit policy to some other value, so we can really check if existing modules don't raise any warnings. --Adam From ono at java.pl Wed Sep 17 09:58:49 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 17 Sep 2014 15:58:49 +0200 Subject: [cmake-developers] Nice DMG layout for CMake OSX builds In-Reply-To: References: Message-ID: > This looks amazing, thanks for the work. FYI I have updated TIF with sharper textual logo image taken from new website and bigger shorter and pixel aligned arrow so its shape does not overlay icon focus (once it is selected). The updated TIF file is at: https://dl.dropboxusercontent.com/u/64748870/CMakeDMGBackground.tif Source SVG file at: https://dl.dropboxusercontent.com/u/64748870/CMakeDMGBackground.svg Regards, --Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Test.png Type: image/png Size: 47000 bytes Desc: not available URL: From nilsgladitz at gmail.com Wed Sep 17 14:25:17 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 17 Sep 2014 20:25:17 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <54198313.5000001@gmail.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> <54198313.5000001@gmail.com> Message-ID: <5419D20D.9080108@gmail.com> On 17.09.2014 14:48, Nils Gladitz wrote: > > Maybe modules loaded from the cmake installation itself should > implicitly have their policy version set to the current cmake version? > I pushed "root-modules-set-policies-new" to stage which sets all policies to NEW for modules from cmake's own Modules directory if NO_POLICY_SCOPE is not used. I haven't merged it to next yet in case someone things this is the wrong thing to do in general. I figured since the new behavior only applies to cmake's own modules it should not require a policy. Nils From clinton at elemtech.com Wed Sep 17 15:29:43 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Wed, 17 Sep 2014 13:29:43 -0600 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: References: <1409917844-28297-3-git-send-email-ono@java.pl> <1579949.fFJZQIyjfv@stryke> Message-ID: <5905178.NbCzcQviLF@stryke> On Wednesday, September 17, 2014 01:13:45 AM Adam Strzelecki wrote: > > What is the new optional parameter to gp_file_type() used for? > > My intention was to pass exepath rather than take it from the path of > original_file. But this is in fact not necessary. > > I don't see any code in your branch calling that function with the new > > parameter. > > You are right, I am not using that. So I can drop that change. > > --Adam After that change is dropped, I give a +1 for the patch set. Thanks, Clint From mantis at public.kitware.com Thu Sep 18 00:55:24 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 18 Sep 2014 00:55:24 -0400 Subject: [cmake-developers] [CMake 0015162]: FindGettext.cmake documentation issue Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15162 ====================================================================== Reported By: vollmond Assigned To: ====================================================================== Project: CMake Issue ID: 15162 Category: CMake Reproducibility: always Severity: trivial Priority: low Status: new ====================================================================== Date Submitted: 2014-09-18 00:55 EDT Last Modified: 2014-09-18 00:55 EDT ====================================================================== Summary: FindGettext.cmake documentation issue Description: GETTEXT_PROCESS_POT => GETTEXT_PROCESS_POT_FILE ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-18 00:55 vollmond New Issue 2014-09-18 00:55 vollmond File Added: FindGettext.cmake.patch ====================================================================== From ono at java.pl Thu Sep 18 04:21:05 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 18 Sep 2014 10:21:05 +0200 Subject: [cmake-developers] [PATCH 3/5] Resolve & replace @rpath placeholders In-Reply-To: <1410900215-99370-3-git-send-email-ono@java.pl> References: <1410900215-99370-3-git-send-email-ono@java.pl> Message-ID: <1411028467-47190-3-git-send-email-ono@java.pl> This is done by gathering LC_RPATH commands for main bundle executable and using it for @rpath lookup in dependent frameworks. All functions that need to carry rpaths to now take optional argument. This enabled apps using @rpath to be bundled correctly, which will be necessary for upcoming Qt 5.4 that will use @rpath for all frameworks. --- Modules/BundleUtilities.cmake | 93 ++++++++++++++++++++++++++++++++++-------- Modules/GetPrerequisites.cmake | 23 +++++++---- 2 files changed, 90 insertions(+), 26 deletions(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 7e2b173..cc27310 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -19,6 +19,7 @@ # get_bundle_and_executable # get_bundle_all_executables # get_item_key +# get_item_rpaths # clear_bundle_keys # set_bundle_key_values # get_bundle_keys @@ -124,7 +125,7 @@ # :: # # SET_BUNDLE_KEY_VALUES( -# ) +# []) # # Add a key to the list (if necessary) for the given item. If added, # also set all the variables associated with that key. @@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var) endfunction() +function(get_item_rpaths item rpaths_var) + if(APPLE) + find_program(otool_cmd "otool") + mark_as_advanced(otool_cmd) + endif() + + if(otool_cmd) + execute_process( + COMMAND "${otool_cmd}" -l "${item}" + OUTPUT_VARIABLE load_cmds_ov + ) + string(REGEX REPLACE "[^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+) \\(offset[^\n]+\n" "rpath \\1\n" load_cmds_ov "${load_cmds_ov}") + string(REGEX MATCHALL "rpath [^\n]+" load_cmds_ov "${load_cmds_ov}") + string(REGEX REPLACE "rpath " "" load_cmds_ov "${load_cmds_ov}") + if(load_cmds_ov) + gp_append_unique(${rpaths_var} "${load_cmds_ov}") + endif() + endif() + + set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE) +endfunction() + + function(get_item_key item key_var) get_filename_component(item_name "${item}" NAME) if(WIN32) @@ -425,12 +449,14 @@ function(clear_bundle_keys keys_var) set(${key}_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE) set(${key}_COPYFLAG PARENT_SCOPE) + set(${key}_RPATHS PARENT_SCOPE) endforeach() set(${keys_var} PARENT_SCOPE) endfunction() function(set_bundle_key_values keys_var context item exepath dirs copyflag) + set(rpaths "${ARGV6}") get_filename_component(item_name "${item}" NAME) get_item_key("${item}" key) @@ -440,10 +466,12 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) list(LENGTH ${keys_var} length_after) if(NOT length_before EQUAL length_after) - gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${context}" "${item}" "${exepath}" "${dirs}" resolved_item "${rpaths}") gp_item_default_embedded_path("${item}" default_embedded_path) + get_item_rpaths("${resolved_item}" item_rpaths) + if(item MATCHES "[^/]+\\.framework/") # For frameworks, construct the name under the embedded path from the # opening "${item_name}.framework/" to the closing "/${item_name}": @@ -479,6 +507,8 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) set(${key}_EMBEDDED_ITEM "${embedded_item}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${resolved_embedded_item}" PARENT_SCOPE) set(${key}_COPYFLAG "${copyflag}" PARENT_SCOPE) + set(${key}_RPATHS "${item_rpaths}" PARENT_SCOPE) + set(${key}_RDEP_RPATHS "${rpaths}" PARENT_SCOPE) else() #message("warning: item key '${key}' already in the list, subsequent references assumed identical to first") endif() @@ -499,18 +529,27 @@ function(get_bundle_keys app libs dirs keys_var) # get_bundle_all_executables("${bundle}" exes) + # Set keys for main executable first: + # + set_bundle_key_values(${keys_var} "${executable}" "${executable}" "${exepath}" "${dirs}" 0) + + # Get rpaths specified by main executable: + # + get_item_key("${executable}" executable_key) + set(main_rpaths "${${executable_key}_RPATHS}") + # For each extra lib, accumulate a key as well and then also accumulate # any of its prerequisites. (Extra libs are typically dynamically loaded # plugins: libraries that are prerequisites for full runtime functionality # but that do not show up in otool -L output...) # foreach(lib ${libs}) - set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0) + set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0 "${main_rpaths}") set(prereqs "") - get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}" "${main_rpaths}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${lib}" "${pr}" "${exepath}" "${dirs}" 1 "${main_rpaths}") endforeach() endforeach() @@ -519,16 +558,27 @@ function(get_bundle_keys app libs dirs keys_var) # binaries in the bundle have been analyzed. # foreach(exe ${exes}) - # Add the exe itself to the keys: + # Main executable is scanned first above: # - set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0) + if(NOT "${exe}" STREQUAL "${executable}") + # Add the exe itself to the keys: + # + set_bundle_key_values(${keys_var} "${exe}" "${exe}" "${exepath}" "${dirs}" 0 "${main_rpaths}") + + # Get rpaths specified by executable: + # + get_item_key("${exe}" exe_key) + set(exe_rpaths "${main_rpaths}" "${${exe_key}_RPATHS}") + else() + set(exe_rpaths "${main_rpaths}") + endif() # Add each prerequisite to the keys: # set(prereqs "") - get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}") + get_prerequisites("${exe}" prereqs 1 1 "${exepath}" "${dirs}" "${exe_rpaths}") foreach(pr ${prereqs}) - set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1) + set_bundle_key_values(${keys_var} "${exe}" "${pr}" "${exepath}" "${dirs}" 1 "${exe_rpaths}") endforeach() endforeach() @@ -542,6 +592,8 @@ function(get_bundle_keys app libs dirs keys_var) set(${key}_EMBEDDED_ITEM "${${key}_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_RESOLVED_EMBEDDED_ITEM "${${key}_RESOLVED_EMBEDDED_ITEM}" PARENT_SCOPE) set(${key}_COPYFLAG "${${key}_COPYFLAG}" PARENT_SCOPE) + set(${key}_RPATHS "${${key}_RPATHS}" PARENT_SCOPE) + set(${key}_RDEP_RPATHS "${${key}_RDEP_RPATHS}" PARENT_SCOPE) endforeach() endif() endfunction() @@ -647,8 +699,10 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) message(FATAL_ERROR "cannot fixup an item that is not in the bundle...") endif() + set(rpaths "${${ikey}_RPATHS}" "${${ikey}_RDEP_RPATHS}") + set(prereqs "") - get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}") + get_prerequisites("${resolved_embedded_item}" prereqs 1 0 "${exepath}" "${dirs}" "${rpaths}") set(changes "") @@ -668,12 +722,20 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs) execute_process(COMMAND chmod u+w "${resolved_embedded_item}") endif() + foreach(rpath ${${ikey}_RPATHS}) + set(changes ${changes} -delete_rpath "${rpath}") + endforeach() + + if(${ikey}_EMBEDDED_ITEM) + set(changes ${changes} -id "${${ikey}_EMBEDDED_ITEM}") + endif() + # Change this item's id and all of its references in one call # to install_name_tool: # - execute_process(COMMAND install_name_tool - ${changes} -id "${${ikey}_EMBEDDED_ITEM}" "${resolved_embedded_item}" - ) + if(changes) + execute_process(COMMAND install_name_tool ${changes} "${resolved_embedded_item}") + endif() endfunction() @@ -764,10 +826,8 @@ function(verify_bundle_prerequisites bundle result_var info_var) get_bundle_main_executable("${bundle}" main_bundle_exe) - file(GLOB_RECURSE file_list "${bundle}/*") + get_bundle_all_executables("${bundle}" file_list) foreach(f ${file_list}) - is_file_executable("${f}" is_executable) - if(is_executable) get_filename_component(exepath "${f}" PATH) math(EXPR count "${count} + 1") @@ -806,7 +866,6 @@ function(verify_bundle_prerequisites bundle result_var info_var) set(result 0) set(info ${info} "external prerequisites found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n") endif() - endif() endforeach() if(result) diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 49443e3..9963517 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -41,7 +41,7 @@ # :: # # GET_PREREQUISITES( -# ) +# []) # # Get the list of shared library files required by . The list # in the variable named should be empty on first @@ -113,7 +113,8 @@ # # :: # -# GP_RESOLVE_ITEM( ) +# GP_RESOLVE_ITEM( +# []) # # Resolve an item into an existing full path file. # @@ -122,7 +123,8 @@ # # :: # -# GP_RESOLVED_FILE_TYPE( ) +# GP_RESOLVED_FILE_TYPE( +# []) # # Return the type of with respect to . String # describing type of prerequisite is returned in variable named @@ -321,6 +323,7 @@ endfunction() function(gp_resolve_item context item exepath dirs resolved_item_var) set(resolved 0) set(resolved_item "${item}") + set(rpaths "${ARGV5}") # Is it already resolved? # @@ -375,9 +378,9 @@ function(gp_resolve_item context item exepath dirs resolved_item_var) string(REPLACE "@rpath/" "" norpath_item "${item}") set(ri "ri-NOTFOUND") - find_file(ri "${norpath_item}" ${exepath} ${dirs} NO_DEFAULT_PATH) + find_file(ri "${norpath_item}" ${exepath} ${dirs} ${rpaths} NO_DEFAULT_PATH) if(ri) - #message(STATUS "info: 'find_file' in exepath/dirs (${ri})") + #message(STATUS "info: 'find_file' in exepath/dirs/rpaths (${ri})") set(resolved 1) set(resolved_item "${ri}") set(ri "ri-NOTFOUND") @@ -471,6 +474,7 @@ endfunction() function(gp_resolved_file_type original_file file exepath dirs type_var) + set(rpaths "${ARGV5}") #message(STATUS "**") if(NOT IS_ABSOLUTE "${original_file}") @@ -489,7 +493,7 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) if(NOT is_embedded) if(NOT IS_ABSOLUTE "${file}") - gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file) + gp_resolve_item("${original_file}" "${file}" "${exepath}" "${dirs}" resolved_file "${rpaths}") endif() string(TOLOWER "${original_file}" original_lower) @@ -612,6 +616,7 @@ endfunction() function(get_prerequisites target prerequisites_var exclude_system recurse exepath dirs) set(verbose 0) set(eol_char "E") + set(rpaths "${ARGV6}") if(NOT IS_ABSOLUTE "${target}") message("warning: target '${target}' is not absolute...") @@ -834,7 +839,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(add_item AND ${exclude_system}) set(type "") - gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type) + gp_resolved_file_type("${target}" "${item}" "${exepath}" "${dirs}" type "${rpaths}") if("${type}" STREQUAL "system") set(add_item 0) @@ -855,7 +860,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa # that the analysis tools can simply accept it as input. # if(NOT list_length_before_append EQUAL list_length_after_append) - gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item) + gp_resolve_item("${target}" "${item}" "${exepath}" "${dirs}" resolved_item "${rpaths}") set(unseen_prereqs ${unseen_prereqs} "${resolved_item}") endif() endif() @@ -874,7 +879,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(${recurse}) set(more_inputs ${unseen_prereqs}) foreach(input ${more_inputs}) - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}") + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}" "${rpaths}") endforeach() endif() -- 1.9.3 (Apple Git-50) From ono at java.pl Thu Sep 18 04:22:05 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 18 Sep 2014 10:22:05 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: <5905178.NbCzcQviLF@stryke> References: <1409917844-28297-3-git-send-email-ono@java.pl> <1579949.fFJZQIyjfv@stryke> <5905178.NbCzcQviLF@stryke> Message-ID: > After that change is dropped, I give a +1 for the patch set. Done, both in attached 3/5 patch and GitHub branch of mine. --Adam From brad.king at kitware.com Thu Sep 18 09:13:36 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 18 Sep 2014 09:13:36 -0400 Subject: [cmake-developers] Suggest to not add libosgUI-NOTFOUND to OSG_INCLUDE_DIR if it wasn't required In-Reply-To: References: Message-ID: <541ADA80.203@kitware.com> On 09/17/2014 02:42 AM, Mattias Helsing wrote: > If I'm not requiring osgUI it shouldn't break my build. Applied, thanks: FindOpenSceneGraph: Do not add unfound OSG libs if not required http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b683da3e -Brad From brad.king at kitware.com Thu Sep 18 10:05:39 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 18 Sep 2014 10:05:39 -0400 Subject: [cmake-developers] policies in CMake builtin modules (was: FindCUDA: Wrap keyword in if() string comparison) In-Reply-To: <5419D20D.9080108@gmail.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> <54198313.5000001@gmail.com> <5419D20D.9080108@gmail.com> Message-ID: <541AE6B3.1030208@kitware.com> On 09/17/2014 02:25 PM, Nils Gladitz wrote: > I pushed "root-modules-set-policies-new" to stage which sets all > policies to NEW for modules from cmake's own Modules directory if > NO_POLICY_SCOPE is not used. A minor comment on the impl: use cmSystemTools::GetCMakeRoot instead of looking up CMAKE_ROOT. However, I do not think this approach will work well in general. We do not have extensive testing covering all functionality of the builtin modules. We do not actually know that all the modules will work with every policy set to NEW right away. Typically authors of projects that use the modules will report bugs if things break when the projects set policies to NEW. Meanwhile at least existing projects keep building with the OLD policy behavior. Modules on an individual basis could use cmake_policy(PUSH/POP) and cmake_policy(SET) to get NEW behavior for specific policies that they trigger. -Brad From nilsgladitz at gmail.com Thu Sep 18 10:20:41 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 18 Sep 2014 16:20:41 +0200 Subject: [cmake-developers] policies in CMake builtin modules In-Reply-To: <541AE6B3.1030208@kitware.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> <54198313.5000001@gmail.com> <5419D20D.9080108@gmail.com> <541AE6B3.1030208@kitware.com> Message-ID: <541AEA39.6060706@gmail.com> On 09/18/2014 04:05 PM, Brad King wrote: > On 09/17/2014 02:25 PM, Nils Gladitz wrote: >> I pushed "root-modules-set-policies-new" to stage which sets all >> policies to NEW for modules from cmake's own Modules directory if >> NO_POLICY_SCOPE is not used. > > A minor comment on the impl: use cmSystemTools::GetCMakeRoot > instead of looking up CMAKE_ROOT. Thanks, I'll try to remember that for next time. I copied the use of CMAKE_ROOT from cmMakefile::GetModulesFile(). > However, I do not think this approach will work well in general. > We do not have extensive testing covering all functionality of > the builtin modules. We do not actually know that all the > modules will work with every policy set to NEW right away. > Typically authors of projects that use the modules will report > bugs if things break when the projects set policies to NEW. > Meanwhile at least existing projects keep building with the > OLD policy behavior. OK, thanks. I unstaged the topic. Nils From mantis at public.kitware.com Thu Sep 18 11:44:10 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 18 Sep 2014 11:44:10 -0400 Subject: [cmake-developers] [CMake 0015163]: wrong permissions on base files with nonstandard umask setting Message-ID: <0a15351488bf785a61d91e75296dcc57@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15163 ====================================================================== Reported By: Ilya Rusyanov Assigned To: ====================================================================== Project: CMake Issue ID: 15163 Category: (No Category) Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-18 11:44 EDT Last Modified: 2014-09-18 11:44 EDT ====================================================================== Summary: wrong permissions on base files with nonstandard umask setting Description: If umask is different from 022, CPack will generate wrong permission on base directories. Steps to Reproduce: umask 027 cmake ../src make cpack -G DEB dpkg -c test.deb drwxr-x--- root/root 0 2014-09-18 19:40 ./usr/ drwxr-x--- root/root 0 2014-09-18 19:40 ./usr/share/ drwxr-x--- root/root 0 2014-09-18 19:40 ./usr/share/testproj/ drwxr-x--- root/root 0 2014-09-18 19:40 ./usr/share/testproj/data/ drwxr-xr-x root/root 0 2014-09-18 19:40 ./usr/share/testproj/data/180-188-189/ -rw-r--r-- root/root 16 2014-09-18 15:22 ./usr/share/testproj/data/180-188-189/general.ini Additional Information: Please notice directory permissions on /usr, /usr/share, /usr/share/testproj, /usr/share/testproj/data. Everything is fine with supplied inner directories and files. INSTALL command is not given any PERMISSIONS options, and, as documentation says they should be default: 755 for directories and 644 for regular files. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-18 11:44 Ilya Rusyanov New Issue ====================================================================== From pascal.bach at siemens.com Thu Sep 18 12:03:50 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Thu, 18 Sep 2014 18:03:50 +0200 Subject: [cmake-developers] [PATCH] WINCE: Add toolchain documentation for Windows CE Message-ID: <1411056230-30313-1-git-send-email-pascal.bach@siemens.com> --- Help/manual/cmake-toolchains.7.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/Help/manual/cmake-toolchains.7.rst b/Help/manual/cmake-toolchains.7.rst index f36a43c..095a43f 100644 --- a/Help/manual/cmake-toolchains.7.rst +++ b/Help/manual/cmake-toolchains.7.rst @@ -174,5 +174,25 @@ toolchain which will be used by the compiler driver. The :variable:`CMAKE__COMPILER_EXTERNAL_TOOLCHAIN` variable can be set in a toolchain file to pass the path to the compiler driver. +Cross compiling for Windows CE requires the corresponding SDK being installed on +your system. These SDKs are usually installed under: `C:\\Program Files (x86)\\Windows CE Tools\\SDKs` + +The :variable:`CMAKE_GENERATOR_PLATFORM` tells the generator which SDK to use. +Further :variable:`CMAKE_SYSTEM_VERSION` tells the generator what version of Windows CE to use. +Currently version 8.0 (Windows Embedded Compact 2013) is supported out of the box. Other versions +my require to set :variable:`CMAKE_GENERATOR_TOOLSET` to the correct value. + +A toolchain file for Windows CE may look like this: + +.. code-block:: cmake + + set(CMAKE_SYSTEM_NAME "WindowsCE") + + set(CMAKE_SYSTEM_VERSION "8.0") + set(CMAKE_SYSTEM_PROCESSOR "arm" ) + + set(CMAKE_GENERATOR_TOOLSET "CE800") # Can be omitted for 8.0 + set(CMAKE_GENERATOR_PLATFORM "SDK_AM335X_SK_WEC2013_V310") + The :variable:`CMAKE_CROSSCOMPILING` variable is set to true when CMake is cross-compiling. -- 1.7.10.4 From ono at java.pl Thu Sep 18 12:15:51 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 18 Sep 2014 18:15:51 +0200 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: References: <1409917844-28297-3-git-send-email-ono@java.pl> <1579949.fFJZQIyjfv@stryke> <5905178.NbCzcQviLF@stryke> Message-ID: FYI I pushed stage/fix-OSX-bundle-rpaths-and-Qt5 topic for final review. Regards, -- Adam From ono at java.pl Thu Sep 18 13:00:52 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 18 Sep 2014 19:00:52 +0200 Subject: [cmake-developers] policies in CMake builtin modules In-Reply-To: <541AEA39.6060706@gmail.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> <54198313.5000001@gmail.com> <5419D20D.9080108@gmail.com> <541AE6B3.1030208@kitware.com> <541AEA39.6060706@gmail.com> Message-ID: <946430CD-55F6-4F15-85EE-7E2991233957@java.pl> If I understand correctly all modules included via include/find_package have implicit POLICY PUSH and POP at the EOF. Wouldn't it be reasonable to require all internal .cmake files to begin with: cmake_policy(VERSION 3.1) # or whatever version the module was tested against Then before next release all of these should be checked against new policies and upgraded to: cmake_policy(VERSION 3.2) # next release version Then we can safely drop all these fancy if("x${var}" STREQUAL "xVALUE") in favor of if(var STREQUAL "VALUE") and improve scripts readability, rather that do PUSHes and POPs in various places. Of course I am aware that such task needs lot of work, however I think this should be consequence of introducing CMP0054. --Adam From clinton at elemtech.com Thu Sep 18 13:01:53 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Thu, 18 Sep 2014 11:01:53 -0600 Subject: [cmake-developers] [PATCH 3/6] Resolve & replace @rpath placeholders In-Reply-To: References: <1409917844-28297-3-git-send-email-ono@java.pl> Message-ID: <2024754.uYdjdX8BQq@stryke> On Thursday, September 18, 2014 06:15:51 PM Adam Strzelecki wrote: > FYI I pushed stage/fix-OSX-bundle-rpaths-and-Qt5 topic for final review. > > Regards, Does the functionality you add allow us to modify CMake/Tests/BundleUtilities/CMakeLists.txt such that the last part in the tests where @rpath is used can be changed to separate the binaries into bin/ and lib/ directories instead of everything in one directory. I assume so since you added the the ability to extract rpaths from a binary. Then eventually, someone can add the same capability for Linux. I'm hoping the parameter you added to functions in GetPrerequisite.cmake is not OS X specific (at the moment, it appears so). Thanks, - Clint From brad.king at kitware.com Thu Sep 18 13:39:30 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 18 Sep 2014 13:39:30 -0400 Subject: [cmake-developers] policies in CMake builtin modules In-Reply-To: <946430CD-55F6-4F15-85EE-7E2991233957@java.pl> References: <1410954869-25450-1-git-send-email-ono@java.pl> <7bb8ed244092eac42595b61f9686d874@sf-mail.de> <54198313.5000001@gmail.com> <5419D20D.9080108@gmail.com> <541AE6B3.1030208@kitware.com> <541AEA39.6060706@gmail.com> <946430CD-55F6-4F15-85EE-7E2991233957@java.pl> Message-ID: <541B18D2.6020106@kitware.com> On 09/18/2014 01:00 PM, Adam Strzelecki wrote: > If I understand correctly all modules included via > include/find_package have implicit POLICY PUSH and POP Yes. > at the EOF. Wouldn't it be reasonable to require all > internal .cmake files to begin with: > > cmake_policy(VERSION 3.1) # or whatever version the module was tested against > > Then before next release all of these should be checked > against new policies and upgraded to: > > cmake_policy(VERSION 3.2) # next release version Like Nils' proposal, this will not be reliable without full coverage of module functionality in the test suite (which is very hard to do because every find module depends on another external package). It could be done manually on a per-module basis. > Then we can safely drop all these fancy > if("x${var}" STREQUAL "xVALUE") in favor of if(var STREQUAL "VALUE") This can be done with just cmake_policy(SET CMP0054 NEW) at the top of any module that has been ported accordingly. Most policies do not affect CMake syntax, but several have come before this one and there are very few modules that make any explicit mention of cmake_policy. In most cases the module code can be written to work with any policy settings. On 09/17/2014 08:37 AM, Rolf Eike Beer wrote: > Wait, what? This is actually the opposite of what that policy is for, This is true, but will only affect modules that come with CMake that must work regardless of the cmake_minimum_required(VERSION) used in the project. Once a release of CMake contains this policy, project code can require that version of CMake when it is ready and then use the nicer if() tests. -Brad From brad.king at kitware.com Thu Sep 18 13:43:03 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 18 Sep 2014 13:43:03 -0400 Subject: [cmake-developers] [PATCH] WINCE: Add toolchain documentation for Windows CE In-Reply-To: <1411056230-30313-1-git-send-email-pascal.bach@siemens.com> References: <1411056230-30313-1-git-send-email-pascal.bach@siemens.com> Message-ID: <541B19A7.4000903@kitware.com> On 09/18/2014 12:03 PM, Pascal Bach wrote: > diff --git a/Help/manual/cmake-toolchains.7.rst b/Help/manual/cmake-toolchains.7.rst > index f36a43c..095a43f 100644 > --- a/Help/manual/cmake-toolchains.7.rst > +++ b/Help/manual/cmake-toolchains.7.rst > @@ -174,5 +174,25 @@ toolchain which will be used by the compiler driver. The > :variable:`CMAKE__COMPILER_EXTERNAL_TOOLCHAIN` variable can be set in a > toolchain file to pass the path to the compiler driver. > > +Cross compiling for Windows CE requires the corresponding SDK being installed on > +your system. These SDKs are usually installed under: `C:\\Program Files (x86)\\Windows CE Tools\\SDKs` Over time the "Cross Compiling" section of this manual will gain information about various target platforms. We should add a subsection header for each platform, e.g. Cross Compiling to Windows CE ----------------------------- If you don't mind, please precede this patch with a change that adds such subsection headers for the Clang and QCC cases. Thanks, -Brad From aleixpol at kde.org Thu Sep 18 20:10:12 2014 From: aleixpol at kde.org (Aleix Pol) Date: Fri, 19 Sep 2014 02:10:12 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <540DA65F.4030501@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> Message-ID: On Mon, Sep 8, 2014 at 2:51 PM, Brad King wrote: > On 09/03/2014 12:12 PM, Aleix Pol wrote: > > On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf wrote: > >> I still don't understand why this shouldn't be an additional > ExtraGenerator. > > > > Because it's not possible to change the generator of a build directory > > once it's set up. You need to nuke it and re-create it. > [snip] > On 09/01/2014 07:27 PM, Aleix Pol wrote: > > Ok, how does it sound if we have a variable, such as > CMAKE_EXPORT_COMPILE_COMMANDS? > > Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. > > A control variable like that sounds good to me. The purpose looks very > similar to CMAKE_EXPORT_COMPILE_COMMANDS, but is distinct enough to have > its own control. > > 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 > I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to enable the generation of the file. I also renamed the file to ProjectTargets.json. http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch Does it look better like this? Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Fri Sep 19 01:10:45 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 19 Sep 2014 01:10:45 -0400 Subject: [cmake-developers] [CMake 0015164]: Relative Value for CMAKE_TOOLCHAIN_FILE Does Not Work Under PowerShell Message-ID: <37c7863d68618e89e514aa9df1f45546@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15164 ====================================================================== Reported By: Janne R?nkk? Assigned To: ====================================================================== Project: CMake Issue ID: 15164 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-19 01:10 EDT Last Modified: 2014-09-19 01:10 EDT ====================================================================== Summary: Relative Value for CMAKE_TOOLCHAIN_FILE Does Not Work Under PowerShell Description: The toolchain file is not handled properly under PowerShell if the toolchain file path is relative. The issues (I have noticed so far): - CMAKE_SYSTEM_NAME is not set properly - There is warnings about include with empty file name (this seems to be the reason that at least CMAKE_SYSTEM_NAME is not set correctly) The issue is present at least in versions 3.0.0-3.0.2 (these are the version I tested). Steps to Reproduce: In PowerShell: unzip project.zip cd project mkdir build cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake -G Ninja .. Additional Information: On PowerShell with relative path: ================================= PS C:\Users\janne\project\build> cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake -G Ninja .. CMake Warning (dev) at build/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include): include() given empty file name (ignored). Call Stack (most recent call first): CMakeLists.txt:3 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- The C compiler identification is GNU 4.7.3 -- The CXX compiler identification is GNU 4.7.3 -- Check for working C compiler using: Ninja CMake Warning (dev) at C:/Users/janne/project/build/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include): include() given empty file name (ignored). Call Stack (most recent call first): CMakeLists.txt:2 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info CMake Warning (dev) at C:/Users/janne/project/build/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include): include() given empty file name (ignored). Call Stack (most recent call first): CMakeLists.txt:2 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Ninja CMake Warning (dev) at C:/Users/janne/project/build/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include): include() given empty file name (ignored). Call Stack (most recent call first): CMakeLists.txt:2 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info CMake Warning (dev) at C:/Users/janne/project/build/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include): include() given empty file name (ignored). Call Stack (most recent call first): CMakeLists.txt:2 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- Detecting CXX compiler ABI info - done CMake system name: Windows -- Configuring done -- Generating done -- Build files have been written to: C:/Users/janne/project/build ## Note the line "CMake system name: Windows" On PowerShell with absolute path: ================================= PS C:\Users\janne\project\build> cmake -DCMAKE_TOOLCHAIN_FILE=C:/users/janne/toolchain.cmake -G Ninja .. -- The C compiler identification is GNU 4.7.3 -- The CXX compiler identification is GNU 4.7.3 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake system name: Linux -- Configuring done -- Generating done -- Build files have been written to: C:/Users/janne/project/build On cmd.exe with relative path: ============================== C:\Users\janne\project\build>cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake -G Ninja .. -- The C compiler identification is GNU 4.7.3 -- The CXX compiler identification is GNU 4.7.3 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake system name: Linux -- Configuring done -- Generating done -- Build files have been written to: C:/Users/janne/project/build On cmd.exe with absolute path: ============================== C:\Users\janne\project\build>cmake -DCMAKE_TOOLCHAIN_FILE=C:/users/janne/toolchain.cmake -G Ninja .. -- The C compiler identification is GNU 4.7.3 -- The CXX compiler identification is GNU 4.7.3 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake system name: Linux -- Configuring done -- Generating done -- Build files have been written to: C:/Users/janne/project/build ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-19 01:10 Janne R?nkk? New Issue 2014-09-19 01:10 Janne R?nkk? File Added: project.zip ====================================================================== From jamesbigler at gmail.com Fri Sep 19 01:30:59 2014 From: jamesbigler at gmail.com (James Bigler) Date: Thu, 18 Sep 2014 23:30:59 -0600 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <1410954869-25450-1-git-send-email-ono@java.pl> References: <1410954869-25450-1-git-send-email-ono@java.pl> Message-ID: Could someone please explain to me why we need to change all the if statements to look super ugly? Expanding "WIN32" to dereference the value is just a recipe for confusion. Honestly I would prefer if there was a policy to never deference variables in if statements and replace the if's with: if ("${arg}" STREQAL "WIN32") This way there isn't any trickery involved with whether "WIN32" is string or a variable. By the way creating a variable that has the same string as arguments to command (see add_executable) is an unfortunate dirtying of the language ("WIN32" is a variable here, but over here it's an argument e.g. string). James On Wed, Sep 17, 2014 at 5:54 AM, Adam Strzelecki wrote: > This silents possible CMP0054 related warnings. > --- > Modules/FindCUDA.cmake | 14 +++++++------- > Modules/FindCUDA/run_nvcc.cmake | 2 +- > 2 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake > index 9348aa5..2e2b21c 100644 > --- a/Modules/FindCUDA.cmake > +++ b/Modules/FindCUDA.cmake > @@ -894,15 +894,15 @@ macro(CUDA_GET_SOURCES_AND_OPTIONS _sources > _cmake_options _options) > set( ${_options} ) > set( _found_options FALSE ) > foreach(arg ${ARGN}) > - if(arg STREQUAL "OPTIONS") > + if("x${arg}" STREQUAL "xOPTIONS") > set( _found_options TRUE ) > elseif( > - arg STREQUAL "WIN32" OR > - arg STREQUAL "MACOSX_BUNDLE" OR > - arg STREQUAL "EXCLUDE_FROM_ALL" OR > - arg STREQUAL "STATIC" OR > - arg STREQUAL "SHARED" OR > - arg STREQUAL "MODULE" > + "x${arg}" STREQUAL "xWIN32" OR > + "x${arg}" STREQUAL "xMACOSX_BUNDLE" OR > + "x${arg}" STREQUAL "xEXCLUDE_FROM_ALL" OR > + "x${arg}" STREQUAL "xSTATIC" OR > + "x${arg}" STREQUAL "xSHARED" OR > + "x${arg}" STREQUAL "xMODULE" > ) > list(APPEND ${_cmake_options} ${arg}) > else() > diff --git a/Modules/FindCUDA/run_nvcc.cmake > b/Modules/FindCUDA/run_nvcc.cmake > index 58e0d31..abdd307 100644 > --- a/Modules/FindCUDA/run_nvcc.cmake > +++ b/Modules/FindCUDA/run_nvcc.cmake > @@ -126,7 +126,7 @@ endif() > # and other return variables are present after executing the process. > macro(cuda_execute_process status command) > set(_command ${command}) > - if(NOT _command STREQUAL "COMMAND") > + if(NOT "x${_command}" STREQUAL "xCOMMAND") > message(FATAL_ERROR "Malformed call to cuda_execute_process. Missing > COMMAND as second argument. (command = ${command})") > endif() > if(verbose) > -- > 1.9.3 (Apple Git-50) > > -- > > 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 nilsgladitz at gmail.com Fri Sep 19 02:31:19 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 19 Sep 2014 08:31:19 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: References: <1410954869-25450-1-git-send-email-ono@java.pl> Message-ID: <541BCDB7.2050004@gmail.com> On 09/19/2014 07:30 AM, James Bigler wrote: > Could someone please explain to me why we need to change all the if > statements to look super ugly? It sounds like you might have missed the follow up within this thread. > Expanding "WIN32" to dereference the value is just a recipe for > confusion. Honestly I would prefer if there was a policy to never > deference variables in if statements and replace the if's with: > > if ("${arg}" STREQAL "WIN32") To recap I did introduce a policy similar to this: http://www.cmake.org/cmake/help/git-master/policy/CMP0054.html This is paradoxically also the reason for the proposed "super ugly" changes. The policy not only changes the behavior when set to NEW it also warns about ambiguities like "WIN32" in an if statement while using the OLD behavior. Since the policy may or may not be active (depending on the user's project) they might be using FindCUDA.cmake with CMP0054 set to NEW or OLD. To get identical (and warning free) behavior irregardless of the current policy setting Adam added the proposed ugliness. Afterwards I proposed setting all policies to NEW for internal CMake modules but Brad argues that since there is no proper coverage for find modules within the test suite this might have unintended consequences. As Brad further stated you could set CMP0054 to NEW explicitly within FindCUDA.cmake (so that the ugliness could be avoided) if you can verify that this does not break the module for existing projects. Nils From malak.jiri at gmail.com Fri Sep 19 02:59:36 2014 From: malak.jiri at gmail.com (Jiri Malak) Date: Fri, 19 Sep 2014 08:59:36 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release Message-ID: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> Hi, I did a several fixes to CMake related to Open Watcom which were accepteed to current development branch a few month ago. Up to now they were not included to official version 3.0 branch. What I must do to be include or I doing something wrong? Regards Jiri From nilsgladitz at gmail.com Fri Sep 19 03:13:32 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 19 Sep 2014 09:13:32 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> References: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> Message-ID: <541BD79C.8010304@gmail.com> On 09/19/2014 08:59 AM, Jiri Malak wrote: > I did a several fixes to CMake related to Open Watcom which were accepteed to current development > branch a few month ago. > Up to now they were not included to official version 3.0 branch. > What I must do to be include or I doing something wrong? The current "master" branch is the basis for a 3.1 release. Only few changes are backported for a 3.0.x release (e.g. regressions). Nils From ono at java.pl Fri Sep 19 06:05:23 2014 From: ono at java.pl (Adam Strzelecki) Date: Fri, 19 Sep 2014 12:05:23 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <541BCDB7.2050004@gmail.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> Message-ID: > Since the policy may or may not be active (depending on the user's project) they might be using FindCUDA.cmake with CMP0054 set to NEW or OLD. To get identical (and warning free) behavior irregardless of the current policy setting Adam added the proposed ugliness. Putting my 2?, we can either/or: (1) put everywhere these super ugly changes, which will make code (even more) obscure (2) put cmake_policy(SET CMP0053 NEW) at the every internal .cmake file that has been reviewed for this policy and use normal (not ugly syntax) Since include/find_package does implicit policy PUSH & POP for file scope this is IMHO much cleaner solution. Of course we would need to rollback couple of existing fixes committed by Brad. WDYT? --Adam From dlrdave at aol.com Fri Sep 19 06:23:49 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 19 Sep 2014 06:23:49 -0400 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> Message-ID: <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> I like the "cmake_policy(SET CMP0053 NEW)" solution, too. We should make a concerted effort to encourage module maintainers to do this before the 3.1 release for as many modules as possible. D From malak.jiri at gmail.com Fri Sep 19 06:40:41 2014 From: malak.jiri at gmail.com (Jiri Malak) Date: Fri, 19 Sep 2014 12:40:41 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release Message-ID: <4c4bfafad4cfbffcd56ee5eeeabf9c4c.squirrel@www.malakovi.cz> > On 09/19/2014 08:59 AM, Jiri Malak wrote: >> I did a several fixes to CMake related to Open Watcom which were accepteed to current development >> branch a few month ago. >> Up to now they were not included to official version 3.0 branch. What I must do to be include or I doing something wrong? > > The current "master" branch is the basis for a 3.1 release. > Only few changes are backported for a 3.0.x release (e.g. regressions). > > Nils > > OK, but it was accepted before v3.0.0 was released. Do you know what rules are applied for selection what will be in new release and what cutoff date for it? Jiri From nilsgladitz at gmail.com Fri Sep 19 06:54:46 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 19 Sep 2014 12:54:46 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: <4c4bfafad4cfbffcd56ee5eeeabf9c4c.squirrel@www.malakovi.cz> References: <4c4bfafad4cfbffcd56ee5eeeabf9c4c.squirrel@www.malakovi.cz> Message-ID: <541C0B76.8050208@gmail.com> On 09/19/2014 12:40 PM, Jiri Malak wrote: > OK, but it was accepted before v3.0.0 was released. > Do you know what rules are applied for selection what will be in new release and what cutoff date > for it? On Feb. 19 2014 Brad announced the cutoff [1]. So everything that was in master before that will likely be in 3.0 while everything that went into master afterwards will likely be in 3.1. Nils [1] http://public.kitware.com/pipermail/cmake-developers/2014-February/009820.html From pascal.bach at siemens.com Fri Sep 19 06:59:59 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Fri, 19 Sep 2014 10:59:59 +0000 Subject: [cmake-developers] [PATCH] WINCE: Add toolchain documentation for Windows CE In-Reply-To: <541B19A7.4000903@kitware.com> References: <1411056230-30313-1-git-send-email-pascal.bach@siemens.com> <541B19A7.4000903@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616AD3862@DEFTHW99EH4MSX.ww902.siemens.net> > If you don't mind, please precede this patch with a change that > adds such subsection headers for the Clang and QCC cases. Bellow you find the updated patch, I rearranged the cross compiling section a bit and added subsections. Pascal >From 01aa7fd739ff6bdaf05f882199e79549a04f7bda Mon Sep 17 00:00:00 2001 From: Pascal Bach Date: Fri, 19 Sep 2014 12:58:02 +0200 Subject: [PATCH] WINCE: Add toolchain documentation for Windows CE --- Help/manual/cmake-toolchains.7.rst | 58 ++++++++++++++++++++++++++++++------ 1 file changed, 49 insertions(+), 9 deletions(-) diff --git a/Help/manual/cmake-toolchains.7.rst b/Help/manual/cmake-toolchains.7.rst index f36a43c..05e05ff 100644 --- a/Help/manual/cmake-toolchains.7.rst +++ b/Help/manual/cmake-toolchains.7.rst @@ -97,12 +97,18 @@ Cross Compiling If :manual:`cmake(1)` is invoked with the command line parameter ``-DCMAKE_TOOLCHAIN_FILE=path/to/file``, the file will be loaded early to set -values for the compilers. A typical cross-compiling toolchain has content such +values for the compilers. + +Cross Compiling for Linux +------------------------- + +A typical cross-compiling toolchain for Linux has content such as: .. code-block:: cmake set(CMAKE_SYSTEM_NAME Linux) + set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_SYSROOT /home/devel/rasp-pi-rootfs) set(CMAKE_STAGING_PREFIX /home/devel/stage) @@ -118,6 +124,9 @@ as: The :variable:`CMAKE_SYSTEM_NAME` is the CMake-identifier of the target platform to build for. +The :variable:`CMAKE_SYSTEM_PROCESSOR` is the CMake-identifier of the target architecture +to build for. + The :variable:`CMAKE_SYSROOT` is optional, and may be specified if a sysroot is available. @@ -139,13 +148,17 @@ target system prefixes, whereas executables which must be run as part of the bui should be found only on the host and not on the target. This is the purpose of the ``CMAKE_FIND_ROOT_PATH_MODE_*`` variables. -Some compilers are inherently cross compilers, such as Clang and the QNX QCC -compiler. The :variable:`CMAKE__COMPILER_TARGET` can be set to pass a +Cross Compiling using Clang +--------------------------- + +Some compilers such as Clang are inherently cross compilers. +The :variable:`CMAKE__COMPILER_TARGET` can be set to pass a value to those supported compilers when compiling: .. code-block:: cmake set(CMAKE_SYSTEM_NAME Linux) + set(CMAKE_SYSTEM_PROCESSOR arm) set(triple arm-linux-gnueabihf) @@ -154,7 +167,18 @@ value to those supported compilers when compiling: set(CMAKE_CXX_COMPILER clang++) set(CMAKE_CXX_COMPILER_TARGET ${triple}) -Or, for QCC: +Similarly, some compilers do not ship their own supplementary utilities +such as linkers, but provide a way to specify the location of the external +toolchain which will be used by the compiler driver. The +:variable:`CMAKE__COMPILER_EXTERNAL_TOOLCHAIN` variable can be set in a +toolchain file to pass the path to the compiler driver. + +Cross Compiling for QNX +----------------------- + +As the Clang compiler the QNX QCC compile is inherently a cross compiler. +And the :variable:`CMAKE__COMPILER_TARGET` can be set to pass a +value to those supported compilers when compiling: .. code-block:: cmake @@ -167,12 +191,28 @@ Or, for QCC: set(CMAKE_CXX_COMPILER QCC) set(CMAKE_CXX_COMPILER_TARGET ${arch}) +Cross Compiling for Windows CE +------------------------------ -Similarly, some compilers do not ship their own supplementary utilities -such as linkers, but provide a way to specify the location of the external -toolchain which will be used by the compiler driver. The -:variable:`CMAKE__COMPILER_EXTERNAL_TOOLCHAIN` variable can be set in a -toolchain file to pass the path to the compiler driver. +Cross compiling for Windows CE requires the corresponding SDK being installed on +your system. These SDKs are usually installed under: `C:\\Program Files (x86)\\Windows CE Tools\\SDKs` + +The :variable:`CMAKE_GENERATOR_PLATFORM` tells the generator which SDK to use. +Further :variable:`CMAKE_SYSTEM_VERSION` tells the generator what version of Windows CE to use. +Currently version 8.0 (Windows Embedded Compact 2013) is supported out of the box. Other versions +my require to set :variable:`CMAKE_GENERATOR_TOOLSET` to the correct value. + +A toolchain file for Windows CE may look like this: + +.. code-block:: cmake + + set(CMAKE_SYSTEM_NAME WindowsCE) + + set(CMAKE_SYSTEM_VERSION 8.0) + set(CMAKE_SYSTEM_PROCESSOR arm) + + set(CMAKE_GENERATOR_TOOLSET CE800) # Can be omitted for 8.0 + set(CMAKE_GENERATOR_PLATFORM SDK_AM335X_SK_WEC2013_V310) The :variable:`CMAKE_CROSSCOMPILING` variable is set to true when CMake is cross-compiling. -- 1.7.10.4 From dlrdave at aol.com Fri Sep 19 07:38:58 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 19 Sep 2014 07:38:58 -0400 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release Message-ID: <8D1A2156EEDFD5C-1B24-7561@webmail-m169.sysops.aol.com> The "rule" is (roughly): after the first release candidate for a given release, no more "new features" for that particular release. Only continuing work to complete new features in rc1 and fixing regressions reported from previous versions should go in subsequent release candidates. Possible exceptions may be made for bug fixes deemed "important" and "broadly applicable and helpful." In the end, it's always a judgment call, and up to the folks preparing the releases to decide what goes in and what has to wait till next time. As Nils said, the only stuff guaranteed to be in a release is whatever is in 'master' already at the time the first release candidate is made. HTH, David C. From malak.jiri at gmail.com Fri Sep 19 07:57:22 2014 From: malak.jiri at gmail.com (Jiri Malak) Date: Fri, 19 Sep 2014 13:57:22 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: <541C0B76.8050208@gmail.com> References: <4c4bfafad4cfbffcd56ee5eeeabf9c4c.squirrel@www.malakovi.cz> <541C0B76.8050208@gmail.com> Message-ID: > On 09/19/2014 12:40 PM, Jiri Malak wrote: >> OK, but it was accepted before v3.0.0 was released. >> Do you know what rules are applied for selection what will be in new release and what cutoff >> date >> for it? > > On Feb. 19 2014 Brad announced the cutoff [1]. > So everything that was in master before that will likely be in 3.0 > while everything that went into master afterwards will likely be in 3.1. > > Nils > > [1] > http://public.kitware.com/pipermail/cmake-developers/2014-February/009820.html > Thanks for info. It is clear, it was too late to be included to 3.0. Do you have any idea when version 3.1 first release candidate is planned? Jiri From nilsgladitz at gmail.com Fri Sep 19 08:14:36 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 19 Sep 2014 14:14:36 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: References: <4c4bfafad4cfbffcd56ee5eeeabf9c4c.squirrel@www.malakovi.cz> <541C0B76.8050208@gmail.com> Message-ID: <541C1E2C.9050103@gmail.com> On 09/19/2014 01:57 PM, Jiri Malak wrote: > Thanks for info. > It is clear, it was too late to be included to 3.0. > > Do you have any idea when version 3.1 first release candidate is planned? Mantis (the issue tracker) currently has 3.1 scheduled for 2014-11-01. For now I'd take it as a non binding rough estimate though. Nils From malak.jiri at gmail.com Fri Sep 19 08:21:28 2014 From: malak.jiri at gmail.com (Jiri Malak) Date: Fri, 19 Sep 2014 14:21:28 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: <541C1E2C.9050103@gmail.com> References: <4c4bfafad4cfbffcd56ee5eeeabf9c4c.squirrel@www.malakovi.cz> <541C0B76.8050208@gmail.com> <541C1E2C.9050103@gmail.com> Message-ID: > On 09/19/2014 01:57 PM, Jiri Malak wrote: >> Thanks for info. >> It is clear, it was too late to be included to 3.0. >> >> Do you have any idea when version 3.1 first release candidate is planned? > > Mantis (the issue tracker) currently has 3.1 scheduled for 2014-11-01. > For now I'd take it as a non binding rough estimate though. > > Nils > Nils, Many Thanks for clarification. Jiri From mantis at public.kitware.com Fri Sep 19 09:12:54 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 19 Sep 2014 09:12:54 -0400 Subject: [cmake-developers] [CMake 0015165]: WiX : Remember the INSTALL_ROOT directory for upgrades Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15165 ====================================================================== Reported By: Richard Ulrich Assigned To: ====================================================================== Project: CMake Issue ID: 15165 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-19 09:12 EDT Last Modified: 2014-09-19 09:12 EDT ====================================================================== Summary: WiX : Remember the INSTALL_ROOT directory for upgrades Description: If a user installs to a custom directory, upon upgrade the directory dialog initializes to the standard location again. It would be nice if it started at the previously used custom location. I think this could help: http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern/ Additional Information: I'm in the process of implementing this in my wxs files. But I think it would be a feature that would make sense for the standard. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-19 09:12 Richard Ulrich New Issue ====================================================================== From hobbes1069 at gmail.com Fri Sep 19 09:19:14 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Fri, 19 Sep 2014 08:19:14 -0500 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> References: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> Message-ID: On Fri, Sep 19, 2014 at 1:59 AM, Jiri Malak wrote: > Hi, > > I did a several fixes to CMake related to Open Watcom which were accepteed > to current development > branch a few month ago. > Up to now they were not included to official version 3.0 branch. > What I must do to be include or I doing something wrong? I'd like to hear others opinions, but what I've done is once one of my patches is accepted, as long as it applies cleanly to the current release (and since all I mess with are modules that's usually the case) then I just email the Fedora package maintainer and he applies it within Fedora. You didn't mention if you were on Linux or Windows but if you're running a Linux distro you could probably do the same. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Sep 19 09:34:28 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 19 Sep 2014 15:34:28 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: References: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> Message-ID: <541C30E4.1010301@gmail.com> On 09/19/2014 03:19 PM, Richard Shaw wrote: > I'd like to hear others opinions, but what I've done is once one of my > patches is accepted, as long as it applies cleanly to the current release > (and since all I mess with are modules that's usually the case) then I just > email the Fedora package maintainer and he applies it within Fedora. > > You didn't mention if you were on Linux or Windows but if you're running a > Linux distro you could probably do the same. I personally rather dislike that distributions introduce behavior changes since it might result in your project not only depending on a specific version of CMake but also a specific variant as introduced by the distribution you are working on. It also results in people submitting issues with vanilla CMake which might be specific to distribution patches (e.g. [1]). Nils [1] http://www.cmake.org/Bug/view.php?id=10692 From hobbes1069 at gmail.com Fri Sep 19 09:40:56 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Fri, 19 Sep 2014 08:40:56 -0500 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: <541C30E4.1010301@gmail.com> References: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> <541C30E4.1010301@gmail.com> Message-ID: On Fri, Sep 19, 2014 at 8:34 AM, Nils Gladitz wrote: > On 09/19/2014 03:19 PM, Richard Shaw wrote: > >> I'd like to hear others opinions, but what I've done is once one of my >> patches is accepted, as long as it applies cleanly to the current release >> (and since all I mess with are modules that's usually the case) then I >> just >> email the Fedora package maintainer and he applies it within Fedora. >> >> I personally rather dislike that distributions introduce behavior changes > since it might result in your project not only depending on a specific > version of CMake but also a specific variant as introduced by the > distribution you are working on. > > It also results in people submitting issues with vanilla CMake which might > be specific to distribution patches (e.g. [1]). I don't disagree in theory, but what do you do if you need the fix? One of the fixes I submitted fixed a problem with cross compiling that I'm not sure I could have easily worked around. I don't want to sit on my hands and wait for 3.1. I guess I could have copied the module into my project module folder and applied it locally, but that seems like a worse workaround than patching at the distro level. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Fri Sep 19 09:41:16 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 19 Sep 2014 15:41:16 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: References: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> Message-ID: Richard Shaw wrote: > On Fri, Sep 19, 2014 at 1:59 AM, Jiri Malak > wrote: > >> I did a several fixes to CMake related to Open Watcom which were >> accepteed >> to current development >> branch a few month ago. >> Up to now they were not included to official version 3.0 branch. >> What I must do to be include or I doing something wrong? > > I'd like to hear others opinions, but what I've done is once one of my > patches is accepted, as long as it applies cleanly to the current > release > (and since all I mess with are modules that's usually the case) then I > just > email the Fedora package maintainer and he applies it within Fedora. > > You didn't mention if you were on Linux or Windows but if you're > running a > Linux distro you could probably do the same. While I'm not too happy with the current situation either I don't think this is a good idea as it creates a hard to verify "zoo" of CMake versions with the same version number, but different behavior. This approach is is good for distro-specific patches, something like "we ship a new Python that the upstream FindPython*.cmake does not find by default" or "we put our headers in a strange location", but I think that doing this for other stuff has the danger of making the Fedora packages some sort of shadow-upstream. Eike From nilsgladitz at gmail.com Fri Sep 19 09:50:13 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 19 Sep 2014 15:50:13 +0200 Subject: [cmake-developers] What is necessary for including fixes from current development branch to official release In-Reply-To: References: <8b382ca73f57f90f39888120cee12b75.squirrel@www.malakovi.cz> <541C30E4.1010301@gmail.com> Message-ID: <541C3495.1030502@gmail.com> On 09/19/2014 03:40 PM, Richard Shaw wrote: > I guess I could have copied the module into my project module folder and > applied it locally, but that seems like a worse workaround than patching at > the distro level. I think I would personally prefer that over changing the package for the whole distro. The project is under your direct control and the modified module will be available with the project on all distributions (or platforms/operating systems) that users might try to build your project e.g. not just the distribution you happen to work on. By modifying the module on the distro level this changes behavior also for projects that did not ask for that change (which might work out in some cases but might just as well break in others). Nils From brad.king at kitware.com Fri Sep 19 10:28:01 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 19 Sep 2014 10:28:01 -0400 Subject: [cmake-developers] vs-nsight-tegra-generator topic In-Reply-To: References: Message-ID: <541C3D71.7080806@kitware.com> On 09/16/2014 06:11 PM, Mourad Boufarguine wrote: > So, today I tried the next branch with the new NSight stuff. Great, thanks for testing it out. > 1> (...)/arm-linux-androideabi/bin/ld.bfd.exe: cannot find -l-lGLESv1_CM This should fix it: VS: Fix Tegra-Android platform linking of libraries by name http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=72612e2e > I noticed these minor differences > > * Java files are declared using JCompile xml tags instead of None tags (using cmake) > * some special files are declared using AndroidBuild xml tags > (AndroidManifest.xml, build.xml, project.properties, proguard.cfg, res\values\strings.xml ...) Interesting. I started with an IDE-generated project file to see what the generator needs to produce. What version of Nsight Tegra are you using? Thanks, -Brad From brad.king at kitware.com Fri Sep 19 13:26:58 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 19 Sep 2014 13:26:58 -0400 Subject: [cmake-developers] [PATCH] WINCE: Add toolchain documentation for Windows CE In-Reply-To: <355BE46A91031048906B695426A8D8E616AD3862@DEFTHW99EH4MSX.ww902.siemens.net> References: <1411056230-30313-1-git-send-email-pascal.bach@siemens.com> <541B19A7.4000903@kitware.com> <355BE46A91031048906B695426A8D8E616AD3862@DEFTHW99EH4MSX.ww902.siemens.net> Message-ID: <541C6762.4030802@kitware.com> On 09/19/2014 06:59 AM, Bach, Pascal wrote: > Bellow you find the updated patch, I rearranged the cross compiling > section a bit and added subsections. Thanks. I split that into two commits with slight edits, and added my own commit to add subsections for Windows Phone and Store: Help: Add Cross Compiling subsections in cmake-toolchains.7 manual http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0d72451a Help: Add Windows CE cross-compiling to cmake-toolchains.7 manual http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=db54d872 Help: Add Windows Phone/Store cross-compiling to cmake-toolchains.7 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27022166 Please review the result to make sure I didn't munge information you intended to provide. Thanks, -Brad From Gilles.Khouzam at microsoft.com Fri Sep 19 12:59:50 2014 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Fri, 19 Sep 2014 16:59:50 +0000 Subject: [cmake-developers] Patch: Certificate files are not included in Windows Store projects Message-ID: We do write the proper tag in the VCXProj file for the certificate file, but the file is not included in the project itself causing some failures. When I moved the certificates into their own category in the GeneratorTarget, the new category was never added to the VS10TargetGenerator when the sources get written. Gilles Khouzam Senior Development Lead Microsoft OSG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Patch-Add-Certificates-Windows.patch Type: application/octet-stream Size: 1277 bytes Desc: 0001-Patch-Add-Certificates-Windows.patch URL: From brad.king at kitware.com Fri Sep 19 13:44:45 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 19 Sep 2014 13:44:45 -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> Message-ID: <541C6B8D.2020404@kitware.com> On 09/18/2014 08:10 PM, Aleix Pol wrote: > I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to > enable the generation of the file. > I also renamed the file to ProjectTargets.json. > > http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch Thanks. I made some style updates and converted it to a patch generated with 'git format-patch'. See attached. I also attached a sample ProjectTargets.json generated for the "COnly" test from our test suite. I'd really like to hear from others on the file format itself. Some comments on the format: * A version number field is needed at the top. * There needs to be support for multi-config generators. Perhaps everything that can be affected by the configuration needs to be inside a list that enumerates all configurations. In single-configuration generators the list would have only one entry for the CMAKE_BUILD_TYPE. In multi-configuration generators it would be all of the CMAKE_CONFIGURATION_TYPES. * Don't IDEs want to know the list of source files so they can be used for editing? I haven't looked at what the Extra generators produce in a while but since they are meant for IDEs they would be a good reference for the information needed. However, AFAIK there is not an extra generator for a multi-config generator. -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch Type: text/x-diff Size: 4887 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ProjectTargets.json Type: application/json Size: 1001 bytes Desc: not available URL: From brad.king at kitware.com Fri Sep 19 13:50:11 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 19 Sep 2014 13:50:11 -0400 Subject: [cmake-developers] Patch: Certificate files are not included in Windows Store projects In-Reply-To: References: Message-ID: <541C6CD3.4050108@kitware.com> On 09/19/2014 12:59 PM, Gilles Khouzam wrote: > We do write the proper tag in the VCXProj file for the certificate file, but the file is not included in the project itself causing some failures. When I moved the certificates into their own category in the GeneratorTarget, the new category was never added to the VS10TargetGenerator when the > sources get written. Applied, thanks: VS: Add Certificates to .vcxproj files http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d4ca8fb2 -Brad From eike at sf-mail.de Fri Sep 19 13:57:04 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 19 Sep 2014 19:57:04 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <541C6B8D.2020404@kitware.com> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <541C6B8D.2020404@kitware.com> Message-ID: <1461805.58uUMPt7S5@caliban.sf-tec.de> Am Freitag, 19. September 2014, 13:44:45 schrieb Brad King: > On 09/18/2014 08:10 PM, Aleix Pol wrote: > > I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to > > enable the generation of the file. > > I also renamed the file to ProjectTargets.json. > > > > http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch > > Thanks. I made some style updates and converted it to a patch > generated with 'git format-patch'. See attached. I also > attached a sample ProjectTargets.json generated for the "COnly" > test from our test suite. I see duplicated slashes in the JSON file. 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 Sep 19 14:04:25 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 19 Sep 2014 14:04:25 -0400 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <1461805.58uUMPt7S5@caliban.sf-tec.de> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <541C6B8D.2020404@kitware.com> <1461805.58uUMPt7S5@caliban.sf-tec.de> Message-ID: <541C7029.7030403@kitware.com> On 09/19/2014 01:57 PM, Rolf Eike Beer wrote: > I see duplicated slashes in the JSON file. It looks like those come from cmTarget::GetLocationForBuild. An extra + if(!location.empty()) + { + location += "/"; + } appears to have been added by this commit: Remove the Location member from cmTarget. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=638843af Steve, do you remember why it was added? All lines below that append a slash before appending other content, so it will always end up with a double slash. Is there any reason you see that it cannot be removed? Thanks, -Brad From neundorf at kde.org Fri Sep 19 15:53:40 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Fri, 19 Sep 2014 21:53:40 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <541C6B8D.2020404@kitware.com> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <541C6B8D.2020404@kitware.com> Message-ID: <1593230.4g2cNbzx16@tuxedo.neundorf.net> On Friday, September 19, 2014 13:44:45 Brad King wrote: ... > * Don't IDEs want to know the list of source files so they can > be used for editing? > > I haven't looked at what the Extra generators produce in a > while but since they are meant for IDEs they would be a good > reference for the information needed. typically a list of targets, the command to build each target, source files for each target, used include dirs and defines (-D) for code completion. > However, AFAIK there > is not an extra generator for a multi-config generator. Yes. Alex From robert.maynard at kitware.com Fri Sep 19 16:18:34 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 19 Sep 2014 16:18:34 -0400 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> Message-ID: I agree with David, I think moving packages over to using CMP0054 NEW is the best option going forward. Personally I think that CMP0054 might be the best policy ever, as it significantly reduces the complexity of reading CMake code. On Fri, Sep 19, 2014 at 6:23 AM, David Cole via cmake-developers wrote: > I like the "cmake_policy(SET CMP0053 NEW)" solution, too. We should make a > concerted effort to encourage module maintainers to do this before the 3.1 > release for as many modules as possible. > > > D > > -- > > 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 taylor at braun-jones.org Fri Sep 19 18:07:33 2014 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Fri, 19 Sep 2014 18:07:33 -0400 Subject: [cmake-developers] [CMake] Integrating ExternalData with Artifactory In-Reply-To: <541C7E2B.9080606@kitware.com> References: <541C7E2B.9080606@kitware.com> Message-ID: Shifting discussion to cmake-developers. On Fri, Sep 19, 2014 at 3:04 PM, Brad King wrote: > On 09/19/2014 12:23 PM, Taylor Braun-Jones wrote: > > integrate Artifactory with the ExternalData framework? > > > > the Artifactory REST API is a two step process > > I think it can be activated by a special format of an entry in > ExternalData_URL_TEMPLATES that specifies a lookup key that maps > to some kind of custom configuration of a .cmake script to include > or command to launch with execute_process. > How about defining new URL scheme like: externaldatacommand://<*file|module*>/<*command*> Where *file|module* is something that can be passed to the include command and defines a function or macro named *command*. *command* would then be called like: command(outputfile algo hash) So, using Artifactory as an example case, a projects CMakeLists.txt might look like: list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/Testing/CMake ) set(ARTIFACTORY_BASE_URL https://example.com/artifactory) list(APPEND ExternalData_URL_TEMPLATES "externaldatacommand://ArtifactoryExternalData/ARTIFACTORY_DOWNLOAD_FILE?ALGO=%(algo)&" ) And inside Testing/CMake/ArtifactoryExternalData.cmake it would look like: function(ARTIFACTORY_DOWNLOAD_FILE file algo hash) set(json_response_file ${CMAKE_BINARY_DIR}/artifactory_search_${algo}_${hash}.json) set(artifact_search_query ${ARTIFACTORY_BASE_URL}/api/search/checksum?${algo}=${hash}) message("Query URI: ${artifact_search_query}") file(DOWNLOAD ${artifact_search_query} ${json_response_file} STATUS status) list(GET status 0 error_code) list(GET status 1 error_message) if(error_code) file(REMOVE ${json_response_file}) message(FATAL_ERROR "Artifactory query failed with error ${error_code}: ${error_message}") endif() # For testing file(WRITE ${json_response_file} "{\"results\":[{\"uri\":\" https://example.com/artifactory/api/storage/repo1-cache/lena.png\"}]}") file(READ ${json_response_file} json_response) file(REMOVE ${json_response_file}) # Normalize the JSON response by removing any whitespace (makes it easier to parse) string(REGEX REPLACE "[ \t\n\r]+" "" json_response ${json_response}) if(NOT json_response MATCHES "\"uri\":") message(FATAL_ERROR "Artifactory file was not found") endif() string(REGEX MATCH "https?://[^\"]+" artifact_uri ${json_response}) message("Artifact URI: ${artifact_uri}") file(DOWNLOAD ${artifact_uri} ${file} STATUS status) list(GET status 0 error_code) list(GET status 1 error_message) if(error_code) message(FATAL_ERROR "Artifactory download failed with error ${error_code}: ${error_message}") endif() endfunction() Then if you had: ExternalData_Add_Test(MyProjectData NAME SmoothingTest COMMAND SmoothingExe DATA{Input/Image.png} SmoothedImage.png ) The ExternalData framework would execute: ARTIFACTORY_DOWNLOAD_FILE(${ExternalData_BINARY_ROOT}/Input/Image.png md5 1234567890abcdef1234567890abcdef) Thoughts? Taylor -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Sat Sep 20 09:18:32 2014 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 20 Sep 2014 15:18:32 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <541C6B8D.2020404@kitware.com> <1461805.58uUMPt7S5@caliban.sf-tec.de> <541C7029.7030403@kitware.com> Message-ID: Brad King wrote: > Steve, do you remember why it was added? All lines below > that append a slash before appending other content, so it > will always end up with a double slash. Is there any reason > you see that it cannot be removed? I don't know why I added it. Perhaps to deal with a dashboard error that would emerge again if removed. There is also a 'new' + location += "/"; in that patch further down which might be removable. Thanks, Steve. From ono at java.pl Sat Sep 20 09:20:42 2014 From: ono at java.pl (Adam Strzelecki) Date: Sat, 20 Sep 2014 15:20:42 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> Message-ID: I've pushed stage/CMP0054-FindCUDA: commit 8998557e7c9a7542e78e07b8b06fd728604f0bdf Author: Adam Strzelecki Date: Tue Sep 16 23:31:44 2014 +0200 FindCUDA: Audit for modern CMP0054 if() syntax Enables CMP0054 for whole module to silence quoted variable expansion warning. Just added where the actual code starts: cmake_policy(SET CMP0054 NEW) # modern if() syntax And made one simple fix with unneeded variable and unneeded quoting. I think we may do the same for the other modules. WDYT? --Adam From steveire at gmail.com Sat Sep 20 09:43:54 2014 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 20 Sep 2014 15:43:54 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration 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> Message-ID: Brad King wrote: > I'd really like to hear from others on the file format itself. > > * There needs to be support for multi-config generators. This presumable affects the "directory" and "location". I wonder what the usefulness of putting "exportName" in the file is? Is it possible there is confusion with OUTPUT_NAME? Or do you want some richer information if an IDE opens a file in the build dir generated by export()? Does this generated file enable use-cases like 'Add new file to target' or is that already easy? Or what kind of features are enabled by this? Thanks, Steve. From mantis at public.kitware.com Sat Sep 20 14:05:49 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 20 Sep 2014 14:05:49 -0400 Subject: [cmake-developers] [CMake 0015166]: cc: acomp failed for Source/CursesDialog/form/fld_arg.c Message-ID: <2d023dbb73f2209d8fde880ab7af983e@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15166 ====================================================================== Reported By: dev Assigned To: ====================================================================== Project: CMake Issue ID: 15166 Category: CMake Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-20 14:05 EDT Last Modified: 2014-09-20 14:05 EDT ====================================================================== Summary: cc: acomp failed for Source/CursesDialog/form/fld_arg.c Description: On Oracle Solaris 10 with Oracle Studio 12.3 compilers : [ 48%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 46: cannot find include file: "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 93: error: syntax error before or at: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 120: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 120: warning: syntax requires ";" after last struct/union member "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 110: error: zero-sized struct/union "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 144: error: syntax error before or at: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 291: error: syntax error before or at: ( "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 290: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292: error: syntax error before or at: * "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292: error: syntax error before or at: ) "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 293: warning: old-style declaration or incorrect type for: link_fieldtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 297: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 297: warning: undefined or missing type for: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 296: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: error: syntax error before or at: * "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: error: syntax error before or at: ) "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: warning: syntax error: empty declaration "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 313: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 313: warning: undefined or missing type for: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 316: error: syntax error before or at: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 316: warning: undefined or missing type for: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 317: error: syntax error before or at: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 317: warning: undefined or missing type for: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 321: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 321: warning: undefined or missing type for: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 327: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 327: error: syntax error before or at: field_fore "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 327: warning: old-style declaration or incorrect type for: field_fore "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 328: warning: old-style declaration or incorrect type for: field_back "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: error: identifier redeclared: bool current : int previous: function() returning int : "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292 "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: error: syntax error before or at: new_page "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: warning: old-style declaration or incorrect type for: new_page "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 331: warning: old-style declaration or incorrect type for: field_status "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 353: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 353: error: syntax error before or at: * "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 353: warning: old-style declaration or incorrect type for: form_win "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 354: warning: old-style declaration or incorrect type for: form_sub "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 365: error: syntax error before or at: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 365: warning: undefined or missing type for: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 366: error: syntax error before or at: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 366: warning: undefined or missing type for: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 394: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 394: error: syntax error before or at: data_ahead "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 394: warning: old-style declaration or incorrect type for: data_ahead "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 395: warning: old-style declaration or incorrect type for: data_behind "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 124: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 124: error: syntax error before or at: _nc_Copy_Type "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 124: warning: old-style declaration or incorrect type for: _nc_Copy_Type "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 132: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 132: error: syntax error before or at: _nc_Internal_Validation "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 132: warning: old-style declaration or incorrect type for: _nc_Internal_Validation "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 71: error: improper member use: status "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 72: error: improper member use: makearg "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 73: error: improper member use: copyarg "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 74: error: improper member use: freearg cc: acomp failed for /usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c gmake[2]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o] Error 2 gmake[1]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/all] Error 2 gmake: *** [all] Error 2 node000 $ Steps to Reproduce: fetch and extract the tarball : node000 $ wget http://www.cmake.org/files/v3.0/cmake-3.0.2.tar.gz --2014-09-20 16:25:21-- http://www.cmake.org/files/v3.0/cmake-3.0.2.tar.gz Resolving www.cmake.org... 66.194.253.19 Connecting to www.cmake.org|66.194.253.19|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 5490501 (5.2M) [application/x-gzip] Saving to: ?cmake-3.0.2.tar.gz? 0K ..... 100% 585K=9.2s 2014-09-20 16:25:31 (585 KB/s) - ?cmake-3.0.2.tar.gz? saved [5490501/5490501] node000 $ cd /usr/local/build node000 $ mdigest -a sha256 ../src/cmake-3.0.2.tar.gz 6b4ea61eadbbd9bec0ccb383c29d1f4496eacc121ef7acf37c7a24777805693e ../src/cmake-3.0.2.tar.gz node000 $ gzip -dc ../src/cmake-3.0.2.tar.gz | tar -xf - node000 $ mkdir cmake-3.0.2_SunOS5.10_sparcv9.001 node000 $ cd cmake-3.0.2_SunOS5.10_sparcv9.001 setup env vars : node000 $ env | sort AR=/usr/ccs/bin/ar AS=/usr/ccs/bin/as BUILD=/usr/local/build CC=/opt/solarisstudio12.3/bin/cc CFLAGS=-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 CONFIG_SHELL=/usr/local/bin/bash CPPFLAGS=-I/usr/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE CXXFLAGS=-dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO CXX=/opt/solarisstudio12.3/bin/CC GREP=/usr/local/bin/ggrep HOME=/export/home/dev LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LD_LIBRARY_PATH=/usr/local/lib LD_OPTIONS=-64 -R/usr/local/lib/:/usr/local/lib -L/usr/local/lib/:/usr/local/lib LD_RUN_PATH=/usr/local/lib LD=/usr/ccs/bin/sparcv9/ld LIBTOOL=/usr/local/bin/libtool LOGNAME=dev M4=/usr/local/bin/gm4 MACHTYPE=sparc-sun-solaris MAKE=/usr/local/bin/gmake MANPATH=/usr/share/man:/usr/X11/share/man NM=/usr/ccs/bin/sparcv9/nm -p OSTYPE=solaris PAGER=/usr/xpg4/bin/more PATH=/usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/opt/solarisstudio12.3/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/dt/bin:/usr/openwin/bin:/opt/schily/bin PERL=/usr/local/bin/perl PKG_CONFIG_PATH=/usr/local/lib/pkgconfig PWD=/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001 SED=/usr/local/bin/gsed SHELL=/usr/local/bin/bash SHLVL=1 SRC=/usr/local/src TERM=xterm TZ=GMT0 USER=dev _=/usr/xpg4/bin/env VISUAL=/usr/xpg6/bin/vi XTERM_LOCALE=en_US.UTF-8 Bootstrap : node000 $ ../cmake-3.0.2/bootstrap --------------------------------------------- CMake 3.0.2, Copyright 2000-2014 Kitware, Inc. C compiler on this system is: /opt/solarisstudio12.3/bin/cc -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 C++ compiler on this system is: /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO Makefile processor on this system is: /usr/local/bin/gmake /opt/solarisstudio12.3/bin/CC is not GNU compiler /opt/solarisstudio12.3/bin/CC has setenv /opt/solarisstudio12.3/bin/CC has unsetenv /opt/solarisstudio12.3/bin/CC does not have environ in stdlib.h /opt/solarisstudio12.3/bin/CC has STL in std:: namespace /opt/solarisstudio12.3/bin/CC has ANSI streams /opt/solarisstudio12.3/bin/CC has streams in std:: namespace /opt/solarisstudio12.3/bin/CC has sstream /opt/solarisstudio12.3/bin/CC has operator!=(string, char*) /opt/solarisstudio12.3/bin/CC does not have stl iterator_traits /opt/solarisstudio12.3/bin/CC does not have old iterator_category /opt/solarisstudio12.3/bin/CC has old __iterator_category /opt/solarisstudio12.3/bin/CC has standard template allocator /opt/solarisstudio12.3/bin/CC does not have allocator<>::rebind<> /opt/solarisstudio12.3/bin/CC has non-standard allocator<>::max_size argument /opt/solarisstudio12.3/bin/CC has stl containers supporting allocator objects /opt/solarisstudio12.3/bin/CC has stl wstring /opt/solarisstudio12.3/bin/CC does not have header cstddef /opt/solarisstudio12.3/bin/CC requires template friends to use <> /opt/solarisstudio12.3/bin/CC supports member templates /opt/solarisstudio12.3/bin/CC has standard template specialization syntax /opt/solarisstudio12.3/bin/CC has argument dependent lookup /opt/solarisstudio12.3/bin/CC has struct stat with st_mtim member /opt/solarisstudio12.3/bin/CC has ios::binary openmode /opt/solarisstudio12.3/bin/CC has ANSI for scoping --------------------------------------------- /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmStandardIncludes.cxx -o cmStandardIncludes.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmake.cxx -o cmake.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmakemain.cxx -o cmakemain.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmcmd.cxx -o cmcmd.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmCommandArgumentLexer.cxx -o cmCommandArgumentLexer.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmCommandArgumentParser.cxx -o cmCommandArgumentParser.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmCommandArgumentParserHelper.cxx -o cmCommandArgumentParserHelper.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmDefinitions.cxx -o cmDefinitions.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmDepends.cxx -o cmDepends.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmDependsC.cxx -o cmDependsC.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmDocumentationFormatter.cxx -o cmDocumentationFormatter.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmPolicies.cxx -o cmPolicies.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmProperty.cxx -o cmProperty.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmPropertyMap.cxx -o cmPropertyMap.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmPropertyDefinition.cxx -o cmPropertyDefinition.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmPropertyDefinitionMap.cxx -o cmPropertyDefinitionMap.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmMakeDepend.cxx -o cmMakeDepend.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmMakefile.cxx -o cmMakefile.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExportFileGenerator.cxx -o cmExportFileGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExportInstallFileGenerator.cxx -o cmExportInstallFileGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExportTryCompileFileGenerator.cxx -o cmExportTryCompileFileGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExportSet.cxx -o cmExportSet.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExportSetMap.cxx -o cmExportSetMap.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmInstallDirectoryGenerator.cxx -o cmInstallDirectoryGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGeneratedFileStream.cxx -o cmGeneratedFileStream.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGeneratorTarget.cxx -o cmGeneratorTarget.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGeneratorExpressionDAGChecker.cxx -o cmGeneratorExpressionDAGChecker.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGeneratorExpressionEvaluator.cxx -o cmGeneratorExpressionEvaluator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGeneratorExpressionLexer.cxx -o cmGeneratorExpressionLexer.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGeneratorExpressionParser.cxx -o cmGeneratorExpressionParser.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGeneratorExpression.cxx -o cmGeneratorExpression.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGlobalGenerator.cxx -o cmGlobalGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmLocalGenerator.cxx -o cmLocalGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmInstallGenerator.cxx -o cmInstallGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmInstallExportGenerator.cxx -o cmInstallExportGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmInstallFilesGenerator.cxx -o cmInstallFilesGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmInstallScriptGenerator.cxx -o cmInstallScriptGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmInstallTargetGenerator.cxx -o cmInstallTargetGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmScriptGenerator.cxx -o cmScriptGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmSourceFile.cxx -o cmSourceFile.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmSourceFileLocation.cxx -o cmSourceFileLocation.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmSystemTools.cxx -o cmSystemTools.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmTestGenerator.cxx -o cmTestGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmVersion.cxx -o cmVersion.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmFileTimeComparison.cxx -o cmFileTimeComparison.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGlobalUnixMakefileGenerator3.cxx -o cmGlobalUnixMakefileGenerator3.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmLocalUnixMakefileGenerator3.cxx -o cmLocalUnixMakefileGenerator3.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmMakefileExecutableTargetGenerator.cxx -o cmMakefileExecutableTargetGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmMakefileLibraryTargetGenerator.cxx -o cmMakefileLibraryTargetGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmMakefileTargetGenerator.cxx -o cmMakefileTargetGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmMakefileUtilityTargetGenerator.cxx -o cmMakefileUtilityTargetGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmOSXBundleGenerator.cxx -o cmOSXBundleGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmNewLineStyle.cxx -o cmNewLineStyle.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmBootstrapCommands1.cxx -o cmBootstrapCommands1.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmBootstrapCommands2.cxx -o cmBootstrapCommands2.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmCommandsForBootstrap.cxx -o cmCommandsForBootstrap.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmTarget.cxx -o cmTarget.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmTest.cxx -o cmTest.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmCustomCommand.cxx -o cmCustomCommand.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmCustomCommandGenerator.cxx -o cmCustomCommandGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmCacheManager.cxx -o cmCacheManager.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmListFileCache.cxx -o cmListFileCache.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmComputeLinkDepends.cxx -o cmComputeLinkDepends.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmComputeLinkInformation.cxx -o cmComputeLinkInformation.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmOrderDirectories.cxx -o cmOrderDirectories.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmComputeTargetDepends.cxx -o cmComputeTargetDepends.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmComputeComponentGraph.cxx -o cmComputeComponentGraph.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExprLexer.cxx -o cmExprLexer.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExprParser.cxx -o cmExprParser.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmExprParserHelper.cxx -o cmExprParserHelper.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmGlobalNinjaGenerator.cxx -o cmGlobalNinjaGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmLocalNinjaGenerator.cxx -o cmLocalNinjaGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmNinjaTargetGenerator.cxx -o cmNinjaTargetGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmNinjaNormalTargetGenerator.cxx -o cmNinjaNormalTargetGenerator.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmNinjaUtilityTargetGenerator.cxx -o cmNinjaUtilityTargetGenerator.o /opt/solarisstudio12.3/bin/cc -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -c /usr/local/build/cmake-3.0.2/Source/cmListFileLexer.c -o cmListFileLexer.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /usr/local/build/cmake-3.0.2/Source/kwsys/Directory.cxx -o Directory.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /usr/local/build/cmake-3.0.2/Source/kwsys/EncodingCXX.cxx -o EncodingCXX.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /usr/local/build/cmake-3.0.2/Source/kwsys/Glob.cxx -o Glob.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /usr/local/build/cmake-3.0.2/Source/kwsys/RegularExpression.cxx -o RegularExpression.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -DKWSYS_CXX_HAS_SETENV=1 -DKWSYS_CXX_HAS_UNSETENV=1 -DKWSYS_CXX_HAS_ENVIRON_IN_STDLIB_H=0 -DKWSYS_CXX_HAS_UTIMENSAT=0 -DKWSYS_CXX_HAS_UTIMES=0 -c /usr/local/build/cmake-3.0.2/Source/kwsys/SystemTools.cxx -o SystemTools.o /opt/solarisstudio12.3/bin/cc -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /usr/local/build/cmake-3.0.2/Source/kwsys/EncodingC.c -o EncodingC.o /opt/solarisstudio12.3/bin/cc -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /usr/local/build/cmake-3.0.2/Source/kwsys/ProcessUNIX.c -o ProcessUNIX.o /opt/solarisstudio12.3/bin/cc -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -DKWSYS_STRING_C -c /usr/local/build/cmake-3.0.2/Source/kwsys/String.c -o String.o /opt/solarisstudio12.3/bin/cc -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /usr/local/build/cmake-3.0.2/Source/kwsys/System.c -o System.o /opt/solarisstudio12.3/bin/CC -dalign -erroff=%none -errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk -I/usr/local/build/cmake-3.0.2/Source -I/usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk cmStandardIncludes.o cmake.o cmakemain.o cmcmd.o cmCommandArgumentLexer.o cmCommandArgumentParser.o cmCommandArgumentParserHelper.o cmDefinitions.o cmDepends.o cmDependsC.o cmDocumentationFormatter.o cmPolicies.o cmProperty.o cmPropertyMap.o cmPropertyDefinition.o cmPropertyDefinitionMap.o cmMakeDepend.o cmMakefile.o cmExportFileGenerator.o cmExportInstallFileGenerator.o cmExportTryCompileFileGenerator.o cmExportSet.o cmExportSetMap.o cmInstallDirectoryGenerator.o cmGeneratedFileStream.o cmGeneratorTarget.o cmGeneratorExpressionDAGChecker.o cmGeneratorExpressionEvaluator.o cmGeneratorExpressionLexer.o cmGeneratorExpressionParser.o cmGeneratorExpression.o cmGlobalGenerator.o cmLocalGenerator.o cmInstallGenerator.o cmInstallExportGenerator.o cmInstallFilesGenerator.o cmInstallScriptGenerator.o cmInstallTargetGenerator.o cmScriptGenerator.o cmSourceFile.o cmSourceFileLocation.o cmSystemTools.o cmTestGenerator.o cmVersion.o cmFileTimeComparison.o cmGlobalUnixMakefileGenerator3.o cmLocalUnixMakefileGenerator3.o cmMakefileExecutableTargetGenerator.o cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o cmMakefileUtilityTargetGenerator.o cmOSXBundleGenerator.o cmNewLineStyle.o cmBootstrapCommands1.o cmBootstrapCommands2.o cmCommandsForBootstrap.o cmTarget.o cmTest.o cmCustomCommand.o cmCustomCommandGenerator.o cmCacheManager.o cmListFileCache.o cmComputeLinkDepends.o cmComputeLinkInformation.o cmOrderDirectories.o cmComputeTargetDepends.o cmComputeComponentGraph.o cmExprLexer.o cmExprParser.o cmExprParserHelper.o cmGlobalNinjaGenerator.o cmLocalNinjaGenerator.o cmNinjaTargetGenerator.o cmNinjaNormalTargetGenerator.o cmNinjaUtilityTargetGenerator.o cmListFileLexer.o Directory.o EncodingCXX.o Glob.o RegularExpression.o SystemTools.o EncodingC.o ProcessUNIX.o String.o System.o -o cmake loading initial cache file /usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001/Bootstrap.cmk/InitialCacheFlags.cmake -- The C compiler identification is SunPro 5.12.0 -- The CXX compiler identification is SunPro 5.12.0 -- Check for working C compiler: /opt/solarisstudio12.3/bin/cc -- Check for working C compiler: /opt/solarisstudio12.3/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /opt/solarisstudio12.3/bin/CC -- Check for working CXX compiler: /opt/solarisstudio12.3/bin/CC -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available -- Checking whether header cstddef is available - no -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator!= for char* - yes -- Checking whether stl has iterator_traits -- Checking whether stl has iterator_traits - no -- Checking whether stl has old iterator_category -- Checking whether stl has old iterator_category - no -- Checking whether stl has internal __iterator_category -- Checking whether stl has internal __iterator_category - yes -- Checking whether stl has standard template allocator -- Checking whether stl has standard template allocator - yes -- Checking for rebind member of stl allocator -- Checking for rebind member of stl allocator - no -- Checking for non-standard argument to stl allocator<>::max_size -- Checking for non-standard argument to stl allocator<>::max_size - yes -- Checking whether stl containers support allocator objects. -- Checking whether stl containers support allocator objects. - yes -- Checking whether ios has binary openmode -- Checking whether ios has binary openmode - yes -- Checking whether "<>" is needed for template friends -- Checking whether "<>" is needed for template friends - yes -- Checking for member template support -- Checking for member template support - yes -- Checking for standard template specialization syntax -- Checking for standard template specialization syntax - yes -- Checking whether argument dependent lookup is supported -- Checking whether argument dependent lookup is supported - yes -- Checking whether struct stat has st_mtim member -- Checking whether struct stat has st_mtim member - yes -- Checking whether C++ compiler has 'long long' -- Checking whether C++ compiler has 'long long' - yes -- Checking whether C++ compiler has '__int64' -- Checking whether C++ compiler has '__int64' - no -- Checking for C type size macros -- Checking for C type size macros - compiled -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of char -- Check size of char - done -- Check size of short -- Check size of short - done -- Check size of int -- Check size of int - done -- Check size of long -- Check size of long - done -- Check size of long long -- Check size of long long - done -- Check size of __int64 -- Check size of __int64 - failed -- Checking whether char is signed -- Checking whether char is signed - yes -- Checking whether wstring is available -- Checking whether wstring is available - yes -- Checking if istream supports long long -- Checking if istream supports long long - yes -- Checking if ostream supports long long -- Checking if ostream supports long long - yes -- Checking whether C compiler has ptrdiff_t in stddef.h -- Checking whether C compiler has ptrdiff_t in stddef.h - yes -- Checking whether C compiler has ssize_t in unistd.h -- Checking whether C compiler has ssize_t in unistd.h - yes -- Checking whether CXX compiler has setenv -- Checking whether CXX compiler has setenv - yes -- Checking whether CXX compiler has unsetenv -- Checking whether CXX compiler has unsetenv - yes -- Checking whether CXX compiler has environ in stdlib.h -- Checking whether CXX compiler has environ in stdlib.h - no -- Checking whether CXX compiler has utimes -- Checking whether CXX compiler has utimes - yes -- Checking whether CXX compiler has utimensat -- Checking whether CXX compiler has utimensat - yes -- Looking for include files sys/types.h, ifaddrs.h -- Looking for include files sys/types.h, ifaddrs.h - not found -- Checking whether CXX compiler has rlimit64 -- Checking whether CXX compiler has rlimit64 - yes -- Checking whether CXX compiler has atol -- Checking whether CXX compiler has atol - yes -- Checking whether CXX compiler has atoll -- Checking whether CXX compiler has atoll - yes -- Checking whether CXX compiler has _atoi64 -- Checking whether CXX compiler has _atoi64 - no -- Looking for C++ include execinfo.h -- Looking for C++ include execinfo.h - not found -- Looking for connect in socket;dl -- Looking for connect in socket;dl - found -- Looking for gethostbyname in c -- Looking for gethostbyname in c - not found -- Looking for recv in network;dl;socket -- Looking for recv in network;dl;socket - not found -- Looking for gethostbyname in nsl;dl;socket -- Looking for gethostbyname in nsl;dl;socket - found -- Looking for getch in ws2_32;dl;socket;nsl -- Looking for getch in ws2_32;dl;socket;nsl - not found -- Looking for getch in winmm;dl;socket;nsl -- Looking for getch in winmm;dl;socket;nsl - not found -- Looking for idna_to_ascii_lz in idn;dl;socket;nsl -- Looking for idna_to_ascii_lz in idn;dl;socket;nsl - found -- Looking for dlopen in dl;socket;nsl;idn -- Looking for dlopen in dl;socket;nsl;idn - found -- Looking for process.h -- Looking for process.h - not found -- Looking for features.h -- Looking for features.h - not found -- Looking for include file stdio.h -- Looking for include file stdio.h - found -- Looking for 4 include files stdio.h, ..., inttypes.h -- Looking for 4 include files stdio.h, ..., inttypes.h - found -- Looking for 5 include files stdio.h, ..., alloca.h -- Looking for 5 include files stdio.h, ..., alloca.h - found -- Looking for 6 include files stdio.h, ..., arpa/inet.h -- Looking for 6 include files stdio.h, ..., arpa/inet.h - found -- Looking for 7 include files stdio.h, ..., dlfcn.h -- Looking for 7 include files stdio.h, ..., dlfcn.h - found -- Looking for 8 include files stdio.h, ..., fcntl.h -- Looking for 8 include files stdio.h, ..., fcntl.h - found -- Looking for 9 include files stdio.h, ..., malloc.h -- Looking for 9 include files stdio.h, ..., malloc.h - found -- Looking for 10 include files stdio.h, ..., memory.h -- Looking for 10 include files stdio.h, ..., memory.h - found -- Looking for 11 include files stdio.h, ..., netdb.h -- Looking for 11 include files stdio.h, ..., netdb.h - found -- Looking for 12 include files stdio.h, ..., sys/poll.h -- Looking for 12 include files stdio.h, ..., sys/poll.h - found -- Looking for 13 include files stdio.h, ..., assert.h -- Looking for 13 include files stdio.h, ..., assert.h - found -- Looking for 14 include files stdio.h, ..., limits.h -- Looking for 14 include files stdio.h, ..., limits.h - found -- Looking for 15 include files stdio.h, ..., sys/socket.h -- Looking for 15 include files stdio.h, ..., sys/socket.h - found -- Looking for 16 include files stdio.h, ..., netinet/in.h -- Looking for 16 include files stdio.h, ..., netinet/in.h - found -- Looking for 17 include files stdio.h, ..., net/if.h -- Looking for 17 include files stdio.h, ..., net/if.h - found -- Looking for 18 include files stdio.h, ..., netinet/if_ether.h -- Looking for 18 include files stdio.h, ..., netinet/if_ether.h - found -- Looking for 19 include files stdio.h, ..., netinet/tcp.h -- Looking for 19 include files stdio.h, ..., netinet/tcp.h - found -- Looking for 20 include files stdio.h, ..., sys/select.h -- Looking for 20 include files stdio.h, ..., sys/select.h - found -- Looking for 21 include files stdio.h, ..., utime.h -- Looking for 21 include files stdio.h, ..., utime.h - found -- Looking for 23 include files stdio.h, ..., pwd.h -- Looking for 23 include files stdio.h, ..., pwd.h - found -- Looking for 24 include files stdio.h, ..., sgtty.h -- Looking for 24 include files stdio.h, ..., sgtty.h - found -- Looking for 26 include files stdio.h, ..., stdlib.h -- Looking for 26 include files stdio.h, ..., stdlib.h - found -- Looking for 27 include files stdio.h, ..., string.h -- Looking for 27 include files stdio.h, ..., string.h - found -- Looking for 28 include files stdio.h, ..., strings.h -- Looking for 28 include files stdio.h, ..., strings.h - found -- Looking for 29 include files stdio.h, ..., sys/param.h -- Looking for 29 include files stdio.h, ..., sys/param.h - found -- Looking for 30 include files stdio.h, ..., sys/stat.h -- Looking for 30 include files stdio.h, ..., sys/stat.h - found -- Looking for 31 include files stdio.h, ..., sys/time.h -- Looking for 31 include files stdio.h, ..., sys/time.h - found -- Looking for 32 include files stdio.h, ..., sys/resource.h -- Looking for 32 include files stdio.h, ..., sys/resource.h - found -- Looking for 33 include files stdio.h, ..., termios.h -- Looking for 33 include files stdio.h, ..., termios.h - found -- Looking for 34 include files stdio.h, ..., termio.h -- Looking for 34 include files stdio.h, ..., termio.h - found -- Looking for 35 include files stdio.h, ..., io.h -- Looking for 35 include files stdio.h, ..., io.h - not found -- Looking for 35 include files stdio.h, ..., time.h -- Looking for 35 include files stdio.h, ..., time.h - found -- Looking for 36 include files stdio.h, ..., unistd.h -- Looking for 36 include files stdio.h, ..., unistd.h - found -- Looking for 37 include files stdio.h, ..., sys/utime.h -- Looking for 37 include files stdio.h, ..., sys/utime.h - found -- Looking for 38 include files stdio.h, ..., sockio.h -- Looking for 38 include files stdio.h, ..., sockio.h - not found -- Looking for 38 include files stdio.h, ..., sys/sockio.h -- Looking for 38 include files stdio.h, ..., sys/sockio.h - found -- Looking for 39 include files stdio.h, ..., x509.h -- Looking for 39 include files stdio.h, ..., x509.h - not found -- Looking for 39 include files stdio.h, ..., locale.h -- Looking for 39 include files stdio.h, ..., locale.h - found -- Looking for 40 include files stdio.h, ..., setjmp.h -- Looking for 40 include files stdio.h, ..., setjmp.h - found -- Looking for 41 include files stdio.h, ..., signal.h -- Looking for 41 include files stdio.h, ..., signal.h - found -- Looking for 42 include files stdio.h, ..., sys/ioctl.h -- Looking for 42 include files stdio.h, ..., sys/ioctl.h - found -- Looking for 43 include files stdio.h, ..., sys/utsname.h -- Looking for 43 include files stdio.h, ..., sys/utsname.h - found -- Looking for 44 include files stdio.h, ..., idn-free.h -- Looking for 44 include files stdio.h, ..., idn-free.h - not found -- Looking for 44 include files stdio.h, ..., idna.h -- Looking for 44 include files stdio.h, ..., idna.h - not found -- Looking for 44 include files stdio.h, ..., tld.h -- Looking for 44 include files stdio.h, ..., tld.h - not found -- Looking for 44 include files stdio.h, ..., arpa/tftp.h -- Looking for 44 include files stdio.h, ..., arpa/tftp.h - found -- Looking for 45 include files stdio.h, ..., errno.h -- Looking for 45 include files stdio.h, ..., errno.h - found -- Looking for 46 include files stdio.h, ..., libgen.h -- Looking for 46 include files stdio.h, ..., libgen.h - found -- Looking for 47 include files stdio.h, ..., sys/filio.h -- Looking for 47 include files stdio.h, ..., sys/filio.h - found -- Check size of size_t -- Check size of size_t - done -- Check size of ssize_t -- Check size of ssize_t - done -- Check size of long long -- Check size of long long - done -- Check size of long -- Check size of long - done -- Check size of __int64 -- Check size of __int64 - failed -- Check size of time_t -- Check size of time_t - done -- Looking for basename -- Looking for basename - found -- Looking for socket -- Looking for socket - found -- Looking for poll -- Looking for poll - found -- Looking for select -- Looking for select - found -- Looking for strdup -- Looking for strdup - found -- Looking for strstr -- Looking for strstr - found -- Looking for strtok_r -- Looking for strtok_r - found -- Looking for strftime -- Looking for strftime - found -- Looking for uname -- Looking for uname - found -- Looking for strcasecmp -- Looking for strcasecmp - found -- Looking for stricmp -- Looking for stricmp - not found -- Looking for strcmpi -- Looking for strcmpi - not found -- Looking for strncmpi -- Looking for strncmpi - not found -- Looking for gethostbyaddr -- Looking for gethostbyaddr - found -- Looking for gettimeofday -- Looking for gettimeofday - found -- Looking for inet_addr -- Looking for inet_addr - found -- Looking for inet_pton -- Looking for inet_pton - found -- Looking for inet_ntoa -- Looking for inet_ntoa - found -- Looking for inet_ntoa_r -- Looking for inet_ntoa_r - not found -- Looking for tcsetattr -- Looking for tcsetattr - found -- Looking for tcgetattr -- Looking for tcgetattr - found -- Looking for perror -- Looking for perror - found -- Looking for closesocket -- Looking for closesocket - not found -- Looking for setvbuf -- Looking for setvbuf - found -- Looking for sigsetjmp -- Looking for sigsetjmp - found -- Looking for getpass_r -- Looking for getpass_r - not found -- Looking for getpwuid -- Looking for getpwuid - found -- Looking for geteuid -- Looking for geteuid - found -- Looking for utime -- Looking for utime - found -- Looking for gmtime_r -- Looking for gmtime_r - found -- Looking for localtime_r -- Looking for localtime_r - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for gethostbyname_r -- Looking for gethostbyname_r - found -- Looking for gethostbyaddr_r -- Looking for gethostbyaddr_r - found -- Looking for signal -- Looking for signal - found -- Looking for SIGALRM -- Looking for SIGALRM - found -- Looking for strtoll -- Looking for strtoll - found -- Looking for _strtoi64 -- Looking for _strtoi64 - not found -- Looking for strerror_r -- Looking for strerror_r - found -- Looking for siginterrupt -- Looking for siginterrupt - found -- Looking for fork -- Looking for fork - found -- Looking for pipe -- Looking for pipe - found -- Looking for ftruncate -- Looking for ftruncate - found -- Looking for getprotobyname -- Looking for getprotobyname - found -- Looking for getrlimit -- Looking for getrlimit - found -- Looking for idn_free -- Looking for idn_free - not found -- Looking for idna_strerror -- Looking for idna_strerror - not found -- Looking for tld_strerror -- Looking for tld_strerror - not found -- Looking for setlocale -- Looking for setlocale - found -- Looking for setrlimit -- Looking for setrlimit - found -- Looking for sigaction -- Looking for sigaction - found -- Performing Curl Test HAVE_FIONBIO -- Performing Curl Test HAVE_FIONBIO - Failed -- Performing Curl Test HAVE_IOCTLSOCKET -- Performing Curl Test HAVE_IOCTLSOCKET - Failed -- Performing Curl Test HAVE_IOCTLSOCKET_CASE -- Performing Curl Test HAVE_IOCTLSOCKET_CASE - Failed -- Performing Curl Test HAVE_O_NONBLOCK -- Performing Curl Test HAVE_O_NONBLOCK - Success -- Performing Curl Test HAVE_SO_NONBLOCK -- Performing Curl Test HAVE_SO_NONBLOCK - Failed -- Performing Curl Test TIME_WITH_SYS_TIME -- Performing Curl Test TIME_WITH_SYS_TIME - Success -- Performing Curl Test HAVE_O_NONBLOCKHAVE_GETHOSTBYADDR_R_5 -- Performing Curl Test HAVE_O_NONBLOCKHAVE_GETHOSTBYADDR_R_5 - Failed -- Performing Curl Test HAVE_GETHOSTBYADDR_R_7 -- Performing Curl Test HAVE_GETHOSTBYADDR_R_7 - Success -- Performing Curl Test HAVE_GETHOSTBYADDR_R_8 -- Performing Curl Test HAVE_GETHOSTBYADDR_R_8 - Failed -- Performing Curl Test HAVE_GETHOSTBYADDR_R_5_REENTRANT -- Performing Curl Test HAVE_GETHOSTBYADDR_R_5_REENTRANT - Failed -- Performing Curl Test HAVE_GETHOSTBYADDR_R_7_REENTRANT -- Performing Curl Test HAVE_GETHOSTBYADDR_R_7_REENTRANT - Success -- Performing Curl Test HAVE_GETHOSTBYADDR_R_8_REENTRANT -- Performing Curl Test HAVE_GETHOSTBYADDR_R_8_REENTRANT - Failed -- Performing Curl Test HAVE_GETHOSTBYNAME_R_3 -- Performing Curl Test HAVE_GETHOSTBYNAME_R_3 - Failed -- Performing Curl Test HAVE_GETHOSTBYNAME_R_5 -- Performing Curl Test HAVE_GETHOSTBYNAME_R_5 - Success -- Performing Curl Test HAVE_GETHOSTBYNAME_R_6 -- Performing Curl Test HAVE_GETHOSTBYNAME_R_6 - Failed -- Performing Curl Test HAVE_GETHOSTBYNAME_R_3_REENTRANT -- Performing Curl Test HAVE_GETHOSTBYNAME_R_3_REENTRANT - Failed -- Performing Curl Test HAVE_GETHOSTBYNAME_R_5_REENTRANT -- Performing Curl Test HAVE_GETHOSTBYNAME_R_5_REENTRANT - Success -- Performing Curl Test HAVE_GETHOSTBYNAME_R_6_REENTRANT -- Performing Curl Test HAVE_GETHOSTBYNAME_R_6_REENTRANT - Failed -- Performing Curl Test HAVE_SOCKLEN_T -- Performing Curl Test HAVE_SOCKLEN_T - Success -- Performing Curl Test HAVE_IN_ADDR_T -- Performing Curl Test HAVE_IN_ADDR_T - Success -- Performing Curl Test STDC_HEADERS -- Performing Curl Test STDC_HEADERS - Success -- Performing Curl Test RETSIGTYPE_TEST -- Performing Curl Test RETSIGTYPE_TEST - Success -- Performing Curl Test HAVE_INET_NTOA_R_DECL -- Performing Curl Test HAVE_INET_NTOA_R_DECL - Failed -- Performing Curl Test HAVE_INET_NTOA_R_DECL_REENTRANT -- Performing Curl Test HAVE_INET_NTOA_R_DECL_REENTRANT - Failed -- Performing Curl Test HAVE_GETADDRINFO -- Performing Curl Test HAVE_GETADDRINFO - Success -- Performing Curl Test HAVE_FILE_OFFSET_BITS -- Performing Curl Test HAVE_FILE_OFFSET_BITS - Success -- Check size of curl_off_t -- Check size of curl_off_t - done -- Performing Test curl_cv_recv -- Performing Test curl_cv_recv - Success -- Performing Test int recv(int, void *, size_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, size_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, void *, size_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, size_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, void *, int, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, void *, int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, void *, socklen_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, socklen_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, void *, socklen_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, socklen_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, void *, unsigned int, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, unsigned int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, void *, unsigned int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, void *, unsigned int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, size_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, size_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, size_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, size_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, int, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, socklen_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, socklen_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, socklen_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, socklen_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, unsigned int, int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, unsigned int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(int, char *, unsigned int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(int, char *, unsigned int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, size_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, size_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, size_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, size_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, int, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, socklen_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, socklen_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, socklen_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, socklen_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, unsigned int, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, unsigned int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, void *, unsigned int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, void *, unsigned int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, size_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, size_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, size_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, size_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, int, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, socklen_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, socklen_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, socklen_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, socklen_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, unsigned int, int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, unsigned int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(ssize_t, char *, unsigned int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(ssize_t, char *, unsigned int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, size_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, size_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, size_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, size_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, int, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, socklen_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, socklen_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, socklen_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, socklen_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, unsigned int, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, unsigned int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, void *, unsigned int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, void *, unsigned int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, size_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, size_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, size_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, size_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, int, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, socklen_t, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, socklen_t, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, socklen_t, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, socklen_t, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, unsigned int, int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, unsigned int, int) (curl_cv_func_recv_test) - Failed -- Performing Test int recv(SOCKET, char *, unsigned int, unsigned int) (curl_cv_func_recv_test) -- Performing Test int recv(SOCKET, char *, unsigned int, unsigned int) (curl_cv_func_recv_test) - Failed -- Performing Test ssize_t recv(int, void *, size_t, int) (curl_cv_func_recv_test) -- Performing Test ssize_t recv(int, void *, size_t, int) (curl_cv_func_recv_test) - Success -- Performing Test curl_cv_send -- Performing Test curl_cv_send - Success -- Performing Test int send(int, const void *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const void *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const void *, int, int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const void *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const void *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const void *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const void *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const void *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const void *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, int, int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, void *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, void *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, int, int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, char *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, char *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, int, int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(int, const char *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(int, const char *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const void *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const void *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, void *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, void *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, char *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, char *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(ssize_t, const char *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(ssize_t, const char *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const void *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const void *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, void *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, void *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, char *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, char *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, size_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, size_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, size_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, size_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, socklen_t, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, socklen_t, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, socklen_t, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, socklen_t, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, unsigned int, int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, unsigned int, int) (curl_cv_func_send_test) - Failed -- Performing Test int send(SOCKET, const char *, unsigned int, unsigned int) (curl_cv_func_send_test) -- Performing Test int send(SOCKET, const char *, unsigned int, unsigned int) (curl_cv_func_send_test) - Failed -- Performing Test ssize_t send(int, const void *, size_t, int) (curl_cv_func_send_test) -- Performing Test ssize_t send(int, const void *, size_t, int) (curl_cv_func_send_test) - Success -- Performing Test HAVE_MSG_NOSIGNAL -- Performing Test HAVE_MSG_NOSIGNAL - Failed -- Performing Test HAVE_STRUCT_TIMEVAL -- Performing Test HAVE_STRUCT_TIMEVAL - Success -- Check size of sig_atomic_t -- Check size of sig_atomic_t - done -- Performing Test HAVE_SIG_ATOMIC_T_NOT_VOLATILE -- Performing Test HAVE_SIG_ATOMIC_T_NOT_VOLATILE - Success -- Check size of struct sockaddr_storage -- Check size of struct sockaddr_storage - done -- Found ZLIB: cmzlib -- Found BZip2: cmbzip2 (found version "1.0.5") -- Looking for BZ2_bzCompressInit in cmbzip2 -- Looking for BZ2_bzCompressInit in cmbzip2 - not found -- Performing Test HAVE_DIRENT_H -- Performing Test HAVE_DIRENT_H - Success -- Looking for include files sys/types.h, acl/libacl.h -- Looking for include files sys/types.h, acl/libacl.h - not found -- Looking for include files sys/types.h, ctype.h -- Looking for include files sys/types.h, ctype.h - found -- Looking for 3 include files sys/types.h, ..., copyfile.h -- Looking for 3 include files sys/types.h, ..., copyfile.h - not found -- Looking for 3 include files sys/types.h, ..., direct.h -- Looking for 3 include files sys/types.h, ..., direct.h - not found -- Looking for 5 include files sys/types.h, ..., ext2fs/ext2_fs.h -- Looking for 5 include files sys/types.h, ..., ext2fs/ext2_fs.h - not found -- Performing Test HAVE_WORKING_EXT2_IOC_GETFLAGS -- Performing Test HAVE_WORKING_EXT2_IOC_GETFLAGS - Failed -- Looking for 6 include files sys/types.h, ..., grp.h -- Looking for 6 include files sys/types.h, ..., grp.h - found -- Looking for 8 include files sys/types.h, ..., langinfo.h -- Looking for 8 include files sys/types.h, ..., langinfo.h - found -- Looking for 10 include files sys/types.h, ..., linux/types.h -- Looking for 10 include files sys/types.h, ..., linux/types.h - not found -- Looking for 10 include files sys/types.h, ..., linux/fiemap.h -- Looking for 10 include files sys/types.h, ..., linux/fiemap.h - not found -- Looking for 10 include files sys/types.h, ..., linux/fs.h -- Looking for 10 include files sys/types.h, ..., linux/fs.h - not found -- Looking for 10 include files sys/types.h, ..., linux/magic.h -- Looking for 10 include files sys/types.h, ..., linux/magic.h - not found -- Looking for 12 include files sys/types.h, ..., paths.h -- Looking for 12 include files sys/types.h, ..., paths.h - not found -- Looking for 12 include files sys/types.h, ..., poll.h -- Looking for 12 include files sys/types.h, ..., poll.h - found -- Looking for 14 include files sys/types.h, ..., regex.h -- Looking for 14 include files sys/types.h, ..., regex.h - found -- Looking for 16 include files sys/types.h, ..., spawn.h -- Looking for 16 include files sys/types.h, ..., spawn.h - found -- Looking for 17 include files sys/types.h, ..., stdarg.h -- Looking for 17 include files sys/types.h, ..., stdarg.h - found -- Looking for 22 include files sys/types.h, ..., sys/acl.h -- Looking for 22 include files sys/types.h, ..., sys/acl.h - found -- Looking for 23 include files sys/types.h, ..., sys/cdefs.h -- Looking for 23 include files sys/types.h, ..., sys/cdefs.h - not found -- Looking for 24 include files sys/types.h, ..., sys/mkdev.h -- Looking for 24 include files sys/types.h, ..., sys/mkdev.h - found -- Looking for 25 include files sys/types.h, ..., sys/mount.h -- Looking for 25 include files sys/types.h, ..., sys/mount.h - found -- Looking for 30 include files sys/types.h, ..., sys/statfs.h -- Looking for 30 include files sys/types.h, ..., sys/statfs.h - found -- Looking for 31 include files sys/types.h, ..., sys/statvfs.h -- Looking for 31 include files sys/types.h, ..., sys/statvfs.h - found -- Looking for 35 include files sys/types.h, ..., sys/vfs.h -- Looking for 35 include files sys/types.h, ..., sys/vfs.h - found -- Looking for 36 include files sys/types.h, ..., sys/wait.h -- Looking for 36 include files sys/types.h, ..., sys/wait.h - found -- Looking for 40 include files sys/types.h, ..., wchar.h -- Looking for 40 include files sys/types.h, ..., wchar.h - found -- Looking for 41 include files sys/types.h, ..., wctype.h -- Looking for 41 include files sys/types.h, ..., wctype.h - found -- Looking for 42 include files sys/types.h, ..., windows.h -- Looking for 42 include files sys/types.h, ..., windows.h - not found -- Looking for 42 include files sys/types.h, ..., wincrypt.h -- Looking for 42 include files sys/types.h, ..., wincrypt.h - not found -- Looking for 42 include files sys/types.h, ..., winioctl.h -- Looking for 42 include files sys/types.h, ..., winioctl.h - not found -- Performing Test SAFE_TO_DEFINE_EXTENSIONS -- Performing Test SAFE_TO_DEFINE_EXTENSIONS - Success -- Looking for MD5Init in md -- Looking for MD5Init in md - found -- Looking for _CrtSetReportMode -- Looking for _CrtSetReportMode - not found -- Looking for chflags -- Looking for chflags - not found -- Looking for chown -- Looking for chown - found -- Looking for chroot -- Looking for chroot - found -- Looking for ctime_r -- Looking for ctime_r - found -- Looking for dirfd -- Looking for dirfd - not found -- Looking for fchdir -- Looking for fchdir - found -- Looking for fchflags -- Looking for fchflags - not found -- Looking for fchmod -- Looking for fchmod - found -- Looking for fchown -- Looking for fchown - found -- Looking for fcntl -- Looking for fcntl - found -- Looking for fdopendir -- Looking for fdopendir - found -- Looking for fstat -- Looking for fstat - found -- Looking for fstatat -- Looking for fstatat - found -- Looking for fstatfs -- Looking for fstatfs - found -- Looking for fstatvfs -- Looking for fstatvfs - found -- Looking for futimens -- Looking for futimens - found -- Looking for futimes -- Looking for futimes - not found -- Looking for futimesat -- Looking for futimesat - found -- Looking for getgrgid_r -- Looking for getgrgid_r - found -- Looking for getgrnam_r -- Looking for getgrnam_r - found -- Looking for getpwnam_r -- Looking for getpwnam_r - found -- Looking for getpwuid_r -- Looking for getpwuid_r - found -- Looking for getpid -- Looking for getpid - found -- Looking for getvfsbyname -- Looking for getvfsbyname - not found -- Looking for lchflags -- Looking for lchflags - not found -- Looking for lchmod -- Looking for lchmod - not found -- Looking for lchown -- Looking for lchown - found -- Looking for link -- Looking for link - found -- Looking for lstat -- Looking for lstat - found -- Looking for lutimes -- Looking for lutimes - not found -- Looking for mbrtowc -- Looking for mbrtowc - found -- Looking for memmove -- Looking for memmove - found -- Looking for mkdir -- Looking for mkdir - found -- Looking for mkfifo -- Looking for mkfifo - found -- Looking for mknod -- Looking for mknod - found -- Looking for mkstemp -- Looking for mkstemp - found -- Looking for nl_langinfo -- Looking for nl_langinfo - found -- Looking for openat -- Looking for openat - found -- Looking for posix_spawnp -- Looking for posix_spawnp - found -- Looking for readlink -- Looking for readlink - found -- Looking for setenv -- Looking for setenv - found -- Looking for statfs -- Looking for statfs - found -- Looking for statvfs -- Looking for statvfs - found -- Looking for strchr -- Looking for strchr - found -- Looking for strerror -- Looking for strerror - found -- Looking for strncpy_s -- Looking for strncpy_s - not found -- Looking for strrchr -- Looking for strrchr - found -- Looking for symlink -- Looking for symlink - found -- Looking for timegm -- Looking for timegm - not found -- Looking for tzset -- Looking for tzset - found -- Looking for utimes -- Looking for utimes - found -- Looking for utimensat -- Looking for utimensat - found -- Looking for vfork -- Looking for vfork - found -- Looking for wcrtomb -- Looking for wcrtomb - found -- Looking for wcscmp -- Looking for wcscmp - found -- Looking for wcscpy -- Looking for wcscpy - found -- Looking for wcslen -- Looking for wcslen - found -- Looking for wctomb -- Looking for wctomb - found -- Looking for _ctime64_s -- Looking for _ctime64_s - not found -- Looking for _fseeki64 -- Looking for _fseeki64 - not found -- Looking for _get_timezone -- Looking for _get_timezone - not found -- Looking for _localtime64_s -- Looking for _localtime64_s - not found -- Looking for _mkgmtime64 -- Looking for _mkgmtime64 - not found -- Looking for cygwin_conv_path -- Looking for cygwin_conv_path - not found -- Looking for fseeko -- Looking for fseeko - found -- Looking for vprintf -- Looking for vprintf - found -- Looking for wmemcmp -- Looking for wmemcmp - found -- Looking for wmemcpy -- Looking for wmemcpy - found -- Performing Test HAVE_READDIR_R -- Performing Test HAVE_READDIR_R - Success -- Performing Test HAVE_READLINKAT -- Performing Test HAVE_READLINKAT - Failed -- Performing Test MAJOR_IN_MKDEV -- Performing Test MAJOR_IN_MKDEV - Success -- Performing Test MAJOR_IN_SYSMACROS -- Performing Test MAJOR_IN_SYSMACROS - Success -- Looking for EFTYPE -- Looking for EFTYPE - not found -- Looking for EILSEQ -- Looking for EILSEQ - found -- Looking for D_MD_ORDER -- Looking for D_MD_ORDER - not found -- Looking for INT64_MAX -- Looking for INT64_MAX - found -- Looking for INT64_MIN -- Looking for INT64_MIN - found -- Looking for UINT32_MAX -- Looking for UINT32_MAX - found -- Looking for UINT64_MAX -- Looking for UINT64_MAX - found -- Looking for SIZE_MAX -- Looking for SIZE_MAX - found -- Looking for SSIZE_MAX -- Looking for SSIZE_MAX - found -- Performing Test HAVE_STRUCT_TM_TM_GMTOFF -- Performing Test HAVE_STRUCT_TM_TM_GMTOFF - Failed -- Performing Test HAVE_STRUCT_TM___TM_GMTOFF -- Performing Test HAVE_STRUCT_TM___TM_GMTOFF - Failed -- Performing Test HAVE_STRUCT_STATFS_F_NAMEMAX -- Performing Test HAVE_STRUCT_STATFS_F_NAMEMAX - Failed -- Performing Test HAVE_STRUCT_STAT_ST_BIRTHTIME -- Performing Test HAVE_STRUCT_STAT_ST_BIRTHTIME - Failed -- Performing Test HAVE_STRUCT_STAT_ST_BIRTHTIMESPEC_TV_NSEC -- Performing Test HAVE_STRUCT_STAT_ST_BIRTHTIMESPEC_TV_NSEC - Failed -- Performing Test HAVE_STRUCT_STAT_ST_MTIMESPEC_TV_NSEC -- Performing Test HAVE_STRUCT_STAT_ST_MTIMESPEC_TV_NSEC - Failed -- Performing Test HAVE_STRUCT_STAT_ST_MTIM_TV_NSEC -- Performing Test HAVE_STRUCT_STAT_ST_MTIM_TV_NSEC - Success -- Performing Test HAVE_STRUCT_STAT_ST_MTIME_N -- Performing Test HAVE_STRUCT_STAT_ST_MTIME_N - Failed -- Performing Test HAVE_STRUCT_STAT_ST_UMTIME -- Performing Test HAVE_STRUCT_STAT_ST_UMTIME - Failed -- Performing Test HAVE_STRUCT_STAT_ST_MTIME_USEC -- Performing Test HAVE_STRUCT_STAT_ST_MTIME_USEC - Failed -- Performing Test HAVE_STRUCT_STAT_ST_BLKSIZE -- Performing Test HAVE_STRUCT_STAT_ST_BLKSIZE - Success -- Performing Test HAVE_STRUCT_STAT_ST_FLAGS -- Performing Test HAVE_STRUCT_STAT_ST_FLAGS - Failed -- Performing Test HAVE_STRUCT_STATVFS_F_IOSIZE -- Performing Test HAVE_STRUCT_STATVFS_F_IOSIZE - Failed -- Check size of short -- Check size of short - done -- Check size of int -- Check size of int - done -- Check size of long -- Check size of long - done -- Check size of long long -- Check size of long long - done -- Check size of unsigned short -- Check size of unsigned short - done -- Check size of unsigned -- Check size of unsigned - done -- Check size of unsigned long -- Check size of unsigned long - done -- Check size of unsigned long long -- Check size of unsigned long long - done -- Check size of __int64 -- Check size of __int64 - failed -- Check size of unsigned __int64 -- Check size of unsigned __int64 - failed -- Check size of int16_t -- Check size of int16_t - done -- Check size of int32_t -- Check size of int32_t - done -- Check size of int64_t -- Check size of int64_t - done -- Check size of intmax_t -- Check size of intmax_t - done -- Check size of uint8_t -- Check size of uint8_t - done -- Check size of uint16_t -- Check size of uint16_t - done -- Check size of uint32_t -- Check size of uint32_t - done -- Check size of uint64_t -- Check size of uint64_t - done -- Check size of uintmax_t -- Check size of uintmax_t - done -- Check size of dev_t -- Check size of dev_t - done -- Check size of gid_t -- Check size of gid_t - done -- Check size of id_t -- Check size of id_t - done -- Check size of mode_t -- Check size of mode_t - done -- Check size of off_t -- Check size of off_t - done -- Check size of size_t -- Check size of size_t - done -- Check size of ssize_t -- Check size of ssize_t - done -- Check size of uid_t -- Check size of uid_t - done -- Check size of pid_t -- Check size of pid_t - done -- Check size of intptr_t -- Check size of intptr_t - done -- Check size of uintptr_t -- Check size of uintptr_t - done -- Check size of wchar_t -- Check size of wchar_t - done -- Checking _FILE_OFFSET_BITS for large files -- Checking _FILE_OFFSET_BITS for large files - not needed -- Checking support for ARCHIVE_CRYPTO_MD5_LIBC -- Checking support for ARCHIVE_CRYPTO_MD5_LIBC -- not found -- Checking support for ARCHIVE_CRYPTO_RMD160_LIBC -- Checking support for ARCHIVE_CRYPTO_RMD160_LIBC -- not found -- Checking support for ARCHIVE_CRYPTO_SHA1_LIBC -- Checking support for ARCHIVE_CRYPTO_SHA1_LIBC -- not found -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBC -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBC -- not found -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBC -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBC -- not found -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBC -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBC -- not found -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBC2 -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBC2 -- not found -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBC2 -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBC2 -- not found -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBC2 -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBC2 -- not found -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBC3 -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBC3 -- not found -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBC3 -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBC3 -- not found -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBC3 -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBC3 -- not found -- Checking support for ARCHIVE_CRYPTO_MD5_LIBSYSTEM -- Checking support for ARCHIVE_CRYPTO_MD5_LIBSYSTEM -- not found -- Checking support for ARCHIVE_CRYPTO_SHA1_LIBSYSTEM -- Checking support for ARCHIVE_CRYPTO_SHA1_LIBSYSTEM -- not found -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBSYSTEM -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBSYSTEM -- not found -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBSYSTEM -- Checking support for ARCHIVE_CRYPTO_SHA384_LIBSYSTEM -- not found -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBSYSTEM -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBSYSTEM -- not found -- Checking support for ARCHIVE_CRYPTO_MD5_LIBMD -- Checking support for ARCHIVE_CRYPTO_MD5_LIBMD -- found -- Checking support for ARCHIVE_CRYPTO_RMD160_LIBMD -- Checking support for ARCHIVE_CRYPTO_RMD160_LIBMD -- not found -- Checking support for ARCHIVE_CRYPTO_SHA1_LIBMD -- Checking support for ARCHIVE_CRYPTO_SHA1_LIBMD -- not found -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBMD -- Checking support for ARCHIVE_CRYPTO_SHA256_LIBMD -- not found -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBMD -- Checking support for ARCHIVE_CRYPTO_SHA512_LIBMD -- not found -- Check if the system is big endian -- Searching 16 bit integer -- Check size of unsigned short -- Check size of unsigned short - done -- Using unsigned short -- Check if the system is big endian - big endian -- Looking for wsyncup in /usr/lib/64/libcurses.so -- Looking for wsyncup in /usr/lib/64/libcurses.so - found -- Looking for cbreak in /usr/local/lib/libncurses.a -- Looking for cbreak in /usr/local/lib/libncurses.a - found -- Looking for elf.h -- Looking for elf.h - found -- Looking for a Fortran compiler -- Looking for a Fortran compiler - NOTFOUND -- Configuring done -- Generating done -- Build files have been written to: /usr/local/build/cmake-3.0.2_SunOS5.10_sparcv9.001 --------------------------------------------- CMake has bootstrapped. Now run /usr/local/bin/gmake. node000 $ node000 $ /usr/local/bin/gmake Scanning dependencies of target cmIML_test [ 0%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test.c.o [ 0%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_ABI_C.c.o [ 0%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_INT_C.c.o [ 1%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_include_C.c.o [ 1%] Building CXX object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_ABI_CXX.cxx.o [ 1%] Building CXX object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_INT_CXX.cxx.o [ 1%] Building CXX object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_include_CXX.cxx.o Linking CXX executable cmIML_test [ 1%] Built target cmIML_test Scanning dependencies of target cmsys [ 1%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/ProcessUNIX.c.o [ 1%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/Base64.c.o [ 2%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/EncodingC.c.o [ 2%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/MD5.c.o [ 2%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/Terminal.c.o [ 2%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/System.c.o [ 3%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/String.c.o [ 3%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/Directory.cxx.o [ 3%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/DynamicLoader.cxx.o [ 3%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/EncodingCXX.cxx.o [ 3%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/Glob.cxx.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/RegularExpression.cxx.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemTools.cxx.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/CommandLineArguments.cxx.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/IOStream.cxx.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemInformation.cxx.o Linking CXX static library libcmsys.a [ 4%] Built target cmsys Scanning dependencies of target cmsysTestDynload [ 5%] Building C object Source/kwsys/CMakeFiles/cmsysTestDynload.dir/testDynload.c.o Linking C shared module libcmsysTestDynload.so [ 5%] Built target cmsysTestDynload Scanning dependencies of target cmsys_c [ 5%] Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/ProcessUNIX.c.o [ 6%] Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/Base64.c.o [ 6%] Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/EncodingC.c.o [ 6%] Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/MD5.c.o [ 6%] Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/Terminal.c.o [ 6%] Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/System.c.o [ 7%] Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/String.c.o Linking C static library libcmsys_c.a [ 7%] Built target cmsys_c Scanning dependencies of target cmsysTestProcess [ 7%] Building C object Source/kwsys/CMakeFiles/cmsysTestProcess.dir/testProcess.c.o Linking C executable cmsysTestProcess [ 7%] Built target cmsysTestProcess Scanning dependencies of target cmsysTestSharedForward [ 7%] Building C object Source/kwsys/CMakeFiles/cmsysTestSharedForward.dir/testSharedForward.c.o Linking C executable cmsysTestSharedForward [ 7%] Built target cmsysTestSharedForward Scanning dependencies of target cmsysTestsC [ 7%] Building C object Source/kwsys/CMakeFiles/cmsysTestsC.dir/cmsysTestsC.c.o [ 8%] Building C object Source/kwsys/CMakeFiles/cmsysTestsC.dir/testEncode.c.o [ 8%] Building C object Source/kwsys/CMakeFiles/cmsysTestsC.dir/testTerminal.c.o Linking C executable cmsysTestsC [ 8%] Built target cmsysTestsC Scanning dependencies of target cmsysTestsCxx [ 8%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/cmsysTestsCxx.cxx.o [ 8%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testAutoPtr.cxx.o [ 8%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testHashSTL.cxx.o [ 9%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testIOS.cxx.o [ 9%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testSystemTools.cxx.o [ 9%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testCommandLineArguments.cxx.o [ 9%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testCommandLineArguments1.cxx.o [ 10%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testEncoding.cxx.o [ 10%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testFStream.cxx.o [ 10%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testSystemInformation.cxx.o [ 10%] Building CXX object Source/kwsys/CMakeFiles/cmsysTestsCxx.dir/testDynamicLoader.cxx.o Linking CXX executable cmsysTestsCxx [ 10%] Built target cmsysTestsCxx Scanning dependencies of target cmzlib [ 10%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/adler32.c.o [ 10%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/compress.c.o [ 10%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/crc32.c.o [ 11%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/deflate.c.o [ 11%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/gzio.c.o [ 11%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/inffast.c.o [ 11%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/inflate.c.o [ 11%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/inftrees.c.o [ 12%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/trees.c.o [ 12%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/uncompr.c.o [ 12%] Building C object Utilities/cmzlib/CMakeFiles/cmzlib.dir/zutil.c.o Linking C static library libcmzlib.a [ 12%] Built target cmzlib Scanning dependencies of target cmcurl [ 13%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/base64.c.o [ 13%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/connect.c.o [ 13%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/content_encoding.c.o [ 13%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/cookie.c.o [ 13%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/dict.c.o [ 14%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/easy.c.o [ 14%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/escape.c.o [ 14%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/file.c.o [ 14%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/formdata.c.o [ 15%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/ftp.c.o [ 15%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/getenv.c.o [ 15%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/getinfo.c.o [ 15%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/gtls.c.o [ 15%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hash.c.o [ 16%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hostares.c.o [ 16%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hostasyn.c.o [ 16%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hostip4.c.o [ 16%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hostip6.c.o [ 16%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hostip.c.o [ 17%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hostsyn.c.o [ 17%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/hostthre.c.o [ 17%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/http.c.o [ 17%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/http_chunks.c.o [ 18%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/http_digest.c.o [ 18%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/http_negotiate.c.o [ 18%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/http_ntlm.c.o [ 18%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/if2ip.c.o [ 18%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/inet_ntop.c.o [ 19%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/inet_pton.c.o [ 19%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/krb4.c.o [ 19%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/ldap.c.o [ 19%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/llist.c.o [ 20%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/md5.c.o [ 20%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/mprintf.c.o [ 20%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/multi.c.o [ 20%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/netrc.c.o [ 20%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/parsedate.c.o [ 21%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/progress.c.o [ 21%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/security.c.o [ 21%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/select.c.o [ 21%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/sendf.c.o [ 22%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/share.c.o [ 22%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/socks.c.o [ 22%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/speedcheck.c.o [ 22%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/splay.c.o [ 22%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/ssh.c.o [ 23%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/sslgen.c.o [ 23%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/ssluse.c.o [ 23%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/strdup.c.o [ 23%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/strequal.c.o [ 23%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/strerror.c.o [ 24%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/telnet.c.o [ 24%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/tftp.c.o [ 24%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/timeval.c.o [ 24%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/transfer.c.o [ 25%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/url.c.o [ 25%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/version.c.o Linking C static library libcmcurl.a [ 25%] Built target cmcurl Scanning dependencies of target LIBCURL [ 25%] Building C object Utilities/cmcurl/CMakeFiles/LIBCURL.dir/Testing/curltest.c.o Linking C executable LIBCURL [ 25%] Built target LIBCURL Scanning dependencies of target cmcompress [ 25%] Building C object Utilities/cmcompress/CMakeFiles/cmcompress.dir/cmcompress.c.o Linking C static library libcmcompress.a [ 25%] Built target cmcompress Scanning dependencies of target cmbzip2 [ 25%] Building C object Utilities/cmbzip2/CMakeFiles/cmbzip2.dir/blocksort.c.o [ 25%] Building C object Utilities/cmbzip2/CMakeFiles/cmbzip2.dir/huffman.c.o [ 25%] Building C object Utilities/cmbzip2/CMakeFiles/cmbzip2.dir/crctable.c.o [ 25%] Building C object Utilities/cmbzip2/CMakeFiles/cmbzip2.dir/randtable.c.o [ 26%] Building C object Utilities/cmbzip2/CMakeFiles/cmbzip2.dir/compress.c.o [ 26%] Building C object Utilities/cmbzip2/CMakeFiles/cmbzip2.dir/decompress.c.o [ 26%] Building C object Utilities/cmbzip2/CMakeFiles/cmbzip2.dir/bzlib.c.o "/usr/local/build/cmake-3.0.2/Utilities/cmbzip2/bzlib.c", line 857: warning: statement not reached "/usr/local/build/cmake-3.0.2/Utilities/cmbzip2/bzlib.c", line 1218: warning: statement not reached Linking C static library libcmbzip2.a [ 26%] Built target cmbzip2 Scanning dependencies of target cmlibarchive [ 27%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_acl.c.o [ 27%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_check_magic.c.o [ 27%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_cmdline.c.o [ 27%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_crypto.c.o [ 28%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_entry.c.o [ 28%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_entry_copy_stat.c.o [ 28%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_entry_link_resolver.c.o [ 28%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_entry_sparse.c.o [ 28%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_entry_stat.c.o [ 29%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_entry_strmode.c.o [ 29%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_entry_xattr.c.o [ 29%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_getdate.c.o [ 29%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_match.c.o [ 29%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_options.c.o [ 30%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_pathmatch.c.o [ 30%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_ppmd7.c.o [ 30%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_rb.c.o [ 30%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read.c.o [ 31%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_append_filter.c.o [ 31%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_data_into_fd.c.o [ 31%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_disk_entry_from_file.c.o [ 31%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_disk_posix.c.o [ 31%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_disk_set_standard_lookup.c.o [ 32%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_extract.c.o [ 32%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_open_fd.c.o [ 32%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_open_file.c.o [ 32%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_open_filename.c.o [ 33%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_open_memory.c.o [ 33%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_set_format.c.o [ 33%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_set_options.c.o [ 33%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_all.c.o [ 33%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_bzip2.c.o [ 34%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_compress.c.o [ 34%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_gzip.c.o [ 34%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_grzip.c.o [ 34%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_lrzip.c.o [ 34%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_lzop.c.o [ 35%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_none.c.o [ 35%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_program.c.o [ 35%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_rpm.c.o [ 35%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_uu.c.o [ 36%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_xz.c.o [ 36%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_7zip.c.o [ 36%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_all.c.o [ 36%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_ar.c.o [ 36%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_by_code.c.o [ 37%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_cab.c.o [ 37%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_cpio.c.o [ 37%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_empty.c.o [ 37%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_iso9660.c.o [ 38%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_lha.c.o [ 38%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_mtree.c.o [ 38%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_rar.c.o [ 38%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_raw.c.o [ 38%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_tar.c.o [ 39%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_xar.c.o [ 39%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_format_zip.c.o [ 39%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_string.c.o [ 39%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_string_sprintf.c.o [ 39%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_util.c.o [ 40%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_virtual.c.o [ 40%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write.c.o [ 40%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_disk_acl.c.o [ 40%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_disk_posix.c.o [ 41%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_disk_set_standard_lookup.c.o [ 41%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_open_fd.c.o [ 41%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_open_file.c.o [ 41%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_open_filename.c.o [ 41%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_open_memory.c.o [ 42%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter.c.o [ 42%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_b64encode.c.o [ 42%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_by_name.c.o [ 42%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_bzip2.c.o [ 43%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_compress.c.o [ 43%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_grzip.c.o [ 43%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_gzip.c.o [ 43%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_lrzip.c.o [ 43%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_lzop.c.o [ 44%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_none.c.o [ 44%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_program.c.o [ 44%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_uuencode.c.o [ 44%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_add_filter_xz.c.o [ 45%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format.c.o [ 45%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_7zip.c.o [ 45%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_ar.c.o [ 45%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_by_name.c.o [ 45%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_cpio.c.o [ 46%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_cpio_newc.c.o [ 46%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_gnutar.c.o [ 46%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_iso9660.c.o [ 46%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_mtree.c.o [ 46%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_pax.c.o [ 47%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_shar.c.o [ 47%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_ustar.c.o [ 47%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_v7tar.c.o [ 47%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_xar.c.o [ 48%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_zip.c.o [ 48%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_options.c.o [ 48%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/filter_fork_posix.c.o Linking C static library libcmlibarchive.a [ 48%] Built target cmlibarchive Scanning dependencies of target cmexpat [ 48%] Building C object Utilities/cmexpat/CMakeFiles/cmexpat.dir/xmlparse.c.o [ 48%] Building C object Utilities/cmexpat/CMakeFiles/cmexpat.dir/xmltok.c.o [ 48%] Building C object Utilities/cmexpat/CMakeFiles/cmexpat.dir/xmlrole.c.o Linking C static library libcmexpat.a [ 48%] Built target cmexpat Scanning dependencies of target cmForm [ 48%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 46: cannot find include file: "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 93: error: syntax error before or at: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 120: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 120: warning: syntax requires ";" after last struct/union member "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 110: error: zero-sized struct/union "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 144: error: syntax error before or at: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 291: error: syntax error before or at: ( "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 290: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292: error: syntax error before or at: * "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292: error: syntax error before or at: ) "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 293: warning: old-style declaration or incorrect type for: link_fieldtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 297: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 297: warning: undefined or missing type for: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 296: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: error: syntax error before or at: * "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: error: function cannot return function or array "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: error: syntax error before or at: ) "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 298: warning: syntax error: empty declaration "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 313: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 313: warning: undefined or missing type for: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 316: error: syntax error before or at: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 316: warning: undefined or missing type for: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 317: error: syntax error before or at: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 317: warning: undefined or missing type for: chtype "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 321: error: syntax error before or at: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 321: warning: undefined or missing type for: bool "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 327: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 327: error: syntax error before or at: field_fore "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 327: warning: old-style declaration or incorrect type for: field_fore "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 328: warning: old-style declaration or incorrect type for: field_back "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: error: identifier redeclared: bool current : int previous: function() returning int : "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 292 "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: error: syntax error before or at: new_page "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 330: warning: old-style declaration or incorrect type for: new_page "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 331: warning: old-style declaration or incorrect type for: field_status "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 353: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 353: error: syntax error before or at: * "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 353: warning: old-style declaration or incorrect type for: form_win "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 354: warning: old-style declaration or incorrect type for: form_sub "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 365: error: syntax error before or at: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 365: warning: undefined or missing type for: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 366: error: syntax error before or at: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 366: warning: undefined or missing type for: WINDOW "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 394: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 394: error: syntax error before or at: data_ahead "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 394: warning: old-style declaration or incorrect type for: data_ahead "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 395: warning: old-style declaration or incorrect type for: data_behind "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 124: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 124: error: syntax error before or at: _nc_Copy_Type "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 124: warning: old-style declaration or incorrect type for: _nc_Copy_Type "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 132: warning: no explicit type given "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 132: error: syntax error before or at: _nc_Internal_Validation "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.priv.h", line 132: warning: old-style declaration or incorrect type for: _nc_Internal_Validation "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 71: error: improper member use: status "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 72: error: improper member use: makearg "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 73: error: improper member use: copyarg "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c", line 74: error: improper member use: freearg cc: acomp failed for /usr/local/build/cmake-3.0.2/Source/CursesDialog/form/fld_arg.c gmake[2]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o] Error 2 gmake[1]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/all] Error 2 gmake: *** [all] Error 2 node000 $ Additional Information: Problem may be the commented out bit in Source/CursesDialog/form/form.h . . . /**************************************************************************** * Author: Juergen Pfeifer 1995,1997 * ****************************************************************************/ #ifndef FORM_H #define FORM_H #if defined(__sun__) && defined(__GNUC__) #define _MSE_INT_H #endif #include /* figure out which curses.h to include */ # if defined(CURSES_HAVE_NCURSES_H) # include # elif defined(CURSES_HAVE_NCURSES_NCURSES_H) # include # elif defined(CURSES_HAVE_NCURSES_CURSES_H) # include # else # include # endif #include #include . . . So looks like no curses.h or ncurses.h is ever include'd. By the way : node000 $ ls -lap /usr/local/include/ncurses/curses.h -rw-r--r-- 1 root bin 76233 Sep 19 2012 /usr/local/include/ncurses/curses.h In which I see : /**************************************************************************** * Author: Zeyd M. Ben-Halim 1992,1995 * * and: Eric S. Raymond * * and: Thomas E. Dickey 1996-on * ****************************************************************************/ /* $Id: curses.h.in,v 1.220 2011/01/22 19:47:20 tom Exp $ */ ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-20 14:05 dev New Issue ====================================================================== From tobias.hunger at gmail.com Sat Sep 20 15:57:25 2014 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sat, 20 Sep 2014 21:57:25 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration Message-ID: Hello! Sorry for breaking the threading, I only joined this ML just now to comment on this thread:-) Thanks Stephen for pointing me here! I am not a regular cmake user (used to be a couple of years ago), but I im interested in this topic since I work on Qt Creator. While cmake currently is not our focus, I would personally like to see better cmake integration into our tool. Unfortunately I do not have the time to work on this myself:-/ I do want to provide some input to this discussion though. >From my experience we would need a bit more information than proposed in http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=1100 This is the structure suggested for each target: { "name": "testc1", "type": "STATIC_LIBRARY", "directory": "/tmp/COnly-bld", "location": "/tmp/COnly-bld//libtestc1.a", "exportName": "testc1", "backtrace": ["/tmp/COnly-src/CMakeLists.txt:6"], "installed": false }, That information will be valuable. I would love to see two additional field with information: The first is should this be run in a terminal or is this a GUI. Not sure whether cmake has that information. 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. 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. 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. 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. The general list can be clutched around by just assuming that all source files in the current project directory belong to the project. But how can I know that "something_win.h" will not be used when building on my Linux box? Best Regards, Tobias From joubert.sy at gmail.com Sat Sep 20 16:55:01 2014 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Sat, 20 Sep 2014 22:55:01 +0200 Subject: [cmake-developers] [PATCH] Prevent compilers to be silently modified when using Ninja, generator Message-ID: <541DE9A5.6060902@gmail.com> Hi, Please find attached a patch that fixes Ninja generator. Unlike Unix Makefiles generator it was possible to change compiler path without being notified, without the cache being deleted and more important the generated Ninja solution was not updated with the new compilers while the CMake cache was. I also activated the tests for this feature when building/testing CMake using Ninja Regards, Sylvain -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Prevent-compilers-to-be-silently-modified-when-using.patch Type: text/x-patch Size: 1840 bytes Desc: not available URL: From nilsgladitz at gmail.com Sat Sep 20 17:53:38 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sat, 20 Sep 2014 23:53:38 +0200 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: References: Message-ID: <541DF762.2000107@gmail.com> On 20.09.2014 23:31, Roland Schulz wrote: > Hi, > > it would be nice if there were a way to emulate rpath under Windows. > As far as I can see there are two possible approaches: > - Generate a shell script which sets PATH > - Generate a manifest for the application and a manifest for the > dependencies. > http://sourceforge.net/p/mingw-w64/mailman/message/30019971/ has an > example of how to do it. > > To generate either the script or the manifest, all paths to the all > required libraries need to be queried for an executable target. Then > those paths could be put into the script/manifest with e.g. > coonfigure_file. Those paths correspond to those used to set the rpath. I suppose it might be slightly more complex given that the import library that is being linked to and the DLL that corresponds to the import library might not be in the same location (and cmake might know the location of the one but not always the location of the the other). > This functionality has been suggested in this issue: > http://www.cmake.org/Bug/bug_relationship_graph.php?bug_id=10449 > The issue has been suspended with a comment that this idea, needs more > discussion on the mailing list first. Brad probably meant the developer's rather than the user's mailing list. (I am sending this reply to both) Nils From ono at java.pl Sun Sep 21 12:45:24 2014 From: ono at java.pl (Adam Strzelecki) Date: Sun, 21 Sep 2014 18:45:24 +0200 Subject: [cmake-developers] [PATCH] stage/compact-status-log Message-ID: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> I have pushed new branch stage/compact-status-log for review. Idea behind is to reduce cmake output when we are in terminal. When we are outputting message "Trying feature" we can later remove it when new output comes using ANSI escape codes. This is done by appending (but not flushing) \e[9999D\e[K to stdout. Once new status comes and flushes stdout (explicitly or implicitly by \n) these codes will be executed and will clear the line, so we get: Trying some feature - success Instead of: Trying some feature Trying some feature - success NOTE this behavior only applies to terminal (isatty check), so when piping cmake output to file is works as before. Waiting for your feedback. --Adam commit 224a515538f9574af80bb8a2d28525a44039ead7 Author: Adam Strzelecki Date: Sun Sep 21 18:29:33 2014 +0200 Use message(CLEAR "...") when starting checks This emits more compact logs when cmake is running in terminal. commit 61b57ec4549606bcafdfc2f5579c570ab8644b53 Author: Adam Strzelecki Date: Sun Sep 21 18:22:40 2014 +0200 message(...) function now accepts CLEAR keyword Status text emitted with message(CLEAR "...") will be immediately cleared when next stdout output arrives. This ensures we get more compact message logs, e.g.: Trying some feature - success Instead of: Trying some feature Trying some feature - success From dev at cor0.com Sun Sep 21 12:53:14 2014 From: dev at cor0.com (dev) Date: Sun, 21 Sep 2014 12:53:14 -0400 (EDT) Subject: [cmake-developers] =?utf-8?q?cc=3A_=E2=80=8Bacomp_failed_forSour?= =?utf-8?b?4oCLY2UvQ3Vyc2VzRGlhbG9nL2Zvcm3igIsvZmxkX2FyZy5j4oCL?= Message-ID: <1620003916.19615.1411318394744.JavaMail.vpopmail@webmail2.networksolutionsemail.com> Ran into what looks like a small issue : [ 48%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o "/usr/local/build/cmake-3.0.2/Source/CursesDialog/form/form.h", line 46: cannot find include file: which is odd because I do have /usr/local/include/ncurses/curses.h which says inside it : /* $Id: curses.h.in,v 1.220 2011/01/22 19:47:20 tom Exp $ */ So I am thinking somehow that the -I/usr/local/include was ignored or some other such nuisance. Any hints ? dev documented to death here : http://public.kitware.com/Bug/view.php?id=15166 From ono at java.pl Sun Sep 21 14:34:15 2014 From: ono at java.pl (Adam Strzelecki) Date: Sun, 21 Sep 2014 20:34:15 +0200 Subject: [cmake-developers] [PATCH] stage/fix-OSX-bundle-rpaths-and-Qt5 In-Reply-To: References: <1409917844-28297-3-git-send-email-ono@java.pl> <1579949.fFJZQIyjfv@stryke> <5905178.NbCzcQviLF@stryke> Message-ID: <2C02EADD-4EAB-4E30-BB4E-B3989F01CB7A@java.pl> FYI I pushed updated branch stage/fix-OSX-bundle-rpaths-and-Qt5 with reworked codesign fix at e6cdf62d3a7d8b30466bb82f04026f8a06222c8a. The previous worked well for <= 10.9.4, but doesn't work anymore. Since 10.9.5 there is new policy that prevents codesign when bundle contains framework with invalid layout, this commit tries to fix the layout (which is the case of Qt frameworks!). https://developer.apple.com/library/mac/technotes/tn2206 Altogether with this updated commit it now builds CMake.app well again with Qt5 and it can be code signed with: codesign -s 'Developer ID' --deep CMake.app on 10.9.5 and Yosemite. commit e6cdf62d3a7d8b30466bb82f04026f8a06222c8a Author: Adam Strzelecki Date: Thu Sep 4 15:01:17 2014 +0200 Framework codesign Resources/Info.plist & Current We need to ensure copied framework has proper layout with Resources/Info.plist present next to versioned binary and Current symlink in Versions: https://developer.apple.com/library/mac/technotes/tn2206 https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html If Resources/ is not present we may try to copy Contents/Info.plist if present to embedded Resources/Info.plist. This is a case of Qt5 that has obsolete/invalid framework layout (see QTBUG-38511). --Adam From ono at java.pl Sun Sep 21 14:48:45 2014 From: ono at java.pl (Adam Strzelecki) Date: Sun, 21 Sep 2014 20:48:45 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> Message-ID: FYI unfortunately this solution does not work for CMakeFiles.txt with cmake_minimum_required(VERSION 2.6.1) or earlier because of CMP0011 that does implicit PUSH/POP does not work there. So setting cmake_policy(SET CMP0054 NEW) is internal modules will cause this policy to be not popped and carried out of the module. This is pretty nasty surprise, since I thought this implicit PUSH/POP happened since the beginning. So currently I do not have any idea how to solve this in some elegant fashion therefore for now I removed stage/CMP0054-FindCUDA branch. Maybe you can suggest something? --Adam From ono at java.pl Sun Sep 21 14:50:46 2014 From: ono at java.pl (Adam Strzelecki) Date: Sun, 21 Sep 2014 20:50:46 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> Message-ID: Addendum: Maybe CMP0011 should be forced implicitly for all built-in modules? --Adam From neundorf at kde.org Sun Sep 21 16:27:49 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Sun, 21 Sep 2014 22:27:49 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <1593230.4g2cNbzx16@tuxedo.neundorf.net> References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <541C6B8D.2020404@kitware.com> <1593230.4g2cNbzx16@tuxedo.neundorf.net> Message-ID: <2678382.YpKxU8K3e4@tuxedo.neundorf.net> On Friday, September 19, 2014 21:53:40 Alexander Neundorf wrote: > On Friday, September 19, 2014 13:44:45 Brad King wrote: > ... > > > * Don't IDEs want to know the list of source files so they can > > > > be used for editing? > > > > I haven't looked at what the Extra generators produce in a > > while but since they are meant for IDEs they would be a good > > reference for the information needed. > > typically a list of targets, the command to build each target, source files > for each target, used include dirs and defines (-D) for code completion. > > > However, AFAIK there > > is not an extra generator for a multi-config generator. > > Yes. also after reading the other replies, I still don't understand why this shouldn't be a generator. If I understand correctly, this is for people who simply run cmake and later on want to use kdevelop on the existing build tree. How about simply adding support for an environment variable like "CMAKE_GENERATOR", which, when set, will be used as generator as long as no other generator has been set via -G ? KDE developers could set this variable, still run their build scripts, and later on use kdevelop. I have a hard time imagining a user who uses let's say Eclipse with the Eclipse generator, who then suddenly wants to use kdevelop on his build tree. Alex From mantis at public.kitware.com Mon Sep 22 04:22:11 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 22 Sep 2014 04:22:11 -0400 Subject: [cmake-developers] [CMake 0015167]: How to detect --debug-output and/or --trace Message-ID: <4ab9490c56e500d96601f47a0d1b560a@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15167 ====================================================================== Reported By: kurt.dupont Assigned To: ====================================================================== Project: CMake Issue ID: 15167 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-22 04:22 EDT Last Modified: 2014-09-22 04:22 EDT ====================================================================== Summary: How to detect --debug-output and/or --trace Description: I want to detect if the project is configured with --debug-output and/or --trace. I could not find a (list) of CMake variable that is set when the options are supplied. I want to pass the options on to (sub)projects integrated as external projects. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-22 04:22 kurt.dupont New Issue ====================================================================== From nilsgladitz at gmail.com Mon Sep 22 05:03:06 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 22 Sep 2014 11:03:06 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: Message-ID: <541FE5CA.7030002@gmail.com> On 09/20/2014 09:57 PM, Tobias Hunger wrote: > Hello! > > Sorry for breaking the threading, I only joined this ML just now to > comment on this thread:-) Thanks Stephen for pointing me here! > > I am not a regular cmake user (used to be a couple of years ago), but > I im interested in this topic since I work on Qt Creator. While cmake > currently is not our focus, I would personally like to see better > cmake integration into our tool. Unfortunately I do not have the time > to work on this myself:-/ > > I do want to provide some input to this discussion though. > > From my experience we would need a bit more information than proposed > in http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=1100 > > This is the structure suggested for each target: > > > { > "name": "testc1", > "type": "STATIC_LIBRARY", > "directory": "/tmp/COnly-bld", > "location": "/tmp/COnly-bld//libtestc1.a", > "exportName": "testc1", > "backtrace": ["/tmp/COnly-src/CMakeLists.txt:6"], > "installed": false > }, > > > That information will be valuable. > > I would love to see two additional field with information: > > The first is should this be run in a terminal or is this a GUI. Not > sure whether cmake has that information. At least on windows where there are distinct link time subsystems for console and gui applications the information is known; don't think it is available anywhere else(?) > > 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. That might not be necessary since CMake automatically constructs build time RPATHs by default. Might be nice for platforms where RPATHs aren't supported (e.g. Windows) though a generic, non IDE specific solution might be preferable: http://public.kitware.com/pipermail/cmake-developers/2014-September/011373.html Nils From steveire at gmail.com Mon Sep 22 09:39:24 2014 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 22 Sep 2014 15:39:24 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration References: <541FE5CA.7030002@gmail.com> Message-ID: Nils Gladitz wrote: > Might be nice for platforms where RPATHs aren't supported (e.g. Windows) > though a generic, non IDE specific solution might be preferable: > The proposed ProjectTargets.json isn't particularly IDE specific. That's only the motivation. Thanks, Steve. From nilsgladitz at gmail.com Mon Sep 22 09:42:48 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 22 Sep 2014 15:42:48 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <541FE5CA.7030002@gmail.com> Message-ID: <54202758.1060702@gmail.com> On 09/22/2014 03:39 PM, Stephen Kelly wrote: > Nils Gladitz wrote: > >> Might be nice for platforms where RPATHs aren't supported (e.g. Windows) >> though a generic, non IDE specific solution might be preferable: >> > > The proposed ProjectTargets.json isn't particularly IDE specific. That's > only the motivation. I meant it would be imo preferable if CMake could implement a solution for this directly rather than leaving it to any IDE or target buildsystem. e.g. something that would also work without an IDE (like RPATHs where currently supported). Nils From mantis at public.kitware.com Mon Sep 22 09:48:05 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 22 Sep 2014 09:48:05 -0400 Subject: [cmake-developers] [CMake 0015168]: incomplete builds with CMake, Make backend Message-ID: <5fc55f7657bb0ae2a3c1dfe2e5bea3e6@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15168 ====================================================================== Reported By: dhardy Assigned To: ====================================================================== Project: CMake Issue ID: 15168 Category: CMake Reproducibility: sometimes Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-22 09:48 EDT Last Modified: 2014-09-22 09:48 EDT ====================================================================== Summary: incomplete builds with CMake, Make backend Description: Several times recently running 'make' has resulted in incomplete builds, resulting in mysteriously failing unit tests or commits which at the time appeared fine but actually contained build errors. At least sometimes this is the result of changing "foo.h", and finding that "bar.cpp", which indirectly imports "foo.h" does not get rebuilt whenever touching foo.h. Running gc with -MD does correctly tell me that bar.cpp depends on foo.h. Steps to Reproduce: Following these instructions you can get roughly the same set up I have. When I try this, however, the issue is not reproduced in the new checkout. Diffing the two build folders, I am not able to see why one should have this dependency problem and not the other. git clone https://code.google.com/p/openmalaria/ cd openmalaria git checkout ccf0d9b5b292b68a284cb72d4d83f0c0c1d97fcf mkdir build cd build ccmake .. # see https://code.google.com/p/openmalaria/wiki/UnixBuildOpenMalaria for help make -j5 # full build touch ../include/util/DecayFunction.h make # should rebuild interventions/Vaccine.cpp among others Additional Information: I have a tarball of the offending build directory for the above example, so I may be able to provide more information given specific questions. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-22 09:48 dhardy New Issue ====================================================================== From steveire at gmail.com Mon Sep 22 10:03:44 2014 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 22 Sep 2014 16:03:44 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration References: Message-ID: Tobias Hunger 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. > 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. > 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"] } ] > 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 > 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. 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. ) 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. From brad.king at kitware.com Mon Sep 22 10:07:23 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 10:07:23 -0400 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> Message-ID: <54202D1B.5040300@kitware.com> On 09/21/2014 02:48 PM, Adam Strzelecki wrote: > FYI unfortunately this solution does not work for CMakeFiles.txt > with cmake_minimum_required(VERSION 2.6.1) or earlier because of > CMP0011 that does implicit PUSH/POP does not work there. So > setting cmake_policy(SET CMP0054 NEW) is internal modules will > cause this policy to be not popped and carried out of the module. > > I do not have any idea how to solve this in some elegant fashion This is one reason I just fixed the warnings with the "super ugly" approach on some of the other modules. It is a cost we pay upstream to support older clients, but the policy will still allow cleaner code in applications. Or, one could add the explicit PUSH/POP in modules, e.g. cmake_policy(PUSH) cmake_policy(SET CMP0054 NEW) ... module code ... cmake_policy(POP) -Brad From brad.king at kitware.com Mon Sep 22 10:07:38 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 10:07:38 -0400 Subject: [cmake-developers] [CMake] Integrating ExternalData with Artifactory In-Reply-To: References: <541C7E2B.9080606@kitware.com> Message-ID: <54202D2A.5020706@kitware.com> On 09/19/2014 06:07 PM, Taylor Braun-Jones wrote: > On Fri, Sep 19, 2014 at 3:04 PM, Brad King wrote: >> I think it can be activated by a special format of an entry in >> ExternalData_URL_TEMPLATES that specifies a lookup key that maps >> to some kind of custom configuration of a .cmake script to include >> or command to launch with execute_process. > > How about defining new URL scheme like: > > externaldatacommand://<*file|module*>/<*command*> Yes, something along these lines is what I had in mind. > list(APPEND ExternalData_URL_TEMPLATES > "externaldatacommand://ArtifactoryExternalData/ARTIFACTORY_DOWNLOAD_FILE?ALGO=%(algo)&" > ) > > And inside Testing/CMake/ArtifactoryExternalData.cmake it would look like: > > function(ARTIFACTORY_DOWNLOAD_FILE file algo hash) Since CMake does not support variable evaluation in a command name, this would require configuring a file with code in it to launch for each entry of this form in the url templates list. Also CMAKE_MODULE_PATH will not be available to the ExternalData module when it is launched at build time to do the download. The include() will have to work with a full path, perhaps stored in the configured copy of "ExternalData_config.cmake.in". It could be indexed with a key. Perhaps: list(APPEND ExternalData_URL_TEMPLATES "ExternalDataCustomScript://MyFetch/%(algo)/%(hash)" ) set(ExternalData_CUSTOM_SCRIPT_MyFetch /path/to/MyFetch.cmake) The script would be include()-ed in place of the current call to _ExternalData_download_file with the part of the URL after the "MyFetch/" already parsed into some variable(s). -Brad From brad.king at kitware.com Mon Sep 22 10:07:30 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 10:07:30 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> Message-ID: <54202D22.8030708@kitware.com> On 09/21/2014 12:45 PM, Adam Strzelecki wrote: > I have pushed new branch stage/compact-status-log for review. Neat. > Idea behind is to reduce cmake output when we are in terminal. > When we are outputting message "Trying feature" we can later > remove it when new output comes using ANSI escape codes. > This is done by appending (but not flushing) \e[9999D\e[K > to stdout. What if stdout's buffer happens to fill up and flush anyway? I think the text needs to be buffered somewhere for CMake to decide whether to clear it. The message()s have to be paired somehow so that we clear the first one only if the second one is the very next message to print. > NOTE this behavior only applies to terminal (isatty check), > so when piping cmake output to file is works as before. Look at Source/kwsys/Terminal.c for detection of whether we are actually working with a terminal capable of VT100 escapes. Thanks, -Brad From brad.king at kitware.com Mon Sep 22 10:07:46 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 10:07:46 -0400 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <8D194B4B1E73A83-15CC-952@webmail-m269.sysops.aol.com> <541C6B8D.2020404@kitware.com> <1461805.58uUMPt7S5@caliban.sf-tec.de> <541C7029.7030403@kitware.com> Message-ID: <54202D32.6010206@kitware.com> On 09/20/2014 09:18 AM, Stephen Kelly wrote: > I don't know why I added it. > > There is also a 'new' > > + location += "/"; > > in that patch further down which might be removable. Thanks for pointing that one out too. I've removed both with a commit message that explains one hypothesis as to why they appeared: Remove extra slashes from LOCATION target property value http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=92b2c618 Thanks, -Brad From brad.king at kitware.com Mon Sep 22 10:07:53 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 10:07:53 -0400 Subject: [cmake-developers] [PATCH] Prevent compilers to be silently modified when using Ninja, generator In-Reply-To: <541DE9A5.6060902@gmail.com> References: <541DE9A5.6060902@gmail.com> Message-ID: <54202D39.60709@kitware.com> On 09/20/2014 04:55 PM, Sylvain Joubert wrote: > Please find attached a patch that fixes Ninja generator. Applied, thanks: Ninja: Prevent compilers to be silently modified http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6120fca8 -Brad From pascal.bach at siemens.com Mon Sep 22 10:19:10 2014 From: pascal.bach at siemens.com (Bach, Pascal) Date: Mon, 22 Sep 2014 14:19:10 +0000 Subject: [cmake-developers] [PATCH] WINCE: Add toolchain documentation for Windows CE In-Reply-To: <541C6762.4030802@kitware.com> References: <1411056230-30313-1-git-send-email-pascal.bach@siemens.com> <541B19A7.4000903@kitware.com> <355BE46A91031048906B695426A8D8E616AD3862@DEFTHW99EH4MSX.ww902.siemens.net> <541C6762.4030802@kitware.com> Message-ID: <355BE46A91031048906B695426A8D8E616AD3B80@DEFTHW99EH4MSX.ww902.siemens.net> > Thanks. I split that into two commits with slight edits, and added > my own commit to add subsections for Windows Phone and Store: > > Help: Add Cross Compiling subsections in cmake-toolchains.7 manual > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0d72451a > > Help: Add Windows CE cross-compiling to cmake-toolchains.7 manual > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=db54d872 > > Help: Add Windows Phone/Store cross-compiling to cmake-toolchains.7 > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27022166 > > Please review the result to make sure I didn't munge information > you intended to provide. > Looks fine to me. Pascal From pascal.bach at siemens.com Mon Sep 22 10:19:36 2014 From: pascal.bach at siemens.com (Pascal Bach) Date: Mon, 22 Sep 2014 16:19:36 +0200 Subject: [cmake-developers] [PATCH] VS, WINCE: Only set EntryPointSymbol for executables Message-ID: <1411395576-6621-1-git-send-email-pascal.bach@siemens.com> --- Source/cmVisualStudio10TargetGenerator.cxx | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/Source/cmVisualStudio10TargetGenerator.cxx b/Source/cmVisualStudio10TargetGenerator.cxx index 4b5c83f..e0a32a2 100644 --- a/Source/cmVisualStudio10TargetGenerator.cxx +++ b/Source/cmVisualStudio10TargetGenerator.cxx @@ -2118,7 +2118,10 @@ cmVisualStudio10TargetGenerator::ComputeLinkOptions(std::string const& config) if (this->GlobalGenerator->TargetsWindowsCE()) { linkOptions.AddFlag("SubSystem", "WindowsCE"); - linkOptions.AddFlag("EntryPointSymbol", "WinMainCRTStartup"); + if (this->Target->GetType() == cmTarget::EXECUTABLE) + { + linkOptions.AddFlag("EntryPointSymbol", "WinMainCRTStartup"); + } } else { @@ -2130,7 +2133,10 @@ cmVisualStudio10TargetGenerator::ComputeLinkOptions(std::string const& config) if (this->GlobalGenerator->TargetsWindowsCE()) { linkOptions.AddFlag("SubSystem", "WindowsCE"); - linkOptions.AddFlag("EntryPointSymbol", "mainACRTStartup"); + if (this->Target->GetType() == cmTarget::EXECUTABLE) + { + linkOptions.AddFlag("EntryPointSymbol", "mainACRTStartup"); + } } else { -- 1.7.10.4 From brad.king at kitware.com Mon Sep 22 10:24:26 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 10:24:26 -0400 Subject: [cmake-developers] [PATCH] VS, WINCE: Only set EntryPointSymbol for executables In-Reply-To: <1411395576-6621-1-git-send-email-pascal.bach@siemens.com> References: <1411395576-6621-1-git-send-email-pascal.bach@siemens.com> Message-ID: <5420311A.1010503@kitware.com> On 09/22/2014 10:19 AM, Pascal Bach wrote: > --- > Source/cmVisualStudio10TargetGenerator.cxx | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) VS, WINCE: Only set EntryPointSymbol for executables http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7aeb79f Thanks, -Brad From taylor at braun-jones.org Mon Sep 22 10:28:29 2014 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Mon, 22 Sep 2014 10:28:29 -0400 Subject: [cmake-developers] [CMake] Integrating ExternalData with Artifactory In-Reply-To: <54202D2A.5020706@kitware.com> References: <541C7E2B.9080606@kitware.com> <54202D2A.5020706@kitware.com> Message-ID: On Mon, Sep 22, 2014 at 10:07 AM, Brad King wrote: > Perhaps: > > list(APPEND ExternalData_URL_TEMPLATES > "ExternalDataCustomScript://MyFetch/%(algo)/%(hash)" > ) > set(ExternalData_CUSTOM_SCRIPT_MyFetch /path/to/MyFetch.cmake) > > The script would be include()-ed in place of the current call > to _ExternalData_download_file with the part of the URL after > the "MyFetch/" already parsed into some variable(s). > This all sounds reasonable to me. I'd love to see this land in a future CMake release. I'm willing to help if you need a tester/reviewer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at cor0.com Mon Sep 22 12:08:43 2014 From: dev at cor0.com (dev) Date: Mon, 22 Sep 2014 12:08:43 -0400 (EDT) Subject: [cmake-developers] Fwd: Re: How to get a nightly build process going. Message-ID: <1440402903.30242.1411402123884.JavaMail.vpopmail@webmail2.networksolutionsemail.com> Please see last comment at http://public.kitware.com/Bug/view.php?id=15166 ---------- Original Message ---------- Date: September 1, 2014 at 2:35 PM Subject: Re: [cmake-developers] How to get a nightly build process going. Back on topic... > Solaris 10 + SolarisStudio > http://open.cdash.org/buildSummary.php?buildid=3470493 > No build failures, 4 test failures > > Solaris 10 + GCC (from OpenCSW) > http://open.cdash.org/buildSummary.php?buildid=3470687 > No build failures, 5 test failures > I dug more into the test failures. 3 of the failures were due to a borked mercurial install on the machine, i.e. not a cmake problem but a system problem, which has since been fixed. Another was a FindGTK2 bug, which I just pushed a fix to next for. Given the _Bool fix and GTK2 fix, all tests should pass for nightly next on Solaris + suncc, and 1 failure for Solaris + GCC. So once you get your nightly submissions set up, I would expect a clean Solaris Studio build and test and a clean GCC build with 1 test failure. From ono at java.pl Mon Sep 22 12:26:45 2014 From: ono at java.pl (Adam Strzelecki) Date: Mon, 22 Sep 2014 18:26:45 +0200 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <54202D22.8030708@kitware.com> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> Message-ID: > What if stdout's buffer happens to fill up and flush anyway? I think I can provide other terminal-less solution via filtering stdout and stderr via pipe and background thread. I got some proof-of-concept program already. Idea is: stdout & stderr are duped and proxied by some background thread. (1) When background thread finds a line beginning with '--' on stdout then it writes it to real stdout without trailing new line, and stores it in some lookup variable (2a) When something new that comes to stdout begins exactly the same as previous line (previous line is prefix of new coming line) then only the difference suffix is wrote out to stdout (2b) Otherwise when anything new comes to stderr or stdout that does not start exactly as previous line then suspended new line and new coming text is wrote to real stderr/stdout This should effectively compact all successive try & success/fail lines together is there was no other output in between them. Also this will require absolutely no changes in .cmake files or any cmake commands. WDYT? --Adam From brad.king at kitware.com Mon Sep 22 12:37:25 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 12:37:25 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> Message-ID: <54205045.1060607@kitware.com> On 09/22/2014 12:26 PM, Adam Strzelecki wrote: > stdout & stderr are duped and proxied by some background thread. IMO that is too much infrastructure to solve what is essentially a cosmetic problem. -Brad From brad.king at kitware.com Mon Sep 22 12:50:18 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 22 Sep 2014 12:50:18 -0400 Subject: [cmake-developers] How to get a nightly build process going. In-Reply-To: <1440402903.30242.1411402123884.JavaMail.vpopmail@webmail2.networksolutionsemail.com> References: <1440402903.30242.1411402123884.JavaMail.vpopmail@webmail2.networksolutionsemail.com> Message-ID: <5420534A.80101@kitware.com> On 09/22/2014 12:08 PM, dev wrote: > Please see last comment at > http://public.kitware.com/Bug/view.php?id=15166 [snip] > Your nightly process needs to have mercurial around it seems and not > subversion or git which I have. Only git is needed. If hg or svn is available some extra tests are activated, but they are not required. > I also think that cmake nightly needs "cmake" to be around also. The nightly process is driven by "ctest" so you need to bootstrap a CMake to get that first. You don't need ccmake for that. Once one version is installed it can be used to run nightly testing for the nightly versions. Chuck's fixes are in our 'master' branch now so you can check out from there and try bootstrapping with: ../cmake/bootstrap -- -DBUILD_CursesDialog=OFF make Then use the resulting "bin/ctest" to drive the dashboard script: http://www.cmake.org/Wiki/CMake/Git/Dashboard -Brad From ono at java.pl Mon Sep 22 15:08:15 2014 From: ono at java.pl (Adam Strzelecki) Date: Mon, 22 Sep 2014 21:08:15 +0200 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <54205045.1060607@kitware.com> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> Message-ID: <98B3C804-F496-4879-8686-6141639E8B71@java.pl> > IMO that is too much infrastructure to solve what is essentially > a cosmetic problem. Well, IMHO it is usability problem, because cmake emits simply too much (redundant) information. FYI I have pushed new stage/compact-status-log which does include this automatic subsequent status log line merging facility without using any ANSI escape sequences or any changes to .cmake files and it works with any UNIX having pipe, select & pthreads. What's more good it works regardless if cmake output is piped to file or goes directly terminal. Here's a commit log: commit e464a698e773dcbaba26b5af0327561312717b58 Author: Adam Strzelecki Date: Mon Sep 22 20:53:48 2014 +0200 Automatically compact two subsequent status lines This is done with background thread acting as stdout/stderr proxy monitoring subsequent lines emitted to stdout. Only lines beginning with "--" (status lines) are considered. If previously emitted line is a prefix to currently emitted line then this line gets merged, e.g.: -- Looking for iconv.h -- Looking for iconv.h - Found Is replaced with: -- Looking for iconv.h - Found However if there is any output both on stdout and stderr in between then the merging is not executed, e.g: -- Looking for iconv.h -- Cannot compile test.c -- Looking for iconv.h - Not found This currently works only on UNIX. And the results when running cmake on cmake: $ /tmp/cmake.PTeJch9J/bin/cmake ~/Code/SDK/cmake -- The C compiler identification is AppleClang 6.0.0.6000054 -- The CXX compiler identification is AppleClang 6.0.0.6000054 -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info - done -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream - found -- Check for STD namespace - found -- Check for ANSI scope - found -- Check for sstream - found -- Looking for unsetenv - found -- Looking for environ - not found -- Checking whether header cstdio is available - yes -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available - yes -- Checking whether stl string has operator!= for char* - yes -- Checking whether stl has iterator_traits - yes -- Checking whether stl has standard template allocator - yes -- Checking for rebind member of stl allocator - yes -- Checking for non-standard argument to stl allocator<>::max_size - no -- Checking whether stl containers support allocator objects. - yes -- Checking whether ios has binary openmode - yes -- Checking whether "<>" is needed for template friends - yes -- Checking for member template support - yes -- Checking for standard template specialization syntax - yes -- Checking whether argument dependent lookup is supported - yes -- Checking whether struct stat has st_mtim member - no -- Checking whether C++ compiler has 'long long' - yes -- Checking whether C++ compiler has '__int64' - no -- Checking for C type size macros - compiled -- Looking for sys/types.h - found -- Looking for stdint.h - found -- Looking for stddef.h - found Versus old non-compact cmake: $ /Volumes/cmake-3.0.2-Darwin64-universal/CMake.app/Contents/bin/cmake ~/Code/SDK/cmake -- The C compiler identification is AppleClang 6.0.0.6000054 -- The CXX compiler identification is AppleClang 6.0.0.6000054 -- 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 -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available -- Checking whether header cstddef is available - yes -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator!= for char* - yes -- Checking whether stl has iterator_traits -- Checking whether stl has iterator_traits - yes -- Checking whether stl has standard template allocator -- Checking whether stl has standard template allocator - yes -- Checking for rebind member of stl allocator -- Checking for rebind member of stl allocator - yes -- Checking for non-standard argument to stl allocator<>::max_size -- Checking for non-standard argument to stl allocator<>::max_size - no -- Checking whether stl containers support allocator objects. -- Checking whether stl containers support allocator objects. - yes -- Checking whether ios has binary openmode -- Checking whether ios has binary openmode - yes -- Checking whether "<>" is needed for template friends -- Checking whether "<>" is needed for template friends - yes -- Checking for member template support -- Checking for member template support - yes -- Checking for standard template specialization syntax -- Checking for standard template specialization syntax - yes -- Checking whether argument dependent lookup is supported -- Checking whether argument dependent lookup is supported - yes -- Checking whether struct stat has st_mtim member --Adam From mantis at public.kitware.com Mon Sep 22 15:36:45 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 22 Sep 2014 15:36:45 -0400 Subject: [cmake-developers] [CMake 0015169]: CPackRPM: component-specific settings "fall through" to next component Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15169 ====================================================================== Reported By: Sam Hartsfield Assigned To: ====================================================================== Project: CMake Issue ID: 15169 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-22 15:36 EDT Last Modified: 2014-09-22 15:36 EDT ====================================================================== Summary: CPackRPM: component-specific settings "fall through" to next component Description: When component support is enabled in CPackRPM, component-specific settings get applied not only to the specified component, but also to any subsequent components. Some of these settings can be unset for the latter components, but some cannot (e.g. CPACK_RPM_USER_BINARY_SPECFILE). Steps to Reproduce: See attached example. For spec.in file, use a standard template (cpack -D CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE=1 -G RPM). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-22 15:36 Sam Hartsfield New Issue 2014-09-22 15:36 Sam Hartsfield File Added: CMakeLists.txt ====================================================================== From aleixpol at kde.org Mon Sep 22 19:15:40 2014 From: aleixpol at kde.org (Aleix Pol) Date: Tue, 23 Sep 2014 01:15:40 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <541C6B8D.2020404@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> Message-ID: On Fri, Sep 19, 2014 at 7:44 PM, Brad King wrote: > On 09/18/2014 08:10 PM, Aleix Pol wrote: > > I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to > > enable the generation of the file. > > I also renamed the file to ProjectTargets.json. > > > > http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch > > Thanks. I made some style updates and converted it to a patch > generated with 'git format-patch'. See attached. I also > attached a sample ProjectTargets.json generated for the "COnly" > test from our test suite. > Cool! Thanks a lot for taking your time to look into this! > > I'd really like to hear from others on the file format itself. > > Some comments on the format: > > * A version number field is needed at the top. > Sure, can't hurt. So you'd encapsulate it such as: { version: "1.0", targets: [...] } > > * There needs to be support for multi-config generators. > Perhaps everything that can be affected by the configuration > needs to be inside a list that enumerates all configurations. > In single-configuration generators the list would have only > one entry for the CMAKE_BUILD_TYPE. In multi-configuration > generators it would be all of the CMAKE_CONFIGURATION_TYPES. > I've never worked with those, but it sounds like it would make sense. What about: { version: .. configurations: { { name: "Debug", targets: [...] }, { name: "Release", targets: [...] } } } > > * Don't IDEs want to know the list of source files so they can > be used for editing? > It would probably make sense, yes. We can introduce an input field. > > I haven't looked at what the Extra generators produce in a > while but since they are meant for IDEs they would be a good > reference for the information needed. However, AFAIK there > is not an extra generator for a multi-config generator. > > -Brad > Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Sep 23 03:05:57 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 23 Sep 2014 09:05:57 +0200 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: <541DF762.2000107@gmail.com> References: <541DF762.2000107@gmail.com> Message-ID: <54211BD5.4010108@gmail.com> On 09/20/2014 11:53 PM, Nils Gladitz wrote: > On 20.09.2014 23:31, Roland Schulz wrote: >> it would be nice if there were a way to emulate rpath under Windows. >> As far as I can see there are two possible approaches: >> - Generate a shell script which sets PATH >> - Generate a manifest for the application and a manifest for the >> dependencies. >> http://sourceforge.net/p/mingw-w64/mailman/message/30019971/ has an >> example of how to do it. So I am thinking opt-in (target property) wrapper binaries that take the place of the actual binaries. e.g. # Initializes ENABLE_EXECUTABLE_WRAPPER target property set(CMAKE_ENABLE_EXECUTABLE_WRAPPER ON) add_executable(foo foo.cpp) Could produce foo.exe.real # Actual target binary foo.exe.wrapper # CMake generated configuration file foo.exe # Wrapper binary that reads "foo.exe.wrapper", sets up the environment and runs "foo.exe.real" COMMANDs (add_custom_command()/add_custom_target()/add_test()) could transparently call foo.exe (like they would have done without the wrapper). install(TARGETS) should ignore the wrapper and transparently install and rename the real binary. $ should continue to point at the real binary. A new $ could point at the wrapper binary. The wrapper binary itself could be precompiled and included with cmake itself. It would determine which configuration to read and which binary to run by inspecting its own name. I primarily had windows native builds in mind. Are there additional use cases? Nils From steveire at gmail.com Tue Sep 23 03:58:58 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 23 Sep 2014 09:58:58 +0200 Subject: [cmake-developers] Was AUTOMOC designed to run for each build? Message-ID: Hi (especially Alex), I noticed that the automoc target is run each time, even for a trivial project: cmake_minimum_required(VERSION 2.8) project(automoctest) set(CMAKE_AUTOMOC ON) find_package(Qt5Widgets REQUIRED) add_executable(main main.cpp) target_link_libraries(main Qt5::Widgets) Each time I run make I get [ 33%] Automatic moc for target main /path/to/cmake -E cmake_autogen /path/to/build/CMakeFiles/main_automoc.dir/ "" I checked CMake 2.8.7 and it executes the target each time too. In the implementation, makefile->AddUtilityCommand is called with 'true' to set the excludeFromAll parameter. I don't see why the target is executed each time, but is it that way by design? Thanks, Steve. From florent.castelli at gmail.com Tue Sep 23 04:26:52 2014 From: florent.castelli at gmail.com (Florent Castelli) Date: Tue, 23 Sep 2014 10:26:52 +0200 Subject: [cmake-developers] iOS support Message-ID: Hi! My company is organizing soon a hack week where each employee is able to work on any project he wants. So, I've decided to work with Cmake and improve support for iOS to help the product team getting rid of manual project files, constant merge conflicts and bad project file documentation, while improving our tooling possibilities (all that with Cmake!). I've had a quick look at the first issue that popped into my mind the other day and fixed try_compile by adding another variable to set the executable type in the generated project (it has to be MACOSX_BUNDLE) and fixing the search path for the resulting binary. So this is now working... Providing we are targeting the simulator. Due to the nature of Xcode projects that can easily target either the simulator or devices, thus using different compilation flags, the resulting projects aren't working in both case. There are conflicts between some options like the minimum iOS version target and the minimum iOS simulator target for example (which you need to build the try_compile binaries without signing them). Also, the Xcode support is very OSX focused and all variables have MACOSX in their name, which is confusing. So, has anyone worked on similar issues and can suggest a way to progress and improve support for iOS? In the end, I'd like to have a working Xcode project with separate settings for both simulator and device, Cmake compiler flag detection working, and possibly later Make/Ninja projects working too. Regards, /Orphis -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Tue Sep 23 07:45:51 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 23 Sep 2014 07:45:51 -0400 Subject: [cmake-developers] [CMake 0015170]: CMAKE_SYSTEM_PROCESSOR is broken on Windows Message-ID: <1cd35aa1e53b7fa428fbc40e9fb33fa5@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15170 ====================================================================== Reported By: stopiccot Assigned To: ====================================================================== Project: CMake Issue ID: 15170 Category: CMake Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-23 07:45 EDT Last Modified: 2014-09-23 07:45 EDT ====================================================================== Summary: CMAKE_SYSTEM_PROCESSOR is broken on Windows Description: According to it's description CMAKE_SYSTEM_PROCESSOR should have value of "The name of the CPU CMake is building for". On Windows x64 hosts it always has value of AMD64 no matter which architecture you are building for: x86/x64 or arm. I have a strong opinion that this behavior should be fixed cause otherwise this var is completely useless on windows. And yes I know there is a CMAKE_CL_64 var for determining what arch we are building for. But it looks like a x64-only dirty hack not a generic solution ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-23 07:45 stopiccot New Issue ====================================================================== From robert.maynard at kitware.com Tue Sep 23 08:09:38 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 23 Sep 2014 08:09:38 -0400 Subject: [cmake-developers] iOS support In-Reply-To: References: Message-ID: The lowest hanging fruit would be to transition over to setting the global variable CMAKE_MACOSX_BUNDLE which is used to initialize the MACOSX_BUNDLE property on all the targets. CMake also supports CMAKE_XCODE_ATTRIBUTE global variables to allow easy code signing etc. Lastly have you looked at setting up different toolchains for the simulator and device? On Tue, Sep 23, 2014 at 4:26 AM, Florent Castelli wrote: > Hi! > > My company is organizing soon a hack week where each employee is able to > work on any project he wants. So, I've decided to work with Cmake and > improve support for iOS to help the product team getting rid of manual > project files, constant merge conflicts and bad project file documentation, > while improving our tooling possibilities (all that with Cmake!). > > I've had a quick look at the first issue that popped into my mind the other > day and fixed try_compile by adding another variable to set the executable > type in the generated project (it has to be MACOSX_BUNDLE) and fixing the > search path for the resulting binary. > So this is now working... Providing we are targeting the simulator. > Due to the nature of Xcode projects that can easily target either the > simulator or devices, thus using different compilation flags, the resulting > projects aren't working in both case. There are conflicts between some > options like the minimum iOS version target and the minimum iOS simulator > target for example (which you need to build the try_compile binaries without > signing them). > Also, the Xcode support is very OSX focused and all variables have MACOSX in > their name, which is confusing. > > So, has anyone worked on similar issues and can suggest a way to progress > and improve support for iOS? > In the end, I'd like to have a working Xcode project with separate settings > for both simulator and device, Cmake compiler flag detection working, and > possibly later Make/Ninja projects working too. > > Regards, > /Orphis > > > -- > > 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 DLRdave at aol.com Tue Sep 23 09:13:25 2014 From: DLRdave at aol.com (David Cole) Date: Tue, 23 Sep 2014 09:13:25 -0400 Subject: [cmake-developers] [CMake] Windows rpath emulation Message-ID: What is the problem that this feature is trying to solve? It seems unnecessary to me as a first-class feature of CMake. I must be missing something... But if you do pursue something like this, it seems to me that install(TARGETS ...) should install all files including the wrapper. Is this only for executable files, or would something like this also be possible/necessary for shared libraries, too? Slicer and ParaView do (or did in the past) have similar wrappers to set up necessary environment variables before invoking the "real" exe. Thanks, David C. On Tue, Sep 23, 2014 at 3:05 AM, Nils Gladitz wrote: > On 09/20/2014 11:53 PM, Nils Gladitz wrote: >> >> On 20.09.2014 23:31, Roland Schulz wrote: >>> >>> it would be nice if there were a way to emulate rpath under Windows. >>> As far as I can see there are two possible approaches: >>> - Generate a shell script which sets PATH >>> - Generate a manifest for the application and a manifest for the >>> dependencies. >>> http://sourceforge.net/p/mingw-w64/mailman/message/30019971/ has an >>> example of how to do it. > > > So I am thinking opt-in (target property) wrapper binaries that take the > place of the actual binaries. > > e.g. > # Initializes ENABLE_EXECUTABLE_WRAPPER target property > set(CMAKE_ENABLE_EXECUTABLE_WRAPPER ON) > > add_executable(foo foo.cpp) > > Could produce > foo.exe.real # Actual target binary > foo.exe.wrapper # CMake generated configuration file > foo.exe # Wrapper binary that reads "foo.exe.wrapper", sets up > the environment and runs "foo.exe.real" > > COMMANDs (add_custom_command()/add_custom_target()/add_test()) could > transparently call foo.exe (like they would have done without the wrapper). > > install(TARGETS) should ignore the wrapper and transparently install and > rename the real binary. > > $ should continue to point at the real binary. > A new $ could point at the wrapper binary. > > The wrapper binary itself could be precompiled and included with cmake > itself. It would determine which configuration to read and which binary to > run by inspecting its own name. > > I primarily had windows native builds in mind. > Are there additional use cases? > > 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 Tue Sep 23 09:24:58 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 23 Sep 2014 15:24:58 +0200 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: References: <541DF762.2000107@gmail.com> <54211BD5.4010108@gmail.com> Message-ID: <542174AA.3060907@gmail.com> On 09/23/2014 03:11 PM, David Cole wrote: > What is the problem that this feature is trying to solve? Being able to run binaries with DLL dependencies within the build tree. Basically the same thing that the build time RPATH feature does on e.g. linux. If you are e.g. linking to Qt5 (shared) and don't have the Qt5 bin directory in your PATH the binary will not run since it can not locate the DLL on its own. As workarounds people often copy the DLLs into their build directories, output all runtime files into a single directory and/or set up custom wrappers that set up PATH. > But if you do pursue something like this, it seems to me that > install(TARGETS ...) should install all files including the wrapper. CMake replaces build time RPATHs with installation RPATHs when deploying. I think the same should apply to these wrappers. They are only useful for a build tree. > Is this only for executable files, or would something like this also > be possible/necessary for shared libraries, too? I have been pondering DLLs as well but would restrict it to executables for now. For DLLs this probably only makes sense in a context where the DLL is build by CMake and used as-is without deployment in a context outside of CMake's control. Also I am guessing this might not be as simple to set up as it is for executables. Thanks for the feedback! Nils From bill.hoffman at kitware.com Tue Sep 23 10:06:11 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 23 Sep 2014 10:06:11 -0400 Subject: [cmake-developers] iOS support In-Reply-To: References: Message-ID: <54217E53.2070902@kitware.com> On 9/23/2014 8:09 AM, Robert Maynard wrote: > The lowest hanging fruit would be to transition over to setting the > global variable CMAKE_MACOSX_BUNDLE which is used to initialize the > MACOSX_BUNDLE property on all the targets. CMake also supports > CMAKE_XCODE_ATTRIBUTE global variables to allow easy code signing etc. > > Lastly have you looked at setting up different toolchains for the > simulator and device? We have recently looked at this problem. Setting CMAKE_MACOSX_BUNDLE in the toolchain file gets you part of the way there. However, some try_compile stuff will still fail because it can not find the app bundles. cmake_minimum_required(VERSION 2.8) project(foo) include(TestBigEndian) test_big_endian(CMAKE_WORDS_BIGENDIAN) https://github.com/Kitware/VTK/blob/master/CMake/ios.toolchain.xcode.cmake This will get you to the problem: cmake -GXcode -DCMAKE_TOOLCHAIN_FILE=../ios.toolchain.xcode.cmake .. -DIOS_PLATFORM=SIMULATOR Trouble is in cmake/Modules/CheckTypeSize.cmake where it does a try_compile with COPY_FILE. The COPY_FILE in cmCoreTryCompile.cxx does not look for the bundle option and therefore can not find the executable. However, now that I look at it, I think I might be able to fix it pretty easy. That said it would be really cool to beef up the xcode support enough to be able to create an actual ios app. I have not dug into that enough. Should be able to do most of it with CMAKE_XCODE_ATTRIBUTE. I will look into this try_compile COPY_FILE issue today and get back to the list. It would be great if you could get an example/Test in place that builds an app for a device and works with Xcode and for a stretch goal also works with makefiles or ninja. -Bill From bill.hoffman at kitware.com Tue Sep 23 10:56:22 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 23 Sep 2014 10:56:22 -0400 Subject: [cmake-developers] iOS support In-Reply-To: <54217E53.2070902@kitware.com> References: <54217E53.2070902@kitware.com> Message-ID: <54218A16.1010008@kitware.com> > That said it would be really cool to beef up the xcode support enough to > be able to create an actual ios app. I have not dug into that enough. > Should be able to do most of it with CMAKE_XCODE_ATTRIBUTE. I will > look into this try_compile COPY_FILE issue today and get back to the list. > > It would be great if you could get an example/Test in place that builds > an app for a device and works with Xcode and for a stretch goal also > works with makefiles or ninja. > Couple of more things. 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. This would be a great thing to work on. Also, Robert M reminded me that there is a test that could be extended as this stuff is developed: https://github.com/Kitware/CMake/tree/master/Tests/iOSNavApp ) as it already builds targeting the iphone simulator. -Bill From florent.castelli at gmail.com Tue Sep 23 11:42:01 2014 From: florent.castelli at gmail.com (Florent Castelli) Date: Tue, 23 Sep 2014 17:42:01 +0200 Subject: [cmake-developers] iOS support In-Reply-To: <54218A16.1010008@kitware.com> References: <54217E53.2070902@kitware.com> <54218A16.1010008@kitware.com> Message-ID: On 23 Sep 2014, at 16:56, Bill Hoffman wrote: > >> That said it would be really cool to beef up the xcode support enough to >> be able to create an actual ios app. I have not dug into that enough. >> Should be able to do most of it with CMAKE_XCODE_ATTRIBUTE. I will >> look into this try_compile COPY_FILE issue today and get back to the list. >> >> It would be great if you could get an example/Test in place that builds >> an app for a device and works with Xcode and for a stretch goal also >> works with makefiles or ninja. >> > Couple of more things. > > 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. This would be a great thing to work on. > 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. Generating projects for Makefiles or Ninja would probably require a dedicated toolchain though (or proper platform files indeed), but that can be done later. > Also, Robert M reminded me that there is a test that could be extended as this stuff is developed: > > https://github.com/Kitware/CMake/tree/master/Tests/iOSNavApp ) as it > already builds targeting the iphone simulator. > > -Bill > Nice, I will have a look! I also have a couple of patches for finding the binary during a try_compile that works with my other change to have an extra variable for the add_executable and I would need to change it. It's mostly changing cmCoreTryCompile::FindOutputFile() and adds "/" + targetName + ".app/Contents/MacOS" to the searchDirs. I'll try to pickup those toolchain files though and see how they work for me soon. I'll probably have some options to override a few things and make it find the compiler properly. Right now, it's hardcoding /usr/bin/clang and that's a no go :) (it should be found in the path or through DEVELOPER_DIR eventually). Not forcing the compiler would be sweet too (but that requires the try_compile fixup first) as it means we could use ccache or an alternative compiler (for reasons). /Orphis > > -- > > 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 bill.hoffman at kitware.com Tue Sep 23 12:18:08 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 23 Sep 2014 12:18:08 -0400 Subject: [cmake-developers] iOS support In-Reply-To: References: <54217E53.2070902@kitware.com> <54218A16.1010008@kitware.com> Message-ID: <54219D40.5010407@kitware.com> On 9/23/2014 11:42 AM, Florent Castelli wrote: > I also have a couple of patches for finding the binary during a try_compile that works with my other change to have an extra variable for the add_executable and I would need to change it. > It's mostly changing cmCoreTryCompile::FindOutputFile() and adds "/" + targetName + ".app/Contents/MacOS" to the searchDirs. I just pushed something to next that adds targetName.app. That worked for the example I was building. -Bill From roland at utk.edu Tue Sep 23 12:37:38 2014 From: roland at utk.edu (Roland Schulz) Date: Tue, 23 Sep 2014 12:37:38 -0400 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: <16db33e45f564825918f0e4e8a4c72bb@DM2PR02MB464.namprd02.prod.outlook.com> References: <541DF762.2000107@gmail.com> <54211BD5.4010108@gmail.com> <16db33e45f564825918f0e4e8a4c72bb@DM2PR02MB464.namprd02.prod.outlook.com> Message-ID: Hi, On Tue, Sep 23, 2014 at 3:05 AM, Nils Gladitz wrote: > On 09/20/2014 11:53 PM, Nils Gladitz wrote: > > On 20.09.2014 23:31, Roland Schulz wrote: > >> it would be nice if there were a way to emulate rpath under Windows. > >> As far as I can see there are two possible approaches: > >> - Generate a shell script which sets PATH > >> - Generate a manifest for the application and a manifest for the > >> dependencies. > >> http://sourceforge.net/p/mingw-w64/mailman/message/30019971/ has an > >> example of how to do it. > > So I am thinking opt-in (target property) wrapper binaries that take the > place of the actual binaries. Why do you prefer that solution over a batch script or a manifest? On Tue, Sep 23, 2014 at 9:24 AM, Nils Gladitz wrote: > On 09/23/2014 03:11 PM, David Cole wrote: > > What is the problem that this feature is trying to solve? > > Being able to run binaries with DLL dependencies within the build tree. > Basically the same thing that the build time RPATH feature does on e.g. > linux. > Why only for the build tree? Even after installing not all DLLs might be in install folder. Or would you recommend to always copy all DLLs? Even things like for e.g. for MingW the libgcc*dll? Roland -- ORNL/UT Center for Molecular Biophysics cmb.ornl.gov 865-241-1537, ORNL PO BOX 2008 MS6309 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Sep 23 12:53:57 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 23 Sep 2014 18:53:57 +0200 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: References: <541DF762.2000107@gmail.com> <54211BD5.4010108@gmail.com> <16db33e45f564825918f0e4e8a4c72bb@DM2PR02MB464.namprd02.prod.outlook.com> Message-ID: <5421A5A5.1080201@gmail.com> On 23.09.2014 18:27, Roland Schulz wrote: > > > So I am thinking opt-in (target property) wrapper binaries that > take the > place of the actual binaries. > > > Why do you prefer that solution over a batch script or a manifest? I looked at manifests but as far as I can tell they won't allow loading libraries from arbitrary locations. File references next to manifests are not allowed a path component. Libraries could at best be put in direct subdirectories next to the consuming executables. Executable wrappers can be drop in replacements for the actual executables and I was considering AddDllDirectory() over modifying PATH hoping that is less intrusive. > > On Tue, Sep 23, 2014 at 9:24 AM, Nils Gladitz > wrote: > > On 09/23/2014 03:11 PM, David Cole wrote: > > What is the problem that this feature is trying to solve? > > Being able to run binaries with DLL dependencies within the build > tree. > Basically the same thing that the build time RPATH feature does on > e.g. > linux. > > > Why only for the build tree? Even after installing not all DLLs might > be in install folder. Or would you recommend to always copy all DLLs? > Even things like for e.g. for MingW the libgcc*dll? On windows when you deploy to a system different from your own it is expected and common practice that you deploy your runtime requirements as well. You can not expect a preexisting installation of your library requirements nor can you expect them to be in the same location as in your development system. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at utk.edu Tue Sep 23 13:12:13 2014 From: roland at utk.edu (Roland Schulz) Date: Tue, 23 Sep 2014 13:12:13 -0400 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: References: <541DF762.2000107@gmail.com> <54211BD5.4010108@gmail.com> <16db33e45f564825918f0e4e8a4c72bb@DM2PR02MB464.namprd02.prod.outlook.com> Message-ID: On Tue, Sep 23, 2014 at 12:53 PM, Nils Gladitz wrote: > On 23.09.2014 18:27, Roland Schulz wrote: > > > >> So I am thinking opt-in (target property) wrapper binaries that take the >> place of the actual binaries. > > > Why do you prefer that solution over a batch script or a manifest? > > > I looked at manifests but as far as I can tell they won't allow loading > libraries from arbitrary locations. > File references next to manifests are not allowed a path component. > I think you're right. There seems to be robust way to refer to DLLs in arbitrary locations. It only works well if the DLL has a manifest in its location, because one can refer to other manifests in arbitrary locations. But that wouldn't be a general solution. Executable wrappers can be drop in replacements for the actual executables > and I was considering AddDllDirectory() over modifying PATH hoping that is > less intrusive. > Seems reasonable. Have you got a solution to the problem you mentioned in your first email: I suppose it might be slightly more complex given that the import > library that is being linked to and the DLL that corresponds to the > import library might not be in the same location (and cmake might know > the location of the one but not always the location of the the other). > On windows when you deploy to a system different from your own it is > expected and common practice that you deploy your runtime requirements as > well. > You can not expect a preexisting installation of your library requirements > nor can you expect them to be in the same location as in your development > system. > I think you are referring to making a binary cpack installation package. I was thinking about installing on the build system. Then It would still be different from the build directory. Roland -- ORNL/UT Center for Molecular Biophysics cmb.ornl.gov 865-241-1537, ORNL PO BOX 2008 MS6309 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Sep 23 13:37:42 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 23 Sep 2014 19:37:42 +0200 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: References: <541DF762.2000107@gmail.com> <54211BD5.4010108@gmail.com> <16db33e45f564825918f0e4e8a4c72bb@DM2PR02MB464.namprd02.prod.outlook.com> Message-ID: <5421AFE6.2050207@gmail.com> On 23.09.2014 19:12, Roland Schulz wrote: > > Have you got a solution to the problem you mentioned in your first email: > > I suppose it might be slightly more complex given that the import > library that is being linked to and the DLL that corresponds to the > import library might not be in the same location (and cmake might know > the location of the one but not always the location of the the other). > > - For local targets CMake does have the location (these are also interesting but the main selling point would imo be external libraries). - For imported targets CMake may have DLL locations. More likely when set up by package configuration files (e.g. Qt5 sets them) than when set up by find modules (e.g. FindQt4 does not set them). There might be incentive to add those locations when they start to be more useful. - It might be possible to guess the DLL location from a given import library (assuming it was provided with a full path); probably not something you can rely on but it might be able to guess the location often enough to be convenient - Additional locations could be provided manually by target property > On windows when you deploy to a system different from your own it > is expected and common practice that you deploy your runtime > requirements as well. > You can not expect a preexisting installation of your library > requirements nor can you expect them to be in the same location as > in your development system. > > > I think you are referring to making a binary cpack installation > package. I was thinking about installing on the build system. Then It > would still be different from the build directory. Yes, but I think that is the least common use case (maybe even more so on windows). CPack uses the same install commands for packaging and local install and I don't think CMake makes the distinction between deploying locally and remotely. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From neundorf at kde.org Tue Sep 23 16:27:51 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 23 Sep 2014 22:27:51 +0200 Subject: [cmake-developers] Was AUTOMOC designed to run for each build? In-Reply-To: References: Message-ID: <1701926.YV4YG1IxjZ@tuxedo.neundorf.net> On Tuesday, September 23, 2014 09:58:58 Stephen Kelly wrote: > Hi (especially Alex), > > I noticed that the automoc target is run each time, even for a trivial > project: > > cmake_minimum_required(VERSION 2.8) > project(automoctest) > > set(CMAKE_AUTOMOC ON) > > find_package(Qt5Widgets REQUIRED) > > add_executable(main main.cpp) > target_link_libraries(main Qt5::Widgets) > > Each time I run make I get > > [ 33%] Automatic moc for target main > /path/to/cmake -E cmake_autogen /path/to/build/CMakeFiles/main_automoc.dir/ > " > > I checked CMake 2.8.7 and it executes the target each time too. > > In the implementation, makefile->AddUtilityCommand is called with 'true' to > set the excludeFromAll parameter. > > I don't see why the target is executed each time, but is it that way by > design? iirc, yes. The moc files have to be generated before any of the source files is compiled, so automoc is in a target the actual target depends on. IIRC it is exclude_from_all so that it is only built when the actual target is built. Do you think it should only rerun if any of the source files has changed ? There was some problem with this. The headers are usually not part of the listed source files. I would have to check to find out the details again. Alex From d3ck0r at gmail.com Wed Sep 24 03:17:43 2014 From: d3ck0r at gmail.com (J Decker) Date: Wed, 24 Sep 2014 00:17:43 -0700 Subject: [cmake-developers] OpenWatcom wMake and VERBOSE=1 Message-ID: VERBOSE=1 only triggers the first level to be verbose in a make... any subsequent call to wmake passes '-s' option and not VERBOSE=1 continuously... I'm not sure where the '-s' option on wmake is coming from, browsed the code a little... but it'd be kind of nice if this feature worked. -------------- next part -------------- An HTML attachment was scrubbed... URL: From samho5888 at gmail.com Wed Sep 24 07:18:00 2014 From: samho5888 at gmail.com (Sam H.) Date: Wed, 24 Sep 2014 19:18:00 +0800 Subject: [cmake-developers] Integrate fixdep for kconfig Message-ID: Hi, 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. My scratch is attached. 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. So could any expert in CMake development give me some recommendations? Thanks, Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_kconfig.diff.gz Type: application/x-gzip Size: 2708 bytes Desc: not available URL: From ono at java.pl Wed Sep 24 08:02:25 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 24 Sep 2014 14:02:25 +0200 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <98B3C804-F496-4879-8686-6141639E8B71@java.pl> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> Message-ID: <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> FYI stage/compact-status-log was updated with more elegant C++ implementation introducing new cmStdoutFilter & cmThread utility classes enabled when certain headers are present in the system, so in cmakemain.cxx we simply put: cmStdoutFilter stdoutFilter("-- "); --Adam From ono at java.pl Wed Sep 24 08:26:55 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 24 Sep 2014 14:26:55 +0200 Subject: [cmake-developers] [OSX CMake.dmg] Replace >10.6 build with 64-bit only and use bzip2 compression Message-ID: <1AE2B46D-8E37-43C1-BAB2-F7C8D03AB26C@java.pl> Not an big issue but official DMG bundles are 40 MB where my manually built one is 21 MB (half of it). So any reason for: * providing universal FAT binaries instead of 64-bit only for >=10.6 Darwin64 build, as anyway there is 32-bit build for these who have 32-bit only CPU? * using DMG zlib compression instead bzip2 for all builds which is available for 10.4+ and provides much better compression ratio? --Adam From mornymorny at gmail.com Wed Sep 24 08:28:38 2014 From: mornymorny at gmail.com (Christopher Maughan) Date: Wed, 24 Sep 2014 13:28:38 +0100 Subject: [cmake-developers] Windows shader compile options Message-ID: I've been playing with the Windows shader options. I can see that it's now possible to set the following: set_property(SOURCE ${PIXELSHADER_FILES} PROPERTY VS_SHADER_TYPE Pixel) set_property(SOURCE ${VERTEXSHADER_FILES} PROPERTY VS_SHADER_TYPE Vertex) Which is cool, but I can't see if there's a way to specify the other options to the shader compiler, such as output header file, shader model, etc. Is there a way to do that, or is it a TODO? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Sep 24 08:36:30 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 08:36:30 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> Message-ID: <5422BACE.2070600@kitware.com> On 09/24/2014 08:02 AM, Adam Strzelecki wrote: > cmThread utility class Introducing threads is exactly the "too much infrastructure" to which I was referring in my previous response. I'm sorry to reject all the effort you put into the threads approach so far, but I did say this earlier. > cmake emits simply too much (redundant) information. IIRC the original reason for having separate -- Looking for iconv.h -- Looking for iconv.h - Found lines is that the first one prints what is about to be done in case something happens (e.g. crash) that prevents the second output from ever showing up. That helps a lot in tracking down the problem. If another thread buffers the first message then it might not show up at all. The terminal escape codes approach does not have that problem. The same de-dup you do in the threaded filter could be done with a shell alias that pipes 'cmake' output through a sed script or something to de-dup it. That would handle local interactive terminal use of cmake without any upstream changes. -Brad From chuck.atkins at kitware.com Wed Sep 24 09:44:27 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 24 Sep 2014 09:44:27 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <5422BACE.2070600@kitware.com> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> Message-ID: I like the idea of reducing the extra-verbose output, and maybe I'm missing something here but could this possibly be done with a much simpler approach? It seems the way these double messages happen is with the following CMake code: message(STATUS "Doing something") # Do some stuff message(STATUS "Doing something - Result") Couldn't the same thing be achieved in a platform agnostic way by adding a NOENDL option (or something similar) to the message command? Then you could achieve the same result with: message(STATUS "Doing something" NOENDL) # Do some stuff message(STATUS " - Result") Just a bit of logic to add the NOENDL option and then another to omit the message prefix if the previous call used NOENDL. It seems this could achieve the compact log result, do it in a platform agnostic way, and also provide the useful feature to the message command for users. It would be a two-step process: first, enhance the message command, second, update the various .cmake files in Sources/Modules to leverage the new syntax. Just my 2 cents. - Chuck On Wed, Sep 24, 2014 at 8:36 AM, Brad King wrote: > On 09/24/2014 08:02 AM, Adam Strzelecki wrote: > > cmThread utility class > > Introducing threads is exactly the "too much infrastructure" > to which I was referring in my previous response. I'm sorry > to reject all the effort you put into the threads approach so > far, but I did say this earlier. > > > cmake emits simply too much (redundant) information. > > IIRC the original reason for having separate > > -- Looking for iconv.h > -- Looking for iconv.h - Found > > lines is that the first one prints what is about to be > done in case something happens (e.g. crash) that prevents > the second output from ever showing up. That helps a lot > in tracking down the problem. If another thread buffers > the first message then it might not show up at all. The > terminal escape codes approach does not have that problem. > > The same de-dup you do in the threaded filter could be done > with a shell alias that pipes 'cmake' output through a sed > script or something to de-dup it. That would handle local > interactive terminal use of cmake without any upstream > changes. > > -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 Wed Sep 24 09:48:24 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 09:48:24 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> Message-ID: <5422CBA8.5030201@kitware.com> On 09/24/2014 09:44 AM, Chuck Atkins wrote: > message(STATUS "Doing something" NOENDL) > # Do some stuff > message(STATUS " - Result") What happens if something else occurs in between that prints a message? Do we tolerate -- Doing something-- Unrelated Message - Result instead of -- Doing something -- Unrelated Message -- Doing something - Result ? Also the approach needs to work in ccmake where only one status line is shown at a time. -Brad From brad.king at kitware.com Wed Sep 24 09:55:42 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 09:55:42 -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> Message-ID: <5422CD5E.7020008@kitware.com> 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. -Brad From robert.maynard at kitware.com Wed Sep 24 10:07:10 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 24 Sep 2014 10:07:10 -0400 Subject: [cmake-developers] [OSX CMake.dmg] Replace >10.6 build with 64-bit only and use bzip2 compression In-Reply-To: <1AE2B46D-8E37-43C1-BAB2-F7C8D03AB26C@java.pl> References: <1AE2B46D-8E37-43C1-BAB2-F7C8D03AB26C@java.pl> Message-ID: I believe that the reason for both of these behaviors is that the DragNDrop generator was written when a significant number of < 10.6 machines existed in the wild. I don't see any reason why we shouldn't update the default for CPACK_DMG_FORMAT to be UDBZ instead of UDZO On Wed, Sep 24, 2014 at 8:26 AM, Adam Strzelecki wrote: > Not an big issue but official DMG bundles are 40 MB where my manually built one is 21 MB (half of it). > > So any reason for: > * providing universal FAT binaries instead of 64-bit only for >=10.6 Darwin64 build, as anyway there is 32-bit build for these who have 32-bit only CPU? > * using DMG zlib compression instead bzip2 for all builds which is available for 10.4+ and provides much better compression ratio? > > --Adam > > -- > > 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 chuck.atkins at kitware.com Wed Sep 24 10:11:56 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 24 Sep 2014 10:11:56 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <5422CBA8.5030201@kitware.com> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> <5422CBA8.5030201@kitware.com> Message-ID: > > What happens if something else occurs in between that prints > a message? Do we tolerate > > -- Doing something-- Unrelated Message > - Result > > instead of > > -- Doing something > -- Unrelated Message > -- Doing something - Result > Sure, why not? There's no requirement to use the NOENDL, it would just be an additional option. The places where this happens is most in the Modules/* code for system introspection. If the code path allows for extensive messaging in between status messages, then just don't use the NOENDL option. It would be entirely optional and up to whomever is writing the CMake code whether or not to use it. We could easily use it in most of the system introspection modules without worry though. > Also the approach needs to work in ccmake where only one > status line is shown at a time. > Sure it would. Nothing monumental would need to change though. It currently output's every message separately, but it could just output the current message append to the previous message and then when an endline is found then clear the append message buffer. I'm not saying it should be done this way, just offering an alternate approach that might be more flexible. The details and tests would still need to be worked out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Sep 24 10:13:16 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 10:13:16 -0400 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <54202D1B.5040300@kitware.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> <54202D1B.5040300@kitware.com> Message-ID: <5422D17C.3000408@kitware.com> On 09/22/2014 10:07 AM, Brad King wrote: > Or, one could add the explicit PUSH/POP in modules, e.g. > > cmake_policy(PUSH) > cmake_policy(SET CMP0054 NEW) > ... module code ... > cmake_policy(POP) Until such time as someone wishes to port a module explicitly with the above approach we can use the explicit dereference approach Adam first posted. I've applied his patch here: FindCUDA: Avoid if() auto-dereference in string comparisons http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=84e3fde9 -Brad From brad.king at kitware.com Wed Sep 24 10:15:29 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 10:15:29 -0400 Subject: [cmake-developers] [OSX CMake.dmg] Replace >10.6 build with 64-bit only and use bzip2 compression In-Reply-To: References: <1AE2B46D-8E37-43C1-BAB2-F7C8D03AB26C@java.pl> Message-ID: <5422D201.5010808@kitware.com> On 09/24/2014 10:07 AM, Robert Maynard wrote: > I believe that the reason for both of these behaviors is that the > DragNDrop generator was written when a significant number of < 10.6 > machines existed in the wild. > > I don't see any reason why we shouldn't update the default for > CPACK_DMG_FORMAT to be UDBZ instead of UDZO IIUC Adam was talking about the CMake binary distribution itself, not CPack defaults. I don't think we should change the defaults in a minor release, but we can change the way our official binary is built. Thanks, -Brad From robert.maynard at kitware.com Wed Sep 24 10:22:30 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 24 Sep 2014 10:22:30 -0400 Subject: [cmake-developers] [OSX CMake.dmg] Replace >10.6 build with 64-bit only and use bzip2 compression In-Reply-To: <5422D201.5010808@kitware.com> References: <1AE2B46D-8E37-43C1-BAB2-F7C8D03AB26C@java.pl> <5422D201.5010808@kitware.com> Message-ID: Okay I have just merged into next a topic that switches over the official release to be built with UDBZ. Once the dashboards are happy I will update the x86_64 release to not be universal binaries. On Wed, Sep 24, 2014 at 10:15 AM, Brad King wrote: > On 09/24/2014 10:07 AM, Robert Maynard wrote: >> I believe that the reason for both of these behaviors is that the >> DragNDrop generator was written when a significant number of < 10.6 >> machines existed in the wild. >> >> I don't see any reason why we shouldn't update the default for >> CPACK_DMG_FORMAT to be UDBZ instead of UDZO > > IIUC Adam was talking about the CMake binary distribution itself, > not CPack defaults. I don't think we should change the defaults > in a minor release, but we can change the way our official binary > is built. > > Thanks, > -Brad > From ono at java.pl Wed Sep 24 10:29:39 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 24 Sep 2014 16:29:39 +0200 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <5422CBA8.5030201@kitware.com> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> <5422CBA8.5030201@kitware.com> Message-ID: <04D547CB-627C-40A2-8644-AC8016EF745C@java.pl> > What happens if something else occurs in between that prints > a message? That's why my solution is completely automatic, does not require any changes in existing modules, and it works as desired so only: -- Doing something -- Doing something - Result That arrive to stdout are compacted to: -- Doing something - Result When anything comes in between both to stdout and stderr then compaction does not occur. Also the preliminary message "-- Doing something" is of course emitted, but cursor waits on end of line instead new line, just in case we get 2nd matching Result line. If next line is anything else then new line gets appended and rest goes as usual. Please try to build this stage branch and try to run cmake agains cmake :) (FYI fixed bug preventing compiling on Linux) --Adam From brad.king at kitware.com Wed Sep 24 10:34:45 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 10:34:45 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <04D547CB-627C-40A2-8644-AC8016EF745C@java.pl> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> <5422CBA8.5030201@kitware.com> <04D547CB-627C-40A2-8644-AC8016EF745C@java.pl> Message-ID: <5422D685.1030201@kitware.com> On 09/24/2014 10:29 AM, Adam Strzelecki wrote: > Please try to build this stage branch and try to run cmake In case I was not clear the last two times: We will *NOT* be introducing use of *THREADS* in CMake just to filter our own output. -Brad From ono at java.pl Wed Sep 24 10:47:45 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 24 Sep 2014 16:47:45 +0200 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <5422D685.1030201@kitware.com> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> <5422CBA8.5030201@kitware.com> <04D547CB-627C-40A2-8644-AC8016EF745C@java.pl> <5422D685.1030201@kitware.com> Message-ID: > We will *NOT* be introducing use of *THREADS* in CMake just > to filter our own output. Yeah, got it. Are subprocess allowed then? > (?) just to filter our own output. Please note that such solution that filters stdout low level is superior to doing it as CMake owns level because cmake may be launching some external program, library or whatever that also pushes something to stdout/stderr and if we don't take this into account then output will get likely broken. --Adam From ono at java.pl Wed Sep 24 10:49:19 2014 From: ono at java.pl (Adam Strzelecki) Date: Wed, 24 Sep 2014 16:49:19 +0200 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <5422D17C.3000408@kitware.com> References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> <54202D1B.5040300@kitware.com> <5422D17C.3000408@kitware.com> Message-ID: <3142951A-E638-46A3-8F4E-E84B767C1933@java.pl> Again, shouldn't we consider having CMP0011 always NEW for internal modules / or do implicit push&pop for include when CMP0011 is NEW *OR* when included module is part of CMake own modules? --Adam From brad.king at kitware.com Wed Sep 24 10:55:09 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 10:55:09 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> <5422CBA8.5030201@kitware.com> <04D547CB-627C-40A2-8644-AC8016EF745C@java.pl> <5422D685.1030201@kitware.com> Message-ID: <5422DB4D.2030707@kitware.com> On 09/24/2014 10:47 AM, Adam Strzelecki wrote: > Are subprocess allowed then? > >> (?) just to filter our own output. > > Please note that such solution that filters stdout low level Yes, but I do not think we should have to do any filtering at all. The output should just be written to match what we want in the first place. I think the delayed-\n approach is the simplest. In the case that the output is interrupted by other content it almost certainly means something is going wrong anyway. -Brad From brad.king at kitware.com Wed Sep 24 10:58:03 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 10:58:03 -0400 Subject: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison In-Reply-To: <3142951A-E638-46A3-8F4E-E84B767C1933@java.pl> References: <1410954869-25450-1-git-send-email-ono@java.pl> <541BCDB7.2050004@gmail.com> <8D1A20AEF89DE03-1B24-71B4@webmail-m169.sysops.aol.com> <54202D1B.5040300@kitware.com> <5422D17C.3000408@kitware.com> <3142951A-E638-46A3-8F4E-E84B767C1933@java.pl> Message-ID: <5422DBFB.8060806@kitware.com> On 09/24/2014 10:49 AM, Adam Strzelecki wrote: > do implicit push&pop for include when CMP0011 is NEW *OR* > when included module is part of CMake own modules I think this would be okay, as long as NO_POLICY_SCOPE is still honored when given explicitly to include() and find_package(). The only reason for the pre-CMP0011 behavior and NO_POLICY_SCOPE is in case the purpose of a module is to set policies. None of the builtin modules do that. Thanks, -Brad From aleixpol at kde.org Wed Sep 24 12:51:26 2014 From: aleixpol at kde.org (Aleix Pol) Date: Wed, 24 Sep 2014 18:51:26 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <5422CD5E.7020008@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> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gilles.Khouzam at microsoft.com Wed Sep 24 13:40:47 2014 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Wed, 24 Sep 2014 17:40:47 +0000 Subject: [cmake-developers] Windows shader compile options In-Reply-To: References: Message-ID: <275c0f79a0274db39a920d60c97fa930@CY1PR0301MB0713.namprd03.prod.outlook.com> Hi Christopher, We added the support for shaders but have only added the basic support to include shaders. Let me check what can be done to add the other properties. Gilles Khouzam Senior Development Lead Microsoft OSG From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Christopher Maughan Sent: Wednesday, September 24, 2014 05:29 To: cmake-developers at cmake.org Subject: [cmake-developers] Windows shader compile options I've been playing with the Windows shader options. I can see that it's now possible to set the following: set_property(SOURCE ${PIXELSHADER_FILES} PROPERTY VS_SHADER_TYPE Pixel) set_property(SOURCE ${VERTEXSHADER_FILES} PROPERTY VS_SHADER_TYPE Vertex) Which is cool, but I can't see if there's a way to specify the other options to the shader compiler, such as output header file, shader model, etc. Is there a way to do that, or is it a TODO? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Sep 24 14:40:15 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Sep 2014 14:40:15 -0400 Subject: [cmake-developers] vs-nsight-tegra-generator topic In-Reply-To: <541C3D71.7080806@kitware.com> References: <541C3D71.7080806@kitware.com> Message-ID: <5423100F.3030205@kitware.com> On 09/20/2014 12:09 PM, Mourad Boufarguine wrote: > On 09/19/2014 10:28 AM, Brad King wrote: >> Interesting. I started with an IDE-generated project file to >> see what the generator needs to produce. What version of >> Nsight Tegra are you using? > > I'm using Nsight Tegra 1.6. I used 1.5.1 originally. It looks like the use of JCompile is new in 1.6. I've added a mapping: VS: Map Nsight Tegra file types in .vcxproj files http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1167882a Thanks, -Brad From Anton.Makeev at jetbrains.com Thu Sep 25 03:14:38 2014 From: Anton.Makeev at jetbrains.com (Anton Makeev) Date: Thu, 25 Sep 2014 07:14:38 +0000 (UTC) Subject: [cmake-developers] Extracting target metadata, IDE integration References: Message-ID: Hey everyone, We are developing CLion at JetBrains that utilizes CMake as its main project model. Stephen Kelly timely drew our attention to this discussion, and I?d like to share some thoughts. Here are the general ones and I?ll also comment on separate messages in the thread. We?ve managed to get almost all the necessary project information, using ?GNU/MinGW Makefiles? generators: * list of targets comes from 'CMakeFiles/TargetDirectories.txt' * list of source files from ?CMakeFiles/A.dir/DependInfo.cmake? * list of headers and resources from ?codeblocks.cbp? file * per-file/target compiler and its flags from ?CMakeFiles/Target.dir/flags.make? * location of product files from ?CMakeFiles/Target.dir/build.make? What we miss (not all of them are directly related the targets metadata, but I'd like to share anyway since the topic is about IDE integration): * Location of every source file and target in CMakeLists - it would greatly help to refactorings, navigation etc. * Complete list of headers and resource files - they are only listed in special generators like code blocks. * An easily parseable list of errors and warnings with origin information. At the moment we parse error output but not everything can be parsed reliably. * No progress indication. Since the generation may take several minutes, providing feedback is crucial. * Ability to distinguish a library from an executable target. This will help to offer a better UI for run/debug configurations. * Possibility to collect information for every build target in one run. Currently, we have to invoke generator for every CMAKE_BUILT_TYPE separately. * CMake stops processing when it find a missing file, so that IDE cannot have full project model, until this files is created. * When there are existing in-source generated files in the project dir, CMake doesn't allow generating into a separate out-of-source folder. An IDE has to invent workarounds here. * Not sure if it?s possible at all - a lightweight phase where CMake only collects necessary information (list of files/targets, compiler settings). This will help IDE react to the changes much faster. Here is why I think the discussed functionality should not be a separate generator: CLion doesn?t have it?s own project model nor is intended as build tool replacement. Currently, the only option for CLion users is makefiles build, that is not a best option for everyone: there is a good and fast alternative ?Ninja?. Ideally, users should be able to choose whatever tool better suites them. The problem is that the generated Makefiles are used both, for internal needs, like reading project structure, and also to build and run the user?s program. If we wanted to support Ninja generator, we would need to rewrite all the logic that retrieves the project information, using the files that are created by Ninja generator. While I suppose it?s possible, it?s not the best option - very error prone and resource demanding. If CMake generated a separate descriptor, regardless the generator used (Makefiles, Ninja), it would be much easier to support; and the users will benefit from better, more reliable and faster CMake integration in an IDE. Regards, Anton Makeev From nilsgladitz at gmail.com Thu Sep 25 08:45:22 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 25 Sep 2014 14:45:22 +0200 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: <541DF762.2000107@gmail.com> References: <541DF762.2000107@gmail.com> Message-ID: <54240E62.9070001@gmail.com> @Brad: Before I rush into implementing anything and given that David already raised concerns ... would anything like this be considered for merge into CMake? Nils From brad.king at kitware.com Thu Sep 25 09:17:24 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 25 Sep 2014 09:17:24 -0400 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: <54240E62.9070001@gmail.com> References: <541DF762.2000107@gmail.com> <54240E62.9070001@gmail.com> Message-ID: <542415E4.7030708@kitware.com> On 09/25/2014 08:45 AM, Nils Gladitz wrote: > @Brad: Before I rush into implementing anything and given that David > already raised concerns ... would anything like this be considered for > merge into CMake? I'm not convinced it should be a builtin CMake feature. KWSys provides the "SharedForward" component specifically to help projects create launcher executables like this. It even helps create relocatable binaries on *NIX without $ORIGIN, and works for redistributable packages on both Windows and *NIX. All of this works without any special CMake features. While it would be nice to provide a helper for applications to do this, the only reason to include it in CMake would be to avoid an additional external dependency for the application. The same dependency management argument could be made for any library, and we can't include the world in CMake. > $ should continue to point at the real binary. > A new $ could point at the wrapper binary. The original purpose of $ was for add_custom_command and add_test to be able to refer to executables to run on command lines. That would have to be the wrapper for this use case. However, other use cases may want to pass the real binary with $. This makes the behavior of a magic wrapper hard to define in general, so it would be better to have application code manage the separate targets explicitly. Note that CMake now has a "cmake -E env" feature that could be used in custom commands and tests to set PATH before launching an executable. -Brad From ono at java.pl Thu Sep 25 09:43:23 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 25 Sep 2014 15:43:23 +0200 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <5422DB4D.2030707@kitware.com> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> <5422CBA8.5030201@kitware.com> <04D547CB-627C-40A2-8644-AC8016EF745C@java.pl> <5422D685.1030201@kitware.com> <5422DB4D.2030707@kitware.com> Message-ID: <5F27DAAB-BDE1-40FE-8377-18ED08FE6DAA@java.pl> > I think the delayed-\n approach is the simplest. In the > case that the output is interrupted by other content it > almost certainly means something is going wrong anyway. Does CMake use popen to launch processes? Or it just spawns them providing them direct access to stdin/out/err? If it was using popen then we can circumvent that too. --Adam From brad.king at kitware.com Thu Sep 25 09:49:11 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 25 Sep 2014 09:49:11 -0400 Subject: [cmake-developers] [PATCH] stage/compact-status-log In-Reply-To: <5F27DAAB-BDE1-40FE-8377-18ED08FE6DAA@java.pl> References: <61896308-4699-4ED5-9F81-86A11B270EC3@java.pl> <54202D22.8030708@kitware.com> <54205045.1060607@kitware.com> <98B3C804-F496-4879-8686-6141639E8B71@java.pl> <0DDB5FED-7359-44A2-A749-D5424D7BFCC0@java.pl> <5422BACE.2070600@kitware.com> <5422CBA8.5030201@kitware.com> <04D547CB-627C-40A2-8644-AC8016EF745C@java.pl> <5422D685.1030201@kitware.com> <5422DB4D.2030707@kitware.com> <5F27DAAB-BDE1-40FE-8377-18ED08FE6DAA@java.pl> Message-ID: <54241D57.5040001@kitware.com> On 09/25/2014 09:43 AM, Adam Strzelecki wrote: >> I think the delayed-\n approach is the simplest. In the >> case that the output is interrupted by other content it >> almost certainly means something is going wrong anyway. > > Does CMake use popen to launch processes? Or it just spawns > them providing them direct access to stdin/out/err? In Source/kwsys/Process.h.in there is an API for executing child processes. Most of CMake uses a RunSingleCommand method wrapping it up here: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmSystemTools.cxx;hb=v3.0.2#l624 Some call sites share stdout/stderr and some do not. The execute_process() command is implemented with the KWSys Process API too, and that command has options for what to do with the pipes. As for the check message lines, I think it should be up to the check macro to ensure it does not invoke anything that could print intermediate output between the beginning of the line and the result of the check. -Brad From nilsgladitz at gmail.com Thu Sep 25 09:49:33 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 25 Sep 2014 15:49:33 +0200 Subject: [cmake-developers] [CMake] Windows rpath emulation In-Reply-To: <542415E4.7030708@kitware.com> References: <541DF762.2000107@gmail.com> <54240E62.9070001@gmail.com> <542415E4.7030708@kitware.com> Message-ID: <54241D6D.7030709@gmail.com> On 09/25/2014 03:17 PM, Brad King wrote: > Note that CMake now has a "cmake -E env" feature that could be > used in custom commands and tests to set PATH before launching > an executable. I currently use CMake scripts as wrappers for custom commands which set ENV{PATH} and the ENVIRONMENT property in tests. I don't currently have anything to conveniently run binaries manually from the build tree but I guess I could come up with something custom for that as well without having to make this a first class feature. It would just have been convenient having something more transparent and without manual set up for every project given how common this seems. Given the opposition I won't pursue this further. Thanks. Nils From neundorf at kde.org Thu Sep 25 16:29:44 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 25 Sep 2014 22:29:44 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: Message-ID: <1434786.OYXG2l82AR@tuxedo.neundorf.net> On Thursday, September 25, 2014 07:14:38 Anton Makeev wrote: ... > Here is why I think the discussed functionality should not be a separate > generator: > > CLion doesn?t have it?s own project model nor is intended as build tool > replacement. Currently, the only option for CLion users is makefiles build, > that is not a best option for everyone: there is a good and fast > alternative ?Ninja?. Ideally, users should be able to choose whatever tool > better suites them. > > The problem is that the generated Makefiles are used both, for internal > needs, like reading project structure, and also to build and run the user?s > program. If we wanted to support Ninja generator, we would need to rewrite > all the logic that retrieves the project information, using the files that > are created by Ninja generator. While I suppose it?s possible, it?s not the > best option - very error prone and resource demanding. > > If CMake generated a separate descriptor, regardless the generator used > (Makefiles, Ninja), it would be much easier to support; and the users will > benefit from better, more reliable and faster CMake integration in an IDE. not sure I fully understand, but it seems you are maybe not aware how the "extra generators" in cmake work. Those are basically run additionally to a "normal" generator. I.e. cmake generates makefiles or ninja files, and additionally project files for an IDE. This project file typically contains the list of targets, and for each target the build command. At that point it doesn't matter much anymore for the IDE whether the main generator is make or ninja. This is implemented with the Eclipse generator, the CodeBlocks generator and the Kate generator. They all write a project file for the IDE additionally to the makefiles/ninja files for the actual building. Alex From aklitzing at gmail.com Thu Sep 25 16:40:52 2014 From: aklitzing at gmail.com (A. Klitzing) Date: Thu, 25 Sep 2014 22:40:52 +0200 Subject: [cmake-developers] Support of codesign In-Reply-To: References: Message-ID: Hi there, I refactored the patches of Brian Milco to support code signing of bundles in MacOS. As we don't need AppStore support at the moment we didn't added the special generator for it. That could be a separate step later. As long as it runs codesign only it should be trivial enough to add it. Is it possible to add it to cmake 3.1? Original commits are taken from github: https://github.com/iPenguin/cmake Best regards Andr? Klitzing -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-codesign-on-MacOS.patch Type: text/x-diff Size: 9248 bytes Desc: not available URL: From mantis at public.kitware.com Thu Sep 25 19:17:30 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 26 Sep 2014 01:17:30 +0200 Subject: [cmake-developers] [CMake 0015172]: Show progress during generation step Message-ID: <38991cd01570a1516e6bac3c1a048a36@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15172 ====================================================================== Reported By: Stephen Kelly Assigned To: ====================================================================== Project: CMake Issue ID: 15172 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-26 01:17 CEST Last Modified: 2014-09-26 01:17 CEST ====================================================================== Summary: Show progress during generation step Description: CMake gives a lot of output during the configure step, but no output during the generate step. As of the last few releases, CMake is doing more during the generation stage to resolve transitive build properties, which can take more time, so feedback could be more valuable. CMake could show more output during the multiple stages of cmGlobalGenerator::Generate quite easily, however, the granularity of that is only the directory level. For the granularity of generating for individual targets (if that is desirable/possible/practical), each of the concrete generators would need to be modified to produce output. The output would have to be the same for each generator so that it could be uniformly parsed. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-26 01:17 Stephen Kelly New Issue ====================================================================== From steveire at gmail.com Thu Sep 25 19:25:21 2014 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 26 Sep 2014 01:25:21 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration References: Message-ID: Anton Makeev wrote: > Hey everyone, > > We are developing CLion at JetBrains that utilizes CMake as its main > project model. Stephen Kelly timely drew our attention to this discussion, > and I?d like to share some thoughts. Here are the general ones and I?ll > also comment on separate messages in the thread. Thanks! > * Location of every source file and target in CMakeLists > - it would greatly help to refactorings, navigation etc. Ok, that seems to already be part of the current design/implementation. > * Complete list of headers and resource files > - they are only listed in special generators like code blocks. That generator guesses that if foo.cpp is in the project and foo.h exists, then foo.h must also be part of the project: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmExtraCodeBlocksGenerator.cxx;h=56a6edbb;hb=HEAD#l449 That might not be true, but you can probably make the same guess inside CLion anyway? > * An easily parseable list of errors and warnings with origin information. > At the moment we parse error output but not everything can be parsed > reliably. That non-reliability of parsing that stuff might be something to file bugs about. I think it's out of scope of the metadata file design. > * No progress indication. Since the generation may take several minutes, > providing feedback is crucial. There is feedback during the configure stage, and as the generation stage may take longer as of the last few releases, I have thought that showing some progress could be worthwhile. I haven't looked into it though. I filed http://public.kitware.com/Bug/view.php?id=15172 to track the idea. Again though, this is out of scope of the target metadata file. > * Ability to distinguish a library from an executable target. > This will help to offer a better UI for run/debug configurations. This is already part of the current design/implementation. > * Possibility to collect information for every build target in one run. > Currently, we have to invoke generator for every CMAKE_BUILD_TYPE > separately. This is part of the updated design. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11041 > * CMake stops processing when it find a missing file, so that IDE cannot > have > full project model, until this files is created. True. However, if cmake stops processing (because of a missing file or many other reasons, such as a missing dependency), the full project model is not known. I'm not sure this is 'fixable'. > * When there are existing in-source generated files in the project dir, > CMake doesn't allow generating into a separate out-of-source folder. > An IDE has to invent workarounds here. I'm not sure CMake can provide a better solution to this. Would you want to run cmake in a mode which clears out such files somehow? I'm not sure that would be accepted. > Here is why I think the discussed functionality should not be a separate > generator: I think that ship has sailed. The feature is being implemented with a variable for control, not a generator. Thanks for the feedback! Steve. From steveire at gmail.com Thu Sep 25 19:27:58 2014 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 26 Sep 2014 01:27:58 +0200 Subject: [cmake-developers] Extracting target metadata, IDE integration 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: Aleix Pol wrote: > Hi, > Here's another iteration of the patch [1]. Thanks for this. Can you tell me why exportName is part of the output? http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11009 Thanks, Steve. From steveire at gmail.com Thu Sep 25 19:53:35 2014 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 26 Sep 2014 01:53:35 +0200 Subject: [cmake-developers] Was AUTOMOC designed to run for each build? References: <1701926.YV4YG1IxjZ@tuxedo.neundorf.net> Message-ID: Alexander Neundorf wrote: >> I don't see why the target is executed each time, but is it that way by >> design? > > iirc, yes. > The moc files have to be generated before any of the source files is > compiled, so automoc is in a target the actual target depends on. > IIRC it is exclude_from_all so that it is only built when the actual > target is built. > Do you think it should only rerun if any of the source files has changed ? > There was some problem with this. > The headers are usually not part of the listed source files. Hmm, well, we do know which header is relevant right? Because it's the one (or many) we set up commands to run moc on. Maybe we only know the relevant headers too late (at the time of running the -E cmake_autogen command, not at cmake time)? Something else I've wondered is why the parsing of the files is done 'delayed' with the -E cmake_autogen command. Is it just to avoid doing that task during cmake time (because it's time consuming), and to allow parallelization? Thanks, Steve. From aklitzing at gmail.com Fri Sep 26 03:29:47 2014 From: aklitzing at gmail.com (A. Klitzing) Date: Fri, 26 Sep 2014 09:29:47 +0200 Subject: [cmake-developers] Support of codesign In-Reply-To: References: Message-ID: Well, first patch had a little mistake. I attached an update... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-codesign-on-MacOS.patch Type: text/x-diff Size: 8649 bytes Desc: not available URL: From brad.king at kitware.com Fri Sep 26 09:52:52 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 26 Sep 2014 09:52:52 -0400 Subject: [cmake-developers] Support of codesign In-Reply-To: References: Message-ID: <54256FB4.1000903@kitware.com> On 09/25/2014 04:40 PM, A. Klitzing wrote: > I refactored the patches of Brian Milco to support > code signing of bundles in MacOS. [snip] On 09/26/2014 03:29 AM, A. Klitzing wrote: > Well, first patch had a little mistake. I attached an update... Thanks! I've applied the patch and merged to our 'next' branch for testing: CPack: Add support for code signing of bundles on MacOS http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1a9b0668 I would appreciate any feedback from others too. -Brad From clinton at elemtech.com Fri Sep 26 10:08:42 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Fri, 26 Sep 2014 08:08:42 -0600 (MDT) Subject: [cmake-developers] Support of codesign In-Reply-To: <54256FB4.1000903@kitware.com> References: <54256FB4.1000903@kitware.com> Message-ID: <731237400.306083.1411740522094.JavaMail.zimbra@elemtech.com> 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. Clint ----- Original Message ----- > On 09/25/2014 04:40 PM, A. Klitzing wrote: > > I refactored the patches of Brian Milco to support > > code signing of bundles in MacOS. > [snip] > On 09/26/2014 03:29 AM, A. Klitzing wrote: > > Well, first patch had a little mistake. I attached an update... > > Thanks! > > I've applied the patch and merged to our 'next' branch for > testing: > > CPack: Add support for code signing of bundles on MacOS > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1a9b0668 > > I would appreciate any feedback from others too. > > -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 > From brad.king at kitware.com Fri Sep 26 15:15:35 2014 From: brad.king at kitware.com (Brad King) Date: Fri, 26 Sep 2014 15:15:35 -0400 Subject: [cmake-developers] Support of codesign In-Reply-To: <54256FB4.1000903@kitware.com> References: <54256FB4.1000903@kitware.com> Message-ID: <5425BB57.5080003@kitware.com> On 09/26/2014 09:52 AM, Brad King wrote: > I've applied the patch and merged to our 'next' branch for > testing: > > CPack: Add support for code signing of bundles on MacOS > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1a9b0668 I reverted the topic because several CPackComponents tests fail on OS X when the 'codesign' binary is not available. > + const std::string codesign_path = cmSystemTools::FindProgram("codesign", > + std::vector(), false); > + if(codesign_path.empty()) > + { > + cmCPackLogger(cmCPackLog::LOG_ERROR, > + "Cannot locate codesign command" > + << std::endl); > + return 0; > + } > + this->SetOptionIfNotSet("CPACK_COMMAND_CODESIGN", codesign_path.c_str()); It should not be an error for 'codesign' to not be available in the PATH. The user may have set CPACK_COMMAND_CODESIGN to some other location. The error should only occur if no value for CPACK_COMMAND_CODESIGN is available when the tool is actually needed for signing. -Brad From neundorf at kde.org Fri Sep 26 16:04:23 2014 From: neundorf at kde.org (Alexander Neundorf) Date: Fri, 26 Sep 2014 22:04:23 +0200 Subject: [cmake-developers] Was AUTOMOC designed to run for each build? In-Reply-To: References: <1701926.YV4YG1IxjZ@tuxedo.neundorf.net> Message-ID: <201690555.7z5O7jgyHi@tuxedo.neundorf.net> On Friday, September 26, 2014 01:53:35 Stephen Kelly wrote: > Alexander Neundorf wrote: > >> I don't see why the target is executed each time, but is it that way by > >> design? > > > > iirc, yes. > > The moc files have to be generated before any of the source files is > > compiled, so automoc is in a target the actual target depends on. > > IIRC it is exclude_from_all so that it is only built when the actual > > target is built. > > Do you think it should only rerun if any of the source files has changed ? > > There was some problem with this. > > The headers are usually not part of the listed source files. > > Hmm, well, we do know which header is relevant right? Because it's the one > (or many) we set up commands to run moc on. Maybe we only know the relevant > headers too late (at the time of running the -E cmake_autogen command, not > at cmake time)? > > Something else I've wondered is why the parsing of the files is done > 'delayed' with the -E cmake_autogen command. Is it just to avoid doing that > task during cmake time (because it's time consuming), and to allow > parallelization? it can't be done at cmake time, because editing a cpp file and inserting #include "foo.moc" does not cause cmake to rerun, so the parsing must happen during buildtime. Alex From aleixpol at kde.org Fri Sep 26 19:09:40 2014 From: aleixpol at kde.org (Aleix Pol) Date: Sat, 27 Sep 2014 01:09:40 +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 Fri, Sep 26, 2014 at 1:27 AM, Stephen Kelly wrote: > Aleix Pol wrote: > > Hi, > > Here's another iteration of the patch [1]. > > Thanks for this. > > Can you tell me why exportName is part of the output? > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11009 > > Thanks, > > Steve. > > I just looked into it, GetOutputName is a private method. Now that you mention it though, we can just probably not output the exportName, at least for now. I can provide a new version of the patch if requested. Aleix -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sat Sep 27 15:25:24 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 27 Sep 2014 15:25:24 -0400 Subject: [cmake-developers] [CMake 0015173]: MinGW compiler can NOT be used when also Visual Studio 2013 is installed Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15173 ====================================================================== Reported By: Christoph Bastuck Assigned To: ====================================================================== Project: CMake Issue ID: 15173 Category: CMake Reproducibility: always Severity: major Priority: none Status: new ====================================================================== Date Submitted: 2014-09-27 15:25 EDT Last Modified: 2014-09-27 15:25 EDT ====================================================================== Summary: MinGW compiler can NOT be used when also Visual Studio 2013 is installed Description: Using Cmake 3.0.2 and compiling my project with MinGW with following command for Makefile generation: cmake X:\Projects\Path -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_RC_COMPILER=windres -G "MinGW Makefiles" gcc/g++ is in PATH and cl/link is NOT. CMake is actually detecting g++/gcc compiler and tries to compile a test sample. But uses visual studio style compiler flags instead of gcc style, i.e. /DWIN32 instead of -DWIN32. Hence compiling fails. Currently there seems possibility to choose MinGW (explicitly). So downgraded to Cmake 2.8. Here selecting the generator with flag "-G" work as expected. Steps to Reproduce: 1. Install MinGW compiler and Visual Studio 2013 on same machine 2. PATH must hold to MingGW compiler 3. remove cl/link from PATH if exists 4. Create MinGW Makefile for your project wirh command: cmake X:\Projects\Path -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_RC_COMPILER=windres -G "MinGW Makefiles" ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-27 15:25 Christoph BastuckNew Issue ====================================================================== From mantis at public.kitware.com Sun Sep 28 09:44:09 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 28 Sep 2014 09:44:09 -0400 Subject: [cmake-developers] [CMake 0015174]: TARGET_LINK_LIBRARIES adds libraries to INTERFACE_LINK_LIBRARIES without LINK_INTERFACE_LIBRARIES Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15174 ====================================================================== Reported By: Marc Seebold Assigned To: ====================================================================== Project: CMake Issue ID: 15174 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-28 09:44 EDT Last Modified: 2014-09-28 09:44 EDT ====================================================================== Summary: TARGET_LINK_LIBRARIES adds libraries to INTERFACE_LINK_LIBRARIES without LINK_INTERFACE_LIBRARIES Description: TARGET_LINK_LIBRARIES(MYTARGET PRIVATE "mylib.lib") adds "mylib.lib" to "INTERFACE_LINK_LIBRARIES" property of target "MYTARGET". However, only in LINK_INTERFACE_LIBRARIES mode this property should be set. Steps to Reproduce: TARGET_LINK_LIBRARIES(MYTARGET PRIVATE "mylib.lib") Additional Information: Hotfix: SET_PROPERTY(TARGET MYTARGET PROPERTY INTERFACE_LINK_LIBRARIES "") ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-28 09:44 Marc Seebold New Issue ====================================================================== From mantis at public.kitware.com Sun Sep 28 14:26:45 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 28 Sep 2014 14:26:45 -0400 Subject: [cmake-developers] [CMake 0015175]: Intel Fortran 15.0 Visual Studio integration requires TargetName property for renamed targets Message-ID: <10099103d363557a20fed7f6f0070e60@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15175 ====================================================================== Reported By: Ian Harvey Assigned To: ====================================================================== Project: CMake Issue ID: 15175 Category: CMake Reproducibility: sometimes Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-28 14:26 EDT Last Modified: 2014-09-28 14:26 EDT ====================================================================== Summary: Intel Fortran 15.0 Visual Studio integration requires TargetName property for renamed targets Description: A change to the behaviour of the Visual Studio integration with ifort 15.0 means that executable and DLL projects that have the base part of the output filename different to the name of the project need to have the TargetName property set for the project, or the integration will issue warnings during the build and the manifest tool will fail (an EXE or DLL may still be produced). Steps to Reproduce: With the following Fortran source in a file named HelloWorld.f90: IMPLICIT NONE PRINT "('Hello world')" END and the following CMakeLists.txt in the same directory as above: cmake_minimum_required(VERSION 3.0.2) project(helloworld Fortran) add_executable(helloworld "HelloWorld.f90") set_target_properties(helloworld PROPERTIES OUTPUT_NAME foobar) >From within an Intel Fortran command prompt in a build subdirectory run cmake: >"c:\Program Files (x86)\CMake\bin\cmake.exe" .. -- Building for: Visual Studio 10 2010 -- The Fortran compiler identification is Intel -- Check for working Fortran compiler using: Visual Studio 10 2010 -- Check for working Fortran compiler using: Visual Studio 10 2010 -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Determine Intel Fortran Compiler Implicit Link Path -- Determine Intel Fortran Compiler Implicit Link Path -- done -- Checking whether C:/Program Files (x86)/Intel/Composer XE 2015/bin/ia32/ifort.exe supports Fortran 90 -- Checking whether C:/Program Files (x86)/Intel/Composer XE 2015/bin/ia32/ifort.exe supports Fortran 90 -- yes -- Configuring done -- Generating done -- Build files have been written to: H:/Projects/cmake-test/build Use cmake to then build the generated solution: >"c:\Program Files (x86)\CMake\bin\cmake.exe" --build . 1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32 ------ 1> Checking Build System 1> CMake does not need to re-run because H:/Projects/cmake-test/build/CMakeFiles/generate.stamp is up-to-date. 2>------ Build started: Project: helloworld, Configuration: Debug Win32 ------ 2>helloworld: warning: TargetPath(H:\Projects\cmake-test\build\Debug\helloworld.exe) does not match the Linker's OutputF ile property value (H:\Projects\cmake-test\build\Debug\foobar.exe). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile). 2>Compiling with Intel(R) Visual Fortran Compiler XE 15.0.0.108 [IA-32]... 2>HelloWorld.f90 2>Compiling manifest to resources... 2>Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385 2>Copyright (C) Microsoft Corporation. All rights reserved. 2>Linking... 2>Microsoft (R) Incremental Linker Version 10.00.40219.01 2>Copyright (C) Microsoft Corporation. All rights reserved. 2>/OUT:H:\Projects\cmake-test\build\Debug\foobar.exe 2>/VERSION:0.0 2>/MANIFEST 2>/MANIFESTFILE:helloworld.dir\Debug\helloworld.exe.intermediate.manifest 2>"/MANIFESTUAC:level='asInvoker' uiAccess='false'" 2>/DEBUG 2>/PDB:H:\Projects\cmake-test\build\Debug/foobar.pdb 2>/SUBSYSTEM:CONSOLE 2>/IMPLIB:H:\Projects\cmake-test\build\Debug\foobar.lib 2>user32.lib 2>/machine:X86 2>/debug 2>/INCREMENTAL 2>helloworld.dir\Debug\HelloWorld.obj 2>helloworld.dir\Debug\helloworld.exe.embed.manifest.res 2>Embedding manifest... 2>mt.exe : general error c10100b1: Failed to load file "H:\Projects\cmake-test\build\Debug\helloworld.exe". The system c annot find the file specified. 2> 2>Build log written to "file://H:\Projects\cmake-test\build\helloworld.dir\Debug\BuildLog.htm" 2>helloworld - 1 error(s), 1 warning(s) 3>------ Build started: Project: ALL_BUILD, Configuration: Debug Win32 ------ 3> Building Custom Rule H:/Projects/cmake-test/CMakeLists.txt 3> CMake does not need to re-run because H:\Projects\cmake-test\build\CMakeFiles\generate.stamp is up-to-date. 3> Build all projects ========== Build: 3 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== Additional Information: This patch applied to cmLocalVisualStudio7Generator.cxx is a crude fix. 637a638,641 > > // stolen from cmGlobalVisualStudio7Generator.cxx > #define CM_INTEL_PLUGIN_GUID "{B68A201D-CB9B-47AF-A52F-7EEC72E217E4}" > 651a656,677 > // ifort 15.0 integration uses TargetName property. Installed integration > // version test lifted from cmGlobalVisualStudio7Generator.cxx. > unsigned int intelVersionNumber = ~0u; > if (this->FortranProject) { > cmGlobalVisualStudio7Generator* gg = > static_cast( > this->GlobalGenerator ); > std::string intel_registry_version; > std::string vskey = gg->GetRegistryBase(); > vskey += "\\Packages\\" CM_INTEL_PLUGIN_GUID ";ProductVersion"; > cmSystemTools::ReadRegistryValue(vskey.c_str(), intel_registry_version, > cmSystemTools::KeyWOW64_32); > sscanf(intel_registry_version.c_str(), "%u", &intelVersionNumber); > if (intelVersionNumber == 15) { > std::string prefix; > std::string base; > std::string suffix; > target.GetFullNameComponents(prefix, base, suffix); > fout << "\t\t\tTargetName=\"" << this->EscapeForXML(base.c_str()) > << "\"\n"; > } > } ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-28 14:26 Ian Harvey New Issue ====================================================================== From mantis at public.kitware.com Mon Sep 29 06:24:22 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 29 Sep 2014 06:24:22 -0400 Subject: [cmake-developers] [CMake 0015176]: typo in Modules/GNUInstallDirs.cmake Message-ID: <55bf009b044a5d83380b3603a10a6242@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15176 ====================================================================== Reported By: David Coppa Assigned To: ====================================================================== Project: CMake Issue ID: 15176 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-29 06:24 EDT Last Modified: 2014-09-29 06:24 EDT ====================================================================== Summary: typo in Modules/GNUInstallDirs.cmake Description: Commit d4fdd9c189f85d659f4294f8ec6da3e7e51215ec ("GNUInstallDirs: use the proper default for info and man paths on OpenBSD") introduced a typo: CMAKE_INSTALL_MANDDIR -> CMAKE_INSTALL_MANDIR The attached diff fixes the issue. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-29 06:24 David Coppa New Issue 2014-09-29 06:24 David Coppa File Added: 0001-Fix-typo-in-Modules-GNUInstallDirs.cmake.patch ====================================================================== From aklitzing at gmail.com Mon Sep 29 06:29:20 2014 From: aklitzing at gmail.com (A. Klitzing) Date: Mon, 29 Sep 2014 12:29:20 +0200 Subject: [cmake-developers] Support of codesign In-Reply-To: <5425BB57.5080003@kitware.com> References: <54256FB4.1000903@kitware.com> <5425BB57.5080003@kitware.com> Message-ID: > > It should not be an error for 'codesign' to not be available > in the PATH. The user may have set CPACK_COMMAND_CODESIGN > to some other location. The error should only occur if no > value for CPACK_COMMAND_CODESIGN is available when the tool > is actually needed for signing. > I attached another patch that will fix the broken tests. It will check for defined CPACK_APPLE_CERT_APP before it will search for 'codesign'. Well, the FindProgram line for codesign looks like the line for Rez, hdiutil, SetFile and so on. I don't know cmake sources enough... but shouldn't it be the same here? Andr? -------------- 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: 8662 bytes Desc: not available URL: From ruslan_baratov at yahoo.com Mon Sep 29 09:35:21 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Mon, 29 Sep 2014 17:35:21 +0400 Subject: [cmake-developers] iOS support In-Reply-To: References: <54217E53.2070902@kitware.com> <54218A16.1010008@kitware.com> Message-ID: <54296019.40602@yahoo.com> On 23-Sep-14 19:42, Florent Castelli wrote: > On 23 Sep 2014, at 16:56, Bill Hoffman wrote: > >>> That said it would be really cool to beef up the xcode support enough to >>> be able to create an actual ios app. I have not dug into that enough. >>> Should be able to do most of it with CMAKE_XCODE_ATTRIBUTE. I will >>> look into this try_compile COPY_FILE issue today and get back to the list. >>> >>> It would be great if you could get an example/Test in place that builds >>> an app for a device and works with Xcode and for a stretch goal also >>> works with makefiles or ninja. >>> >> Couple of more things. >> >> 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. This would be a great thing to work on. >> > 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. > Hi, Universal libraries can be built by setting CMAKE_OSX_SYSROOT to "iphoneos". This is how it works for me: * https://github.com/ruslo/polly/blob/master/ios-7-1.cmake * https://github.com/ruslo/polly/blob/master/os/iphone.cmake * https://github.com/ruslo/polly/wiki/Toolchain-list#ios real root was found by invoking `xcode-select -print-path`, i.e. you can switch iOS version by providing appropriate DEVELOPER_DIR environment variable. Works for Xcode only (since Xcode 5.0). Ruslo From clinton at elemtech.com Mon Sep 29 09:55:28 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Mon, 29 Sep 2014 07:55:28 -0600 (MDT) Subject: [cmake-developers] Support of codesign In-Reply-To: References: <54256FB4.1000903@kitware.com> <5425BB57.5080003@kitware.com> Message-ID: <1481907634.197627.1411998928462.JavaMail.zimbra@elemtech.com> ----- Original Message ----- > > It should not be an error for 'codesign' to not be available > > > in the PATH. The user may have set CPACK_COMMAND_CODESIGN > > > to some other location. The error should only occur if no > > > value for CPACK_COMMAND_CODESIGN is available when the tool > > > is actually needed for signing. > > I attached another patch that will fix the broken tests. It will check for > defined CPACK_APPLE_CERT_APP before it will search for 'codesign'. > Well, the FindProgram line for codesign looks like the line for Rez, hdiutil, > SetFile and so on. I don't know cmake sources enough... but shouldn't it be > the same here? 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? Thanks, Clint -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Mon Sep 29 10:19:45 2014 From: DLRdave at aol.com (David Cole) Date: Mon, 29 Sep 2014 10:19:45 -0400 Subject: [cmake-developers] Support of codesign In-Reply-To: <1481907634.197627.1411998928462.JavaMail.zimbra@elemtech.com> References: <54256FB4.1000903@kitware.com> <5425BB57.5080003@kitware.com> <1481907634.197627.1411998928462.JavaMail.zimbra@elemtech.com> Message-ID: Maybe it shouldn't even be a CPack thing..... Maybe it should be an install time step so that all CPack generators will contains signed binaries if codesign is used... D On Mon, Sep 29, 2014 at 9:55 AM, wrote: > > > ________________________________ >> >> It should not be an error for 'codesign' to not be available >> in the PATH. The user may have set CPACK_COMMAND_CODESIGN >> to some other location. The error should only occur if no >> value for CPACK_COMMAND_CODESIGN is available when the tool >> is actually needed for signing. > > > I attached another patch that will fix the broken tests. It will check for > defined CPACK_APPLE_CERT_APP before it will search for 'codesign'. > > Well, the FindProgram line for codesign looks like the line for Rez, > hdiutil, SetFile and so on. I don't know cmake sources enough... but > shouldn't it be the same here? > > > 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? > > Thanks, > Clint > > -- > > 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 chuck.atkins at kitware.com Mon Sep 29 13:23:04 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 29 Sep 2014 13:23:04 -0400 Subject: [cmake-developers] Support of codesign In-Reply-To: References: <54256FB4.1000903@kitware.com> <5425BB57.5080003@kitware.com> <1481907634.197627.1411998928462.JavaMail.zimbra@elemtech.com> Message-ID: > > Maybe it shouldn't even be a CPack thing..... Maybe it should be an > install time step so that all CPack generators will contains signed > binaries if codesign is used... > I know this is a bit after the fact and I'm jumping in here pretty late, but... It would be nice to have package signing as a general top level CPack feature. Most supported package formats support some form of signing, rpm and deb with gpg keys, apple bundles, dmgs, nsis installers, etc. Could this be done as a generic CPack variable, CPACK_PACKAGE_SIGNING_KEY, for example, and then if set, then each CPack generator would use it accordingly? Just a thought, not to derail this current patch though. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton at elemtech.com Mon Sep 29 14:00:59 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Mon, 29 Sep 2014 12:00:59 -0600 Subject: [cmake-developers] Support of codesign In-Reply-To: References: Message-ID: <2614570.QAlDDbOxL6@stryke> On Monday, September 29, 2014 01:23:04 PM Chuck Atkins wrote: > > Maybe it shouldn't even be a CPack thing..... Maybe it should be an > > install time step so that all CPack generators will contains signed > > binaries if codesign is used... > > I know this is a bit after the fact and I'm jumping in here pretty late, > but... > > It would be nice to have package signing as a general top level CPack > feature. Most supported package formats support some form of signing, rpm > and deb with gpg keys, apple bundles, dmgs, nsis installers, etc. Could > this be done as a generic CPack variable, CPACK_PACKAGE_SIGNING_KEY, for > example, and then if set, then each CPack generator would use it > accordingly? > > Just a thought, not to derail this current patch though. The patch does introduce a SignPackage() function, but what its really doing is signing the application, not the package. There is another suggestion for the patch -- rename the SignPackage() function to be clear that the application is being signed, not the package. At least in the CPack context, the package is the .dmg file, not the .app bundle. The Bundle generator creates an application bundle plus the package. Because the Bundle generator makes the application, a user would want a way to sign it. This is why its Bundle generator specific. With any other generator, the application signing can be done with an install() command. 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. Clint From mantis at public.kitware.com Tue Sep 30 06:38:12 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 30 Sep 2014 06:38:12 -0400 Subject: [cmake-developers] [CMake 0015178]: CMake very slow at generation stage Message-ID: <68f6564abd8b35cd72fe1a50c397fbe0@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15178 ====================================================================== Reported By: Christophe Prud'homme Assigned To: ====================================================================== Project: CMake Issue ID: 15178 Category: (No Category) Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-30 06:38 EDT Last Modified: 2014-09-30 06:38 EDT ====================================================================== Summary: CMake very slow at generation stage Description: on macosx the generation stage is very slow and it seems that it is the dependencies computation. On our projet (http://www.feelpp.org) is takes minutes for the generation stage while it took seconds in the previous version. On Linux no such issues. It seems that there are a lot of call to otool on macosx and it might be that that slows down thinks ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-30 06:38 Christophe Prud'hommeNew Issue ====================================================================== From ewmailing at gmail.com Tue Sep 30 07:07:32 2014 From: ewmailing at gmail.com (Eric Wing) Date: Tue, 30 Sep 2014 04:07:32 -0700 Subject: [cmake-developers] iOS support In-Reply-To: References: Message-ID: On 9/23/14, Florent Castelli wrote: > Hi! > > My company is organizing soon a hack week where each employee is able to > work on any project he wants. So, I've decided to work with Cmake and > improve support for iOS to help the product team getting rid of manual > project files, constant merge conflicts and bad project file documentation, > while improving our tooling possibilities (all that with Cmake!). > > I've had a quick look at the first issue that popped into my mind the other > day and fixed try_compile by adding another variable to set the executable > type in the generated project (it has to be MACOSX_BUNDLE) and fixing the > search path for the resulting binary. > So this is now working... Providing we are targeting the simulator. > Due to the nature of Xcode projects that can easily target either the > simulator or devices, thus using different compilation flags, the resulting > projects aren't working in both case. There are conflicts between some > options like the minimum iOS version target and the minimum iOS simulator > target for example (which you need to build the try_compile binaries > without signing them). > Also, the Xcode support is very OSX focused and all variables have MACOSX > in their name, which is confusing. > > So, has anyone worked on similar issues and can suggest a way to progress > and improve support for iOS? > In the end, I'd like to have a working Xcode project with separate settings > for both simulator and device, Cmake compiler flag detection working, and > possibly later Make/Ninja projects working too. > > Regards, > /Orphis > This is off the top of my head, and its late... Some context...I'm developing a new SDK for game developers. I've been spending a lot of time with the generators (Windows, Linux, Mac, iOS, Android, and playing with Windows Phone recently). CMake is the best game in town for handling all these platforms. But there are also a ton of things that annoy me. My goal is to help people build apps they can ship, but much of CMake's thought process is about building apps locally for your system and the work flow isn't correct in my opinion. I've done a lot to address these short-comings and I hope to clear some time to talk about all this and share my changes in the near future. (Especially the Android stuff...I had to build a lot of crap to make that work and I would like to fold that back into the CMake core because it is evil.) As for iOS (and some Mac), one of my peevs is that the application bundle process doesn't happen as part of the build. For a normal Mac/iOS development, you always rebuild your code and your application bundle. CMake treats this as two discrete steps so what you develop/test is different from what you ship. (And incidentally in the Visual Studio case, I discovered it is impossible to launch your app via the debugger because of this too.) Additionally, the iOS/CMake stuff is flakey about letting you switch between device and simulator. You shouldn't have to generate a completely different project to test between the two. This is not how iOS developers work nor how the Xcode toolchain is designed. (And now that we have 32-bit and 64-bit versions of both, it's ridiculous.) I some how got mine to the point where I can switch targets in the same project, but it's flakey due to the way CMake injects paths/values into the Xcode project. It isn't the same exact values as Apple, so somethings like finding frameworks/libraries cause me to do some tricks. Also on that note, just getting CMake to pick the proper "Lastest SDK" value by default would be nice. It is hard coding some full path which seems to work in base cases, but causes me problems in other cases. I noticed when Xcode versions change, this often is the main culprit for new breakage. All the configuration options are blank for me. The Mac one works, but iOS is blank for me. This means thinks like all my optimization settings are the same (debug and release have the same values). I can set these values manually, but I have only been able to do it to my own targets explicitly. My attempts to set the values globally (at the root) have not succeeded. I still haven't dealt with launch images and icons. A proper sized launch image is required to get the iPhone 5 and iPhone 6 "tall" resolutions without letterboxing. I'm not sure what the right thing to do here is with CMake. I'm doing my own application bundling to some degree. As I said, CMake's normal process goes against the grain of the normal workflow so I changed it to behave like the real thing. I'm having trouble remembering, but I think the CMake/Mac had better handling than CMake/iOS. CMake was doing some stuff for me better than iOS, but I don't fully remember. (May have something to do with listing resources as part of the target.) But one place I found CMake to be really annoying was with nested directories and also symlinks. Copying a framework into a bundle is a good example because it has both. And ideally, you only want to do it when there is a change. (I think I got lazy and call rsync in some places since I know it is installed on Mac.) Codesigning for both Mac and iOS I haven't figured out yet either. On iOS, you have development and distribution keys. On Mac, you also have Mac App Store vs. GateKeeper. Xcode normally gives you a display to let you see and configure important things like Sandboxing options, launch images, icon resolutions, code signing. But when going through the CMake generator, it doesn't show any of this stuff. I don't know why, but it's disturbing/scary (because it feels broken/fragile) and annoying. Maybe updating the underlying Xcode template CMake uses will help? I would like CMake's install/packaging system to work seamlessly with the built in archiving system which is what people use to prepare an iOS app for submission to the App Store. There is a bug I sometimes hit where the generated Xcode project causes the "Indexing" phase to get stuck and I have to kill Xcode. And when it happens to me, it keeps happening. This really scares me, but I can't reliably reproduce it. Xcode 6 seems to have improved the problem for me (so far). For building libraries instead of applications, iOS 8 now has 3rd party framework support (to support their new plugin system). I have not tested this. But the framework layout is different than in Mac (similar to how the .app bundle layout differs between iOS and Mac). I'm guessing this will need to be adjusted in CMake. Also, FYI, flat dylibs are not supported as far as I know...only frameworks. Also, I think the @rpath stuff is still important, and I read that Apple has now split the setting that was once the "install path" into two separate entries, where the new entry is just for the rpath. (Install path never made a lot of sense the way Apple does things since there is never really an install path.) Yes, it would be nice to build Universal binaries with simulator and devices in the same fat binary, but Apple doesn't do this for you, and I don't know if CMake should do this for you either. I saw on the Xcode list, one senior Apple engineer was being difficult when pressed on this issue. I think Apple is trying to leave open the possibility that there could be an x86 device target some day, in which case it would conflict with an x86 simulator target. Annoying. Currently, I just lipo everything myself manually and say screw it. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ From nilsgladitz at gmail.com Tue Sep 30 10:05:43 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 30 Sep 2014 16:05:43 +0200 Subject: [cmake-developers] kwsys SystemTools::RelativePath() Message-ID: <542AB8B7.8020102@gmail.com> When both operands are the same absolute path I get the empty string as a result. Should it be "."? Nils From norman-k-williams at uiowa.edu Tue Sep 30 10:14:15 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Tue, 30 Sep 2014 14:14:15 +0000 Subject: [cmake-developers] find_package issues with ITK and VTK (and SlicerExecution Model) Message-ID: This is a problem that has been cropping up in our projects that use ITK, VTK and SlicerExecutionModel. You won?t see it UNLESS you turn on the ITKVTK/ITKVtkGlue modules. The problem is this: if you find packages in this order: find_package(VTK REQUIRED) find_package(ITK REQUIRED) You can?t real compile anything that needs VTK, because down in the ITK deployment stuff, it calls find_package(VTK) like this: find_package(VTK COMPONENTS vtkCommonCore vtkRenderingCore vtkRenderingOpenGL vtkRenderingFreeType vtkInteractionStyle vtkIOImage vtkImagingSources REQUIRED) Which blows away the larger list of include directories and libraries that the first find_package(VTK REQUIRED) built. Even better ? or worse ? Modules/Segmentation/LevelSetsv4Visualization/CMakeLists.txt also include find_package(VTK) ? so ITK tries to import VTK twice, with different module lists. It doesn?t even help to reverse the order: find_package(ITK REQUIRED) find_package(VTK REQUIRED) because apparently there?s some hangover from the find_package(VTK) inside the ITK CMake deployment files. The only thing that works is to use COMPONENTS, i.e. find_package(ITK REQUIRED) find_package(VTK COMPONENTS vtkCommonCore vtkRenderingAnnotation ? REQUIRED) Which seems to trigger a proper re-scan and build of the library/include lists. It gets even worse if you use find_package(SlicerExecutionModel) after find_package(ITK), for the same reason ? SlicerExecutionModel depends on ITK, so it clobbers the include/library lists from the first find_package(ITK). ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Sep 30 10:48:47 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 30 Sep 2014 10:48:47 -0400 Subject: [cmake-developers] [ITK-dev] find_package issues with ITK and VTK (and SlicerExecution Model) In-Reply-To: References: Message-ID: <542AC2CF.7030008@kitware.com> On 09/30/2014 10:14 AM, Williams, Norman K wrote: > find_package(VTK REQUIRED) > find_package(ITK REQUIRED) > > You can?t real compile anything that needs VTK, because down in > the ITK deployment stuff, it calls find_package(VTK) like this: [snip] > Which blows away the larger list of include directories and libraries One may use the itk_module_config and vtk_module_config macros from the *ModuleAPI.cmake modules that come with the respective packages to compute the list of libraries and include dirs for a given list of components. All ITKConfig and VTKConfig do with the list of components is: itk_module_config(ITK ${ITK_MODULES_REQUESTED}) # sets ITK_LIBRARIES, ITK_INCLUDE_DIRS, etc. and vtk_module_config(VTK ${VTK_MODULES_REQUESTED}) # sets VTK_LIBRARIES, VTK_INCLUDE_DIRS, etc. One can invoke these directly: itk_module_config(ITK ${MY_LIST_OF_ITK_COMPONENTS}) vtk_module_config(VTK ${MY_LIST_OF_VTK_COMPONENTS}) at any time after the find_package calls. One could even use a different prefix: itk_module_config(MyITK ${MY_LIST_OF_ITK_COMPONENTS}) # sets MyITK_LIBRARIES, MyITK_INCLUDE_DIRS, etc. In the long run the plan is to stop recommending use of component lists at find_package time and instead use imported targets and usage requirements: http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#build-specification-and-usage-requirements but that will have to wait until we can require CMake 3.0. -Brad From brad.king at kitware.com Tue Sep 30 11:22:57 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 30 Sep 2014 11:22:57 -0400 Subject: [cmake-developers] [ITK-dev] find_package issues with ITK and VTK (and SlicerExecution Model) In-Reply-To: References: <542AC2CF.7030008@kitware.com> Message-ID: <542ACAD1.2040805@kitware.com> On 09/30/2014 11:13 AM, Bradley Lowekamp wrote: > Do you have a suggestion on how to conditionally include a > module if it's available? e.g. Use ITKDeprecated if ITK was > configure with it? find_package(ITK REQUIRED) set(MY_ITK_COMPONENTS ...) # list required mods here if(";${ITK_MODULES_ENABLED};" MATCHES ";ITKDeprecated;") list(APPEND MY_ITK_COMPONENTS ITKDeprecated) endif() itk_module_config(ITK ${MY_ITK_COMPONENTS}) I think the if() line could also be written if(TARGET ITKDeprecated) but I don't remember off the top of my head whether the library names and module names always match exactly. -Brad From brad.king at kitware.com Tue Sep 30 11:27:12 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 30 Sep 2014 11:27:12 -0400 Subject: [cmake-developers] Integrate fixdep for kconfig In-Reply-To: References: Message-ID: <542ACBD0.3030209@kitware.com> 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 From brad.king at kitware.com Tue Sep 30 11:37:27 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 30 Sep 2014 11:37:27 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic Message-ID: <542ACE37.1040302@kitware.com> Hi Folks, Picking up from the end of an earlier thread: [PATCH] stage/fix-OSX-bundle-rpaths-and-Qt5 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10781/focus=11016 Is the fix-OSX-bundle-rpaths-and-Qt5 topic ready to be merged to 'next' for testing? Clinton, have your comments been addressed? Thanks, -Brad From clinton at elemtech.com Tue Sep 30 11:54:59 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Tue, 30 Sep 2014 09:54:59 -0600 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <542ACE37.1040302@kitware.com> References: <542ACE37.1040302@kitware.com> Message-ID: <5370725.77ofmgz3NP@stryke> On Tuesday, September 30, 2014 11:37:27 AM Brad King wrote: > Hi Folks, > > Picking up from the end of an earlier thread: > > [PATCH] stage/fix-OSX-bundle-rpaths-and-Qt5 > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10781/focu > s=11016 > > Is the fix-OSX-bundle-rpaths-and-Qt5 topic ready to be merged to > 'next' for testing? Clinton, have your comments been addressed? > > Thanks, > -Brad My concerns of breaking backward compatibility were already addressed. However, I do wish there is a test for this. Although the commits target OS X, I would like to see some proof that the API changes in GetPrerequisites for supporting rpaths will work on other platforms such as Linux. A test for both OS X and Linux will help justify the API changes. Clint From ono at java.pl Tue Sep 30 12:24:29 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 30 Sep 2014 18:24:29 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <5370725.77ofmgz3NP@stryke> References: <542ACE37.1040302@kitware.com> <5370725.77ofmgz3NP@stryke> Message-ID: > A test for both OS X and Linux will help justify the API changes. Well. All I can say that failing tests were already addressed in latest version of this branch. Also it does not break existing functions signature or behavior. All new parameters are optional. I have no other means to prove that everything is OK. --Adam From mantis at public.kitware.com Tue Sep 30 12:49:34 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 30 Sep 2014 12:49:34 -0400 Subject: [cmake-developers] [CMake 0015179]: Please set default CMAKE_{C, CXX}_FLAGS_DEBUG to -g -Og if -Og is available Message-ID: <8ea06d3ca2251d41808eb9b4915a3548@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15179 ====================================================================== Reported By: Daniel Schepler Assigned To: ====================================================================== Project: CMake Issue ID: 15179 Category: CMake Reproducibility: have not tried Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-30 12:49 EDT Last Modified: 2014-09-30 12:49 EDT ====================================================================== Summary: Please set default CMAKE_{C,CXX}_FLAGS_DEBUG to -g -Og if -Og is available Description: gcc-4.8 introduced the new -Og flag, to enable some minor optimizations which don't interfere with debugging. It would be nice to have this set by default in debug builds. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-30 12:49 Daniel ScheplerNew Issue ====================================================================== From matt.mccormick at kitware.com Tue Sep 30 12:59:39 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 30 Sep 2014 12:59:39 -0400 Subject: [cmake-developers] [ITK-dev] find_package issues with ITK and VTK (and SlicerExecution Model) In-Reply-To: References: Message-ID: Hi Kent, On Tue, Sep 30, 2014 at 10:14 AM, Williams, Norman K wrote: > This is a problem that has been cropping up in our projects that use ITK, > VTK and SlicerExecutionModel. > > You won?t see it UNLESS you turn on the ITKVTK/ITKVtkGlue modules. > > The problem is this: if you find packages in this order: > > find_package(VTK REQUIRED) > find_package(ITK REQUIRED) > > You can?t real compile anything that needs VTK, because down in the ITK > deployment stuff, it calls find_package(VTK) like this: > find_package(VTK COMPONENTS > vtkCommonCore > vtkRenderingCore > vtkRenderingOpenGL > vtkRenderingFreeType > vtkInteractionStyle > vtkIOImage > vtkImagingSources > REQUIRED) > > Which blows away the larger list of include directories and libraries that > the first find_package(VTK REQUIRED) built. > > Even better ? or worse ? > Modules/Segmentation/LevelSetsv4Visualization/CMakeLists.txt also include > find_package(VTK) ? so ITK tries to import VTK twice, with different module > lists. > > It doesn?t even help to reverse the order: > find_package(ITK REQUIRED) > find_package(VTK REQUIRED) > > because apparently there?s some hangover from the find_package(VTK) inside > the ITK CMake deployment files. The only thing that works is to use > COMPONENTS, i.e. > > find_package(ITK REQUIRED) > find_package(VTK COMPONENTS vtkCommonCore vtkRenderingAnnotation ? REQUIRED) > > Which seems to trigger a proper re-scan and build of the library/include > lists. This was discussed in this thread [1]. There does not seem to be interest at this time to have mixed COMPONENTS / non-COMPONENTS calls to find_package. It is also recommended to use the MODULE option to find_package. A "newer" version of VTK 6 is also required. > It gets even worse if you use find_package(SlicerExecutionModel) after > find_package(ITK), for the same reason ? SlicerExecutionModel depends on > ITK, so it clobbers the include/library lists from the first > find_package(ITK). > A patch was merged a few days ago that might address this issue [2]. Is this behavior still see with current ITK? Thanks, Matt [1] http://public.kitware.com/pipermail/vtk-developers/2014-September/015376.html [2] http://review.source.kitware.com/#/c/16963/ From brad.king at kitware.com Tue Sep 30 13:00:46 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 30 Sep 2014 13:00:46 -0400 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: References: <542ACE37.1040302@kitware.com> <5370725.77ofmgz3NP@stryke> Message-ID: <542AE1BE.4000608@kitware.com> On 09/30/2014 12:24 PM, Adam Strzelecki wrote: > I have no other means to prove that everything is OK. Please merge the topic to 'next' for testing when you're ready. We can at least see if the dashboard stays clean with it. Thanks, -Brad From mantis at public.kitware.com Tue Sep 30 13:04:56 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 30 Sep 2014 13:04:56 -0400 Subject: [cmake-developers] [CMake 0015180]: FindGLUT.cmake should search for glut64 instead of glut32 on 64-bit Windows Message-ID: <0c3ab23d76d06da7291caeaa52c02f7f@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15180 ====================================================================== Reported By: Daniel Schepler Assigned To: ====================================================================== Project: CMake Issue ID: 15180 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-30 13:04 EDT Last Modified: 2014-09-30 13:04 EDT ====================================================================== Summary: FindGLUT.cmake should search for glut64 instead of glut32 on 64-bit Windows Description: On 64-bit Windows, the GLUT stub library is named glut64.lib instead of glut32.lib. So, find_package(GLUT) should be searching for glut64 instead of glut32 on that platform. (Or maybe search for both with glut64 preferred, if in fact there are some 64-bit versions of glut32.lib/glut32.dll out there.) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-30 13:04 Daniel ScheplerNew Issue ====================================================================== From mantis at public.kitware.com Tue Sep 30 13:18:37 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 30 Sep 2014 13:18:37 -0400 Subject: [cmake-developers] [CMake 0015181]: math can't handle negative numbers. Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15181 ====================================================================== Reported By: tron_thomas Assigned To: ====================================================================== Project: CMake Issue ID: 15181 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-30 13:18 EDT Last Modified: 2014-09-30 13:18 EDT ====================================================================== Summary: math can't handle negative numbers. Description: The math command cannot do addition with negative numbers Steps to Reproduce: Run CMake against the following CMakeLists.txt file: cmake_minimum_required (VERSION 2.8) project (MathFailure) set (value -1) math (EXPR value "${value} + 1") Expected: value should be incremented to zero Actual: CMake Error at CMakeLists.txt:6 (math): math cannot parse the expression: "-1 + 1": syntax error, unexpected exp_MINUS, expecting exp_OPENPARENT or exp_NUMBER (1) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-30 13:18 tron_thomas New Issue ====================================================================== From ono at java.pl Tue Sep 30 13:44:56 2014 From: ono at java.pl (Adam Strzelecki) Date: Tue, 30 Sep 2014 19:44:56 +0200 Subject: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic In-Reply-To: <542AE1BE.4000608@kitware.com> References: <542ACE37.1040302@kitware.com> <5370725.77ofmgz3NP@stryke> <542AE1BE.4000608@kitware.com> Message-ID: > 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. --Adam From mantis at public.kitware.com Tue Sep 30 16:26:23 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 30 Sep 2014 16:26:23 -0400 Subject: [cmake-developers] [CMake 0015182]: FindMPI.cmake fails to properly detect Intel MPI 5.0.1 Message-ID: <0c0f9f12fa13f2b7bc935abc68d50e60@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15182 ====================================================================== Reported By: Kelly Thompson Assigned To: ====================================================================== Project: CMake Issue ID: 15182 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-09-30 16:26 EDT Last Modified: 2014-09-30 16:26 EDT ====================================================================== Summary: FindMPI.cmake fails to properly detect Intel MPI 5.0.1 Description: The FindMPI.cmake module queries for include path and link libraries by attempting to use various options (e.g.: -showme:compile) of MPI_${lang}_COMPILER. # Check whether the -showme:compile option works. This indicates that we have either OpenMPI # or a newer version of LAM-MPI, and implies that -showme:link will also work. execute_process( COMMAND ${MPI_${lang}_COMPILER} -showme:compile OUTPUT_VARIABLE MPI_COMPILE_CMDLINE OUTPUT_STRIP_TRAILING_WHITESPACE ERROR_VARIABLE MPI_COMPILE_CMDLINE ERROR_STRIP_TRAILING_WHITESPACE RESULT_VARIABLE MPI_COMPILER_RETURN) For Intel MPI, MPI_CXX_COMPILER has the value 'mpiicpc.' The command 'mpiicpc -showme:compile' fails, but returns a '0' error code: % mpiicpc -showme:comple; echo $? icpc: command line warning http://public.kitware.com/Bug/view.php?id=10006: ignoring unknown option '-showme:comple' /var/lib/perceus/vnfs/asc-fe/rootfs/usr/bin/../lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' 0 I have contacted Intel support and they confirmed that this is by design. Unknown compiler options are considered to be warnings, not errors. This issue can be fixed by adding more complex logic to test the error state of the 'mpiicpc -showme:compile' command. In my local install of CMake, I added the following logic: if( "${MPI_COMPILE_CMDLINE}" MATCHES "undefined reference") set( MPI_COMPILER_RETURN 255 ) endif() This appears to solve the problem of incorrect information being saved in MPI_LINK_CMDLINE, MPI_INCDIRS, and MPI_LIBDIRS. Steps to Reproduce: Before running cmake, I needed to set these environment variables: export CXX=`which mpiicpc` export CC=`which mpiicc` export MPIEXEC=`which srun` So that FindMPI would query the correct MPI compile wrappers. See bug description for more details. Additional Information: I can reproduce this issue with Intel MPI 5.0.1 and Intel MPI 4.1.3 on two different systems (RHEL 6.4 and RHEL 6.5) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-09-30 16:26 Kelly Thompson New Issue ====================================================================== From ewmailing at gmail.com Tue Sep 30 19:42:07 2014 From: ewmailing at gmail.com (Eric Wing) Date: Tue, 30 Sep 2014 16:42:07 -0700 Subject: [cmake-developers] iOS support In-Reply-To: References: Message-ID: 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