Re: [cmake-developers] Can we please require TR1 to build CMake?
On Mon, Jan 9, 2017 at 8:30 PM, Brad King wrote: > On 01/09/2017 05:46 AM, Daniel Pfeifer wrote: > > start using TR1/C++11 library features, namely std::function, std::bind, > > std::placeholders, std::shared_ptr, std::make_shared. > > I'd love to be able to start using those too, but last time I checked > they are not supported everywhere CMake builds, at least in the standard > libraries (see below). > > > AIX-7.1_IBM-12.1 reports that __IBMCPP_TR1__ must be defined to use TR1. > > Hopefully, but that would take some investigation. > > > Xcode 2.1 and 3.2 fail. These builds are not marked as "expected". > > I'd be okay with dropping these. > > > This leaves HP-UX.11iv2.ia64-aCC and Solaris-10-8.11_Oracle-12.3. > > IIUC the Oracle compiler supports C++11 when told to use the proper > stdlib. However, I don't think there is a solution on HP-UX with its > standard library. > > > * Explicitly require SP1 for Visual Studio 2008. > > Okay. For hosting CMake's own build we could even consider requiring > VS 2010. One blocker for that on Kitware's side is updating our > dashboard machines as needed to be able to host CMake builds even if > testing generators for older versions. I'm not sure when I'll have > time to do that. > > > * Disallow compiling in C++98 mode if compiler is capable of C++11. > > Okay. > > > * Require TR1 by all means. This may require setting up Boost.TR1 > > on a very small number of exotic platforms. > > IIRC there is a tool to extract a subset of boost. Please see how > small it can get. We can even remove the config headers for the > platforms we don't need to use it, perhaps manually. > I have pushed an updated branch to https://gitlab.kitware.com/cmake/cmake/merge_requests/760/diffs The necessary subset of boost can be generated with: ``` mkdir -p cm_boost bcp --boost= \ boost/bind.hpp \ boost/function.hpp \ boost/mem_fn.hpp \ boost/ref.hpp \ boost/unordered_map.hpp \ boost/unordered_set.hpp \ boost/shared_ptr.hpp \ boost/weak_ptr.hpp \ boost/enable_shared_from_this.hpp \ cm_boost ``` The resulting directory is 6.5 MB, 2.6 MB of which are preprocessed headers for Boost.MPL. When we remove them, we get the size down to 3.9 MB. Removing individual config headers is tedious and does not save much. Cheers, Daniel -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Patch: Don't emit warning when config file not found
Hi Brad, please find attached a first attempt to implement OPTIONAL for find_package. It is supposed to suppress all warnings and indicate the negative result by a single line of output. Unfortunately, I still get a warning and I could figure out how to simply print a message without the warning. Could you give me some hints and comment on my patch? Thanks Christoph -- [..] Mathematicians are like theologians: we regard existence as the prime attribute of what we study. But unlike theologians, we need not always rely upon faith alone. [Lawrence Evans] Am 10.10.2016 um 14:51 schrieb Brad King: > On 10/09/2016 03:24 PM, Christoph GrĂ¼ninger wrote: >> * or loosing the output of tests and feature summary, as both tests are >> QUIET. >> >> I'd prefer to write the error message to the CMakeError.log and reduce >> the output to one line. I think, the current behavior must be considered >> a bug. > > The default behavior evolved over many years to satisfy many use cases and > give people the information they need to resolve real problems. It is not > going to change. However, if you'd like to propose additional options to > these interfaces to get the behavior you want then that would be fine. > Perhaps find_package could gain an ``OPTIONAL`` switch. I'm not very > familiar with feature_summary so I'm not sure what that would need off the > top of my head. > > -Brad >From efebb5e08dacb5eedc9cd2c809f2a937a156de8c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christoph=20Gr=C3=83=C2=BCninger?= Date: Tue, 25 Apr 2017 06:41:31 +0200 Subject: [PATCH] cmFindPackageCommand: Add OPTIONAL If OPTIONAL is set and the package is not found, just a single line of output is written and despite QUIET the package appears in the feature summary. --- Help/command/find_package.rst | 18 -- Source/cmFindPackageCommand.cxx | 24 ++-- Source/cmFindPackageCommand.h | 1 + 3 files changed, 35 insertions(+), 8 deletions(-) diff --git a/Help/command/find_package.rst b/Help/command/find_package.rst index 60a77b85e..61b31ac46 100644 --- a/Help/command/find_package.rst +++ b/Help/command/find_package.rst @@ -5,8 +5,8 @@ Load settings for an external project. :: - find_package( [version] [EXACT] [QUIET] [MODULE] - [REQUIRED] [[COMPONENTS] [components...]] + find_package( [version] [EXACT] [OPTIONAL] [QUIET] + [MODULE] [REQUIRED] [[COMPONENTS] [components...]] [OPTIONAL_COMPONENTS components...] [NO_POLICY_SCOPE]) @@ -14,7 +14,10 @@ Finds and loads settings from an external project. ``_FOUND`` will be set to indicate whether the package was found. When the package is found package-specific information is provided through variables and :ref:`Imported Targets` documented by the package itself. The -``QUIET`` option disables messages if the package cannot be found. The +``OPTIONAL`` option reduces the lengthy warning message to a single +line of output if the package cannot be found. The ``QUIET`` option +disables messages if the package cannot be found and suppresses the +feature summary for this package. The ``MODULE`` option disables the second signature documented below. The ``REQUIRED`` option stops processing with an error message if the package cannot be found. @@ -54,7 +57,7 @@ option is not given the command proceeds to Config mode. The complete Config mode command signature is:: - find_package( [version] [EXACT] [QUIET] + find_package( [version] [EXACT] [OPTIONAL] [QUIET] [REQUIRED] [[COMPONENTS] [components...]] [CONFIG|NO_MODULE] [NO_POLICY_SCOPE] @@ -100,8 +103,11 @@ version are stored in the cmake variable ``_CONSIDERED_CONFIGS``, the associated versions in ``_CONSIDERED_VERSIONS``. If the package configuration file cannot be found CMake will generate -an error describing the problem unless the ``QUIET`` argument is -specified. If ``REQUIRED`` is specified and the package is not found a +an error describing the problem. When the ``OPTIONAL`` argument is +specified, the error is reduced to a single line containing the package +status. When the ``QUIET`` argument is specified, the error and +possible feature summary entries are suppressed. +If ``REQUIRED`` is specified and the package is not found a fatal error is generated and the configure step stops executing. If ``_DIR`` has been set to a directory not containing a configuration file CMake will ignore it and search from scratch. diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx index 17fa92ccd..2f899a38f 100644 --- a/Source/cmFindPackageCommand.cxx +++ b/Source/cmFindPackageCommand.cxx @@ -83,6 +83,7 @@ void cmFindPackageCommand::Sort(std::vector::iterator begin, cmFindPackageCommand::cmFindPackageCommand() { this->CMakePathName = "PACKAGE"; + this->Optional = false; this->Quiet = false; this->Required = false; this->NoUserR
Re: [cmake-developers] Nighly build of CMake release branch available?
On 04/25/2017 10:32 AM, Gregor Jasny via cmake-developers wrote: > I wonder if a nightly (or on-demand) build of the CMake release branch > is available somewhere as it is for the master branch. That would help > me testing those snapshots within our companies projects. No, we don't currently have one for `release`. Unfortunately I don't think the build machines have room for more than one binary each night since they are also used for other things. Also we'd have to be careful providing such binaries because their version number would look like a release even though they are not the actual tagged version. Technically there is not one for `master` either. They are built from the MR topic staging branch, which consists of `master` plus all the staged MRs. This makes it easy for reporters to test fixes before they are merged. It also gives our MRs the same testing that is done for release binary builds (except for manual steps). -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
[cmake-developers] Nighly build of CMake release branch available?
Hello, I wonder if a nightly (or on-demand) build of the CMake release branch is available somewhere as it is for the master branch. That would help me testing those snapshots within our companies projects. Thanks, Gregor -- 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
Re: [cmake-developers] Trouble with FindPNG module
To give you some context, this is an Ubuntu 14 installation for hosting our Atlassian Bamboo build server. We use it to build a 32-bit application. The OS itself is 64-bit, but our app does not compile 64 bit (code is too crappy). So I had to make sure to be careful that I'm using the correct toolchain (gcc 4.9) and 32-bit libs. CMake uses find_package() for most libraries, and those libs must be the 32-bit versions. What instructions would you suggest for setting up the VM like you mentioned? It needs to be something I can "initialize" from within Bamboo. Basically as part of the build process, before doing anything, I need to be able to tell bamboo to use a specific environment (in this case specific VM). I'm not incredibly familiar with Linux, so hopefully there is a recommended path here. Thanks. On Mon, Apr 24, 2017 at 1:17 PM, Roger Leigh wrote: > On 24/04/2017 15:54, Robert Dailey wrote: >> >> Sorry to bump; any info on this? I'm completely blocked :-( >> >> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey >> wrote: >>> >>> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following: >>> >>> find_package(PNG REQUIRED) >>> >>> Which gives me the output in CMake: >>> >>> Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50") >>> >>> The CMakeCache.txt file has these variables set: >>> >>> PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND >>> PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND >>> PNG_PNG_INCLUDE_DIR:PATH=/usr/include >>> >>> So it found the headers, but not the libs. Why did it not find the >>> libs? Note that my version of Ubuntu is 64-bit, and I've installed the >>> 32-bit libs like so: >>> >>> $ sudo apt-get install libpng12-dev:i386 >>> >>> Would the find module be confused because it is trying to find the >>> 64-bit library? What's the issue? > > > Sounds like that's exactly the problem. You can only have one libpng > *development* package installed at once. You probably want the regular > "libpng-dev" package installed if you want to build against the standard > libpng. > > What's your goal here? Why did you install a single i386 development > package? > > If you want to build i386 binaries, it's usually simpler to build in a > virtual machine, i.e. a chroot, container, full VM or whatever you like, > where you have a fully 32-bit environment. The multiarch library support is > primarily intended for *deploying and running* 32-bit code rather than > development. While you can use it for development, it gets painful due to > the conflicts with the headers and other bits in the native development > packages. > > > Regards, > Roger > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] On-going UseSWIG troubles with the official versions --SOLVED
On 04/25/2017 04:08 AM, Alan W. Irwin wrote: > set PREFIX to "" for all languages not specifically covered by the if > and elseif blocks. Do you mean ``` diff --git a/Modules/UseSWIG.cmake b/Modules/UseSWIG.cmake index 277f4ca28a..bfe1a6f754 100644 --- a/Modules/UseSWIG.cmake +++ b/Modules/UseSWIG.cmake @@ -326,6 +326,9 @@ macro(SWIG_ADD_LIBRARY name) if (APPLE) set_target_properties (${SWIG_MODULE_${name}_REAL_NAME} PROPERTIES SUFFIX ".bundle") endif () + else() +# assume empty prefix because we expect the module to be dynamically loaded +set_target_properties (${SWIG_MODULE_${name}_REAL_NAME} PROPERTIES PREFIX "") endif () endmacro() ``` ? -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
Re: [cmake-developers] On-going UseSWIG troubles with the official versions --SOLVED
On 2017-04-23 14:26-0700 Alan W. Irwin wrote: [... My] further testing showed the versions of FindSWIG.cmake and UseSWIG.cmake from CMake-3.0.2 has build failures for Java and Lua, and the versions from CMake-3.6.2 and 3.8.0-rc4 have build failures for Java even though none of these "official" versions exhibited the rule contamination. I have bumped the minimum CMake version from 3.0.2 to 3.6.2 for PLplot so I am not going to worry about the Lua issue for 3.0.2. And it turned out the Java issue was simply a change in naming convention for the resulting module between my special UseSWIG.cmake and the official ones that I needed to adjust for. So that concludes this topic from the PLplot perspective. However, while researching this, I did notice one issue with the CMake git master version of Modules/UseSWIG.cmake that the CMake maintainers of that file might want to address which is the if...elseif...elseif clauses establishing the PREFIX and SUFFIX properties for each specific language language covered currently has no else clause to set PREFIX to "" for all languages not specifically covered by the if and elseif blocks. I suggest you do implement such an else cause to be consistent with older versions of UseSWIG.cmake (such as my special version) which simply set PREFIX to "" for all languages, and also consistent with the specificially covered languages where PREFIX is set to "" as well (except for the Java case). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers