[cmake-developers] [CMake 0013528]: FindBLAS does not find MKL 10.3 when using gcc 4.x
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13528 == Reported By:Maciej Dems Assigned To: == Project:CMake Issue ID: 13528 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-09-12 04:35 EDT Last Modified: 2012-09-12 04:35 EDT == Summary:FindBLAS does not find MKL 10.3 when using gcc 4.x Description: This report closely relates to http://public.kitware.com/Bug/view.php?id=13394. After applying in CMake 2.8.9 the fix proposed there, FindBLAS cannot locate MKL 10.3. The reason for this is that gomp was added to the searched list of libraries searched by Check_Fortran_Libraries. However gomp is not in the list of patch searched by find_library by default, which makes the search fail. The proposed solution is to revert the FinbBLAS back to the 2.8.8 and patch FindLAPACK instead to resolve http://public.kitware.com/Bug/view.php?id=13394. In the attachment I enclose the proposed patch against 2.8.9. == Issue History Date ModifiedUsername FieldChange == 2012-09-12 04:35 Maciej DemsNew Issue 2012-09-12 04:35 Maciej DemsFile Added: cmake_blas_lapack_mkl_gcc.patch == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Backlog bugs
Rolf Eike Beer wrote: Am Sonntag, 9. September 2012, 11:00:48 schrieb Mathias Gaunard: In particular some people told me they had been severely put off by CMake development when their bugs with attached patches that really improved CMake were moved to the backlog and ignored. This is just a misunderstanding of what happened. The bugs were moved to a state where it is clear to everyone noone is currently looking at this. This is no difference to the state the bug was in before, it is just properly tagged this way now. Good explanation. Mathias, maybe it would help if you explain to your colleagues that 'backlog' is similar in meaning to 'product backlog' in scrum terminology. Simply no one is currently working on it. It is not the end of the line. If you want to get your patches in, you can get a git account too: http://www.cmake.org/Wiki/CMake/Git Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exclusive Or operator
On 09/11/2012 05:09 PM, Robert Dailey wrote: I don't see an exlusive or operator in CMake. Could I add one? Would such a feature be accepted? Syntax would be: if( var1 XOR var2 ) Many languages like C, C++, python, lua, etc. do not offer logical XOR operators, only bitwise XOR. Unlike AND/OR/NOT the XOR operation cannot be used in short-circuit evaluation (CMake's if() command does not currently short-circuit, but it could.). -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013530]: FindBullet.cmake should be able to check installs in /usr/local
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13530
==
Reported By:prevot
Assigned To:
==
Project:CMake
Issue ID: 13530
Category: CMake
Reproducibility:always
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2012-09-12 08:22 EDT
Last Modified: 2012-09-12 08:22 EDT
==
Summary:FindBullet.cmake should be able to check installs in
/usr/local
Description:
When installing bullet (with make install) it goes in /usr/local/include/bullet
and /usr/local/lib. We should be able to use find_package(Bullet) with
BOOST_ROOT=/usr/local.
To do this you need to add ${BULLET_ROOT}/include/bullet when looking for
includes (after line 55 fore example)
Additional Information:
--- /usr/share/cmake-2.8/Modules/FindBullet.cmake 2012-09-12
12:36:35.716125456
+0200
+++ FinBullet.cmake 2012-09-12 14:07:03.544471313 +0200
@@ -53,6 +53,7 @@
HINTS
${BULLET_ROOT}/include
${BULLET_ROOT}/src
+${BULLET_ROOT}/include/bullet
PATH_SUFFIXES bullet
)
==
Issue History
Date ModifiedUsername FieldChange
==
2012-09-12 08:22 prevot New Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Added very basic Windows CE Makefile support
Hi, On Wed, 05 Sep 2012 16:03:59 -0400, Brad King wrote: On 09/05/2012 04:26 AM, Patrick Gansterer wrote: Thanks for the feedback. I've updated my changes and pushed it to the same branch. Great, thanks. I've pushed the platform file commits with minor tweaks: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7cb8055 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=28d744c9 Please rebase the rest of the topic on those, or on master after they make it there. The topic meged a few hours ago. I rebased the code and pushed it again as ce to https://gitorious.org/~paroga/cmake/parogas-cmake (git://gitorious.org/~paroga/cmake/parogas-cmake.git) -- Patrick -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013532]: kitware-provided CMake installer/executables should be codesigned with 'Developer ID' for GateKeeper on OS X
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13532 == Reported By:Sean McBride Assigned To: == Project:CMake Issue ID: 13532 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2012-09-12 11:33 EDT Last Modified: 2012-09-12 11:33 EDT == Summary:kitware-provided CMake installer/executables should be codesigned with 'Developer ID' for GateKeeper on OS X Description: As of Mac OS X 10.8, Apple the OS now expect that all installers and apps be code signed. Summary: http://arstechnica.com/apple/2012/07/os-x-10-8/14/ http://arstechnica.com/apple/2012/07/os-x-10-8/15/ If not, they warn and installation is more complicated, see attached. Instructions on accomplishing what is needed: https://developer.apple.com/resources/developer-id/ == Issue History Date ModifiedUsername FieldChange == 2012-09-12 11:33 Sean McBride New Issue 2012-09-12 11:33 Sean McBride File Added: CMake-not-signed.png == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exclusive Or operator
CMake tends to be incredibly verbose, so I like to avoid code like
you've just shown me.
Sometimes I have features that require two cache variables. Either
both must be defined, or neither (in the latter case, the feature is
disabled). Specifying one or the other is erroneous. A simple test
would be like this with XOR:
if( var1 AND var2 )
message( Feature is ON )
elseif( var1 XOR var2 )
message( SEND_ERROR Both variables must be specified )
endif()
However, because I do not have XOR, I have to do crazy logic:
if( var1 AND var2 )
message( Feature is ON )
elseif( (NOT var1 AND var2) OR (var1 AND NOT var2) )
message( SEND_ERROR Both variables must be specified )
endif()
On Wed, Sep 12, 2012 at 11:30 AM, David Cole david.c...@kitware.com wrote:
Do you have a concrete example of why an IF XOR construct would be
useful to you? (i.e. -- do you encounter the need for this logical
construct frequently in your CMakeLists files?)
It would certainly be easy to have a macro/function in the CMake
language that returns the logical equivalent of an XOR in a variable,
and then you could do a simple if test on that variable immediately
after calling that function...
That requires no changes to CMake, but would not be quite as readable.
And just like python, if you only care about the boolean state of a
variable, you could always do the casting something like this:
if(var1)
set(var1 1)
else()
set(var1 0)
endif()
# same for var2, then
if(NOT ${var1} EQUAL ${var2})
# voila, one is true, the other is not
else()
# they're both the same
endif()
On Wed, Sep 12, 2012 at 12:00 PM, Robert Dailey
rcdailey.li...@gmail.com wrote:
Honestly I'm not really worried about the band wagon or what other
languages do. CMake is its own independent entity and domain language,
if the feature is useful then it should have it :) Anyway I was just
wondering if the feature would be accepted useful. As I said I don't
mind doing the work.
Not every operator needs to short circuit. If you can't short circuit,
then you can't. For example, in C++ you understand what short
circuiting rules are and you work with that. But not every C++
operator allows it.
Also FWIW, in Python you can kind-of get XOR by converting both
operands to boolean:
bool(a) != bool(b)
But we can't cast operands to bool on-the-fly in CMake (AFAIK) so this
wouldn't be feasible.
On Wed, Sep 12, 2012 at 6:49 AM, Brad King brad.k...@kitware.com wrote:
On 09/11/2012 05:09 PM, Robert Dailey wrote:
I don't see an exlusive or operator in CMake. Could I add one? Would
such a feature be accepted?
Syntax would be:
if( var1 XOR var2 )
Many languages like C, C++, python, lua, etc. do not offer
logical XOR operators, only bitwise XOR. Unlike AND/OR/NOT
the XOR operation cannot be used in short-circuit evaluation
(CMake's if() command does not currently short-circuit, but
it could.).
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exclusive Or operator
Fair enough.
Thanks for the concrete example.
On Wed, Sep 12, 2012 at 12:47 PM, Robert Dailey
rcdailey.li...@gmail.com wrote:
CMake tends to be incredibly verbose, so I like to avoid code like
you've just shown me.
Sometimes I have features that require two cache variables. Either
both must be defined, or neither (in the latter case, the feature is
disabled). Specifying one or the other is erroneous. A simple test
would be like this with XOR:
if( var1 AND var2 )
message( Feature is ON )
elseif( var1 XOR var2 )
message( SEND_ERROR Both variables must be specified )
endif()
However, because I do not have XOR, I have to do crazy logic:
if( var1 AND var2 )
message( Feature is ON )
elseif( (NOT var1 AND var2) OR (var1 AND NOT var2) )
message( SEND_ERROR Both variables must be specified )
endif()
On Wed, Sep 12, 2012 at 11:30 AM, David Cole david.c...@kitware.com wrote:
Do you have a concrete example of why an IF XOR construct would be
useful to you? (i.e. -- do you encounter the need for this logical
construct frequently in your CMakeLists files?)
It would certainly be easy to have a macro/function in the CMake
language that returns the logical equivalent of an XOR in a variable,
and then you could do a simple if test on that variable immediately
after calling that function...
That requires no changes to CMake, but would not be quite as readable.
And just like python, if you only care about the boolean state of a
variable, you could always do the casting something like this:
if(var1)
set(var1 1)
else()
set(var1 0)
endif()
# same for var2, then
if(NOT ${var1} EQUAL ${var2})
# voila, one is true, the other is not
else()
# they're both the same
endif()
On Wed, Sep 12, 2012 at 12:00 PM, Robert Dailey
rcdailey.li...@gmail.com wrote:
Honestly I'm not really worried about the band wagon or what other
languages do. CMake is its own independent entity and domain language,
if the feature is useful then it should have it :) Anyway I was just
wondering if the feature would be accepted useful. As I said I don't
mind doing the work.
Not every operator needs to short circuit. If you can't short circuit,
then you can't. For example, in C++ you understand what short
circuiting rules are and you work with that. But not every C++
operator allows it.
Also FWIW, in Python you can kind-of get XOR by converting both
operands to boolean:
bool(a) != bool(b)
But we can't cast operands to bool on-the-fly in CMake (AFAIK) so this
wouldn't be feasible.
On Wed, Sep 12, 2012 at 6:49 AM, Brad King brad.k...@kitware.com wrote:
On 09/11/2012 05:09 PM, Robert Dailey wrote:
I don't see an exlusive or operator in CMake. Could I add one? Would
such a feature be accepted?
Syntax would be:
if( var1 XOR var2 )
Many languages like C, C++, python, lua, etc. do not offer
logical XOR operators, only bitwise XOR. Unlike AND/OR/NOT
the XOR operation cannot be used in short-circuit evaluation
(CMake's if() command does not currently short-circuit, but
it could.).
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] conditionals in generator expressions
On 09/12/2012 11:36 AM, Stephen Kelly wrote:
I've force-pushed the generator-expression-refactor branch to my gitorious
clone.
Great progress!
One thing that bothers me about the current design is that the
cmGeneratorExpression instances now have more states. This
pattern appears everywhere they're used now:
+ ge.Parse(*cli);
+ ge.Evaluate(this-Makefile, 0, true);
If one forgets the first line there will be runtime errors. Can you
split the class up so that ge.Parse() returns a compiled generator
expression as a separate object that provides the Evaluate() interface?
This documentation needs clarification:
+ This generator expression can only be evaluated if it is used in\
+ target scope, such as a target property.\n \
All expressions are evaluated in target scope when used to generate
build rules. Only expressions used in add_test calls are evaluated
without a this target. Please refactor the way the documentation of
generator expressions is produced so that the copy that appears in the
docs of add_test does not mention expressions it can't use.
The unit tests pass for me, and I think it's ready to merge to next. I don't
remember the magic git log command to check the style for text width though?
git log origin/master.. --pickaxe-regex -S'.{80}'
The next thing I want to do is to see if I can make full use of
cmGeneratorTarget and use const proactively while doing so, to make the code
more clear. I'm not 100% certain that's possible, but it's the next goal I
have. Any comments on that?
That would be a really great example of splitting configure-time
constructs from generate-time constructs.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] The MSVC** version variables
I was looking at http://www.cmake.org/Wiki/CMake_Useful_Variables and while scanning through it I once again saw how many variables we have for the different MSVC versions. Since it's unlikely that MSVC11 is the last (the variable is currently missing, but I'll fix that soon) I thought if it wouldn't be enough to just introduce a MSVC_VERSION variable. Setting this to 6.0 or 7.1 or 11 is easy, and checking it is easy since we have VERSION_LESS and friends. Checking for something like MSVC = 9.0 is currently a pain if one does not want to fall back to the CL_VERSION, which is not obvious as those versions are of a totally different range and one must always comment on what is checked there. Patch for this should be trivial. Any opinions? Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] The MSVC** version variables
On 09/12/2012 02:06 PM, Rolf Eike Beer wrote: I was looking at http://www.cmake.org/Wiki/CMake_Useful_Variables and while scanning through it I once again saw how many variables we have for the different MSVC versions. Since it's unlikely that MSVC11 is the last (the variable is currently missing, but I'll fix that soon) I thought if it wouldn't be enough to just introduce a MSVC_VERSION variable. Setting this to 6.0 or 7.1 or 11 is easy, and checking it is easy since we have VERSION_LESS and friends. Checking for something like MSVC = 9.0 is currently a pain if one does not want to fall back to the CL_VERSION, which is not obvious as those versions are of a totally different range and one must always comment on what is checked there. Patch for this should be trivial. Any opinions? There is a MSVC_VERSION variable already. Furthermore, since the ide-compiler-id topic was merged recently the CMAKE_(C|CXX)_COMPILER_VERSION variables are set. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] The MSVC** version variables
Brad King wrote: On 09/12/2012 02:06 PM, Rolf Eike Beer wrote: I was looking at http://www.cmake.org/Wiki/CMake_Useful_Variables and while scanning through it I once again saw how many variables we have for the different MSVC versions. Since it's unlikely that MSVC11 is the last (the variable is currently missing, but I'll fix that soon) I thought if it wouldn't be enough to just introduce a MSVC_VERSION variable. Setting this to 6.0 or 7.1 or 11 is easy, and checking it is easy since we have VERSION_LESS and friends. Checking for something like MSVC = 9.0 is currently a pain if one does not want to fall back to the CL_VERSION, which is not obvious as those versions are of a totally different range and one must always comment on what is checked there. Patch for this should be trivial. Any opinions? There is a MSVC_VERSION variable already. Furthermore, since the ide-compiler-id topic was merged recently the CMAKE_(C|CXX)_COMPILER_VERSION variables are set. Ah, hm. Ok, this is the compiler version variable that I knew it would exist but did not know how it was named. So this demonstrates exactly what I was talking about: if (MSVC_VERSION VERSION_GREATER 1400) Without looking in the docs, which MSVC version am I talking about? I would propose to name it MSVC_IDE_VERSION then, so this would make it clear to everyone: if (MSVC_IDE_VERSION VERSION_GREATER 8.0) And from all what I know the CMAKE_CXX_COMPILER_VERSION variable would also return 1400 in that case. (Another variable missing on the Wiki) Eike -- signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] The MSVC** version variables
On 09/12/2012 02:33 PM, Rolf Eike Beer wrote: Ah, hm. Ok, this is the compiler version variable that I knew it would exist but did not know how it was named. So this demonstrates exactly what I was talking about: if (MSVC_VERSION VERSION_GREATER 1400) Without looking in the docs, which MSVC version am I talking about? Always subtract 6 from the cl version number to get the IDE version. This is just a standard VS thing and is not CMake-specific. I would propose to name it MSVC_IDE_VERSION then, so this would make it clear to everyone: if (MSVC_IDE_VERSION VERSION_GREATER 8.0) Starting with VS 2010 the projects support specifying the toolchain from a different version of VS. Now that ide-compiler-id is done we can possibly add support for selecting the compiler in the future. Therefore the IDE version can be associated only with the IDE generators, and we already have that from the generator name in CMAKE_GENERATOR. And from all what I know the CMAKE_CXX_COMPILER_VERSION variable would also return 1400 in that case. It would be 14.0.$build or so. It's the cl tool version. (Another variable missing on the Wiki) The Wiki pre-dates the variables section of the reference documentation. Is it really needed anymore? Now it just duplicates information. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Tests with custom launchers and Not Run
There's discussion about that in the following bug tracker entry: http://public.kitware.com/Bug/view.php?id=8466 That issue is presently in the 'backlog' though, which means nobody is actively looking at it. And there does not appear to be a consensus forming about what the right solution to the problem is. Although if everybody else involve converges on a reasonable consensus *and* the CDash results still make sense, I will withdraw my objections to the feature request. On Wed, Sep 12, 2012 at 1:26 PM, Mathias Gaunard mathias.gaun...@ens-lyon.org wrote: Hi, When not using a custom launcher for a test, if the executable doesn't exist then ctest will report Not Run. Is there a way to do this with a custom launcher as well? When the file doesn't exist it always gives me Failed instead. I need to run my tests in qemu because of cross-compilation, and because of this all my Not Run tests end up being marked as Failed, which is a bit annoying. Maybe CTest should be changed to interpret a certain return value as test does not exist? -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] The MSVC** version variables
The Wiki pre-dates the variables section of the reference documentation. Is it really needed anymore? Now it just duplicates information. I agree with this point. The wiki should simply point to the real documentation of variables that are documented, and get rid of the duplication. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] The MSVC** version variables
Brad King wrote: On 09/12/2012 02:33 PM, Rolf Eike Beer wrote: Ah, hm. Ok, this is the compiler version variable that I knew it would exist but did not know how it was named. So this demonstrates exactly what I was talking about: if (MSVC_VERSION VERSION_GREATER 1400) Without looking in the docs, which MSVC version am I talking about? Always subtract 6 from the cl version number to get the IDE version. This is just a standard VS thing and is not CMake-specific. I have not said that. But as I did not know until 5 minutes ago someone else scanning a CMake file may also not know. So you always need to add a comment. I would propose to name it MSVC_IDE_VERSION then, so this would make it clear to everyone: if (MSVC_IDE_VERSION VERSION_GREATER 8.0) Starting with VS 2010 the projects support specifying the toolchain from a different version of VS. Now that ide-compiler-id is done we can possibly add support for selecting the compiler in the future. Therefore the IDE version can be associated only with the IDE generators, and we already have that from the generator name in CMAKE_GENERATOR. Do a selection of MSVC = 9.0 based on the generator string in one line here please: 1. :) Ok, if you don't like the idea, I really don't care about MSVC that much anymore. But I wonder why then another MSVCnn variable is introduced for every new version of that thing. And from all what I know the CMAKE_CXX_COMPILER_VERSION variable would also return 1400 in that case. It would be 14.0.$build or so. It's the cl tool version. Yes, sure. I just have no MSVC around to check ;) (Another variable missing on the Wiki) The Wiki pre-dates the variables section of the reference documentation. Is it really needed anymore? Now it just duplicates information. In that case I think bug 12567 should be fixed, the wiki page should be cleared and provide just a link to the generated documentation. I wonder if the CYGWIN and WIN32 variables should then get a hint that their behavior changed and which policy was introduced for that. Eike -- signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] The MSVC** version variables
On Wed, Sep 12, 2012 at 3:09 PM, Rolf Eike Beer e...@sf-mail.de wrote: Brad King wrote: On 09/12/2012 02:33 PM, Rolf Eike Beer wrote: Ah, hm. Ok, this is the compiler version variable that I knew it would exist but did not know how it was named. So this demonstrates exactly what I was talking about: if (MSVC_VERSION VERSION_GREATER 1400) Without looking in the docs, which MSVC version am I talking about? Always subtract 6 from the cl version number to get the IDE version. This is just a standard VS thing and is not CMake-specific. I have not said that. But as I did not know until 5 minutes ago someone else scanning a CMake file may also not know. So you always need to add a comment. I would propose to name it MSVC_IDE_VERSION then, so this would make it clear to everyone: if (MSVC_IDE_VERSION VERSION_GREATER 8.0) Starting with VS 2010 the projects support specifying the toolchain from a different version of VS. Now that ide-compiler-id is done we can possibly add support for selecting the compiler in the future. Therefore the IDE version can be associated only with the IDE generators, and we already have that from the generator name in CMAKE_GENERATOR. Do a selection of MSVC = 9.0 based on the generator string in one line here please: 1. :) Ok, if you don't like the idea, I really don't care about MSVC that much anymore. But I wonder why then another MSVCnn variable is introduced for every new version of that thing. And from all what I know the CMAKE_CXX_COMPILER_VERSION variable would also return 1400 in that case. It would be 14.0.$build or so. It's the cl tool version. Yes, sure. I just have no MSVC around to check ;) (Another variable missing on the Wiki) The Wiki pre-dates the variables section of the reference documentation. Is it really needed anymore? Now it just duplicates information. In that case I think bug 12567 should be fixed, the wiki page should be cleared and provide just a link to the generated documentation. I wonder if the CYGWIN and WIN32 variables should then get a hint that their behavior changed and which policy was introduced for that. Eike -- -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers Let's just apply the patch from http://public.kitware.com/Bug/view.php?id=12567 and then recommend (strongly) to people that they use the new CMAKE_CXX_COMPILER_VERSION variable with VERSION_GREATER and friends. It's usually the compiler version that you need to do checks against, so that it works regardless of the IDE version being used to drive the build. (Since VS10, they've added the ability to use other compiler toolchains, which we are trying to support as well.) -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New find module: FindGLEW.cmake
On Tuesday 11 September 2012, Benjamin Eikel wrote: Am Dienstag, 11. September 2012 um 21:44:29 schrieb Alexander Neundorf: On Thursday 30 August 2012, Benjamin Eikel wrote: Am Mittwoch, 29. August 2012 um 18:53:51 schrieb Brad King: On 08/29/2012 05:43 AM, Benjamin Eikel wrote: I have written a find module for the OpenGL Extension Wrangler (GLEW) [1] library (see attachment). I tried to follow all the instructions that I have found. I am willing to maintain that module. Great, thanks for your work! Please proceed through steps 5 and 6 here: http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer You're welcome to work on other modules (like SDL) as well, but please bring up changes for discussion on the list with the current maintainer of each. glew.h does not contain any version information. It looks like there are version macros that evaluate to runtime tests. How is one supposed to do any preprocessor conditionals based on the version when using GLEW? I do not know of any preprocessor tests. There is a possiblity at runtime to call glewGetString(GLEW_VERSION), but I think it would be too resource intensive to compile and run an application in the find module. Any progress here ? I did not plan to include a test that runs an application to determine the version. Do you think that this should be done? My personal opinion: a FindGLEW.cmake which does not test the version is better than no FindGLEW.cmake at all . Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New find module: FindGLEW.cmake
Am Mittwoch, 12. September 2012 um 21:50:35 schrieb Alexander Neundorf: On Tuesday 11 September 2012, Benjamin Eikel wrote: Am Dienstag, 11. September 2012 um 21:44:29 schrieb Alexander Neundorf: On Thursday 30 August 2012, Benjamin Eikel wrote: Am Mittwoch, 29. August 2012 um 18:53:51 schrieb Brad King: On 08/29/2012 05:43 AM, Benjamin Eikel wrote: I have written a find module for the OpenGL Extension Wrangler (GLEW) [1] library (see attachment). I tried to follow all the instructions that I have found. I am willing to maintain that module. Great, thanks for your work! Please proceed through steps 5 and 6 here: http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer You're welcome to work on other modules (like SDL) as well, but please bring up changes for discussion on the list with the current maintainer of each. glew.h does not contain any version information. It looks like there are version macros that evaluate to runtime tests. How is one supposed to do any preprocessor conditionals based on the version when using GLEW? I do not know of any preprocessor tests. There is a possiblity at runtime to call glewGetString(GLEW_VERSION), but I think it would be too resource intensive to compile and run an application in the find module. Any progress here ? I did not plan to include a test that runs an application to determine the version. Do you think that this should be done? My personal opinion: a FindGLEW.cmake which does not test the version is better than no FindGLEW.cmake at all . Yes, okay. But in your opinion, do you think version support is worth the test by running an application? I cannot estimate how large the running time of such a find module will increase (compiling and running an application). Is it common to use such a test in find modules? I believe that you have much more experience in using CMake and can give me a suggestion if it should be implemented. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New find module: FindGLEW.cmake
On 09/12/2012 03:59 PM, Benjamin Eikel wrote: Yes, okay. But in your opinion, do you think version support is worth the test by running an application? I cannot estimate how large the running time of such a find module will increase (compiling and running an application). Is it common to use such a test in find modules? I believe that you have much more experience in using CMake and can give me a suggestion if it should be implemented. Running an application will not work for cross compiling. I don't think we have any find modules that actually build something against the found library to detect its version. If you can't get the version from pkgconfig I think leaving it off is fine for now. IMO the upstream should be fixed to actually provide a meaningful version at compile time. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Tests with custom launchers and Not Run
I'd be content with just interpreting a return value of 77 as a Not Run status; this is a fairly trivial change that should work well in any existing setups. I don't think it is really needed to make things as complex as in the bug report. Any intelligence, if required, can go in the test command itself. On 12/09/2012 20:59, David Cole wrote: There's discussion about that in the following bug tracker entry: http://public.kitware.com/Bug/view.php?id=8466 That issue is presently in the 'backlog' though, which means nobody is actively looking at it. And there does not appear to be a consensus forming about what the right solution to the problem is. Although if everybody else involve converges on a reasonable consensus *and* the CDash results still make sense, I will withdraw my objections to the feature request. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
