Re: [cmake-developers] [CMake] Problems with WriteCompilerDetectionHeader and cxx_nullptr
On 03/11/2015 05:22 PM, Roman Wüger wrote: > This simple example produces the following error on Mac OS: > error: cannot initialize a parameter of type 'bool *' with an rvalue of type > 'void *' > void doSomething(int n = 1, bool *ok = static_cast(0)) { > ^~ Indeed. It looks like it was written that way originally in the module: Add the WriteCompilerDetectionHeader module. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=62a4a67d There is a proposed library-only implementation of nullptr here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf "1.1 Alternative #1: A Library Implementation of nullptr" but that is probably too complicated for this compatibility macro that is just supposed to provide the advantages of C++11 when it is available but otherwise work as normal C++98. On 03/12/2015 06:59 AM, Roman Wüger wrote: > -#define ${def_value} static_cast(0) > +#ifdef NULL > +# define ${def_value} NULL > +#else > +# define ${def_value} 0 > +#endif In C++98, NULL is always just "0" AFAIK so the condition may not be needed. I think it is cleaner to not have the definition depend on the order of includes (whether a standard header provides NULL). 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
Re: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support
On 03/11/2015 01:39 PM, Geoffrey Viola wrote: > Attached is a patch with the recommended changes Thanks! The basic toolchain initialization is pretty close. Here are more comments. In Modules/Platform/GHS-MULTI-Initialize.cmake: > +#Setup consistent compiler executables > +find_program(CMAKE_GENERATOR_CC ccarm PATHS ${GHS_COMP_ROOT}) > +find_program(CMAKE_GENERATOR_CXX cxarm PATHS ${GHS_COMP_ROOT}) This should not be needed at all. The CMAKE_GENERATOR_* variables are just hints to the compiler detection logic. Since this generator hard-codes the compiler setting in C++ the logic that uses these variables is never executed anyway. > +string(REGEX MATCH "(comp_)([0-9]+)" CMAKE_SYSTEM_VERSION > "${CMAKE_MAKE_PROGRAM}") > +string(REPLACE "comp_" "" CMAKE_SYSTEM_VERSION "${CMAKE_SYSTEM_VERSION}") EnableLanguage should be able to set CMAKE_SYSTEM_VERSION too now that it has code to find the comp root. > +mark_as_advanced(CMAKE_MAKE_PROGRAM) This should not be needed. > +include(Platform/WindowsPaths) This should move to Modules/Platform/GHS-MULTI.cmake In EnableLanguage: > + mf->AddDefinition("CMAKE_MAKE_PROGRAM", > +std::string(ghsCompRootStart + "gbuild.exe").c_str()); The VS and Xcode generators no longer put this in the cache. Take a look at how the Xcode generator now does this with cmGlobalXCodeGenerator::FindMakeProgram cmGlobalXCodeGenerator::GetXcodeBuildCommand cmGlobalXCodeGenerator::FindXcodeBuildCommand and its call to SelectMakeProgram in GenerateBuildCommand: this->SelectMakeProgram(makeProgram, this->GetXcodeBuildCommand()) Together this all allows the generator to compute the proper build tool without exposing any settings to the user. > + mf->AddDefinition("CMAKE_C_COMPILER_ID", "GhsMultiArmC"); [snip] > + mf->AddDefinition("CMAKE_CXX_COMPILER_ID", "GhsMultiArmCXX"); Instead of "GhsMultiArm*" these should be just "GHS", to be consistent with "Modules/Compiler/GHS-DetermineCompiler.cmake". - Please also look at modifying the Help/ directory to document the new generator. You'll need at least to create/update: Help/manual/cmake-generators.7.rst Help/generator/Green Hills MULTI.rst Help/variable/CMAKE_MAKE_PROGRAM.rst where the change to the last one depends on the above updates. 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
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 03/12/2015 12:35 PM, Raffi Enficiaud wrote: >> Please find the attached patch addressing the issues. In the current >> implementation, if the Matlab_ROOT_DIR is changed by the user, the >> cached variables are all cleared. >> Also, Matlab_ROOT_DIR is now the only variable that is seen as non >> advanced. > > The attached patch replaces the previous one: now the versions on > Windows are ordered starting the most recent (+ an ugly remaining > FATAL_ERROR debug). Great. I applied that on top of where we last left off and then rebased on 'master' to resolve conflicts. I also made a couple minor tweaks: * Renamed one more MATLAB_USER_ROOT => Matlab_ROOT_DIR * Do not call list(REMOVE_DUPLICATES/SORT/REVERSE) with no list The commits are now: FindMatlab: Rewrite module and provide a usage API http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c025a5f FindMatlab: Further revisions http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=842ab109 FindMatlab: Further revisions http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3743aa11 I will squash all this together once everything is done. For now please base further work on commit 3743aa11. We'll see how this does on the nightly testing! 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
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Le 11/03/15 00:12, Raffi Enficiaud a écrit : Hi Brad, Please find the attached patch addressing the issues. In the current implementation, if the Matlab_ROOT_DIR is changed by the user, the cached variables are all cleared. Also, Matlab_ROOT_DIR is now the only variable that is seen as non advanced. Best, Raffi Hi Brad, The attached patch replaces the previous one: now the versions on Windows are ordered starting the most recent (+ an ugly remaining FATAL_ERROR debug). Best, Raffi >From bca63b3669366d3d2db4438efe91c58d3a82fc40 Mon Sep 17 00:00:00 2001 From: Raffi Enficiaud Date: Thu, 12 Mar 2015 17:08:44 +0100 Subject: [PATCH] * Simplified workflow, better isolation of the code when Matlab is to be found from the PATH * Removing the "which matlab" as the find_program was erroneous * MATLAB_USER_ROOT renamed to Matlab_ROOT_DIR, which now reflects the found root, removed Matlab_ROOT * Reduced the number of find_program(matlab) * Nulled the input stream of the execute_process in order to avoid the troubleshooting with the terminal * Clearing all the cached variables in case the Matlab_ROOT_DIR is changed by the user * Marking all but Matlab_ROOT_DIR variable as advanced * Hiding all internal cache entries * Avoiding the computation of the version (Matlab_ROOT_DIR set) if the first pass produced the version automatically * Windows: now versions are ordered starting from the most recent --- Modules/FindMatlab.cmake | 490 - Modules/MatlabTestsRedirect.cmake | 8 + Tests/FindMatlab/cmake_matlab_unit_tests_timeout.m | 3 +- Tests/RunCMake/CMakeLists.txt | 1 + 4 files changed, 289 insertions(+), 213 deletions(-) diff --git a/Modules/FindMatlab.cmake b/Modules/FindMatlab.cmake index 9686a76..b61c620 100644 --- a/Modules/FindMatlab.cmake +++ b/Modules/FindMatlab.cmake @@ -28,14 +28,15 @@ # :command:`matlab_get_release_name_from_version` allow a mapping # from the release name to the version. # -# The variable :variable:`MATLAB_USER_ROOT` may be specified in order to give +# The variable :variable:`Matlab_ROOT_DIR` may be specified in order to give # the path of the desired Matlab version. Otherwise, the behaviour is platform # specific: # # * Windows: The installed versions of Matlab are retrieved from the # Windows registry # * OS X: The installed versions of Matlab are given by the MATLAB -# paths in ``/Application`` +# paths in ``/Application``. If no such application is found, it falls back +# to the one that might be accessible from the PATH. # * Unix: The desired Matlab should be accessible from the PATH. # # Additional information is provided when :variable:`MATLAB_FIND_DEBUG` is set. @@ -59,7 +60,7 @@ # Users or projects may set the following variables to configure the module # behaviour: # -# :variable:`MATLAB_USER_ROOT` +# :variable:`Matlab_ROOT_DIR` # the root of the Matlab installation. # :variable:`MATLAB_FIND_DEBUG` # outputs debug information @@ -77,14 +78,15 @@ # ``TRUE`` if the Matlab installation is found, ``FALSE`` # otherwise. All variable below are defined if Matlab is found. # ``Matlab_ROOT_DIR`` -# the root of the Matlab installation determined by the FindMatlab module. +# the final root of the Matlab installation determined by the FindMatlab +# module. # ``Matlab_MAIN_PROGRAM`` # the Matlab binary program. Available only if the component ``MAIN_PROGRAM`` # is given in the :command:`find_package` directive. # ``Matlab_INCLUDE_DIRS`` # the path of the Matlab libraries headers # ``Matlab_MEX_LIBRARY`` -# library for mex +# library for mex, always available. # ``Matlab_MX_LIBRARY`` # mx library of Matlab (arrays). Available only if the component # ``MX_LIBRARY`` has been requested. @@ -102,6 +104,9 @@ # # ``Matlab_MEX_EXTENSION`` # the extension of the mex files for the current platform (given by Matlab). +# ``Matlab_ROOT_DIR`` +# the location of the root of the Matlab installation found. If this value +# is changed by the user, the result variables are recomputed. # # Provided macros # --- @@ -162,10 +167,11 @@ # Reference # -- # -# .. variable:: MATLAB_USER_ROOT +# .. variable:: Matlab_ROOT_DIR # -#The root folder of the Matlab installation. This is set before the call to -#:command:`find_package`. If not set, then an automatic search of Matlab +#The root folder of the Matlab installation. If set before the call to +#:command:`find_package`, the module will look for the components in that +#path. If not set, then an automatic search of Matlab #will be performed. If set, it should point to a valid version of Matlab. # # .. variable:: MATLAB_FIND_DEBUG @@ -176,7 +182,6 @@ # .. variable:: MATLAB_ADDITIONAL_VERSIONS # # If set, specifies additional versions of Matlab that may be looked for. -# This variable will be used if :variable:`MATLA
Re: [cmake-developers] Extracting target metadata, IDE integration
On Wed, Mar 11, 2015 at 3:15 PM, Ben Boeckel wrote: > On Tue, Mar 10, 2015 at 01:25:16 +0100, Aleix Pol wrote: >> >>"output" : >> >> "/home/kde-devel/tmp/llvm/build/lib/libLLVMPowerPCInfo.a", >> > >> > Can this be a list? >> It's 1 output per target, no? > > Not on Windows with .dll and .lib splits. So it needs to be a list:-) >> > Running/Debugging is a bit tricky again: All the information used for >> > linking the binaries is gone. So there is no way to figure out which >> > LD_LIBRARY_PATH needs to be set or anything. There also seems to be no >> > information where files are going to get installed to. Would it be >> > possible to add that information? >> I ignore it, on the other hand I'm quite a n00b when it comes to cmake >> codebase and internals. I'm sure if somebody knows where to get that >> information, he is reading this mailing list. (hello) > > CMake has options for RPATH for the relevant platforms. By default, > binaries have the RPATH set for the build tree. Relevant CMake target > properties (there are variables to set default values as well): > > - BUILD_WITH_INSTALL_RPATH > - SKIP_BUILD_RPATH > > Without SKIP_BUILD_RPATH set, LD_LIBRARY_PATH should not be necessary > for running targets. We try hard to have Creator "do the right thing", not "usually do the right thing". That may sound arrogant, but it is simply that we found that devs are highly suspicious folks: If something is not absolutely reliable they won't use it:-) Setting LD_LIBRARY_PATH will not hurt, even when unneeded, will it? So we should set it, just in case somebody tries to shoot himself into the foot by setting SKIP_BUILD_RPATH:-) Best Regards, Tobias -- 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] Extracting target metadata, IDE integration
Hi Aleix, On Tue, Mar 10, 2015 at 1:25 AM, Aleix Pol wrote: > Thank you for taking some of your time. Thank you for doing the work:-) > On Sat, Mar 7, 2015 at 11:46 AM, Tobias Hunger > wrote: >> How about adding some information on what this is you are actually >> building here? CMake has the PROJECT command that does provide quite a >> bit of information that could go here. > I can look into that, I can see if I can extract the projects tree > somehow and dispose them like it's doing with the targets. >> Where are the sources this thing here is building? How were those >> sources configured? CMake supports quite a few generators, so which >> ones where used? Do I need to run ninja or make to build this (or >> should I use "cmake build" anyway)? > The sources are listed within the targets, separately for each > configuration (as you can have different sources for debug builds and > release). No, which source directory was this created from? How was this build configured (e.g. which compiler is used, which Qt version does it link to, that kind of thing). For qmake projects you can point to some directories that you built when loading a project and that build is then imported into Qt Creator. That is rather convenient as it can save a lot of time rebuilding stuff just to make the IDE happy:-) For that we need to sanity check: Is this indeed a build-directory of the project we are opening? Which Kit (== configuration) was used to generate that build? > Regarding ninja/make, in KDevelop we just check if there's a > rules.ninja file or a Makefile. Alternatively you can also check the > CMAKE_GENERATOR value in the CMakeCache.txt. Or we can introduce it if > you find it useful. I don't have a strong opinion there. My -- maybe naive -- hope is that I can integrate cmake into an IDE *without looking outside this json-file*. I do not want to figure out which files are generated by which generators, how those are structured internally or under which set of conditions they may or may not be generated:-) Basically the less the IDE needs to know about the cmake implementation (outside of the IDE integration file) the more robust the support can be. >> Creator does allow existing qmake builds to be imported and that kind >> of information does help a lot with that functionality. >> >>> "dependencies" : >>> [ >>> "/home/kde-devel/tmp/llvm/build/CMakeFiles/3.2.20150306-g139588/CMakeSystem.cmake", >>> "/lots/more/files", ... ] What does that tell me? That file is even in the build directory, so it is most likely not the CMakeLists.txt you built. There are also more than one CMakeLists.txt in that file, so which one is "the one"? And there is no hint as to how the project is configured... That is probably available in CMakeCache.txt, but again, ideally I would not need to know about that file. >>>"configs" : >>>[ >>>{ >>>"name" : "", >> >> Why is the name empty? > Because it was built without specifying any name. (i.e. it didn't pass > -DCMAKE_BUILD_TYPE=...). There is no default for CMAKE_BUILD_TYPE? >>>"sources" : [ "/list/of/cpp/files, ] >> >> Any way to also get the headers? Do you see any option to hint where >> new sources would need to be added to make them a part of this target? > I looked into how the CodeBlocks did it to provide the header files. > It's just brute-forcing to see if the file renamed to *.h/*.hpp/*.hxx > is present. > CMake doesn't have this kind of information, so I think it's better > that the IDE's do the hacky parts than cmake. A list of *all* headers used during the building of the target would be fine. There is no need to filter that list down in any way. CMake has that information: Without it cmake could not possibly know when a cpp file needs rebuilding. It would not be as successful a build system when it did not know that:-) > Also we don't really have information about where to put them. You can > use the minimum common denominator among the sources I guess. I don't understand that part, sorry. >> >>>} >>>], >>>"installed" : "true", >> >> I guess this means "make install" will install it. Where will this file end >> up? > Yes. I tried to figure it out but didn't manage to find the correct > way to query it. I can try harder. :D > >> >>>"name" : "LLVMPowerPCInfo", >>>"output_directory" : >>> "/home/kde-devel/tmp/llvm/build/lib/Target/PowerPC/TargetInfo", >> >> For what is the output directory relevant? The output above does >> implicitly list that already, doesn't it? > It's important in case the output path is overriden, see last e-mail > by Alexander Neundorf. > >> >>>"type" : "STATIC_LIBRARY" >> >> Which types are possible here? > It's an enum internal to cmake. At the moment: > EXECUTABLE, STATIC_LIBRARY, SHARED_LIBRARY, MODULE_LIBRARY, > OBJECT_LIBRARY, UTILITY, GLOBAL_TARGET, INTERFACE_LIBRARY, > UNKNOWN_LIBRARY. > >> >>> }, >> >> >> There is a lot of useful information here! Thanks for pu
[cmake-developers] Problems with WriteCompilerDetectionHeader and cxx_nullptr
Hello, I've attached a patch for this problem. Best Regards From 3b77b957a41ce00c8e5d8d47ce442887181d669d Mon Sep 17 00:00:00 2001 From: Roman Wüger Date: Thu, 12 Mar 2015 11:51:24 +0100 Subject: [PATCH] WCDH: Fix cxx_nullptr for compilers which doesn't support C++11 --- Modules/WriteCompilerDetectionHeader.cmake | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Modules/WriteCompilerDetectionHeader.cmake b/Modules/WriteCompilerDetectionHeader.cmake index d18f47c..721bbdb 100644 --- a/Modules/WriteCompilerDetectionHeader.cmake +++ b/Modules/WriteCompilerDetectionHeader.cmake @@ -586,7 +586,11 @@ function(write_compiler_detection_header # if ${def_name} #define ${def_value} nullptr # else -#define ${def_value} static_cast(0) +#ifdef NULL +# define ${def_value} NULL +#else +# define ${def_value} 0 +#endif # endif \n") endif() -- 1.9.5.msysgit.0 -- 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] Problems with WriteCompilerDetectionHeader and cxx_nullptr
Hello, i tried to use the generated compiler detection header but get an error if I use the cxx_nullptr feature on a compiler which doesnt support C++11. void doSomething(int n, bool *ok = 0) { if (ok) *ok = true; if (n != 0) { if (ok) *ok = false; } } This simple example produces the following error on Mac OS: error: cannot initialize a parameter of type 'bool *' with an rvalue of type 'void *' void doSomething(int n = 1, bool *ok = static_cast(0)) { ^~ However, if C++11 could be used then the nullptr is working fine. Couldnt static_cast(0) simply be replaced with 0? Best Regards -- 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] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support
Attached is a patch with the recommended changes to add Green Hills MULTI support. The process of finding the GHS_COMP_ROOT variable is now programmed in cmGlobalGhsMultiGenerator::GetCompRoot. I ran a test with some of those changes: https://open.cdash.org/viewSite.php?siteid=11862&project=1¤ttime=1426035600. I'm currently rerunning them. Geoffrey Viola SOFTWARE ENGINEER asirobots.com -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Tuesday, March 10, 2015 7:30 AM To: Geoffrey Viola Cc: cmake-developers@cmake.org Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support On 03/10/2015 12:57 AM, Geoffrey Viola wrote: > Should I still set CMAKE_GHS_COMPILER_ID? I don't see any reason to set a variable by that name. >> * Have EnableLanguage compute the exact path to the compiler tools >> itself, possibly using GHS_COMP_ROOT. > > I prefer the latter approach [snip] > finding the comp root is a bit complicated. The registry keys change > per version and their does not seem to be a pattern. This should be achievable in C++ inside a helper method called from EnableLanguage. There is no reason to have to use the CMake language to code it. > I'll let you know how things work out, after I implement the above. Great, thanks. -Brad This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 0001-Added-some-support-for-a-Green-Hills-MULTI.patch Description: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch -- 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