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=11862project=1currenttime=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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Wed, Mar 11, 2015 at 3:15 PM, Ben Boeckel ben.boec...@kitware.com 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] 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 raffi.enfici...@tuebingen.mpg.de 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
Re: [cmake-developers] Extracting target metadata, IDE integration
Hi Aleix,
On Tue, Mar 10, 2015 at 1:25 AM, Aleix Pol aleix...@kde.org 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 tobias.hun...@gmail.com
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 pushing into
this direction. I am sure this will help a lot.
Ideally this file would be enough to provide all information we need
as an
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] [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_castvoid*(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_castvoid*(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
[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_castvoid*(0)) {
^~
However, if C++11 could be used then the nullptr is working fine.
Couldnt static_castvoid*(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
[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 roman.wue...@gmx.at
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_castvoid*(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
