Re: [CMake] hook __EOF__
Hi All, I guess it's not commonly used feature. Does anyone who knows a code of cmake a bit can provide information if that's possible at all? Thanks, T Majchrowski. 2011/8/11 t m cm...@majchrowski.co.uk: Hi All, Is it possible to register hook function that will be called at the end of processinf of CMakeLists.txt: Example CMakeLists.txt 0:cmake_minimum_required( VERSION 2.6 ) 1:project( foo.project) 2: 3: add_subdirectory( example ) 4: ... N: -- last line of CMakeLists.txt this will trigger to call other funcion. I mean something simillar like variable_watch but the trigger will be __EOF__ CMakeLists.txt file not a variable (e.g. eof_watch) ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] hook __EOF__
On Mon 15 Aug 2011 10:12:59 AM CEST, t m wrote: Hi All, I guess it's not commonly used feature. Does anyone who knows a code of cmake a bit can provide information if that's possible at all? Thanks, T Majchrowski. 2011/8/11 t m cm...@majchrowski.co.uk: Hi All, Is it possible to register hook function that will be called at the end of processinf of CMakeLists.txt: Example CMakeLists.txt 0:cmake_minimum_required( VERSION 2.6 ) 1:project( foo.project) 2: 3: add_subdirectory( example ) 4: ... N: -- last line of CMakeLists.txt this will trigger to call other funcion. I mean something simillar like variable_watch but the trigger will be __EOF__ CMakeLists.txt file not a variable (e.g. eof_watch) No, it's not possible, and I don't see any Plugin-Hook you could use for that (others might correct me, though). The only way around this is to place the function call at the end of every CMakeLists.txt file manually. Michael ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] append command
On Aug 13, 2011, at 2:57 PM, Clifford Yapp cliffy...@gmail.com wrote: On Sat, Aug 13, 2011 at 5:14 AM, Glenn Coombs glenn.coo...@gmail.com wrote: I haven't seen any discussion yet of my 2nd alternative of getting cmake to automatically convert lists to space separated strings for certain variables like CMAKE_EXE_LINKER_FLAGS_RELEASE. If cmake did this then there would be less need for the concat version of set() as one could just use the existing list(APPEND) functionality. Is this a realistic possibility, or are there implementation issues with this suggestion ? This surprised me as well - if you want to assemble a list of flags on the fly (I needed to assemble lists of lists of flags - we pass a lot of them) you have to take some care to either do the set trick correctly or convert the list to a string at the end (if you can be sure of where that is). Do I understand correctly that the main concern is the ability to pass args with ;' characters in these cases? Then the question becomes whether quoting ; characters as needed in user-specified options is tricker than navigating the current behavior. To be honest, I can see where trying to specify an argument with a quoted ; character from the command line would get a bit messy (in a ok, how do I quote this from this enviornment sort of way) - how common are ; characters as components of variable values? Again, our main concern here will be backward compatibility, not difficulty of encoding semi-colons... There are tons of real-world projects that already use all of these variables and properties being discussed with their current semantics. Cheers, CY ___ 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://www.cmake.org/mailman/listinfo/cmake ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sub dependencies?
What is line 49 of your CMakeLists file...? The output indicates it has a
command on it that yields the error...
On Aug 12, 2011, at 9:55 PM, Doug douglas.lin...@gmail.com wrote:
I see.
I've tried this approach and I get the error:
-- Found LIBPNG
CMake Error at CMakeLists.txt:49 (export):
export given target /usr/lib/libpng.so which is not built by this
project.
-- Configuring incomplete, errors occurred!
~
Doug.
On Fri, Aug 12, 2011 at 4:57 PM, Michael Wild them...@gmail.com wrote:
On Fri 12 Aug 2011 10:49:45 AM CEST, Doug wrote:
I'm sorry if I'm being dumb here, but I fail to see how that helps.
That example is one where foobar depends explicitly on foo and bar.
What if foo depends on bar2?
How do I inherit that dependency from foo in foobar?
_that's_ what I'm looking for.
(If that example somehow explains that, I'm sorry, I can't see it. Can
you point to a specific point in the page?)
~
Doug.
On Fri, Aug 12, 2011 at 2:34 PM, Michael Wild them...@gmail.com
mailto:them...@gmail.com wrote:
If the projects are independent, you might want to take a look at this
Wiki page:
http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file.
HTH
Michael
And that is what the example is *about*. The FooBar project *exports*
its targets, along with their dependencies, so that when other projects
do find_package(FooBar), they will be able to link against the foo
library without having to know any of the dependencies of it. E.g. the
project hello might look like this:
project(hello)
find_package(FooBar REQUIRED)
include_directories(${FOOBAR_INCLUDE_DIRS})
add_executable(hello hello.c)
target_link_libraries(hello ${FOOBAR_LIBRARIES})
Michael
___
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://www.cmake.org/mailman/listinfo/cmake
___
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://www.cmake.org/mailman/listinfo/cmake
[CMake] masm msvc
This script...
# Copy paste from CMake Wiki
# Works only if CMake runs in the Visual Studio DOS Window
SET(MASMFound FALSE)
# test whether it is a x86 machine and masm is available
IF(${CMAKE_SYSTEM_PROCESSOR} MATCHES x86)
ENABLE_LANGUAGE(ASM_MASM)
IF(CMAKE_ASM_MASM_COMPILER_WORKS)
SET(MASMFound TRUE)
ENDIF(CMAKE_ASM_MASM_COMPILER_WORKS)
ENDIF(${CMAKE_SYSTEM_PROCESSOR} MATCHES x86)
# no assembler found
IF(NOT MASMFound)
MESSAGE(STATUS NOT)
ENDIF(NOT MASMFound)
...generates still the message:
The ASM_MASM compiler identification is unknown --!
Found assembler: C:/Program Files/Microsoft Visual Studio
10.0/VC/bin/ml.exe
-
# cAsm.asm is the main program
ADD_EXECUTABLE(tt cAsm.asm)
In Visual Studio the masm starts, but generates these nice messages:
3MASM : warning A4018: invalid command-line option : /STACK:1000
3MASM : warning A4018: invalid command-line option : /SACK:1000
3MASM : warning A4018: invalid command-line option : /SCK:1000
3MASM : warning A4018: invalid command-line option : /SK:1000
3MASM : warning A4018: invalid command-line option : /S:1000
3MASM : warning A4018: invalid command-line option : /S1000
3MASM : warning A4018: invalid command-line option : /S000
3MASM : warning A4018: invalid command-line option : /S00
3MASM : warning A4018: invalid command-line option : /S0
3MASM : warning A4018: invalid command-line option : /S
3MASM : warning A4018: invalid command-line option : /S000
3MASM : warning A4018: invalid command-line option : /S00
3MASM : warning A4018: invalid command-line option : /S0
3 Microsoft (R) Macro Assembler Version 10.00.30319.01
3 Copyright (C) Microsoft Corporation. All rights reserved.
3
3MASM : warning A4018: invalid command-line option : /machine:X86
3MASM : warning A4018: invalid command-line option : /debug
3MASM : warning A4018: invalid command-line option : /subsystem:console
3MASM : warning A4018: invalid command-line option : -o
3 Assembling: tt.exe
3MASM : fatal error A1000: cannot open file : tt.exe
# --
ADD_EXECUTABLE(tt cTest.c cAsm2.asm)
main in cTest.c. cAsm2.asm has a function only.
Visual Studio does not start the masm. A right click on cAsm2.asm in the
project explorer = properties
says: element type: Not part of the build.
# --
The only way to use the masm seems to be:
ADD_CUSTOM_COMMAND(OUTPUT cAsm2.obj
COMMAND ${CMAKE_ASM_MASM_COMPILER} -c
${CMAKE_CURRENT_SOURCE_DIR}/cAsm2.asm
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/cAsm2.asm
COMMENT generate cAsm2.obj)
ADD_EXECUTABLE(cTest CTest.c cAsm2.obj)
Greetings
Micha
___
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] append command
On Mon, Aug 15, 2011 at 7:59 AM, David Cole david.c...@kitware.com wrote: Again, our main concern here will be backward compatibility, not difficulty of encoding semi-colons... There are tons of real-world projects that already use all of these variables and properties being discussed with their current semantics. nods Understood and agreed. I had in the back of my mind a CMAKE_POLICY CMP00## rule of some sort but that would be quite disruptive... the other approach that comes to mind would be to have CMAKE_* variables accept a property of their own telling CMake whether to treat them as space-separated strings or semi-colon separated lists with defaults set to the current behavior (although would have the advantage of not changing behaviors unless the build logic specifically asked for a different behavior.) Cheers, CY ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and NaCl (Google NativeClient)
Hi Nils, Did you try to specify an empty value for the following properties: CMAKE_OSX_SYSROOT CMAKE_OSX_DEPLOYMENT_TARGET CMAKE_OSX_ARCHITECTURES ? On Thu, Aug 11, 2011 at 8:17 AM, Nils Hjelte n...@algoryx.se wrote: Hello! I'm trying to port a C++ project to NaCl (http://code.google.com/chrome/nativeclient/), with cmake as the build system, and I need to figure out some things. I am using a Mac as build machine. I have changed the CMAKE_CXX_COMPILER/LINKER variables to use the nacl toolchain. What I would like to know is if it is possible to discard all the default compiler flags. I get lots of flags that the nacl compiler does not like, example: -mmacosx-version-min=10.5 -arch i386 -isysroot /Developer/SDKs/MacOSX10.7.sdk and the linker adds these flags that I can not get rid of: -compatibility_version 1.12.0 -current_version 1.12.0 Ideally I would like an empty compile command where I can explicitly add the flags needed. Is it possible with CMake? // Nils ___ 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://www.cmake.org/mailman/listinfo/cmake -- +1 919 869 8849 ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: [CMake 0012398]: IF infamous variable/string functionality fails to work with macro arguments
Thanks, Michael...
I'll give this another week or so here on the mailing list (and in the
bug tracker) to gather feedback.
If I don't hear anything else, I'll consider changing some
documentation to clarify the existing situation, but I don't see a
reasonable way to accommodate this feature request *and* maintain
backwards compatibility with existing real world uses of macro and if
commands.
David C.
On Sat, Aug 13, 2011 at 3:39 AM, Michael Wild them...@gmail.com wrote:
For most users, macros should be a taboo anyways. They are much better
served by functions, IMHO. In all of my projects I had only one case
where I actually needed a macro. That was when I wrapped a function
that set some variables in the PARENT_SCOPE and I had to propagate them
outside of the wrapping macro without knowing their name.
Perhaps it would be enough to just properly document the quirky
behaviour of macro arguments in the docs and mention that one should
normally prefer functions over macros unless there is a real reason
that requires a macro?
Michael
On Fri 12 Aug 2011 09:29:21 PM CEST, David Cole wrote:
Does anybody here on the list have an opinion one way or the other on
whether it's worth pursuing a fix to this re-opened bug regarding
CMake macro and if command behavior...?
Thanks for any input, either here on the list, or directly in the bug
notes themselves.
Thanks,
David
-- Forwarded message --
From: Mantis Bug Tracker man...@public.kitware.com
Date: Fri, Aug 12, 2011 at 2:49 PM
Subject: [CMake 0012398]: IF infamous variable/string
functionality fails to work with macro arguments
To: david.c...@kitware.com
The following issue has been REOPENED.
==
http://public.kitware.com/Bug/view.php?id=12398
==
Reported By: freddie
Assigned To: David Cole
==
Project: CMake
Issue ID: 12398
Category: CMake
Reproducibility: always
Severity: major
Priority: normal
Status: feedback
==
Date Submitted: 2011-08-12 08:13 EDT
Last Modified: 2011-08-12 14:49 EDT
==
Summary: IF infamous variable/string functionality
fails
to work with macro arguments
Description:
There is a problem with the IF command when it is used directly with macro
arguments. Apparently, they are not considered variables and are used
directly
as strings.
However, if their contents can be construed as variables themselves (even
though
it is not desired), we have a problem when the only way to perform the test
is
to create another explicit variable assigning it to what the macro argument
contains.
The problem doesn't appear to pertain to functions.
Steps to Reproduce:
Please use the attached CMakeLists.txt file with cmake -Wno-dev ..
Additional Information:
It would really be a good idea to create a version of if/elseif/else/endif
which
does NOT attempt to treat its arguments as variables, either by creating a
new
name for the command or, better yet, by adding a new policy (possibly not
associated with a version yet).
Otherwise, when trying to compare things which might be variables but should
not
be treated as such for the purposes of the comparison, one runs into subtle
problems (when checks randomly fail) or has to create a level of
indirection,
by setting a new variable just for that.
I am sure you've heard this all before.
==
Relationships ID Summary
--
duplicate of 0009590 IF(VARIABLE) doesn't work inside Makro
==
--
(0027199) freddie (reporter) - 2011-08-12 14:49
http://public.kitware.com/Bug/view.php?id=12398#c27199
--
Your comparison of macro with preprocessor macros makes sense. If only it
worked
that way. In cmake language, ${foo} expands a variable; if ARGV0 is not a
variable, then you must either substitute ARGV0 for what was specified in the
parameter list for the macro, or use a different expansion {#{ARGV0}, for
instance); otherwise, people who can't be called stupid will keep running
into
these problems.
However, the analogy stops there; FUNCTION is not equivalent to functions or
methods in C/C++ in the sense that variables are
Re: [CMake] Fwd: [CMake 0012398]: IF infamous variable/string functionality fails to work with macro arguments
On Mon, Aug 15, 2011 at 11:26 AM, David Cole david.c...@kitware.com wrote: Thanks, Michael... I'll give this another week or so here on the mailing list (and in the bug tracker) to gather feedback. If I don't hear anything else, I'll consider changing some documentation to clarify the existing situation, but I don't see a reasonable way to accommodate this feature request *and* maintain backwards compatibility with existing real world uses of macro and if commands. I would like to see the documentation expanded to better explain the differences between a function and a macro. Before this discussion I have never used a function (did not understand what that gave me over a macro) however I have ran into this problem with using if statements in macros. John ___ 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Getting library dependency files without full paths
Hi everyone,
I am currently dealing with some Debian library packages that ship
*LibraryDepends.cmake files with absolute paths to their required shared
objects. Due to the ongoing multiarch transition, many of these .so
files are moved down the directory hierarchy, so that libraries for
multiple architectures can be installed in parallel. Of course this
frequently breaks the build of the offending packages' reverse
dependencies.
It seems that substituting /usr/lib/($MULTIARCH_DIR/)?lib$NAME.so;
with $NAME; in these files doesn't cause any problems; most
importantly, CMake still manages to find the libraries for transitive
linking. Are there any non-obvious issues if this hack is implemented?
Is there a way to tell CMake to not record full paths for .so's in
default locations?
Cheers and thanks in advance,
--
Michael Schutte | michi@{uiae.at,debian.org}
Innsbruck, Austria| happily accepting encrypted mail
OpenPGP: 0x16fb 517b a866 c3f6 8f11 1485 f3e4 122f 1D8C 261A
___
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: [CMake 0012398]: IF infamous variable/string functionality fails to work with macro arguments
On Mon, Aug 15, 2011 at 3:26 PM, David Cole david.c...@kitware.com wrote:
documentation to clarify the existing situation, but I don't see a
reasonable way to accommodate this feature request *and* maintain
backwards compatibility with existing real world uses of macro and if
Umm... once again, doesn't this case look perfect for using a policy?
If cmake knew the difference between identifiers and strings (foo vs.
bar), I wouldn't mind having IF recognize foo as a variable - and only a
variable (if undefined, it shouldn't be treated as foo) - and bar (or
${HAVE_${foo}}) as a string, and behave accordingly.
Otherwise, IF(var) instead of IF(${var}) isn't much of a benefit to me,
given the drawbacks. The unpredictable and inconsistent treatment of its
arguments by IF() is something I'd consider a major drawback.
Every mode of IF() has its own set of variable-vs-string rules. Why does
STREQUAL expect variables on both side and MATCHES doesn't? How should I
remember that? Does EXISTS allow specifying a variable - or only a string
will do? How should I remember that? What if I define SET(YES NO); how do I
remember what IF(YES) will do?
Maybe the esteemed colleagues would suggest another good and reliable way to
handle situations such as this:
IF (lang STREQUAL perl) ...
ELSEIF(lang STREQUAL python) ...
ELSEIF()
...
ENDIF ()
without having to SET(perl perl) (and all the other cases in this switch)
myself (just in case), but still being afraid that somebody, somewhere else,
would SET(perl 5.10.0), and without resorting to IF (lang MATCHES ^perl$)?
On Sat, Aug 13, 2011 at 3:39 AM, Michael Wild them...@gmail.com wrote:
For most users, macros should be a taboo anyways. They are much better
If MACRO is taboo, deprecate it. Having an active command exhibit peculiar
and hard-to-debug behaviour in conjunction with another active command is
hardly a way to deter people from using it. However...
served by functions, IMHO. In all of my projects I had only one case
where I actually needed a macro. That was when I wrapped a function
that set some variables in the PARENT_SCOPE and I had to propagate them
outside of the wrapping macro without knowing their name.
... bingo. It is possible that we are relatively light users, but our use
case involves thousands of directories, half of them libraries with complex
dependency chains, 5k+ lines of specialized cmake code (not counting the
per-directory CMakeLists.txt); I have tried to use functions as much as
possible, and this don't know what variables are being set and how deep my
call stack is is effectively ruling it out in most cases.
Maybe having an easier way to work with properties would help, so that they
can behave like variables. Something like this, for instance:
${dir:var} - property for directory dir
${:var} - property for current directory
${::var} - global property
or
${#GLB:var}
${#DIR:dir:var}
${#SRC:src:var}
${#TGT:tgt:var}
${#TST:tst:var}
${#CCH:entry:var}
with all the requisite DEFINED etc. tests.
Perhaps it would be enough to just properly document the quirky
behaviour of macro arguments in the docs and mention that one should
normally prefer functions over macros unless there is a real reason
that requires a macro?
Properly documenting everything would be nice in general. Emphasizing
stumbling blocks such as these would be nice. Having a separate section on
here is what you should pay attention to would also be nice. Documenting
what happens when a command fails would be nice, too (STRING(REGEX MATCH) if
no match, FILE(READ) if no file etc.) Explaining how to use STRING(FIND)
with STRING(SUBSTRING), if that is even possible, and whether any sort of
arithmetic is available would be good.
Maybe I missed it, but the documentation page below appeared not mention
such basic stuff as how to expand a variable (the ${} syntax is kind of
implied):
http://www.cmake.org/cmake/help/cmake-2-8-docs.html
___
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] append command
On Friday 12 August 2011, Michael Hertling wrote:
On 08/11/2011 10:04 PM, Alexander Neundorf wrote:
On Thursday 11 August 2011, Michael Hertling wrote:
...
Alternatively, one might consider to introduce a new, say,
modifier CONCAT for the SET() command, e.g.
SET(variable value ... CONCAT [SEP sep])
equivalent to
SET(variable ${variable}sepvalue...)
I'm not sure this is actually necessary.
Personally I'm fine with
set(foo ${foo} bar)
It's just one line. For properties more code is needed otherwise.
So far, I also don't need such a string concatenation feature, but
LIST(APPEND ...)
and
SET_PROPERTY(... APPEND/APPEND_STRING ...)
aren't actually necessary, too, but convenient, so I would not be
opposed to another convenience feature for concatenating strings.
Besides, David, due to the same reasons as mentioned above, the new
APPEND_STRING subcommand of SET_PROPERTY() is quite misnamed, IMO -
and quite long. Would it be possible to rename it to CONCAT before
it is released officially? In this way, we would consistently have
APPEND subcommands for list-style variables/properties and CONCAT
subcommands for string-style ones.
We can do that, if other people think also that this would be a better
name. Or STRING_APPEND instead of APPEND_STRING ?
The crucial point is that the subcommand/modifier for concatenating
strings - regardless for which command(s) it is implemented - should
- not be named APPEND because this term is already in use for lists,
and there's at least one occasion where a list-related and a string-
related += operation are about to coincide, namely SET_PROPERTY().
- be named the same in all commands that provide - or possibly will
provide - this functionality. SET_PROPERTY() is going to name it
APPEND_STRING, a longish and unfortunate misnomer, IMO, that will
result in inconsistent CMakeLists.txt code if there'll be a SET()
or STRING() implementation for concatenating strings: Certainly,
one would not want to call the latter SET(... APPEND_STRING) or
STRING(STRING_APPEND ...), so one ends up with two differently
named subcommands/modifiers for the same kind of operation.
For this reason, I'd recommend to reconsider the APPEND_STRING sub-
command's naming and change it to a term that's also suitable for
a string concatenation feature in other CMake commands - just to
leave the door open. Therefor, my suggestion is CONCAT.
Anybody else has an opinion on this ?
I have no preferences among APPEND_STRING, STRING_APPEND and CONCAT.
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://www.cmake.org/mailman/listinfo/cmake
[CMake] Nested Project()
Hi, I have several nested directories, and each directory contains a CMakeLists.txt file. And most start with PROJECT( ) Where xxx is some name for what I like to contains some targets. In VC it is possible to create in the top solution, so called solution folders. Why does CMake not use the PROJECT() statement to create such solution folders, in order to group targets? If I remember well, in older versions of Cmake its VC generators, this was like that. I even remember the documentation of PROJECT() did mention it as a special feature for VC in those days. Why is it gone? Regards, Klaas ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Automoc in cmake
On Tuesday 16 August 2011, Alexander Neundorf wrote: ... There is now a branch AutomocForQt on the cmake stage. Docs and a test are still missing. It has a test now. Docs are still missing. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v2.8.5-1554-g6e5d786
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 6e5d7869eb78b26d35405857d5351b294e6303d5 (commit)
via d5e603026b9bfde90742483df322e0c168407fef (commit)
via af4c58b3bd92f69cce195c3e491d40071b8d0b08 (commit)
from 553a4c956404dc0f53fb33b304b81922c9f7c089 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e5d7869eb78b26d35405857d5351b294e6303d5
commit 6e5d7869eb78b26d35405857d5351b294e6303d5
Merge: 553a4c9 d5e6030
Author: Alexey Ozeritsky aozerit...@gmail.com
AuthorDate: Mon Aug 15 09:38:30 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Aug 15 09:38:30 2011 -0400
Merge topic 'FindLAPACK_FindBLAS' into next
d5e6030 ACML-GPU supportede
af4c58b ACML-GPU supported
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d5e603026b9bfde90742483df322e0c168407fef
commit d5e603026b9bfde90742483df322e0c168407fef
Author: Alexey Ozeritsky aozerit...@gmail.com
AuthorDate: Sat Aug 13 18:50:57 2011 +0400
Commit: Alexey Ozeritsky aozerit...@gmail.com
CommitDate: Sat Aug 13 18:50:57 2011 +0400
ACML-GPU supportede
diff --git a/Modules/FindLAPACK.cmake b/Modules/FindLAPACK.cmake
index 1219102..80fe867 100644
--- a/Modules/FindLAPACK.cmake
+++ b/Modules/FindLAPACK.cmake
@@ -165,11 +165,11 @@ endif (BLA_VENDOR STREQUAL Goto OR BLA_VENDOR STREQUAL
All)
#acml lapack
- if (BLA_VENDOR STREQUAL ACML OR BLA_VENDOR STREQUAL ACML_MP OR BLA_VENDOR
STREQUAL All)
+ if (BLA_VENDOR STREQUAL ACML.* OR BLA_VENDOR STREQUAL All)
if (BLAS_LIBRARIES MATCHES .+acml.+)
set (LAPACK_LIBRARIES ${BLAS_LIBRARIES})
endif ()
- endif (BLA_VENDOR STREQUAL ACML OR BLA_VENDOR STREQUAL ACML_MP OR
BLA_VENDOR STREQUAL All)
+ endif ()
# Apple LAPACK library?
if (BLA_VENDOR STREQUAL Apple OR BLA_VENDOR STREQUAL All)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af4c58b3bd92f69cce195c3e491d40071b8d0b08
commit af4c58b3bd92f69cce195c3e491d40071b8d0b08
Author: Alexey Ozeritsky aozerit...@gmail.com
AuthorDate: Sat Aug 13 17:02:15 2011 +0400
Commit: Alexey Ozeritsky aozerit...@gmail.com
CommitDate: Sat Aug 13 17:03:58 2011 +0400
ACML-GPU supported
diff --git a/Modules/FindBLAS.cmake b/Modules/FindBLAS.cmake
index 4431778..7bad959 100644
--- a/Modules/FindBLAS.cmake
+++ b/Modules/FindBLAS.cmake
@@ -23,7 +23,7 @@
##
### List of vendors (BLA_VENDOR) valid in this module
## Goto,ATLAS PhiPACK,CXML,DXML,SunPerf,SCSL,SGIMATH,IBMESSL,Intel10_32
(intel mkl v10 32 bit),Intel10_64lp (intel mkl v10 64 bit,lp thread model, lp64
model),
-## Intel( older versions of mkl 32 and 64 bit), ACML,ACML_MP,Apple, NAS,
Generic
+## Intel( older versions of mkl 32 and 64 bit), ACML,ACML_MP,ACML_GPU,Apple,
NAS, Generic
# C/CXX should be enabled to use Intel mkl
#=
@@ -57,7 +57,7 @@ else()
endif(BLAS_FIND_REQUIRED)
endif( )
-macro(Check_Fortran_Libraries LIBRARIES _prefix _name _flags _list _optional)
+macro(Check_Fortran_Libraries LIBRARIES _prefix _name _flags _list _thread)
# This macro checks for the existence of the combination of fortran libraries
# given by _list. If the combination is found, this macro checks (using the
# Check_Fortran_Function_Exists macro) whether can link against that library
@@ -69,8 +69,7 @@ macro(Check_Fortran_Libraries LIBRARIES _prefix _name _flags
_list _optional)
# N.B. _prefix is the prefix applied to the names of all cached variables that
# are generated internally and marked advanced by this macro.
-list(GET _optional 0 _thread)
-list(GET _optional 1 _libdir)
+set(_libdir ${ARGN})
set(_libraries_work TRUE)
set(${LIBRARIES})
@@ -267,15 +266,24 @@ if (BLA_VENDOR STREQUAL IBMESSL OR BLA_VENDOR STREQUAL
All)
endif (BLA_VENDOR STREQUAL IBMESSL OR BLA_VENDOR STREQUAL All)
#BLAS in acml library?
-if (BLA_VENDOR STREQUAL ACML OR BLA_VENDOR STREQUAL ACML_MP OR BLA_VENDOR
STREQUAL All)
-# the patch from Chuck Atkins:
- if( ((_BLAS_VENDOR STREQUAL ACML) AND (NOT BLAS_ACML_LIB_DIRS)) OR
-((_BLAS_VENDOR STREQUAL ACML_MP) AND (NOT BLAS_ACML_MP_LIB_DIRS)) )
+if (BLA_VENDOR MATCHES ACML.* OR BLA_VENDOR STREQUAL All)
+ if( ((BLA_VENDOR STREQUAL ACML) AND (NOT BLAS_ACML_LIB_DIRS)) OR
+ ((BLA_VENDOR STREQUAL ACML_MP) AND (NOT BLAS_ACML_MP_LIB_DIRS)) OR
+ ((BLA_VENDOR STREQUAL ACML_GPU) AND (NOT BLAS_ACML_GPU_LIB_DIRS))
+ )
+ # try to find acml in standard paths
if( WIN32 )
file( GLOB _ACML_ROOT C:/AMD/acml*/ACML-EULA.txt )
else()
file( GLOB _ACML_ROOT /opt/acml*/ACML-EULA.txt )
endif()
+ if(
[Cmake-commits] CMake branch, next, updated. v2.8.5-1564-gf9239a2
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via f9239a25c33d6b099d706645ffa3661a922d57fb (commit)
via 1ae3365e9f4126688d57137648e190ca5f4ef8dc (commit)
via f4264960551d088d3a0f1eea3049d2d8ecfd285b (commit)
via f84c7db5928dcb4a46c3f8d51d910e4ad4367113 (commit)
via 9672b332b15a0ba66b929e28fdac2f5d854d9b99 (commit)
from a118650aaf509cdf44ded0405c22203f47422c49 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f9239a25c33d6b099d706645ffa3661a922d57fb
commit f9239a25c33d6b099d706645ffa3661a922d57fb
Merge: a118650 1ae3365
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Aug 15 19:24:43 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Aug 15 19:24:43 2011 -0400
Merge topic 'generate_export_header' into next
1ae3365 Exclude PGI from exports and deprecated.
f426496 Exclude cygwin from the hidden visibility feature.
f84c7db Don't enable deprecated on old GCC
9672b33 Don't enable deprecated on HP.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1ae3365e9f4126688d57137648e190ca5f4ef8dc
commit 1ae3365e9f4126688d57137648e190ca5f4ef8dc
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Aug 16 01:21:59 2011 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Tue Aug 16 01:21:59 2011 +0200
Exclude PGI from exports and deprecated.
diff --git a/Modules/GenerateExportHeader.cmake
b/Modules/GenerateExportHeader.cmake
index f73748c..7a4b6d3 100644
--- a/Modules/GenerateExportHeader.cmake
+++ b/Modules/GenerateExportHeader.cmake
@@ -149,7 +149,7 @@ macro(_test_compiler_hidden_visibility)
# Exclude XL here because it misinterprets -fvisibility=hidden even though
# the check_cxx_compiler_flag passes
# http://www.cdash.org/CDash/testDetails.php?test=109109951build=1419259
- if (NOT GCC_TOO_OLD AND NOT WIN32 AND NOT CYGWIN AND NOT
${CMAKE_CXX_COMPILER_ID} MATCHES XL)
+ if (NOT GCC_TOO_OLD AND NOT WIN32 AND NOT CYGWIN AND NOT
${CMAKE_CXX_COMPILER_ID} MATCHES XL AND NOT ${CMAKE_CXX_COMPILER_ID}
MATCHES PGI)
check_cxx_compiler_flag(-fvisibility=hidden COMPILER_HAS_HIDDEN_VISIBILITY)
check_cxx_compiler_flag(-fvisibility-inlines-hidden
COMPILER_HAS_HIDDEN_INLINE_VISIBILITY)
option(USE_COMPILER_HIDDEN_VISIBILITY Use HIDDEN visibility support if
available. ON)
@@ -158,7 +158,7 @@ macro(_test_compiler_hidden_visibility)
endmacro()
macro(_test_compiler_has_deprecated)
- if(${CMAKE_CXX_COMPILER_ID} MATCHES Borland OR ${CMAKE_CXX_COMPILER_ID}
MATCHES HP OR GCC_TOO_OLD)
+ if(${CMAKE_CXX_COMPILER_ID} MATCHES Borland OR ${CMAKE_CXX_COMPILER_ID}
MATCHES HP OR GCC_TOO_OLD OR ${CMAKE_CXX_COMPILER_ID} MATCHES PGI)
set(COMPILER_HAS_DEPRECATED CACHE INTERNAL Compiler support for a
deprecated attribute)
else()
_check_cxx_compiler_attribute(__attribute__((__deprecated__))
COMPILER_HAS_DEPRECATED_ATTR)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f4264960551d088d3a0f1eea3049d2d8ecfd285b
commit f4264960551d088d3a0f1eea3049d2d8ecfd285b
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Aug 16 01:19:37 2011 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Tue Aug 16 01:19:37 2011 +0200
Exclude cygwin from the hidden visibility feature.
diff --git a/Modules/GenerateExportHeader.cmake
b/Modules/GenerateExportHeader.cmake
index f3a1836..f73748c 100644
--- a/Modules/GenerateExportHeader.cmake
+++ b/Modules/GenerateExportHeader.cmake
@@ -149,7 +149,7 @@ macro(_test_compiler_hidden_visibility)
# Exclude XL here because it misinterprets -fvisibility=hidden even though
# the check_cxx_compiler_flag passes
# http://www.cdash.org/CDash/testDetails.php?test=109109951build=1419259
- if (NOT GCC_TOO_OLD AND NOT WIN32 AND NOT ${CMAKE_CXX_COMPILER_ID} MATCHES
XL)
+ if (NOT GCC_TOO_OLD AND NOT WIN32 AND NOT CYGWIN AND NOT
${CMAKE_CXX_COMPILER_ID} MATCHES XL)
check_cxx_compiler_flag(-fvisibility=hidden COMPILER_HAS_HIDDEN_VISIBILITY)
check_cxx_compiler_flag(-fvisibility-inlines-hidden
COMPILER_HAS_HIDDEN_INLINE_VISIBILITY)
option(USE_COMPILER_HIDDEN_VISIBILITY Use HIDDEN visibility support if
available. ON)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f84c7db5928dcb4a46c3f8d51d910e4ad4367113
commit f84c7db5928dcb4a46c3f8d51d910e4ad4367113
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Aug 16 01:17:26 2011 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Tue Aug 16 01:17:26 2011 +0200
Don't enable deprecated on old GCC
Hopefully a fix for
