[cmake-developers] Test for compiler flags ineffective with xlc?
Hi,
In this build log the test for -fvisibility=hidden results in success, but
when the flag is used it fails:
http://www.cdash.org/CDash/testDetails.php?test=109109951build=1419259
I'm guessing that compiler treats -ffoo as a filename for some reason. Can
anything be done about that? Should I just exclude that platform from
performing the test? How? Would if (${CMAKE_CXX_COMPILER_ID} MATCHES xlC)
match?
Thanks,
Steve.
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting environment variables for builds
On Monday 08 August 2011, Brad King wrote: On 8/8/2011 4:24 AM, Johan Björk wrote: This has been discussed a billion times, so I'll keep it short. Problem: Some parts of the build requires a environment variable to be set Solution: Several workarounds, use custom commands, wrapper scripts etc. While the solution works fine for basic stuff, I have several toolchains etc that requires environment variables to be installed for them to work. CMake has always assumed that the environment is setup correctly for the desired toolchain before either cmake or make runs. Typically developers have dealt with this by naming the build tree after the toolchain needed as a reminder of the environment needed. I'm sure an alternative would be welcomed by many. Since I'm using cmake --build for all my building, I am thinking about creating a new command in cmake that will store certain environment variables in the cache, and if building using cmake --build, they will be set before the build starts. This sounds like a great compromise. I don't think the cache is the right place to put this though. I think you can create your own file like CMakeFiles/cmake--build.env and give it a format customized for this purpose (like one line per variable or something). In the Eclipse project generator, I do something similar. Depending on the used compiler, a set of env.variables are stored in the cache and written into the project file, so they will be set when Eclipse invokes make. E.g. for the Intel compiler that's the license-related one, for MSVC it's LIBDIR or something like this. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Test for compiler flags ineffective with xlc?
Hi Stephen :-)
On Thursday 11 August 2011, Stephen Kelly wrote:
Hi,
In this build log the test for -fvisibility=hidden results in success, but
when the flag is used it fails:
http://www.cdash.org/CDash/testDetails.php?test=109109951build=1419259
I'm guessing that compiler treats -ffoo as a filename for some reason.
Can anything be done about that? Should I just exclude that platform from
performing the test? How?
Would if (${CMAKE_CXX_COMPILER_ID} MATCHES xlC) match?
Should be XL, see Modules/CMakeCCompilerId.c.in, there they are all defined.
You can also see this here in the output from the cmake run:
http://www.cdash.org/CDash/viewConfigure.php?buildid=1419259
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting environment variables for builds
On Thu, Aug 11, 2011 at 3:51 PM, Alexander Neundorf neund...@kde.orgwrote:
On Monday 08 August 2011, Brad King wrote:
On 8/8/2011 4:24 AM, Johan Björk wrote:
This has been discussed a billion times, so I'll keep it short.
Problem: Some parts of the build requires a environment variable to be
set Solution: Several workarounds, use custom commands, wrapper scripts
etc.
While the solution works fine for basic stuff, I have several
toolchains
etc that requires environment variables to be installed for them to
work.
CMake has always assumed that the environment is setup correctly for the
desired toolchain before either cmake or make runs. Typically developers
have dealt with this by naming the build tree after the toolchain needed
as a reminder of the environment needed. I'm sure an alternative would
be welcomed by many.
Since I'm using cmake --build for all my building, I am thinking about
creating a new command in cmake that will store certain environment
variables in the cache, and if building using cmake --build, they will
be set before the build starts.
This sounds like a great compromise. I don't think the cache is the
right place to put this though. I think you can create your own file
like CMakeFiles/cmake--build.env and give it a format customized for
this purpose (like one line per variable or something).
In the Eclipse project generator, I do something similar.
Depending on the used compiler, a set of env.variables are stored in the
cache
and written into the project file, so they will be set when Eclipse invokes
make.
E.g. for the Intel compiler that's the license-related one, for MSVC it's
LIBDIR or something like this.
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
You could have a --with-env env.cmake for the --build stuff.
And in the env.cmake file, you could simply have commands of the form:
set(ENV{abc} abc val)
set(ENV{xyz} xyz val)
As long as the script is processed in the same CMake process that runs the
--build, the environment settings should stick around for the duration of
the build.
Of course, there's not an easy, existing way to prevent other non-env
commands from being executed in such a script. This may or may not be deemed
a good idea, but I figured I had to throw it out there: rather than
inventing a whole new way of expressing environment variables in a file,
let's use some existing mechanism...
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] touch flag once all (target) sucess
Hi All, I would like to touch flag file in the CMAKE_BINARY_DIR once the target all is executed with sucess. Since currently I'm not able to specify the dependency to this build-in target I do not have any hook to recognize if all sucess and to touch file. 1. Does anyone knows any hint that can help me with this issue 2. Question to CMake developers/maintainers: Is there any plan to implement this ticket in near future: http://www.cmake.org/Bug/view.php?id=8438#c26520 regards, T Majchrowski. Hi All, Does anyone knows any workarround for touching this flag till issue will be solved ? Thanks. regards, T Majchrowski. ___ 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] touch flag once all (target) sucess
On Thu 11 Aug 2011 09:44:00 AM CEST, t m wrote: Hi All, I would like to touch flag file in the CMAKE_BINARY_DIR once the target all is executed with sucess. Since currently I'm not able to specify the dependency to this build-in target I do not have any hook to recognize if all sucess and to touch file. 1. Does anyone knows any hint that can help me with this issue 2. Question to CMake developers/maintainers: Is there any plan to implement this ticket in near future: http://www.cmake.org/Bug/view.php?id=8438#c26520 regards, T Majchrowski. Hi All, Does anyone knows any workarround for touching this flag till issue will be solved ? Thanks. regards, T Majchrowski. The only way I can think of is to provide custom functions for add_library, add_executable and add_custom_target (if you use the same name, the original commands are available by appending a underscore to the name) which add a dependency of you flag target on all the other targets. What do you need it for? 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] include directories,
Hi Michael, All
Thanks a lot for your explanation,
Now it's obvious for me why it behaves like that, include directories
is inherited from directory properties, and this will be stable after
processing cmakelists.
What I want to do is a little bit different, I would like to reset
value of INCLUDE_DIRECTORIES.
I know that man pages says that this property is read_only, but in all
cases that I need cmake is allowing me to change it this. (again I
don't know if this is misbehaviours or property is not readonly
anymore?)
In my project I have wrapper macro for adding libraries and
executables, and I need to manipulate includes a little, I wanted to
do this in wrapper macro, but it looks like I need to find some other
hook to attach in place when CMakelists will be processed.
Any ideas?
thanks a lot
Lukasz
2011/8/10 Michael Wild them...@gmail.com:
On Wed 10 Aug 2011 04:51:36 PM CEST, Łukasz Tasz wrote:
Hi All,
Can somebody please advise me with this topic, if it is expected
behaviour or a bug?
thanks in advance
Lukasz
2011/8/4 Łukasz Tasz luk...@tasz.eu:
Hi All,
I have a question according include_directories() function and
INCLUDE_DIRECTORIES directory property.
Is it possible that I will know set of include directories that will
be used by preprocessor when I'm calling add_executable function?
I notticed, that order does not matter, for example:
add_library(test test.cxx)
include_directories(${CMAKE_CURRENT_SOURCE_DIR}libtest)
add_library(test1 test1.cxx)
both targets will have the same include directories.
so from CMake phase I'm not able to check what will be includes
configuration, INCLUDE_DIRECTORIES property contain only current one.
is this expected behaviour or this can be tuned by setting some policy?
thanks in advance
Lukasz Tasz
It is expected behaviour. The INCLUDE_DIRECTORIES is a directory
property, and applies to *all* targets defined in that directory. The
targets themselves get generated *after* the processing of the full
CMakeLists.txt file in this directory. However, the get_directory() call
gets evaluated immediately.
I suspect what you want is different include paths for some of the files
or targets, right? Currently the only solution is to put these targets
into different directories. If you need file-level differentiation,
you'll need static libraries in distinct directories.
I know, it is a PITA and has caused much grief for a lot of people on
this list... ;-)
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
--
Lukasz Tasz
___
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] Sub dependencies?
Hrm... this seems like something cmake should be able to do, but I don't
know how to make it work.
If I have library A, that depends on a library and an executable project
that depends on library A, how can the executable project resolve the sub
dependencies from A?
Specifically libpng in my case:
I have a library that depends on libpng.
I run cmake to build the library no problem.
Then I try to compile a program that depends on the library and get a heap
of errors like:
undefined reference to `png_set_read_fn'
etc. etc.
Presumably this is something about how I depend on the library? I'm using
the LibFindMacros, so my cmake module looks like this for the library:
include(LibFindMacros)
find_path(LIBNW_INCLUDE_DIR NAMES nw.h PATHS ${LIBNW_PKGCONF_INCLUDE_DIRS})
find_library(LIBNW_LIBRARY NAMES nw PATHS ${LIBNW_PKGCONF_LIBRARY_DIRS})
set(LIBNW_PROCESS_INCLUDES LIBNW_INCLUDE_DIR)
set(LIBNW_PROCESS_LIBS LIBNW_LIBRARY LIBNW_LIBRARIES)
libfind_process(LIBNW)
I know I can use ADD_SUBDIRECTORY to include stuff for a sub dir, but that
isn't really appropriate in this case.
~
Doug.
___
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] MinGW response file problem
Hi, I am using CMake 2.8.4 and MinGW (gcc 4.4.4, from the Qt SDK 1.1.2) on a Windows 7 64bit system. For my project, I used the MinGW Makefiles CMake generator to configure it, but when issuing a mingw32-make in a cmd.exe window, I get compiler errors due to corrupted command line arguments because my include paths exceed the argument length limit. Is it possible to add response files for include directory arguments, or is there something else I could try? Thanks, Sascha ___ 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] Unable to locate boost_unit_test_framework-vc90-mt-gd-1_45.lib
On 08/10/2011 04:27 PM, Stephen Torri wrote: LNK1104: cannot open file 'boost_unit_test_framework-vc90-mt-gd-1_45.lib' I have boost installed in C:\boost. The FIND_BOOST macro able to find the installation headers and libraries I require. The only thing that is different is that the directory has the Boost unit test framework named as: C:\boost\lib\libboost_unit_test_framework-vc90-mt-gd-1_45.lib That name, libboost_unit_test, is different from the expected name of boost_unit_test... I am at a loss as to why this is the case. The difference between the version with the lib and the one without is that one is a static library and the other is an import library for a DLL. That kind of error probably comes from the fact that Boost does auto-linking with MSVC and that the library you've selected with CMake does not match what the header expects. In any case, the documentation of FindBoost covers this. ___ 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] how to add additional linker options
Something like this:
if (MSVC)
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS}
/FORCE:Multiply)
endif()
in your top level CMakeLists.txt should do the trick. I think the /W0 flag
will suppress any warnings. This would need to be added to CMAKE_C_FLAGS
and/or CMAKE_CPP_FLAGS in a similar manner.
--
Glenn
On 9 August 2011 17:46, Vinay Raj Hampapur vinayraj.hampa...@gmail.comwrote:
Hello,
I need to add to provide additional linker options to the program from
within my CMakeLists.txt targeted at MSVC platform. In particular, I would
like to add the /FORCE:Multiply option to the linker. How would I go about
doing this?
Also, how would I set the options to suppress any (all) warnings generated?
Thanks,
Vinay
___
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] append command
The problem is that we currently already have 2 parallel systems. Some of
the variables like CMAKE_EXE_LINKER_FLAGS are passed through as-is to the
compiler or linker. So, by definition, these variables are space separated
lists of options. Attempting to use list(APPEND) on them adds semicolon
characters which causes breakage unless you manually remove them.
Using list(APPEND), followed by string(REGEX REPLACE) is even more verbose
than just using the set(foo ${foo} ...) approach. I see an append()
command as just the equivalent of the += operator in C/C++ and don't think
that adding it would necessarily require adding any more space separated
list functionality. And I agree that you wouldn't really want
An alternative approach (but harder to implement) would be to abandon space
separated lists altogether. Variables like CMAKE_EXE_LINKER_FLAGS would be
stored as lists and then cmake would format them internally as space
separated strings before passing them to the native build tools. You might
have to change the way cmake internally represents lists if you ever wanted
to be able to pass options with semicolons through to the build tools.
--
Glenn
On 9 August 2011 20:34, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2011-08-09 17:19+0100 Glenn Coombs wrote:
Probably too late now and there isn't a bug filed so far as I know, but
one thing I would love to see added to cmake is an append command
so that lines like this:
set(CMAKE_EXE_LINKER_FLAGS_**RELEASE ${CMAKE_EXE_LINKER_FLAGS_**RELEASE}
/INCREMENTAL:NO)
become shorter and easier to understand:
append(CMAKE_EXE_LINKER_FLAGS_**RELEASE /INCREMENTAL:NO)
The existing syntax for the set command is just ugly when appending. I
know you can define a macro or function to do this but I just
feel that it should be supported out of the box as it would make
CMakeLists.txt files more readable.
Hi Glenn:
I am changing the subject line to keep discussion out of the
bugfix thread as requested by Dave.
It appears what you want is the list APPEND command for
blank-delimited strings. But then later someone will want to add
other parts of the list functionality to blank-delimited strings as
well such as removing items from the blank-delimited list. Until you
have two parallel list systems, one for blank delimited strings and
one for semicolon-delimited strings (i.e., the current lists).
I think most would reject the idea of having two parallel list systems
with different delimiters so here is one possibility.
For now just stick to list functionality, e.g.,
list(APPEND CMAKE_EXE_LINKER_FLAGS_RELEASE /INCREMENTAL:NO)
and then change the semicolon delimiters to blanks using
strings(REGEX REPLACE ...)
once you have the list completely assembled. Of course, that will not
work for the corner case where the strings contain semicolons. So in
the long term, the right thing to do with lists might be to allow a
choice of delimiter if you could do that in such a way as to preserve
backwards compatibility.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting
software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
Powered by www.kitware.com
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] MinGW response file problem
On 8/11/2011 5:06 AM, Sascha Zelzer wrote: Hi, I am using CMake 2.8.4 and MinGW (gcc 4.4.4, from the Qt SDK 1.1.2) on a Windows 7 64bit system. For my project, I used the MinGW Makefiles CMake generator to configure it, but when issuing a mingw32-make in a cmd.exe window, I get compiler errors due to corrupted command line arguments because my include paths exceed the argument length limit. Is it possible to add response files for include directory arguments, or is there something else I could try? I think this might be fixed in 2.8.5, have you tried that? -Bill ___ 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?
Add the sub dependencies that library A has with target_link_libraries():
target_link_libraries(A png)
--
Glenn
On 11 August 2011 10:02, Doug douglas.lin...@gmail.com wrote:
Hrm... this seems like something cmake should be able to do, but I don't
know how to make it work.
If I have library A, that depends on a library and an executable project
that depends on library A, how can the executable project resolve the sub
dependencies from A?
Specifically libpng in my case:
I have a library that depends on libpng.
I run cmake to build the library no problem.
Then I try to compile a program that depends on the library and get a heap
of errors like:
undefined reference to `png_set_read_fn'
etc. etc.
Presumably this is something about how I depend on the library? I'm using
the LibFindMacros, so my cmake module looks like this for the library:
include(LibFindMacros)
find_path(LIBNW_INCLUDE_DIR NAMES nw.h PATHS ${LIBNW_PKGCONF_INCLUDE_DIRS})
find_library(LIBNW_LIBRARY NAMES nw PATHS ${LIBNW_PKGCONF_LIBRARY_DIRS})
set(LIBNW_PROCESS_INCLUDES LIBNW_INCLUDE_DIR)
set(LIBNW_PROCESS_LIBS LIBNW_LIBRARY LIBNW_LIBRARIES)
libfind_process(LIBNW)
I know I can use ADD_SUBDIRECTORY to include stuff for a sub dir, but that
isn't really appropriate in this case.
~
Doug.
___
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] CMake and NaCl (Google NativeClient)
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
Re: [CMake] Sub dependencies?
How can I achieve that _without_ editing my own cmake file?
What if a swap in a different library for my executable that is abi
compatible but uses a different implemented to load images?
I'm not talking hypotheticals here: I literally have two versions of the
library that use slightly different versions of libpng (one for desktop and
one for android) and it's extremely inconvenient to be messing around with
my cmake file every time I change my build target.
Sure I can do a giant IF(TARGET MATCHES Android) ... ENDIF, which I guess
is what I will do for now, but it seems like a poor solution.
Edit: woops; ment that to go to the list.
~
Doug.
On Thu, Aug 11, 2011 at 7:39 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
Add the sub dependencies that library A has with target_link_libraries():
target_link_libraries(A png)
--
Glenn
On 11 August 2011 10:02, Doug douglas.lin...@gmail.com wrote:
Hrm... this seems like something cmake should be able to do, but I don't
know how to make it work.
If I have library A, that depends on a library and an executable project
that depends on library A, how can the executable project resolve the sub
dependencies from A?
Specifically libpng in my case:
I have a library that depends on libpng.
I run cmake to build the library no problem.
Then I try to compile a program that depends on the library and get a heap
of errors like:
undefined reference to `png_set_read_fn'
etc. etc.
Presumably this is something about how I depend on the library? I'm using
the LibFindMacros, so my cmake module looks like this for the library:
include(LibFindMacros)
find_path(LIBNW_INCLUDE_DIR NAMES nw.h PATHS
${LIBNW_PKGCONF_INCLUDE_DIRS})
find_library(LIBNW_LIBRARY NAMES nw PATHS ${LIBNW_PKGCONF_LIBRARY_DIRS})
set(LIBNW_PROCESS_INCLUDES LIBNW_INCLUDE_DIR)
set(LIBNW_PROCESS_LIBS LIBNW_LIBRARY LIBNW_LIBRARIES)
libfind_process(LIBNW)
I know I can use ADD_SUBDIRECTORY to include stuff for a sub dir, but
that isn't really appropriate in this case.
~
Doug.
___
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?
The target_link_libraries() command would be in the CMakeLists.txt for
library A, not the one for your executable. The one for your executable
would just say target_link_libraries(myExe A). And cmake would
automatically know that linking with A also means linking with png.
You say that you have 2 different versions of library A. Does this mean
that you have 2 separate CMakeLists.txt files, one for each variant of A.
Or are both variants built by the same CMakeLists.txt ? Either way, I would
have thought that you could add the appropriate target_link_libraries()
command. Can you describe your current setup in a bit more detail to
explain why this approach won't work ?
On 11 August 2011 14:02, Doug douglas.lin...@gmail.com wrote:
How can I achieve that _without_ editing my own cmake file?
What if a swap in a different library for my executable that is abi
compatible but uses a different implemented to load images?
I'm not talking hypotheticals here: I literally have two versions of the
library that use slightly different versions of libpng (one for desktop and
one for android) and it's extremely inconvenient to be messing around with
my cmake file every time I change my build target.
Sure I can do a giant IF(TARGET MATCHES Android) ... ENDIF, which I guess
is what I will do for now, but it seems like a poor solution.
Edit: woops; ment that to go to the list.
~
Doug.
On Thu, Aug 11, 2011 at 7:39 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
Add the sub dependencies that library A has with target_link_libraries():
target_link_libraries(A png)
--
Glenn
On 11 August 2011 10:02, Doug douglas.lin...@gmail.com wrote:
Hrm... this seems like something cmake should be able to do, but I don't
know how to make it work.
If I have library A, that depends on a library and an executable project
that depends on library A, how can the executable project resolve the sub
dependencies from A?
Specifically libpng in my case:
I have a library that depends on libpng.
I run cmake to build the library no problem.
Then I try to compile a program that depends on the library and get a
heap of errors like:
undefined reference to `png_set_read_fn'
etc. etc.
Presumably this is something about how I depend on the library? I'm using
the LibFindMacros, so my cmake module looks like this for the library:
include(LibFindMacros)
find_path(LIBNW_INCLUDE_DIR NAMES nw.h PATHS
${LIBNW_PKGCONF_INCLUDE_DIRS})
find_library(LIBNW_LIBRARY NAMES nw PATHS ${LIBNW_PKGCONF_LIBRARY_DIRS})
set(LIBNW_PROCESS_INCLUDES LIBNW_INCLUDE_DIR)
set(LIBNW_PROCESS_LIBS LIBNW_LIBRARY LIBNW_LIBRARIES)
libfind_process(LIBNW)
I know I can use ADD_SUBDIRECTORY to include stuff for a sub dir, but
that isn't really appropriate in this case.
~
Doug.
___
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
___
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] MinGW response file problem
Great! It worked with CMake 2.8.5. I was searching the net like crazy but did not land on the CMake 2.8.5 Changelog... Thanks, Sascha On 08/11/2011 01:35 PM, Bill Hoffman wrote: On 8/11/2011 5:06 AM, Sascha Zelzer wrote: Hi, I am using CMake 2.8.4 and MinGW (gcc 4.4.4, from the Qt SDK 1.1.2) on a Windows 7 64bit system. For my project, I used the MinGW Makefiles CMake generator to configure it, but when issuing a mingw32-make in a cmd.exe window, I get compiler errors due to corrupted command line arguments because my include paths exceed the argument length limit. Is it possible to add response files for include directory arguments, or is there something else I could try? I think this might be fixed in 2.8.5, have you tried that? -Bill ___ 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] append command
On Thu, Aug 11, 2011 at 7:29 AM, Glenn Coombs glenn.coo...@gmail.comwrote:
The problem is that we currently already have 2 parallel systems. Some of
the variables like CMAKE_EXE_LINKER_FLAGS are passed through as-is to the
compiler or linker. So, by definition, these variables are space separated
lists of options. Attempting to use list(APPEND) on them adds semicolon
characters which causes breakage unless you manually remove them.
Using list(APPEND), followed by string(REGEX REPLACE) is even more verbose
than just using the set(foo ${foo} ...) approach. I see an append()
command as just the equivalent of the += operator in C/C++ and don't think
that adding it would necessarily require adding any more space separated
list functionality. And I agree that you wouldn't really want
An alternative approach (but harder to implement) would be to abandon space
separated lists altogether. Variables like CMAKE_EXE_LINKER_FLAGS would be
stored as lists and then cmake would format them internally as space
separated strings before passing them to the native build tools. You might
have to change the way cmake internally represents lists if you ever wanted
to be able to pass options with semicolons through to the build tools.
--
Glenn
On 9 August 2011 20:34, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2011-08-09 17:19+0100 Glenn Coombs wrote:
Probably too late now and there isn't a bug filed so far as I know, but
one thing I would love to see added to cmake is an append command
so that lines like this:
set(CMAKE_EXE_LINKER_FLAGS_**RELEASE
${CMAKE_EXE_LINKER_FLAGS_**RELEASE}
/INCREMENTAL:NO)
become shorter and easier to understand:
append(CMAKE_EXE_LINKER_FLAGS_**RELEASE /INCREMENTAL:NO)
The existing syntax for the set command is just ugly when appending. I
know you can define a macro or function to do this but I just
feel that it should be supported out of the box as it would make
CMakeLists.txt files more readable.
Hi Glenn:
I am changing the subject line to keep discussion out of the
bugfix thread as requested by Dave.
It appears what you want is the list APPEND command for
blank-delimited strings. But then later someone will want to add
other parts of the list functionality to blank-delimited strings as
well such as removing items from the blank-delimited list. Until you
have two parallel list systems, one for blank delimited strings and
one for semicolon-delimited strings (i.e., the current lists).
I think most would reject the idea of having two parallel list systems
with different delimiters so here is one possibility.
For now just stick to list functionality, e.g.,
list(APPEND CMAKE_EXE_LINKER_FLAGS_RELEASE /INCREMENTAL:NO)
and then change the semicolon delimiters to blanks using
strings(REGEX REPLACE ...)
once you have the list completely assembled. Of course, that will not
work for the corner case where the strings contain semicolons. So in
the long term, the right thing to do with lists might be to allow a
choice of delimiter if you could do that in such a way as to preserve
backwards compatibility.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and
Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting
software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads
of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
Until somebody comes up with an approach that is reasonably acceptable by
consensus, we will keep things as they are. Please use the (verbose, but
easily understandable) current form for the foreseeable future:
set(xyz ${xyz} /newstuff)
(I am personally adamantly opposed to an actual append command because of
the existence of the list(APPEND feature... I think append will cause
even more confusion...)
Thanks,
David Cole
Kitware, Inc.
___
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 Thu 11 Aug 2011 04:46:44 PM CEST, David Cole wrote:
On Thu, Aug 11, 2011 at 7:29 AM, Glenn Coombs glenn.coo...@gmail.com
mailto:glenn.coo...@gmail.com wrote:
The problem is that we currently already have 2 parallel systems.
Some of the variables like CMAKE_EXE_LINKER_FLAGS are passed through
as-is to the compiler or linker. So, by definition, these variables
are space separated lists of options. Attempting to use
list(APPEND) on them adds semicolon characters which causes breakage
unless you manually remove them.
Using list(APPEND), followed by string(REGEX REPLACE) is even more
verbose than just using the set(foo ${foo} ...) approach. I see
an append() command as just the equivalent of the += operator in
C/C++ and don't think that adding it would necessarily require
adding any more space separated list functionality. And I agree
that you wouldn't really want
An alternative approach (but harder to implement) would be to
abandon space separated lists altogether. Variables like
CMAKE_EXE_LINKER_FLAGS would be stored as lists and then cmake would
format them internally as space separated strings before passing
them to the native build tools. You might have to change the way
cmake internally represents lists if you ever wanted to be able to
pass options with semicolons through to the build tools.
--
Glenn
On 9 August 2011 20:34, Alan W. Irwin ir...@beluga.phys.uvic.ca
mailto:ir...@beluga.phys.uvic.ca wrote:
On 2011-08-09 17:19+0100 Glenn Coombs wrote:
Probably too late now and there isn't a bug filed so far as
I know, but one thing I would love to see added to cmake is
an append command
so that lines like this:
set(CMAKE_EXE_LINKER_FLAGS_ RELEASE
${CMAKE_EXE_LINKER_FLAGS_ RELEASE} /INCREMENTAL:NO)
become shorter and easier to understand:
append(CMAKE_EXE_LINKER_FLAGS_ RELEASE /INCREMENTAL:NO)
The existing syntax for the set command is just ugly when
appending. I know you can define a macro or function to do
this but I just
feel that it should be supported out of the box as it would
make CMakeLists.txt files more readable.
Hi Glenn:
I am changing the subject line to keep discussion out of the
bugfix thread as requested by Dave.
It appears what you want is the list APPEND command for
blank-delimited strings. But then later someone will want to add
other parts of the list functionality to blank-delimited strings as
well such as removing items from the blank-delimited list.
Until you
have two parallel list systems, one for blank delimited strings and
one for semicolon-delimited strings (i.e., the current lists).
I think most would reject the idea of having two parallel list
systems
with different delimiters so here is one possibility.
For now just stick to list functionality, e.g.,
list(APPEND CMAKE_EXE_LINKER_FLAGS_RELEASE /INCREMENTAL:NO)
and then change the semicolon delimiters to blanks using
strings(REGEX REPLACE ...)
once you have the list completely assembled. Of course, that
will not
work for the corner case where the strings contain semicolons. So in
the long term, the right thing to do with lists might be to allow a
choice of delimiter if you could do that in such a way as to
preserve
backwards compatibility.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and
Astronomy,
University of Victoria (astrowww.phys.uvic.ca
http://astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation
for stellar interiors (freeeos.sf.net http://freeeos.sf.net);
PLplot scientific plotting software
package (plplot.org http://plplot.org); the libLASi project
(unifont.org/lasi http://unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net http://loll.sf.net); and the
Linux Brochure Project
(lbproject.sf.net http://lbproject.sf.net).
__
Linux-powered Science
__
Until somebody comes up with an approach that is reasonably acceptable
by consensus, we will keep things as they are. Please use the (verbose,
but easily understandable) current form for the foreseeable future:
set(xyz ${xyz} /newstuff)
(I am personally adamantly opposed to an actual append command because
of the existence of the list(APPEND feature... I
[CMake] hook __EOF__
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] how to add additional linker options
Thanks,
that does the trick. /w alone suppresses all the warnings.
Cheers,
Vinay
On Thu, Aug 11, 2011 at 3:35 AM, Glenn Coombs glenn.coo...@gmail.comwrote:
Something like this:
if (MSVC)
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS}
/FORCE:Multiply)
endif()
in your top level CMakeLists.txt should do the trick. I think the /W0 flag
will suppress any warnings. This would need to be added to CMAKE_C_FLAGS
and/or CMAKE_CPP_FLAGS in a similar manner.
--
Glenn
On 9 August 2011 17:46, Vinay Raj Hampapur vinayraj.hampa...@gmail.comwrote:
Hello,
I need to add to provide additional linker options to the program from
within my CMakeLists.txt targeted at MSVC platform. In particular, I would
like to add the /FORCE:Multiply option to the linker. How would I go about
doing this?
Also, how would I set the options to suppress any (all) warnings
generated?
Thanks,
Vinay
___
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] append command
On 2011-08-11 17:20+0200 Michael Wild wrote:
How about
string(APPEND /newstuff xyz)
It is not satisfactory in that it doesn't follow the semantics of all
the other string(...) commands which never modify their input.
I like that idea, but I would generalize it as
string(APPEND string output_variable input [input...])
to make it similar to other string commands.
BUT if no input is given take it from ${output_variable} just as
for your suggestion.
I would also make that same change for all other string commands of
the same form, i.e., the various REGEX and REPLACE commands. For those, I
find the input string is often ${output_variable} so I believe this
generalization would be a useful convenience for all users of those
string subcommands. Furthermore, even though this generalization of
REGEX et all is a major change, IIRC you get a wrong number
of arguments now for, e.g.,
string(REGEX REPLACE regular_expression replace_expression output
variable)
so I believe this generalization would be backwards compatible.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
Powered by www.kitware.com
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] Is there a way to tell cmake to only care about certain targets?
I'm trying to automate generation of doxygen documentation for codes on a webserver. The webserver contains a working copy of the codes checked out from version control, and I'd like to script the process of going into each and running doxygen. The server that's running the site doesn't have all the libraries necessary to build all the codes that I'd like to generate the doxygen for (and it's unreasonable to install all the libraries for all the codes by everyone in our group, just to generate the documentation). Is there a way to tell cmake to only care about the doc target? As in don't fail when it can't find libraries required by other targets? This question on the FAQ *sounds* like my question: http://www.vtk.org/Wiki/CMake_FAQ#Is_there_a_way_to_skip_checking_of_dependent_libraries_when_compiling.3F but it assumes the makefiles are already generated. If cmake fails because required libraries are missing, the makefiles wont get generated. Any help would be appreciated. ___ 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 08/11/2011 05:20 PM, Michael Wild wrote:
On Thu 11 Aug 2011 04:46:44 PM CEST, David Cole wrote:
On Thu, Aug 11, 2011 at 7:29 AM, Glenn Coombs glenn.coo...@gmail.com
mailto:glenn.coo...@gmail.com wrote:
The problem is that we currently already have 2 parallel systems.
Some of the variables like CMAKE_EXE_LINKER_FLAGS are passed through
as-is to the compiler or linker. So, by definition, these variables
are space separated lists of options. Attempting to use
list(APPEND) on them adds semicolon characters which causes breakage
unless you manually remove them.
Using list(APPEND), followed by string(REGEX REPLACE) is even more
verbose than just using the set(foo ${foo} ...) approach. I see
an append() command as just the equivalent of the += operator in
C/C++ and don't think that adding it would necessarily require
adding any more space separated list functionality. And I agree
that you wouldn't really want
An alternative approach (but harder to implement) would be to
abandon space separated lists altogether. Variables like
CMAKE_EXE_LINKER_FLAGS would be stored as lists and then cmake would
format them internally as space separated strings before passing
them to the native build tools. You might have to change the way
cmake internally represents lists if you ever wanted to be able to
pass options with semicolons through to the build tools.
--
Glenn
On 9 August 2011 20:34, Alan W. Irwin ir...@beluga.phys.uvic.ca
mailto:ir...@beluga.phys.uvic.ca wrote:
On 2011-08-09 17:19+0100 Glenn Coombs wrote:
Probably too late now and there isn't a bug filed so far as
I know, but one thing I would love to see added to cmake is
an append command
so that lines like this:
set(CMAKE_EXE_LINKER_FLAGS_ RELEASE
${CMAKE_EXE_LINKER_FLAGS_ RELEASE} /INCREMENTAL:NO)
become shorter and easier to understand:
append(CMAKE_EXE_LINKER_FLAGS_ RELEASE /INCREMENTAL:NO)
The existing syntax for the set command is just ugly when
appending. I know you can define a macro or function to do
this but I just
feel that it should be supported out of the box as it would
make CMakeLists.txt files more readable.
Hi Glenn:
I am changing the subject line to keep discussion out of the
bugfix thread as requested by Dave.
It appears what you want is the list APPEND command for
blank-delimited strings. But then later someone will want to add
other parts of the list functionality to blank-delimited strings as
well such as removing items from the blank-delimited list.
Until you
have two parallel list systems, one for blank delimited strings and
one for semicolon-delimited strings (i.e., the current lists).
I think most would reject the idea of having two parallel list
systems
with different delimiters so here is one possibility.
For now just stick to list functionality, e.g.,
list(APPEND CMAKE_EXE_LINKER_FLAGS_RELEASE /INCREMENTAL:NO)
and then change the semicolon delimiters to blanks using
strings(REGEX REPLACE ...)
once you have the list completely assembled. Of course, that
will not
work for the corner case where the strings contain semicolons. So in
the long term, the right thing to do with lists might be to allow a
choice of delimiter if you could do that in such a way as to
preserve
backwards compatibility.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and
Astronomy,
University of Victoria (astrowww.phys.uvic.ca
http://astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation
for stellar interiors (freeeos.sf.net http://freeeos.sf.net);
PLplot scientific plotting software
package (plplot.org http://plplot.org); the libLASi project
(unifont.org/lasi http://unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net http://loll.sf.net); and the
Linux Brochure Project
(lbproject.sf.net http://lbproject.sf.net).
__
Linux-powered Science
__
Until somebody comes up with an approach that is reasonably acceptable
by consensus, we will keep things as they are. Please use the (verbose,
but easily understandable) current form for the foreseeable future:
set(xyz ${xyz} /newstuff)
(I am personally adamantly opposed to an actual append command because
of the existence of the list(APPEND
Re: [CMake] append command
On 08/11/2011 07:39 PM, Alan W. Irwin wrote:
On 2011-08-11 17:20+0200 Michael Wild wrote:
How about
string(APPEND /newstuff xyz)
It is not satisfactory in that it doesn't follow the semantics of all
the other string(...) commands which never modify their input.
I like that idea, but I would generalize it as
string(APPEND string output_variable input [input...])
to make it similar to other string commands.
BUT if no input is given take it from ${output_variable} just as
for your suggestion.
I would also make that same change for all other string commands of
the same form, i.e., the various REGEX and REPLACE commands. For those, I
find the input string is often ${output_variable} so I believe this
generalization would be a useful convenience for all users of those
string subcommands. Furthermore, even though this generalization of
REGEX et all is a major change, IIRC you get a wrong number
of arguments now for, e.g.,
string(REGEX REPLACE regular_expression replace_expression output
variable)
so I believe this generalization would be backwards compatible.
Alan
Making the string argument optional is not possible, since there is no
reliable way of determining whether it has been provided or not. Take
string(APPEND foo bar baz)
What is the intention here? Should the result be equivalent to
set(bar foobaz)
or
set(foo ${foo}barbaz)
?
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 08/11/2011 07:48 PM, Michael Hertling wrote:
On 08/11/2011 05:20 PM, Michael Wild wrote:
On Thu 11 Aug 2011 04:46:44 PM CEST, David Cole wrote:
On Thu, Aug 11, 2011 at 7:29 AM, Glenn Coombs glenn.coo...@gmail.com
mailto:glenn.coo...@gmail.com wrote:
The problem is that we currently already have 2 parallel systems.
Some of the variables like CMAKE_EXE_LINKER_FLAGS are passed through
as-is to the compiler or linker. So, by definition, these variables
are space separated lists of options. Attempting to use
list(APPEND) on them adds semicolon characters which causes breakage
unless you manually remove them.
Using list(APPEND), followed by string(REGEX REPLACE) is even more
verbose than just using the set(foo ${foo} ...) approach. I see
an append() command as just the equivalent of the += operator in
C/C++ and don't think that adding it would necessarily require
adding any more space separated list functionality. And I agree
that you wouldn't really want
An alternative approach (but harder to implement) would be to
abandon space separated lists altogether. Variables like
CMAKE_EXE_LINKER_FLAGS would be stored as lists and then cmake would
format them internally as space separated strings before passing
them to the native build tools. You might have to change the way
cmake internally represents lists if you ever wanted to be able to
pass options with semicolons through to the build tools.
--
Glenn
On 9 August 2011 20:34, Alan W. Irwin ir...@beluga.phys.uvic.ca
mailto:ir...@beluga.phys.uvic.ca wrote:
On 2011-08-09 17:19+0100 Glenn Coombs wrote:
Probably too late now and there isn't a bug filed so far as
I know, but one thing I would love to see added to cmake is
an append command
so that lines like this:
set(CMAKE_EXE_LINKER_FLAGS_ RELEASE
${CMAKE_EXE_LINKER_FLAGS_ RELEASE} /INCREMENTAL:NO)
become shorter and easier to understand:
append(CMAKE_EXE_LINKER_FLAGS_ RELEASE /INCREMENTAL:NO)
The existing syntax for the set command is just ugly when
appending. I know you can define a macro or function to do
this but I just
feel that it should be supported out of the box as it would
make CMakeLists.txt files more readable.
Hi Glenn:
I am changing the subject line to keep discussion out of the
bugfix thread as requested by Dave.
It appears what you want is the list APPEND command for
blank-delimited strings. But then later someone will want to add
other parts of the list functionality to blank-delimited strings as
well such as removing items from the blank-delimited list.
Until you
have two parallel list systems, one for blank delimited strings and
one for semicolon-delimited strings (i.e., the current lists).
I think most would reject the idea of having two parallel list
systems
with different delimiters so here is one possibility.
For now just stick to list functionality, e.g.,
list(APPEND CMAKE_EXE_LINKER_FLAGS_RELEASE /INCREMENTAL:NO)
and then change the semicolon delimiters to blanks using
strings(REGEX REPLACE ...)
once you have the list completely assembled. Of course, that
will not
work for the corner case where the strings contain semicolons. So in
the long term, the right thing to do with lists might be to allow a
choice of delimiter if you could do that in such a way as to
preserve
backwards compatibility.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and
Astronomy,
University of Victoria (astrowww.phys.uvic.ca
http://astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation
for stellar interiors (freeeos.sf.net http://freeeos.sf.net);
PLplot scientific plotting software
package (plplot.org http://plplot.org); the libLASi project
(unifont.org/lasi http://unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net http://loll.sf.net); and the
Linux Brochure Project
(lbproject.sf.net http://lbproject.sf.net).
__
Linux-powered Science
__
Until somebody comes up with an approach that is reasonably acceptable
by consensus, we will keep things as they are. Please use the (verbose,
but easily understandable) current form for the foreseeable future:
set(xyz ${xyz} /newstuff)
(I am personally adamantly opposed to an actual append
Re: [CMake] Is there a way to tell cmake to only care about certain targets?
On Thu, 2011-08-11 at 13:42 -0400, cheshirekow wrote: Is there a way to tell cmake to only care about the doc target? As in don't fail when it can't find libraries required by other targets? I've decided that I can accomplish what I want by putting the build commands for the actual outputs inside a conditional. For instance if( Sqlite_FOUND AND Glibmm_FOUND ) message( Found glibmm and sqlite, configuring for library ) ... else( Sqlite_FOUND AND Glibmm_FOUND ) message( Failed to find sqlite or glibmm, configuring only for doxygen ) endif( Sqlite_FOUND AND Glibmm_FOUND ) That way cmake can continue generating a makefile for just the doxygen target. ___ 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 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.
again with sep defaulting to a space. This would preserve the
STRING() command's strict distinction between input and output
variables. Anyway, I agree that this whole APPEND/CONCAT issue
isn't a serious problem but just a convenience feature.
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 ?
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
Re: [CMake] append command
On Thu, Aug 11, 2011 at 4:31 PM, Alan W. Irwin ir...@beluga.phys.uvic.cawrote:
On 2011-08-11 20:34+0200 Michael Wild wrote:
On 08/11/2011 07:39 PM, Alan W. Irwin wrote:
On 2011-08-11 17:20+0200 Michael Wild wrote:
How about
string(APPEND /newstuff xyz)
It is not satisfactory in that it doesn't follow the semantics of all
the other string(...) commands which never modify their input.
I like that idea, but I would generalize it as
string(APPEND string output_variable input [input...])
to make it similar to other string commands.
BUT if no input is given take it from ${output_variable} just as
for your suggestion.
I would also make that same change for all other string commands of
the same form, i.e., the various REGEX and REPLACE commands. For those,
I
find the input string is often ${output_variable} so I believe this
generalization would be a useful convenience for all users of those
string subcommands. Furthermore, even though this generalization of
REGEX et all is a major change, IIRC you get a wrong number
of arguments now for, e.g.,
string(REGEX REPLACE regular_expression replace_expression output
variable)
so I believe this generalization would be backwards compatible.
Alan
Making the string argument optional is not possible
Please reread what I wrote above. string is not optional.
It is input that would be optional. And similarly for
REGEX and friends.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting
software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
__**_
Powered by www.kitware.com
Visit other Kitware open-source projects at http://www.kitware.com/**
opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake
I share Alex's confusion with your proposed signature. All other string
subcommands refer to either string or input in their args list. None
of them have both string *and* input.
If we did have one, it would blend best with a signature like:
string(CONCAT /newStuff variable)
Although, I like CONCAT better than APPEND, I still contend that the
best option so far is still to do nothing.
___
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 Thu, Aug 11, 2011 at 5:28 PM, Alan W. Irwin ir...@beluga.phys.uvic.cawrote:
On 2011-08-11 16:46-0400 David Cole wrote:
I share Alex's confusion with your proposed signature. All other string
subcommands refer to either string or input in their args
list. None of them have both string *and* input.
Sorry I should have been more explicit. The current signatures for
REGEX et al are
string(REGEX MATCH regular_expression
output variable input [input...])
string(REGEX MATCHALL regular_expression
output variable input [input...])
string(REGEX REPLACE regular_expression
replace_expression output variable
input [input...])
string(REPLACE match_string
replace_string output variable
input [input...])
What I am suggesting for all of them is to make input [input...])
optional. When that is not supplied, the input would be taken
from ${output variable} instead. And similarly for
string(APPEND or CONCAT string output variable
input [input...])
Hope that makes clear what I am proposing.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting
software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
It's clear what you mean with the REGEX signatures, but I disagree about the
optional nature of at least one input.
In my experience, the lack of an input to one of these signatures usually
means there's a typo in a dereferenced variable name, or the variable is
unexpectedly empty.
It may or may not be the same as the output variable... but I think it's a
good thing when you get a CMake error in such a case, as is the case now. I
hesitate to stop generating that error.
So I'm voting no on this proposal 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] append command
On 2011-08-11 17:35-0400 David Cole wrote: It's clear what you mean with the REGEX signatures, but I disagree about the optional nature of at least one input. In my experience, the lack of an input to one of these signatures usually means there's a typo in a dereferenced variable name, or the variable is unexpectedly empty. It may or may not be the same as the output variable... but I think it's a good thing when you get a CMake error in such a case, as is the case now. I hesitate to stop generating that error. I assumed the CMake logic parser could distinguish by a count of arguments between the case where the last input argument was missing (i.e. nothing specified by the user) as opposed to the cases you mention where there is something there such as a dereferenced non-existent variable or variable that is unexpectedly empty. However, if the parser cannot distinguish the non-existent last argument case from all others, then I would sadly have to agree with your conclusion that my idea should be rejected. Because I do agree you want to continue to generate CMake errors for the cases you mention. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ Powered by www.kitware.com 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?
That works if it's all in a single project, but it's not.
I totally understand you can do this:
add_library(foo)
target_link_library(foo bar)
add_executable(exec)
target_link_library(exec foo)
If you have _this_ structure:
.../liba/CMakeLists.txt
.../blah/libb/CMakeLists.txt
/some/other/path/exec/CMakeLists.txt
Then in exec you can you use find_package(libb REQUIRED)
However, when I compile it I still get dependency resolution errors on liba
(libpng in my case).
I'm guessing thats because to resolve libb all you get a include path and a
library path; find package has no way to load the CMakeLists.txt in libb/
and parse it, add the dependency to liba.
Seems like there should be a way to do this though.
Am I wrong?
Should the values in libb's CMakeLists.txt be propagating through?
If that's supposed to happen I must be using find_package wrong somehow?
In my specific case libpng and libpng-android are not the same project; they
are completely split and do not even use the same files.
Neither of them are 'child' projects of my library (libnw) via
add_subdirectory or some other weird thing like that.
~
Doug.
On Thu, Aug 11, 2011 at 9:30 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
The target_link_libraries() command would be in the CMakeLists.txt for
library A, not the one for your executable. The one for your executable
would just say target_link_libraries(myExe A). And cmake would
automatically know that linking with A also means linking with png.
You say that you have 2 different versions of library A. Does this mean
that you have 2 separate CMakeLists.txt files, one for each variant of A.
Or are both variants built by the same CMakeLists.txt ? Either way, I would
have thought that you could add the appropriate target_link_libraries()
command. Can you describe your current setup in a bit more detail to
explain why this approach won't work ?
On 11 August 2011 14:02, Doug douglas.lin...@gmail.com wrote:
How can I achieve that _without_ editing my own cmake file?
What if a swap in a different library for my executable that is abi
compatible but uses a different implemented to load images?
I'm not talking hypotheticals here: I literally have two versions of the
library that use slightly different versions of libpng (one for desktop and
one for android) and it's extremely inconvenient to be messing around with
my cmake file every time I change my build target.
Sure I can do a giant IF(TARGET MATCHES Android) ... ENDIF, which I
guess is what I will do for now, but it seems like a poor solution.
Edit: woops; ment that to go to the list.
~
Doug.
On Thu, Aug 11, 2011 at 7:39 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
Add the sub dependencies that library A has with target_link_libraries():
target_link_libraries(A png)
--
Glenn
On 11 August 2011 10:02, Doug douglas.lin...@gmail.com wrote:
Hrm... this seems like something cmake should be able to do, but I don't
know how to make it work.
If I have library A, that depends on a library and an executable project
that depends on library A, how can the executable project resolve the sub
dependencies from A?
Specifically libpng in my case:
I have a library that depends on libpng.
I run cmake to build the library no problem.
Then I try to compile a program that depends on the library and get a
heap of errors like:
undefined reference to `png_set_read_fn'
etc. etc.
Presumably this is something about how I depend on the library? I'm
using the LibFindMacros, so my cmake module looks like this for the
library:
include(LibFindMacros)
find_path(LIBNW_INCLUDE_DIR NAMES nw.h PATHS
${LIBNW_PKGCONF_INCLUDE_DIRS})
find_library(LIBNW_LIBRARY NAMES nw PATHS ${LIBNW_PKGCONF_LIBRARY_DIRS})
set(LIBNW_PROCESS_INCLUDES LIBNW_INCLUDE_DIR)
set(LIBNW_PROCESS_LIBS LIBNW_LIBRARY LIBNW_LIBRARIES)
libfind_process(LIBNW)
I know I can use ADD_SUBDIRECTORY to include stuff for a sub dir, but
that isn't really appropriate in this case.
~
Doug.
___
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
___
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
Re: [CMake] Sub dependencies?
In the vague hopes that using add_subdirectory() will magically fix things
I've changed the structure to be along the lines of:
exec/CMakeLists.txt
exec/cmake/Modules/Findliba.cmake
exec/deps/liba/CMakeLists.txt
exec/deps/liba/cmake/Modules/Findlibb.cmake
exec/deps/liba/deps/libb/CMakeLists.txt
exec/deps/liba/deps/libb/cmake/Modules/Findlibpng.cmake
exec/deps/liba/deps/libb/cmake/Modules/Findlibpng-android.cmake
external/libpng/...
external/libpng-android/...
I can successfully configure using:
add_subdirectory(deps/Natives/libcommon-android/jni)
find_package(libna REQUIRED)
add_executable(exec ...)
link_target_libraries(exec na)
In libna I have:
message(adding sublibs ${extra_libs})
link_target_libraries(na ${extra_libs})
and on running cmake it shows:
-- Found LIBZIP
-- Found LIBPNG
adding sublibs
/usr/lib/libSDLmain.a;/usr/lib/libSDL.so;-lpthread;SDLmain;GL;GLU;X11;/usr/lib/libzip.so;/usr/lib/libpng.so
In exec/CMakelists.txt I invoke:
find_package(libna REQUIRED)
message(na depend? ${LIBNA_LIBRARY})
target_link_libraries(exec ${LIBNA_LIBRARY})
Yielding:
-- Found LIBNA
B depend? /home/doug/projects/Natives/libcommon-android/build/libna.a
However, on compile verbose for exec I still get:
/usr/bin/gcc -std=c99 -g CMakeFiles/stars-android.dir/src/main.c.o
CMakeFiles/stars-android.dir/impl/desktop.c.o -o exec -rdynamic
/home/doug/projects/libn/build/libn.a
/home/doug/projects/libnw/build/libnw.a
/home/doug/projects/libnw-impl/libnw-na/build/libnw-na.a
/home/doug/projects/Natives/libcommon-android/build/libna.a
(The other libraries are fine, only libna has sub-dependencies)
...
:/
Since I invoke:
target_link_library(na
/usr/lib/libSDLmain.a;/usr/lib/libSDL.so;-lpthread;SDLmain;GL;GLU;X11;/usr/lib/libzip.so;/usr/lib/libpng.so)
and then:
target_link_library(exec na)
Shouldn't that import those dependencies?
~
Doug.
On Fri, Aug 12, 2011 at 11:23 AM, Doug douglas.lin...@gmail.com wrote:
That works if it's all in a single project, but it's not.
I totally understand you can do this:
add_library(foo)
target_link_library(foo bar)
add_executable(exec)
target_link_library(exec foo)
If you have _this_ structure:
.../liba/CMakeLists.txt
.../blah/libb/CMakeLists.txt
/some/other/path/exec/CMakeLists.txt
Then in exec you can you use find_package(libb REQUIRED)
However, when I compile it I still get dependency resolution errors on liba
(libpng in my case).
I'm guessing thats because to resolve libb all you get a include path and a
library path; find package has no way to load the CMakeLists.txt in libb/
and parse it, add the dependency to liba.
Seems like there should be a way to do this though.
Am I wrong?
Should the values in libb's CMakeLists.txt be propagating through?
If that's supposed to happen I must be using find_package wrong somehow?
In my specific case libpng and libpng-android are not the same project;
they are completely split and do not even use the same files.
Neither of them are 'child' projects of my library (libnw) via
add_subdirectory or some other weird thing like that.
~
Doug.
On Thu, Aug 11, 2011 at 9:30 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
The target_link_libraries() command would be in the CMakeLists.txt for
library A, not the one for your executable. The one for your executable
would just say target_link_libraries(myExe A). And cmake would
automatically know that linking with A also means linking with png.
You say that you have 2 different versions of library A. Does this mean
that you have 2 separate CMakeLists.txt files, one for each variant of A.
Or are both variants built by the same CMakeLists.txt ? Either way, I would
have thought that you could add the appropriate target_link_libraries()
command. Can you describe your current setup in a bit more detail to
explain why this approach won't work ?
On 11 August 2011 14:02, Doug douglas.lin...@gmail.com wrote:
How can I achieve that _without_ editing my own cmake file?
What if a swap in a different library for my executable that is abi
compatible but uses a different implemented to load images?
I'm not talking hypotheticals here: I literally have two versions of the
library that use slightly different versions of libpng (one for desktop and
one for android) and it's extremely inconvenient to be messing around with
my cmake file every time I change my build target.
Sure I can do a giant IF(TARGET MATCHES Android) ... ENDIF, which I
guess is what I will do for now, but it seems like a poor solution.
Edit: woops; ment that to go to the list.
~
Doug.
On Thu, Aug 11, 2011 at 7:39 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
Add the sub dependencies that library A has with
target_link_libraries():
target_link_libraries(A png)
--
Glenn
On 11 August 2011 10:02, Doug douglas.lin...@gmail.com wrote:
Hrm... this seems like something cmake should be able to do, but I
don't know how to make it work.
If I have
Re: [CMake] append command
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.
Regards,
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
[Cmake-commits] CMake branch, next, updated. v2.8.5-1506-g476ecd3
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 476ecd3b68f6b6d00d67d9c54217ada7be1f2ba2 (commit)
via 91b76e2ab9ed286f20609ab2a0161e4e8c1f507e (commit)
via 66a4bd0cfb41abc7713506590443073e7da67ef6 (commit)
via 975ef3ef1aa36814b2d8f4fac6ce4586f45414e7 (commit)
via 563e3f0e0aa1805fbab6cba39b6f12cafdb758dc (commit)
from 1b83c004423f584137d0630ecbb895cd519a977e (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=476ecd3b68f6b6d00d67d9c54217ada7be1f2ba2
commit 476ecd3b68f6b6d00d67d9c54217ada7be1f2ba2
Merge: 1b83c00 91b76e2
Author: Alexey Ozeritsky aozerit...@gmail.com
AuthorDate: Thu Aug 11 04:25:24 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Aug 11 04:25:24 2011 -0400
Merge topic 'FindLAPACK_FindBLAS' into next
91b76e2 gotoblas supported
66a4bd0 fixed: search of acml libraries
975ef3e KWSys Nightly Date Stamp
563e3f0 KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=91b76e2ab9ed286f20609ab2a0161e4e8c1f507e
commit 91b76e2ab9ed286f20609ab2a0161e4e8c1f507e
Author: Alexey Ozeritsky aozerit...@gmail.com
AuthorDate: Thu Aug 11 12:23:49 2011 +0400
Commit: Alexey Ozeritsky aozerit...@gmail.com
CommitDate: Thu Aug 11 12:23:49 2011 +0400
gotoblas supported
diff --git a/Modules/FindBLAS.cmake b/Modules/FindBLAS.cmake
index 37355bf..4431778 100644
--- a/Modules/FindBLAS.cmake
+++ b/Modules/FindBLAS.cmake
@@ -22,7 +22,7 @@
# BLA_F95 if set on tries to find the f95 interfaces for BLAS/LAPACK
##
### List of vendors (BLA_VENDOR) valid in this module
-## 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),
+## 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
# C/CXX should be enabled to use Intel mkl
@@ -137,6 +137,20 @@ else ($ENV{BLA_VENDOR} MATCHES .+)
endif(NOT BLA_VENDOR)
endif ($ENV{BLA_VENDOR} MATCHES .+)
+if (BLA_VENDOR STREQUAL Goto OR BLA_VENDOR STREQUAL All)
+ if(NOT BLAS_LIBRARIES)
+ # BLAS in ATLAS library? (http://math-atlas.sourceforge.net/)
+ check_fortran_libraries(
+ BLAS_LIBRARIES
+ BLAS
+ sgemm
+
+ goto2
+
+ )
+ endif(NOT BLAS_LIBRARIES)
+endif (BLA_VENDOR STREQUAL Goto OR BLA_VENDOR STREQUAL All)
+
if (BLA_VENDOR STREQUAL ATLAS OR BLA_VENDOR STREQUAL All)
if(NOT BLAS_LIBRARIES)
# BLAS in ATLAS library? (http://math-atlas.sourceforge.net/)
diff --git a/Modules/FindLAPACK.cmake b/Modules/FindLAPACK.cmake
index c57b2e9..1219102 100644
--- a/Modules/FindLAPACK.cmake
+++ b/Modules/FindLAPACK.cmake
@@ -149,6 +149,21 @@ if(BLAS_FOUND)
endif(NOT BLA_VENDOR)
endif ($ENV{BLA_VENDOR} MATCHES .+)
+if (BLA_VENDOR STREQUAL Goto OR BLA_VENDOR STREQUAL All)
+ if(NOT LAPACK_LIBRARIES)
+ check_lapack_libraries(
+ LAPACK_LIBRARIES
+ LAPACK
+ cheev
+
+ goto2
+ ${BLAS_LIBRARIES}
+
+ )
+ endif(NOT LAPACK_LIBRARIES)
+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 (BLAS_LIBRARIES MATCHES .+acml.+)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=66a4bd0cfb41abc7713506590443073e7da67ef6
commit 66a4bd0cfb41abc7713506590443073e7da67ef6
Author: Alexey Ozeritsky aozerit...@gmail.com
AuthorDate: Thu Aug 11 12:07:00 2011 +0400
Commit: Alexey Ozeritsky aozerit...@gmail.com
CommitDate: Thu Aug 11 12:18:39 2011 +0400
fixed: search of acml libraries
diff --git a/Modules/FindBLAS.cmake b/Modules/FindBLAS.cmake
index ae4a13f..37355bf 100644
--- a/Modules/FindBLAS.cmake
+++ b/Modules/FindBLAS.cmake
@@ -57,7 +57,7 @@ else()
endif(BLAS_FIND_REQUIRED)
endif( )
-macro(Check_Fortran_Libraries LIBRARIES _prefix _name _flags _list _threads)
+macro(Check_Fortran_Libraries LIBRARIES _prefix _name _flags _list _optional)
# 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,41 +69,39 @@ macro(Check_Fortran_Libraries LIBRARIES _prefix _name
_flags _list _threads)
# 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
[Cmake-commits] CMake branch, next, updated. v2.8.5-1508-gcfd6e90
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 cfd6e907c41882b87b18dd2822d802229e3926b3 (commit)
via 399f415b1558397e51502914ae36b6d055668eeb (commit)
from 476ecd3b68f6b6d00d67d9c54217ada7be1f2ba2 (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=cfd6e907c41882b87b18dd2822d802229e3926b3
commit cfd6e907c41882b87b18dd2822d802229e3926b3
Merge: 476ecd3 399f415
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Aug 11 04:30:37 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Aug 11 04:30:37 2011 -0400
Merge topic 'generate_export_header' into next
399f415 Only set the deprecated attribute if hidden visibilty is enabled.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=399f415b1558397e51502914ae36b6d055668eeb
commit 399f415b1558397e51502914ae36b6d055668eeb
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Aug 11 10:28:50 2011 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Aug 11 10:28:50 2011 +0200
Only set the deprecated attribute if hidden visibilty is enabled.
This is what is tested in the unit test. If it makes sense, another
option can be added later.
diff --git a/Modules/GenerateExportHeader.cmake
b/Modules/GenerateExportHeader.cmake
index 9dd8f4a..0b93941 100644
--- a/Modules/GenerateExportHeader.cmake
+++ b/Modules/GenerateExportHeader.cmake
@@ -155,7 +155,9 @@ macro(_DO_SET_MACRO_VALUES TARGET_LIBRARY)
set(DEFINE_DEPRECATED __declspec(deprecated))
endif()
else()
-set(DEFINE_DEPRECATED __attribute__ ((__deprecated__)))
+if(COMPILER_HAS_HIDDEN_VISIBILITY AND USE_COMPILER_HIDDEN_VISIBILITY)
+ set(DEFINE_DEPRECATED __attribute__ ((__deprecated__)))
+endif()
endif()
get_property(type TARGET ${TARGET_LIBRARY} PROPERTY TYPE)
---
Summary of changes:
Modules/GenerateExportHeader.cmake |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.5-1510-g0a20056
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 0a200566d20321ba642f3347e85affb27cc559ce (commit) via 1f3be450486c9f3eb140a58fb9bf0f5ef4c858ab (commit) from cfd6e907c41882b87b18dd2822d802229e3926b3 (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=0a200566d20321ba642f3347e85affb27cc559ce commit 0a200566d20321ba642f3347e85affb27cc559ce Merge: cfd6e90 1f3be45 Author: Stephen Kelly steve...@gmail.com AuthorDate: Thu Aug 11 04:40:47 2011 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Aug 11 04:40:47 2011 -0400 Merge topic 'generate_export_header' into next 1f3be45 Make sure the hidden visibility variables never get set on MINGW. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1f3be450486c9f3eb140a58fb9bf0f5ef4c858ab commit 1f3be450486c9f3eb140a58fb9bf0f5ef4c858ab Author: Stephen Kelly steve...@gmail.com AuthorDate: Thu Aug 11 10:39:51 2011 +0200 Commit: Stephen Kelly steve...@gmail.com CommitDate: Thu Aug 11 10:39:51 2011 +0200 Make sure the hidden visibility variables never get set on MINGW. diff --git a/Modules/GenerateExportHeader.cmake b/Modules/GenerateExportHeader.cmake index 0b93941..322439b 100644 --- a/Modules/GenerateExportHeader.cmake +++ b/Modules/GenerateExportHeader.cmake @@ -132,7 +132,7 @@ macro(_test_compiler_hidden_visibility) endif() endif() - if (NOT GCC_TOO_OLD) + if (NOT GCC_TOO_OLD AND NOT MINGW) 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) @@ -252,7 +252,7 @@ function(add_compiler_export_flags) _test_compiler_hidden_visibility() - if(NOT (USE_COMPILER_HIDDEN_VISIBILITY AND COMPILER_HAS_HIDDEN_VISIBILITY) OR MINGW) + if(NOT (USE_COMPILER_HIDDEN_VISIBILITY AND COMPILER_HAS_HIDDEN_VISIBILITY)) message(WARNING Compiler doesn't have hidden visibility) return() endif() --- Summary of changes: Modules/GenerateExportHeader.cmake |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.5-1513-g1197c43
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 1197c43f2792bc89d82927abf0ab91a88b0974f2 (commit)
via 1590d5fe4f95a800635ba9078e822d742a96dc18 (commit)
via 750b67c5a1957f5fa2c7a483050f0ef0959c9924 (commit)
from 0a200566d20321ba642f3347e85affb27cc559ce (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=1197c43f2792bc89d82927abf0ab91a88b0974f2
commit 1197c43f2792bc89d82927abf0ab91a88b0974f2
Merge: 0a20056 1590d5f
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Aug 11 04:56:45 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Aug 11 04:56:45 2011 -0400
Merge topic 'generate_export_header' into next
1590d5f Don't export methods on already exported classes.
750b67c Don't use hidden visibility on non-mingw windows either.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1590d5fe4f95a800635ba9078e822d742a96dc18
commit 1590d5fe4f95a800635ba9078e822d742a96dc18
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Aug 11 10:54:21 2011 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Aug 11 10:55:12 2011 +0200
Don't export methods on already exported classes.
This is always a mistake.
diff --git
a/Tests/Module/GenerateExportHeader/lib_shared_and_static/libshared_and_static.h
b/Tests/Module/GenerateExportHeader/lib_shared_and_static/libshared_and_static.h
index 400d664..049bfe9 100644
---
a/Tests/Module/GenerateExportHeader/lib_shared_and_static/libshared_and_static.h
+++
b/Tests/Module/GenerateExportHeader/lib_shared_and_static/libshared_and_static.h
@@ -8,11 +8,7 @@ class LIBSHARED_AND_STATIC_EXPORT LibsharedAndStatic {
public:
int libshared_and_static() const;
-#ifdef COMPILER_IS_MSVC
int libshared_and_static_exported() const;
-#else
- int LIBSHARED_AND_STATIC_EXPORT libshared_and_static_exported() const;
-#endif
int LIBSHARED_AND_STATIC_DEPRECATED libshared_and_static_deprecated() const;
diff --git a/Tests/Module/GenerateExportHeader/libshared/libshared.h
b/Tests/Module/GenerateExportHeader/libshared/libshared.h
index 280e185..3d9bbff 100644
--- a/Tests/Module/GenerateExportHeader/libshared/libshared.h
+++ b/Tests/Module/GenerateExportHeader/libshared/libshared.h
@@ -8,12 +8,7 @@ class LIBSHARED_EXPORT Libshared {
public:
int libshared() const;
-#ifdef COMPILER_IS_MSVC
- // Double exporting not possible with MSVC
int libshared_exported() const;
-#else
- int LIBSHARED_EXPORT libshared_exported() const;
-#endif
int LIBSHARED_DEPRECATED libshared_deprecated() const;
diff --git a/Tests/Module/GenerateExportHeader/libstatic/libstatic.h
b/Tests/Module/GenerateExportHeader/libstatic/libstatic.h
index cd68cdc..cc7a35b 100644
--- a/Tests/Module/GenerateExportHeader/libstatic/libstatic.h
+++ b/Tests/Module/GenerateExportHeader/libstatic/libstatic.h
@@ -8,7 +8,7 @@ class LIBSTATIC_EXPORT Libstatic {
public:
int libstatic() const;
- int LIBSTATIC_EXPORT libstatic_exported() const;
+ int libstatic_exported() const;
int LIBSTATIC_DEPRECATED libstatic_deprecated() const;
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=750b67c5a1957f5fa2c7a483050f0ef0959c9924
commit 750b67c5a1957f5fa2c7a483050f0ef0959c9924
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Aug 11 10:53:58 2011 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Aug 11 10:53:58 2011 +0200
Don't use hidden visibility on non-mingw windows either.
diff --git a/Modules/GenerateExportHeader.cmake
b/Modules/GenerateExportHeader.cmake
index 322439b..92b9433 100644
--- a/Modules/GenerateExportHeader.cmake
+++ b/Modules/GenerateExportHeader.cmake
@@ -132,7 +132,7 @@ macro(_test_compiler_hidden_visibility)
endif()
endif()
- if (NOT GCC_TOO_OLD AND NOT MINGW)
+ if (NOT GCC_TOO_OLD AND NOT WIN32)
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)
---
Summary of changes:
Modules/GenerateExportHeader.cmake |2 +-
.../lib_shared_and_static/libshared_and_static.h |4
.../GenerateExportHeader/libshared/libshared.h |5 -
.../GenerateExportHeader/libstatic/libstatic.h |2 +-
4 files changed, 2 insertions(+), 11 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
[Cmake-commits] CMake branch, next, updated. v2.8.5-1516-ge4f3202
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 e4f32022c3506941edc52bf121740a527c7184f8 (commit)
via e1f7ee3de71fc0e7a34bf05ec2cf4ec586ff9e32 (commit)
via 9554e1013ef5d9971092ed0cd45daf59b8a6bd87 (commit)
from 1197c43f2792bc89d82927abf0ab91a88b0974f2 (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=e4f32022c3506941edc52bf121740a527c7184f8
commit e4f32022c3506941edc52bf121740a527c7184f8
Merge: 1197c43 e1f7ee3
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Aug 11 18:09:23 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Aug 11 18:09:23 2011 -0400
Merge topic 'generate_export_header' into next
e1f7ee3 Test for compiler features, instead of for specific platforms.
9554e10 Split the deprecated available check from setting macro values.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e1f7ee3de71fc0e7a34bf05ec2cf4ec586ff9e32
commit e1f7ee3de71fc0e7a34bf05ec2cf4ec586ff9e32
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Aug 11 18:18:19 2011 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Aug 11 19:06:23 2011 +0200
Test for compiler features, instead of for specific platforms.
diff --git a/Modules/GenerateExportHeader.cmake
b/Modules/GenerateExportHeader.cmake
index f690655..578d71f 100644
--- a/Modules/GenerateExportHeader.cmake
+++ b/Modules/GenerateExportHeader.cmake
@@ -115,6 +115,20 @@
include(CMakeParseArguments)
include(CheckCXXCompilerFlag)
+
+# TODO: Install this macro separately?
+macro(_check_cxx_compiler_attribute _ATTRIBUTE _RESULT)
+ check_cxx_source_compiles(${_ATTRIBUTE} int somefunc() { return 0; } int
main() { return somefunc();} ${_RESULT}
+# Some compilers do not fail with a bad flag
+FAIL_REGEX unrecognized .*option # GNU
+FAIL_REGEX ignoring unknown option # MSVC
+FAIL_REGEX warning D9002 # MSVC, any lang
+FAIL_REGEX [Uu]nknown option # HP
+FAIL_REGEX [Ww]arning: [Oo]ption # SunPro
+FAIL_REGEX command option .* is not recognized # XL
+ )
+endmacro()
+
macro(_test_compiler_hidden_visibility)
if (CMAKE_COMPILER_IS_GNUCXX)
@@ -141,15 +155,11 @@ macro(_test_compiler_hidden_visibility)
endmacro()
macro(_test_compiler_has_deprecated)
- if (WIN32)
-if (NOT ${CMAKE_CXX_COMPILER_ID} MATCHES Borland)
- set(COMPILER_HAS_DEPRECATED TRUE)
-endif()
+ _check_cxx_compiler_attribute(__declspec(deprecated)
COMPILER_HAS_DEPRECATED_DECLSPEC)
+ if(COMPILER_HAS_DEPRECATED_DECLSPEC)
+set(COMPILER_HAS_DEPRECATED ${COMPILER_HAS_DEPRECATED_DECLSPEC})
else()
-# TODO: Test properly for this
-if(COMPILER_HAS_HIDDEN_VISIBILITY AND USE_COMPILER_HIDDEN_VISIBILITY)
- set(COMPILER_HAS_DEPRECATED TRUE)
-endif()
+_check_cxx_compiler_attribute(__attribute__((__deprecated__))
COMPILER_HAS_DEPRECATED)
endif()
set(COMPILER_HAS_DEPRECATED ${COMPILER_HAS_DEPRECATED} CACHE INTERNAL
Compiler support for a deprecated attribute)
endmacro()
@@ -162,14 +172,10 @@ macro(_DO_SET_MACRO_VALUES TARGET_LIBRARY)
set(DEFINE_IMPORT)
set(DEFINE_NO_EXPORT)
- if(WIN32)
-if (COMPILER_HAS_DEPRECATED)
- set(DEFINE_DEPRECATED __declspec(deprecated))
-endif()
- else()
-if(COMPILER_HAS_DEPRECATED)
- set(DEFINE_DEPRECATED __attribute__ ((__deprecated__)))
-endif()
+ if (COMPILER_HAS_DEPRECATED_DECLSPEC)
+set(DEFINE_DEPRECATED __declspec(deprecated))
+ elseif(COMPILER_HAS_DEPRECATED)
+set(DEFINE_DEPRECATED __attribute__ ((__deprecated__)))
endif()
get_property(type TARGET ${TARGET_LIBRARY} PROPERTY TYPE)
diff --git a/Tests/Module/GenerateExportHeader/CMakeLists.txt
b/Tests/Module/GenerateExportHeader/CMakeLists.txt
index eb19afb..05d1519 100644
--- a/Tests/Module/GenerateExportHeader/CMakeLists.txt
+++ b/Tests/Module/GenerateExportHeader/CMakeLists.txt
@@ -49,7 +49,7 @@ macro(_do_build Include Library LibrarySource Source)
if(CMAKE_COMPILER_IS_GNUCXX OR (${CMAKE_CXX_COMPILER_ID} MATCHES
Clang))\n
add_definitions(-Werror)\n
else()\n
- if(MSVC)\n
+ if(MSVC AND COMPILER_HAS_DEPRECATED)\n
# Treat deprecation warnings as errors.
add_definitions(/we4996)\n
endif()\n
@@ -123,7 +123,7 @@ if (CMAKE_COMPILER_IS_GNUCXX OR (${CMAKE_CXX_COMPILER_ID}
MATCHES Clang))
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wno-deprecated-declarations)
endif()
-if(MSVC)
+if(MSVC AND COMPILER_HAS_DEPRECATED)
add_definitions(/wd4996)
endif()
[Cmake-commits] CMake branch, next, updated. v2.8.5-1519-g1d54f70
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 1d54f70c806a0b24d2e12babd62f36ac9985622f (commit)
via df4615e3380cda2bf29d3dfdcfd26b020a64e707 (commit)
via 78a6e1c1224bbeb92f44dd681cc914030bbf8c82 (commit)
from e4f32022c3506941edc52bf121740a527c7184f8 (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=1d54f70c806a0b24d2e12babd62f36ac9985622f
commit 1d54f70c806a0b24d2e12babd62f36ac9985622f
Merge: e4f3202 df4615e
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Aug 11 18:23:46 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Aug 11 18:23:46 2011 -0400
Merge topic 'generate_export_header' into next
df4615e Add the COMPILER_HAS_DEPRECATED only if it has a declspec variant
78a6e1c Exclude the XL compiler from the hidden-visibility test.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=df4615e3380cda2bf29d3dfdcfd26b020a64e707
commit df4615e3380cda2bf29d3dfdcfd26b020a64e707
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Aug 12 00:21:13 2011 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Fri Aug 12 00:23:00 2011 +0200
Add the COMPILER_HAS_DEPRECATED only if it has a declspec variant
_check_cxx_compiler_attribute does it in the alternative.
diff --git a/Modules/GenerateExportHeader.cmake
b/Modules/GenerateExportHeader.cmake
index 05f36f3..c833a01 100644
--- a/Modules/GenerateExportHeader.cmake
+++ b/Modules/GenerateExportHeader.cmake
@@ -160,11 +160,10 @@ endmacro()
macro(_test_compiler_has_deprecated)
_check_cxx_compiler_attribute(__declspec(deprecated)
COMPILER_HAS_DEPRECATED_DECLSPEC)
if(COMPILER_HAS_DEPRECATED_DECLSPEC)
-set(COMPILER_HAS_DEPRECATED ${COMPILER_HAS_DEPRECATED_DECLSPEC})
+set(COMPILER_HAS_DEPRECATED ${COMPILER_HAS_DEPRECATED_DECLSPEC} CACHE
INTERNAL Compiler support for a deprecated attribute)
else()
_check_cxx_compiler_attribute(__attribute__((__deprecated__))
COMPILER_HAS_DEPRECATED)
endif()
- set(COMPILER_HAS_DEPRECATED ${COMPILER_HAS_DEPRECATED} CACHE INTERNAL
Compiler support for a deprecated attribute)
endmacro()
set(myDir ${CMAKE_CURRENT_LIST_DIR})
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=78a6e1c1224bbeb92f44dd681cc914030bbf8c82
commit 78a6e1c1224bbeb92f44dd681cc914030bbf8c82
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Aug 11 18:18:19 2011 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Fri Aug 12 00:18:43 2011 +0200
Exclude the XL compiler from the hidden-visibility test.
diff --git a/Modules/GenerateExportHeader.cmake
b/Modules/GenerateExportHeader.cmake
index 578d71f..05f36f3 100644
--- a/Modules/GenerateExportHeader.cmake
+++ b/Modules/GenerateExportHeader.cmake
@@ -146,7 +146,10 @@ macro(_test_compiler_hidden_visibility)
endif()
endif()
- if (NOT GCC_TOO_OLD AND NOT WIN32)
+ # 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)
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)
---
Summary of changes:
Modules/GenerateExportHeader.cmake |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.5-1521-gc070dbe
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 c070dbe4e53a87a92da6d2c36f9a1bfd49479188 (commit)
via 856bdb317bc0d38327a7a9c7e9105ee1cd39f18a (commit)
from 1d54f70c806a0b24d2e12babd62f36ac9985622f (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=c070dbe4e53a87a92da6d2c36f9a1bfd49479188
commit c070dbe4e53a87a92da6d2c36f9a1bfd49479188
Merge: 1d54f70 856bdb3
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Aug 11 18:34:41 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Aug 11 18:34:41 2011 -0400
Merge topic 'generate_export_header' into next
856bdb3 Don't change the expected build result based on the platform.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=856bdb317bc0d38327a7a9c7e9105ee1cd39f18a
commit 856bdb317bc0d38327a7a9c7e9105ee1cd39f18a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Aug 12 00:30:31 2011 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Fri Aug 12 00:30:31 2011 +0200
Don't change the expected build result based on the platform.
Hopefully the compiler feature tests will cover those cases.
diff --git a/Tests/Module/GenerateExportHeader/CMakeLists.txt
b/Tests/Module/GenerateExportHeader/CMakeLists.txt
index 05d1519..febf90f 100644
--- a/Tests/Module/GenerateExportHeader/CMakeLists.txt
+++ b/Tests/Module/GenerateExportHeader/CMakeLists.txt
@@ -78,11 +78,7 @@ endmacro()
macro(build_fail Include Library LibrarySource Source Message)
_do_build(${Include} ${Library} ${LibrarySource} ${Source})
- if(COMPILER_HAS_HIDDEN_VISIBILITY OR WIN32 OR (${CMAKE_CXX_COMPILER_ID}
MATCHES Clang))
-test_fail(Result ${Message})
- else()
-test_pass(Result ${Message})
- endif()
+ test_fail(Result ${Message})
endmacro()
macro(build_pass Include Library LibrarySource Source Message)
---
Summary of changes:
Tests/Module/GenerateExportHeader/CMakeLists.txt |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
