[cmake-developers] [CMake 0013834]: FindBLAS doesn't trust pkg-config and may, therefore, fail
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13834 == Reported By:Gert Wollny Assigned To: == Project:CMake Issue ID: 13834 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-01-04 07:25 EST Last Modified: 2013-01-04 07:25 EST == Summary:FindBLAS doesn't trust pkg-config and may, therefore, fail Description: FindBLAS first tries to locate the BLAS libraries by using pkg-config. However, instead of trusting the returned information, it then tries to locate all libraries given in the returned string within the returned library directory. When on Gentoo ACML is selected to provide BLAS, this strategy fails, because apart from the acml libraries, libgfortran and libpthread are reported by phk-config and these libraries are not located within the given library directory, since they are in the default library search path. Steps to Reproduce: on Gentoo: eselect blas set acml-gfortran-openmp Add to CmakeLists.txt: FIND_PACKAGE(BLAS) run cmake Make Error at /usr/share/cmake/Modules/FindBLAS.cmake:58 (message): Something is wrong in your pkg-config file - lib gfortran not found in /opt/acml4.4.0/gfortran64_mp/lib Additional Information: Instead of searching for the libraries, FindBLAS should either just trust pkg-config, or try to link a simple program that requires a BLAS function. == Issue History Date ModifiedUsername FieldChange == 2013-01-04 07:25 Gert WollnyNew Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Interface includes and defines plumbing
Stephen Kelly wrote: Brad King wrote: * In the Use mapped config properties to evaluate $CONFIG you add code to handle MAP_IMPORTED_CONFIG. I think that should be an API on cmTarget refactored from its existing imported config selection code. You mean you want the $CONFIG:mappedCfg expression to depend on whether LOCATION_mappedCfg exists, as the logic in ComputeImportInfo requires? Done now, I think. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Interface includes and defines plumbing
On 01/04/2013 08:39 AM, Stephen Kelly wrote: Stephen Kelly wrote: Brad King wrote: * In the Use mapped config properties to evaluate $CONFIG you add code to handle MAP_IMPORTED_CONFIG. I think that should be an API on cmTarget refactored from its existing imported config selection code. You mean you want the $CONFIG:mappedCfg expression to depend on whether LOCATION_mappedCfg exists, as the logic in ComputeImportInfo requires? Done now, I think. Yes. For any given imported target a specific imported configuration must be chosen to correspond to each of the current project's configs. I think any place that uses context-Config needs to map it through this lookup, not just $CONFIG:..., right? -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Interface includes and defines plumbing
Stephen Kelly wrote: If, you agree, I'll merge this to next. I've also pushed a LINK_LIBRARIES-property branch, and a INTERFACE_LINK_LIBRARIES-genex branch to gitorious. If you can review them and tell me they're fine, modulo what the dashboard says, I can have them dashboard-clean and we can get them all merged early next week. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Interface includes and defines plumbing
On 01/04/2013 09:26 AM, Stephen Kelly wrote: Brad King wrote: Yes. For any given imported target a specific imported configuration must be chosen to correspond to each of the current project's configs. I think any place that uses context-Config needs to map it through this lookup, not just $CONFIG:..., right? Perhaps. There are existing uses in master (For TARGET_SONAME_FILE etc) which could possibly go through the mapping. That goes through GetSOName which goes through ComputeImportInfo which honors the mapping. All target file location info is already handled this way. Looking through cmGeneratorExpressionEvaluator.cxx in your branch I think everyplace is mapped that should be. The other uses of context-Config is in $CONFIGURATION, where I don't think the mapping should be used, and CONFIG_DEBUG, which you said previously should not use the mapping. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5398/focus=5488 Hmm...actually $CONFIG_DEBUG should evaluate to true or false based on whether the mapped configuration was considered a debug configuration according to the exporting project's DEBUG_CONFIGURATIONS property. Yuck. Previously all export properties were generated by evaluating each configuration of the exporting project and recording the results at export time. Now the configuration isn't used for evaluation until loaded by the importing project. One solution is to convert $CONFIG_DEBUG at export time to something like $OR:$CONFIG:Debug1,$CONFIG:Debug2,... where Debug1;Debug2;... are the values of the DEBUG_CONFIGURATIONS global property. Another solution is to use the $OR:... approach instead of $CONFIG_DEBUG altogether. Anyway, since $CONFIG_DEBUG is not part of this topic it doesn't yet matter anyway. The topic that adds it should be based on this topic so it can get the config map handling. If, you agree, I'll merge this to next. Yes, please. Thanks for splitting this out. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Interface includes and defines plumbing
On 01/04/2013 10:15 AM, Stephen Kelly wrote: I've also pushed a LINK_LIBRARIES-property branch, and a INTERFACE_LINK_LIBRARIES-genex branch to gitorious. s/INTERFACE_LINK_LIBRARIES/LINK_INTERFACE_LIBRARIES/ ? Unfortunately I won't have time to review them until at least Monday. Meanwhile please work on the $CONFIG_DEBUG v. $OR:$CONFIG:... approach discussed in a sibling part of this thread. Note that in the default case when no DEBUG_CONFIGURATIONS property is set or when it is set to only one value then you can just use $CONFIG:... with the one value directly instead of using $OR:. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Interface includes and defines plumbing
Brad King wrote: On 01/04/2013 10:15 AM, Stephen Kelly wrote: I've also pushed a LINK_LIBRARIES-property branch, and a INTERFACE_LINK_LIBRARIES-genex branch to gitorious. s/INTERFACE_LINK_LIBRARIES/LINK_INTERFACE_LIBRARIES/ ? Yes. Unfortunately I won't have time to review them until at least Monday. Meanwhile please work on the $CONFIG_DEBUG v. $OR:$CONFIG:... approach discussed in a sibling part of this thread. Note that in the default case when no DEBUG_CONFIGURATIONS property is set or when it is set to only one value then you can just use $CONFIG:... with the one value directly instead of using $OR:. Yes. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] MSYS and Intel Fortran/MSVC/C++
Hi Bill, Alan, just to make sure, I checked that there is an e-drive and a directory temp on that drive. These settings are the same as always when I use the MSVC/C++ or Intel Fortran compilers. My guess is that the use of the forward slash is messing up the argument parsing: - cl uses both / and - as the start characters for a command-line option. - MSYS uses the forward slash to separate path components and in this particular case both forward and backward slashes occur. - cl is complaining about a file called e:, not e:/temp (The DOS shell can use both forward and backward slashes by the way as a path separator, but it is not consistent in this - path completion only works for backward slashes for instance) This means that the MSYS shell can not be readily used to generate the makefiles. An alternative I can imagine is that I use the DOS shell and make the MinGW/MSYS utilities available via the path. Regards, Arjen On Thu, 03 Jan 2013 17:10:09 -0500 Bill Hoffman bill.hoff...@kitware.com wrote: On 1/3/2013 4:37 PM, Alan W. Irwin wrote: ... Recalling that CMake-2.8.10 had a lot of changes to language support is this a regression for cmake-2.8.10.2 or do you get the same issue for earlier cmake versions? This does not seem to have anything to do with CMake versions. Here is the error: c:\PROGRA~1\Microsoft Visual Studio 10.0\VC\bin\cl.exe @e:/Temp\nm591.tmp Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. cl : Command line error D8022 : cannot open 'e:' NMAKE : fatal error U1077: 'c:\PROGRA~1\Microsoft Visual Studio 10.0\VC\bin\cl.exe' : return code '0x2 Looks like cl is using your e:/Temp for temp files. Maybe you have a bad env var. You have to make sure you are running CMake from a shell where the command line tools for cl are configured correctly. Do you have an e: drive on the machine? Is there an e:/Temp? DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- 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] MSYS and Intel Fortran/MSVC/C++
Hi Bill, Alan, here is some further information: As the MSYS environment/shell is started with a batch file that takes care of several options and using the set-up batch file needed for MSVC/C++ can not be used in the default MSYS shell, I have adapted the stock batch file (msys.bat in c:\mingw\msys\1.0) as follows: rem At the start rem Initialise the MSVC/C++ environment call c:\program files\MicroSoft Visual Studio 10.0\VC\vcvarsall.bat x86 rem Rest of the original batch file follows ... This sets all the environment variables required for MSVC/C++ and then starts the default MSYS shell. Regards, Arjen On Fri, 04 Jan 2013 09:31:37 +0100 Arjen Markus arjen.mar...@deltares.nl wrote: Hi Bill, Alan, just to make sure, I checked that there is an e-drive and a directory temp on that drive. These settings are the same as always when I use the MSVC/C++ or Intel Fortran compilers. My guess is that the use of the forward slash is messing up the argument parsing: - cl uses both / and - as the start characters for a command-line option. - MSYS uses the forward slash to separate path components and in this particular case both forward and backward slashes occur. - cl is complaining about a file called e:, not e:/temp (The DOS shell can use both forward and backward slashes by the way as a path separator, but it is not consistent in this - path completion only works for backward slashes for instance) This means that the MSYS shell can not be readily used to generate the makefiles. An alternative I can imagine is that I use the DOS shell and make the MinGW/MSYS utilities available via the path. DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- 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] OBJECT target - usage of translation units in libraries and executables
Hi, I just stumbled across the OBJECT flag in add_library. Now I wonder whether it also works for windows builds with dlexport and dlimport flags attached to symbols. Based on the documentation it seems like object files are built immediately. Is it possible that an object library is used in a dynamic library with its symbols get exported, and in a different target the symbols are hidden. From what I understood the source code of the object library has to be built twice, and the caller of the symbols has to be aware whether the exported symbol references or normal symbols shall be used. regards Andreas -- 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] AC_C_RESTRICT
Hi, I am searching for something appropriate to the autoconf AC_C_RESTRICT macro. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MSYS and Intel Fortran/MSVC/C++
On 1/4/2013 3:31 AM, Arjen Markus wrote: Hi Bill, Alan, just to make sure, I checked that there is an e-drive and a directory temp on that drive. These settings are the same as always when I use the MSVC/C++ or Intel Fortran compilers. My guess is that the use of the forward slash is messing up the argument parsing: - cl uses both / and - as the start characters for a command-line option. - MSYS uses the forward slash to separate path components and in this particular case both forward and backward slashes occur. - cl is complaining about a file called e:, not e:/temp (The DOS shell can use both forward and backward slashes by the way as a path separator, but it is not consistent in this - path completion only works for backward slashes for instance) This means that the MSYS shell can not be readily used to generate the makefiles. An alternative I can imagine is that I use the DOS shell and make the MinGW/MSYS utilities available via the path. I suspect you might be right. I am thinking this is MSYS messing with the command line somehow. Can you build with nmake and a DOS shell? If so, can you then go into that tree with the msys shell and try to build? Some other things you can try: add --debug-trycompile to the cmake command line. This will leave the files in CMakeFiles/CMakeTmp. You can then cd into there and run nmake from the command line and look at the makefiles. I don't think CMake is doing the mixed path stuff. I think this is a bad interaction with nmake and msys. -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] AC_C_RESTRICT
On 1/4/2013 6:50 AM, Kornel Benko wrote: Hi, I am searching for something appropriate to the autoconf AC_C_RESTRICT macro. Kornel What does it do? -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] MSYS and Intel Fortran/MSVC/C++
Hi Bill, I will try that later and I will let you know the results. Regards, Arjen On Fri, 04 Jan 2013 09:09:58 -0500 Bill Hoffman bill.hoff...@kitware.com wrote: On 1/4/2013 3:31 AM, Arjen Markus wrote: Hi Bill, Alan, just to make sure, I checked that there is an e-drive and a directory temp on that drive. These settings are the same as always when I use the MSVC/C++ or Intel Fortran compilers. My guess is that the use of the forward slash is messing up the argument parsing: - cl uses both / and - as the start characters for a command-line option. - MSYS uses the forward slash to separate path components and in this particular case both forward and backward slashes occur. - cl is complaining about a file called e:, not e:/temp (The DOS shell can use both forward and backward slashes by the way as a path separator, but it is not consistent in this - path completion only works for backward slashes for instance) This means that the MSYS shell can not be readily used to generate the makefiles. An alternative I can imagine is that I use the DOS shell and make the MinGW/MSYS utilities available via the path. I suspect you might be right. I am thinking this is MSYS messing with the command line somehow. Can you build with nmake and a DOS shell? If so, can you then go into that tree with the msys shell and try to build? Some other things you can try: add --debug-trycompile to the cmake command line. This will leave the files in CMakeFiles/CMakeTmp. You can then cd into there and run nmake from the command line and look at the makefiles. I don't think CMake is doing the mixed path stuff. I think this is a bad interaction with nmake and msys. -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 DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- 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] AC_C_RESTRICT
On 4 January 2013 14:12, Bill Hoffman bill.hoff...@kitware.com wrote: On 1/4/2013 6:50 AM, Kornel Benko wrote: Hi, I am searching for something appropriate to the autoconf AC_C_RESTRICT macro. Kornel What does it do? Bill, It tests if C compiler supports C99 restrict keyword, perhaps also implementation-specific form, e.g. __restrict, etc. [1] http://en.wikipedia.org/wiki/Restrict Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] Object library doesn't work with CMake 2.8.10.2 Xcode generator
On 01/03/2013 04:33 PM, Bin Chen wrote: clang: error: no such file or directory: '/Users/bchen/share/temp/cmake-obj-lib/b-xcode/Debug/liba.a' clang: error: no such file or directory: '/Users/bchen/share/temp/cmake-obj-lib/b-xcode/Debug/libb.a' Xcode does not seem to recognize targets that do not actually list any source files to compile. It looks like our ObjectLibrary test has a workaround for this by adding an empty dummy.c: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/ObjectLibrary/CMakeLists.txt;hb=v2.8.10.2#l22 I just updated the documentation to note this suggestion: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=51988a4f Searched the build tree, it generated two libs with _obj. ./test.build/Debug/a_obj.build/Objects-normal/liba_obj.a ./test.build/Debug/b_obj.build/Objects-normal/libb_obj.a Xcode treats object files as intermediate products rather than first-class so the only way to implement the compilation part of object libraries is to pretend they are static libraries and then hide the .a files away where no one should be bothered by them. Ignore those. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AC_C_RESTRICT
On 1/4/2013 9:24 AM, Mateusz Loskot wrote: Bill, It tests if C compiler supports C99 restrict keyword, perhaps also implementation-specific form, e.g. __restrict, etc. [1]http://en.wikipedia.org/wiki/Restrict Should be able to do it with a CheckCSourceCompiles: http://www.cmake.org/cmake/help/v2.8.10/cmake.html#module:CheckCSourceCompiles -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] AC_C_RESTRICT
On 4 January 2013 14:46, Bill Hoffman bill.hoff...@kitware.com wrote:
On 1/4/2013 9:24 AM, Mateusz Loskot wrote:
It tests if C compiler supports C99 restrict keyword,
perhaps also implementation-specific form, e.g. __restrict, etc.
[1]http://en.wikipedia.org/wiki/Restrict
Should be able to do it with a CheckCSourceCompiles:
http://www.cmake.org/cmake/help/v2.8.10/cmake.html#module:CheckCSourceCompiles
Yup:
CHECK_C_SOURCE_COMPILES (
int test (void *restrict x); int main (void) {return 0;}
HAVE_RESTRICT)
Lots of examples available:
https://github.com/pjanouch/aapng/blob/master/CMakeLists.txt
https://bitbucket.org/poulson/clique/src/ca43759adbe4/external/elemental/CMakeLists.txt
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
--
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] AC_C_RESTRICT
Am Freitag, 4. Januar 2013 um 14:59:23, schrieb Mateusz Loskot
mate...@loskot.net
On 4 January 2013 14:46, Bill Hoffman bill.hoff...@kitware.com wrote:
On 1/4/2013 9:24 AM, Mateusz Loskot wrote:
It tests if C compiler supports C99 restrict keyword,
perhaps also implementation-specific form, e.g. __restrict, etc.
[1]http://en.wikipedia.org/wiki/Restrict
Should be able to do it with a CheckCSourceCompiles:
http://www.cmake.org/cmake/help/v2.8.10/cmake.html#module:CheckCSourceCompiles
Yup:
CHECK_C_SOURCE_COMPILES (
int test (void *restrict x); int main (void) {return 0;}
HAVE_RESTRICT)
I implemented it now this way (used the autoconf macro as guide :
# Check for restrict keyword
# Builds the macro A_C_RESTRICT form automake
foreach(ac_kw __restrict __restrict__ _Restrict restrict)
check_cxx_source_compiles(
typedef int * int_ptr;
int foo (int_ptr ${ac_kw} ip) {
return ip[0];
}
int main(){
int s[1];
int * ${ac_kw} t = s;
t[0] = 0;
return foo(t);
}
RESTRICT)
if(RESTRICT)
set(ac_cv_c_restrict ${ac_kw})
break()
endif()
endforeach()
if(RESTRICT)
add_definitions(-Drestrict=${ac_cv_c_restrict})
else()
add_definitions(-Drestrict=)
endif()
Thanks to all replies.
Kornel
signature.asc
Description: This is a digitally signed message part.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake absolute paths with gcc, __FILE__ , and logging
2013/1/4 Willy Lambert lambert.wi...@gmail.com: Hi all, Short Story : I am trying to convert an existing project from Manual Makefiles to Cmake for building it. We have a logger that rely on the __FILE__ define to say which file is writing into the log but this is broken by the CMake default behavior using absolute paths. So I wonder if there is any way to have the file name in the code to be able to log Error : line XXX in file.cpp. Long Story : So I have for instance a source /home/me/src/main.cpp, compiled with relative paths gcc -o main.cpp. So the logger say Error : line XXX in main.cpp. Going further, if I have a file dummy.hpp included from main.cpp that have for any reason an inlined function that log something, it will say Error : line YYYin dummy.hpp from main.cpp. This is due to the fact that gcc plays with __FILE__ behind the scene. What defines the __FILE__ value is the path given to the preprocessor (so the one given to gcc, so the one given by the makefile generated by CMake). So now I have something like : Error : line XXX in /home/me/src/main.cpp which is very anoying because : 1/ it reduces lisibility 2/ it show a wrong path when the project is on another machine. I tried to use the suggested trigger set_source_files_properties to define my own __FILE__ but it doesn't works with included files (it shows main.cpp instead oh dummy.hpp) http://www.cmake.org/pipermail/cmake/2011-December/048281.html So this way is a dead end because the compilator (and the one that creates its command line) is the only one to be aware of this information. Beside that, as I would really like to simplify the VERBOSE=2 make output to be able to debug what CMake generates I currently have plenty of path with 20 or more folder level including many ../.., I am looking on making CMake giving relatives paths to gcc. I have seen some thread about the use of CMAKE_USE_RELATIVE_PATHS, but it seems that it is not working, and maybe with no will to support this (is that true ?) http://cmake.3232098.n2.nabble.com/CMAKE-USE-RELATIVE-PATHS-td4042914.html for completeness : http://public.kitware.com/Bug/view.php?id=12563 I'm under linux, is this just a problem under MSVC ? Does anyone have succeeded with relatives path in 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] Cmake absolute paths with gcc, __FILE__ , and logging
Hi,
On Fri, Jan 04, 2013 at 11:47:40AM -0500, cmake-requ...@cmake.org wrote:
Date: Fri, 4 Jan 2013 16:58:05 +0100
From: Willy Lambert lambert.wi...@gmail.com
Hi all,
Short Story :
I am trying to convert an existing project from Manual Makefiles to
Cmake for building it.
We have a logger that rely on the __FILE__ define to say which file is
writing into the log but this is broken by the CMake default
behavior using absolute paths.
So I wonder if there is any way to have the file name in the code to
be able to log Error : line XXX in file.cpp.
Long Story :
So I have for instance a source /home/me/src/main.cpp, compiled with
relative paths gcc -o main.cpp.
So the logger say Error : line XXX in main.cpp.
I'm afraid given the discussion at
Short form of __FILE__
http://bytes.com/topic/c/answers/453661-short-form-__file__
the onus is on your project since it seems to be relying on
seemingly rather volatile (non-standardized) behaviour of the __FILE__ macro
(compilers seem to be free to pass on either a file's basename only
or a relative path or even a FQPN).
And now that one is using a CMake build which needs to do builds from
an entirely separate binary tree referencing source files in a
foreign source tree (thus having a justified reason for needing to
specify paths in full), these improper assumptions in your project
seem to fall flat on their face, since gcc chooses to prefer to pass on
as much information to the __FILE__ macro as it can get
about the file location (i.e., full path).
Since the problem is thus firmly located on the source code side
(i.e. its assumptions about __FILE__),
I'd suggest treating the problem right there,
using e.g. the discussion's strrchr() solution
(workaround?) to achieve a slightly improved guarantee of gaining
sufficiently constant output format (but note that Keith Thompson noted
that the C language itself does not have any business dealing with path
separator definitions).
I tried to use the suggested trigger set_source_files_properties to
define my own __FILE__ but it doesn't works with included files (it
shows main.cpp instead oh dummy.hpp)
http://www.cmake.org/pipermail/cmake/2011-December/048281.html
So this way is a dead end because the compilator (and the one that
creates its command line) is the only one to be aware of this
information.
Beside that, as I would really like to simplify the VERBOSE=2 make
output to be able to debug what CMake generates I currently have
plenty of path with 20 or more folder level including many ../.., I
am looking on making CMake giving relatives paths to gcc.
I guess the problem is that CMake is operating from a separate binary
tree as its base,
thus it obviously needs to pass full paths to the source files to the compiler,
to get to the other source dir over there.
The alternative would be to have cwd set to the source tree directory
when launching gcc, to be able to specify source file arguments
as file-only
(the -o object file argument however should be able to support full paths
without any negative effects, right?).
I have seen some thread about the use of CMAKE_USE_RELATIVE_PATHS, but
it seems that it is not working, and maybe with no will to support
this (is that true ?)
http://cmake.3232098.n2.nabble.com/CMAKE-USE-RELATIVE-PATHS-td4042914.html
I'm actually rather interested in CMAKE_USE_RELATIVE_PATHS myself,
since I'd like to be able to generate a (semi-static) subset of Visual Studio
projects
for permanently adding them to an existing static .sln
(this use case would probably be termed CMake abuse by Kitware :).
Using CMake for this purpose rather than having to create a couple dozen
custom targets manually (which directly translates into creating
a couple dozen project files manually)
-- and the painful challenge of *updating* them manually and consistently! --
seems like a nice and thus rather justified alternative.
Since there's already a (verified working!) possibility
(CACHE var target_GUID_CMAKE)
to have CMake (re-)use a *static* (known) project GUID
rather than recreating a random one, inclusion in existing .sln:s
(with a requirement of project GUIDs unchanged) would not be a problem
there at least.
I was rather bewildered as well about the impression that
CMAKE_USE_RELATIVE_PATHS is expected to remain (semi-)broken.
For people who knowingly want to attempt producing semi-static (SCM-committed)
project files rather than fully machine-introspected specifically-pathed
*temporary* project files, CMAKE_USE_RELATIVE_PATHS
(and possibly avoidance of manual reference to ${CMAKE_PROGRAM} expressions,
to try to even avoid any CMake dependency at all) would be very useful.
Does anyone have succeeded with relatives path in CMake ?
On my recent VS10 experiments, IIRC I ended up with several absolute
paths in project files despite having activated CMAKE_USE_RELATIVE_PATHS.
I'm rather tempted to start improving on this situation
once some of my other CMake work
Re: [CMake] Cmake absolute paths with gcc, __FILE__ , and logging
Hello Willy,
On 1/4/13 4:58 PM, Willy Lambert wrote:
I am trying to convert an existing project from Manual Makefiles to
Cmake for building it.
We have a logger that rely on the __FILE__ define to say which file is
writing into the log but this is broken by the CMake default
behavior using absolute paths.
So I wonder if there is any way to have the file name in the code to
be able to log Error : line XXX in file.cpp.
This is somewhat hackish and should be surrounded by a check for the
Makefile generator:
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -D__FILENAME__='\$(subst
${CMAKE_SOURCE_DIR}/,,$(abspath $))\')
Thanks,
Gregor
--
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] How to set the default compiler on windows ?
Hello, I would like set the default compiler as mingw for cmake. Now, If I try to use cmake from windows command line like below. Cmake CMakeList. I have the a output such as attachement. Can you help me please. Best regards mparchet CMake Warning at CMakeLists.txt:1 (project): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. -- The C compiler identification is unknown -- The CXX compiler identification is unknown -- Check for working C compiler: cl CMake Warning at CMakeLists.txt:2 (PROJECT): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. CMake Error: your C compiler: cl was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name. CMake Error: Internal CMake error, TryCompile configure of cmake failed -- Check for working C compiler: cl -- broken CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler cl is not able to compile a simple test program. It fails with the following output: CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:1 (project) CMake Error: your C compiler: cl was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name. CMake Error: your CXX compiler: cl was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name. -- Configuring incomplete, errors occurred! -- 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 issue compiling CLucene
During several days I am trying to compile CLucene on Windows 7 64 bit without success. I searched all over the internet but did not find a solution for my problem. I will describe all steps which I took and hope somebody can help me further. I downloaded CLucene and extracted it to the folder C:/Users/Gerda/Downloads/clucene-core-2.3.3.4/clucene-core-2.3.3.4 I created the out of source build directory C:/CLucene I installed boost 1.40 using the binary installer from boostpro computing I installed Cmake 2.8.10 I started a regular windows command line prompt and entered set BOOST_BUILD_PATH=C:\Program Files (x86)\boost\boost_1_40\tools\build\v2 set BOOST_PATH=C:\Program Files (x86)\boost set BOOST_ROOT=C:\Program Files (x86)\boost\boost_1_40 I start cmake Gui and set the folders to the ones I mentioned in 1 and 2. I select Microsoft Visual Studio 9 compiler. After clicking configure I get the following error message: CMake Error: CMake was unable to find a build program corresponding to Visual Studio 9 2008. CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. CMake Error: Could not find cmake module file:C:/CLucene/CMakeFiles/2.8.10.2/CMakeCCompiler.cmake CMake Error: Could not find cmake module file:C:/CLucene/CMakeFiles/2.8.10.2/CMakeCXXCompiler.cmake Configuring incomplete, errors occurred! I have the same issue with other compilers including the VS 9 64 bit compiler. Thanks in advance -- View this message in context: http://cmake.3232098.n2.nabble.com/Cmake-issue-compiling-CLucene-tp7582775.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake issue compiling CLucene
Don't use a Regular Command Prompt. Use instead one of the Visual Studio 9 Command Prompt that are provided with a normal Visual Studio installation. Those command prompts have all the necessary paths setup for Visual Studio. This also assumes you have Visual Studio 9 installed and not Visual Studio 8 or 10 and are just getting confused about which one to pick. -- Mike Jackson www.bluequartz.net On Jan 4, 2013, at 5:34 PM, Hatchi wrote: During several days I am trying to compile CLucene on Windows 7 64 bit without success. I searched all over the internet but did not find a solution for my problem. I will describe all steps which I took and hope somebody can help me further. I downloaded CLucene and extracted it to the folder C:/Users/Gerda/Downloads/clucene-core-2.3.3.4/clucene-core-2.3.3.4 I created the out of source build directory C:/CLucene I installed boost 1.40 using the binary installer from boostpro computing I installed Cmake 2.8.10 I started a regular windows command line prompt and entered set BOOST_BUILD_PATH=C:\Program Files (x86)\boost\boost_1_40\tools\build\v2 set BOOST_PATH=C:\Program Files (x86)\boost set BOOST_ROOT=C:\Program Files (x86)\boost\boost_1_40 I start cmake Gui and set the folders to the ones I mentioned in 1 and 2. I select Microsoft Visual Studio 9 compiler. After clicking configure I get the following error message: CMake Error: CMake was unable to find a build program corresponding to Visual Studio 9 2008. CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. CMake Error: Could not find cmake module file:C:/CLucene/CMakeFiles/2.8.10.2/CMakeCCompiler.cmake CMake Error: Could not find cmake module file:C:/CLucene/CMakeFiles/2.8.10.2/CMakeCXXCompiler.cmake Configuring incomplete, errors occurred! I have the same issue with other compilers including the VS 9 64 bit compiler. Thanks in advance -- View this message in context: http://cmake.3232098.n2.nabble.com/Cmake-issue-compiling-CLucene-tp7582775.html Sent from the CMake mailing list archive at Nabble.com. -- 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] Cmake issue compiling CLucene
On 1/4/2013 5:47 PM, Michael Jackson wrote: Don't use a Regular Command Prompt. Use instead one of the Visual Studio 9 Command Prompt that are provided with a normal Visual Studio installation. Those command prompts have all the necessary paths setup for Visual Studio. This also assumes you have Visual Studio 9 installed and not Visual Studio 8 or 10 and are just getting confused about which one to pick. -- You should not have to start from a VS command prompt if you are using the IDE to build. You only need to do that if you are using command line tools. Do you have VS 9 installed? Sounds like cmake can not find devenv. How did you install VS, and what version is it? -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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] (no subject)
Hello, I would like set the default compiler as mingw for cmake. Now, If I try to use cmake from windows command line like below. Cmake CMakeList. I have the a output such as attachement. Can you help me please. Best regards mparchet CMake Warning at CMakeLists.txt:1 (project): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. -- The C compiler identification is unknown -- The CXX compiler identification is unknown -- Check for working C compiler: cl CMake Warning at CMakeLists.txt:2 (PROJECT): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. CMake Error: your C compiler: cl was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name. CMake Error: Internal CMake error, TryCompile configure of cmake failed -- Check for working C compiler: cl -- broken CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler cl is not able to compile a simple test program. It fails with the following output: CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:1 (project) CMake Error: your C compiler: cl was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name. CMake Error: your CXX compiler: cl was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name. -- Configuring incomplete, errors occurred! -- 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] Ralph Barth/AEH/DBS/GDB ist außer Haus. Original subject: 'CMake Digest, Vol 105, Issue 10'
Ralph Barth will be out of the office starting 05.01.2013 and will be returning on 24.01.2013. Ich werde Ihre Nachrichten nach meiner Rückkehr beantworten. WLLM related questions pls. contact Sebastian Neusüß and Jens Keil. Theo Price Feed from EDRE pls contact Jens Keil - Deutsche Börse AG Chairman of the Supervisory Board/ Vorsitzender des Aufsichtsrats: Dr. Joachim Faber Executive Board/Vorstand: Dr. Reto Francioni (Chief Executive Officer/Vorsitzender), Andreas Preuss (Deputy Chief Executive Officer/ stellv. Vorsitzender), Frank Gerstenschläger, Gregor Pottmeyer, Hauke Stars, Jeffrey Tessler. Aktiengesellschaft with registered seat in/mit Sitz in Frankfurt am Main. Commercial register/Handelsregister: Local court/Amtsgericht Frankfurt am Main HRB 32232. - Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen. Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet. The information contained in this message is confidential or protected by law. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited. Legally required information for business correspondence/ Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz: http://deutsche-boerse.com/letterhead -- 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.10.2-1374-g9deb8e8
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 9deb8e8d68354b99b088c53af860cc6f5a78555b (commit)
via 3f6fa6a4021fc21888c887f6d949a62ae85ac82c (commit)
from 1d63c31d9875a89c12eacf8e0cb77cb83aa66336 (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=9deb8e8d68354b99b088c53af860cc6f5a78555b
commit 9deb8e8d68354b99b088c53af860cc6f5a78555b
Merge: 1d63c31 3f6fa6a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Jan 4 06:42:27 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Jan 4 06:42:27 2013 -0500
Merge topic 'test-genex-custom-command' into next
3f6fa6a Don't add INCLUDE_DIRECTORIES from the target to the command line.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f6fa6a4021fc21888c887f6d949a62ae85ac82c
commit 3f6fa6a4021fc21888c887f6d949a62ae85ac82c
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Jan 4 12:40:14 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Fri Jan 4 12:40:14 2013 +0100
Don't add INCLUDE_DIRECTORIES from the target to the command line.
The INCLUDE_DIRECTORIES contains generator expressions which do not
get expanded. It is enough to test that the generator expression
for the COMPILE_DEFINITIONS works.
diff --git a/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
b/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
index 338af58..3044abd 100644
--- a/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
+++ b/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
@@ -48,7 +48,6 @@ set_property(TARGET TargetIncludeDirectories
add_custom_target(test_custom_target
some_bogus_custom_tool
-$TARGET_PROPERTY:TargetIncludeDirectories,INCLUDE_DIRECTORIES
$TARGET_PROPERTY:TargetIncludeDirectories,COMPILE_DEFINITIONS
WORKING_DIRECTORY
${CMAKE_CURRENT_SOURCE_DIR})
---
Summary of changes:
.../TargetIncludeDirectories/CMakeLists.txt|1 -
1 files changed, 0 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.10.2-1376-gc78fd21
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 c78fd215938b0744667631a35fea0835b3c72d0b (commit) via 51988a4f91c6c6a4b91eedfb5010fdbc57b71891 (commit) from 9deb8e8d68354b99b088c53af860cc6f5a78555b (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=c78fd215938b0744667631a35fea0835b3c72d0b commit c78fd215938b0744667631a35fea0835b3c72d0b Merge: 9deb8e8 51988a4 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Jan 4 09:41:01 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Fri Jan 4 09:41:01 2013 -0500 Merge topic 'doc-Xcode-obj-lib-workaround' into next 51988a4 add_library: Document object library portability suggestion http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=51988a4f91c6c6a4b91eedfb5010fdbc57b71891 commit 51988a4f91c6c6a4b91eedfb5010fdbc57b71891 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Jan 4 09:38:22 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Fri Jan 4 09:38:22 2013 -0500 add_library: Document object library portability suggestion Xcode and VS = 7.1 will not build targets that have no source files besides $TARGET_OBJECTS: Suggest in the documentation that projects always add at least one real source file. diff --git a/Source/cmAddLibraryCommand.h b/Source/cmAddLibraryCommand.h index c144565..e5f27cb 100644 --- a/Source/cmAddLibraryCommand.h +++ b/Source/cmAddLibraryCommand.h @@ -134,6 +134,10 @@ public: They may contain custom commands generating such sources, but not PRE_BUILD, PRE_LINK, or POST_BUILD commands. Object libraries cannot be imported, exported, installed, or linked. + + Some native build systems may not like targets that have only + object files, so consider adding at least one real source file + to any target that references $TARGET_OBJECTS:objlib. ; } --- Summary of changes: Source/cmAddLibraryCommand.h |4 1 files changed, 4 insertions(+), 0 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.10.2-1390-gc5dc507
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 c5dc50768e4cf1d1b0a57ae5e42da1c08660db65 (commit)
via 258a94847d1f0cb83cb8f08ae4e4b679ee6257a4 (commit)
from 02a5246066fe1c90a5aa3fdc82cc02221443a0f9 (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=c5dc50768e4cf1d1b0a57ae5e42da1c08660db65
commit c5dc50768e4cf1d1b0a57ae5e42da1c08660db65
Merge: 02a5246 258a948
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Jan 4 19:04:46 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Jan 4 19:04:46 2013 -0500
Merge topic 'interface-includes-defines' into next
258a948 Style fix.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=258a94847d1f0cb83cb8f08ae4e4b679ee6257a4
commit 258a94847d1f0cb83cb8f08ae4e4b679ee6257a4
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sat Jan 5 01:04:10 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Sat Jan 5 01:04:10 2013 +0100
Style fix.
diff --git a/Source/cmGeneratorExpression.cxx b/Source/cmGeneratorExpression.cxx
index b6dc1a9..6d003e1 100644
--- a/Source/cmGeneratorExpression.cxx
+++ b/Source/cmGeneratorExpression.cxx
@@ -251,9 +251,9 @@ std::string cmGeneratorExpression::Preprocess(const
std::string input,
return stripAllGeneratorExpressions(input);
}
else if (context == BuildInterface || context == InstallInterface)
- {
+{
return stripExportInterface(input, context);
- }
+}
assert(!cmGeneratorExpression::Preprocess called with invalid args);
return std::string();
---
Summary of changes:
Source/cmGeneratorExpression.cxx |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.10.2-1403-g6d2c1fc
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 6d2c1fc986d802559d56e238bf444d65769214a5 (commit)
via a3d64fd12de34541baa6de31e40600ee9d50bc68 (commit)
from ffcddb8d3dd1ac85cab2e18e43cd4cc14fff6fdd (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=6d2c1fc986d802559d56e238bf444d65769214a5
commit 6d2c1fc986d802559d56e238bf444d65769214a5
Merge: ffcddb8 a3d64fd
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Jan 4 19:17:20 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Jan 4 19:17:20 2013 -0500
Merge topic 'interface-includes-defines' into next
a3d64fd Style fix.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3d64fd12de34541baa6de31e40600ee9d50bc68
commit a3d64fd12de34541baa6de31e40600ee9d50bc68
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sat Jan 5 01:16:13 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Sat Jan 5 01:16:13 2013 +0100
Style fix.
diff --git a/Source/cmExportFileGenerator.cxx b/Source/cmExportFileGenerator.cxx
index 139aba3..2b133be 100644
--- a/Source/cmExportFileGenerator.cxx
+++ b/Source/cmExportFileGenerator.cxx
@@ -143,11 +143,11 @@ void
cmExportFileGenerator::PopulateInterfaceProperty(const char *propName,
}
std::string prepro = cmGeneratorExpression::Preprocess(input,
- preprocessRule);
+ preprocessRule);
if (!prepro.empty())
{
this-ResolveTargetsInGeneratorExpressions(prepro, target,
-missingTargets);
+ missingTargets);
properties[outputName] = prepro;
}
}
---
Summary of changes:
Source/cmExportFileGenerator.cxx |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.10.2-1411-gc26a74c
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 c26a74cf300772f1e4eaeb0228531b23e3a5e228 (commit)
via 894f52f32d96ae92df0ba3dac2a70fe9c87e818d (commit)
via f5b1980fb27fa902d37856ec3e22daddfeb9d52f (commit)
via c67b8124f735e7f96567a276e16969607b300e43 (commit)
via d0f950fdba88ac08d0e25e340fe558eba008810e (commit)
via 26def1771dfbf502129212c9e728e34860477fac (commit)
via 0c657dc637ca4da6861102c7306069ad157ec08d (commit)
via e04f737c7a3e66c49e2d50813af1fa40a415eff8 (commit)
from 6d2c1fc986d802559d56e238bf444d65769214a5 (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=c26a74cf300772f1e4eaeb0228531b23e3a5e228
commit c26a74cf300772f1e4eaeb0228531b23e3a5e228
Merge: 6d2c1fc 894f52f
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Jan 4 19:20:45 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Jan 4 19:20:45 2013 -0500
Merge topic 'interface-includes-defines' into next
894f52f Handle INTERFACE properties transitively for includes and defines.
f5b1980 Populate the ExportedTargets member early in GenerateMainFile
c67b812 Make cycles in target properties ignored, not an error.
d0f950f Use mapped config properties to evaluate $CONFIG
26def17 Make all relevant targets available in the genex context.
0c657dc Add API to populate INTERFACE properties in exported targets.
e04f737 Add API to extract target names from a genex string.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=894f52f32d96ae92df0ba3dac2a70fe9c87e818d
commit 894f52f32d96ae92df0ba3dac2a70fe9c87e818d
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sun Sep 23 13:45:17 2012 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Sat Jan 5 01:18:37 2013 +0100
Handle INTERFACE properties transitively for includes and defines.
Contextually, the behavior is as if the properties content from another
target is included in the string and then the result is evaluated.
diff --git a/Source/cmExportBuildFileGenerator.cxx
b/Source/cmExportBuildFileGenerator.cxx
index 3e9a9fd..9533319 100644
--- a/Source/cmExportBuildFileGenerator.cxx
+++ b/Source/cmExportBuildFileGenerator.cxx
@@ -52,6 +52,8 @@ bool
cmExportBuildFileGenerator::GenerateMainFile(std::ostream os)
this-GenerateExpectedTargetsCode(os, expectedTargets);
}
+ std::vectorstd::string missingTargets;
+
// Create all the imported targets.
for(std::vectorcmTarget*::const_iterator
tei = allTargets.begin();
@@ -59,8 +61,21 @@ bool
cmExportBuildFileGenerator::GenerateMainFile(std::ostream os)
{
cmTarget* te = *tei;
this-GenerateImportTargetCode(os, te);
+
+ImportPropertyMap properties;
+
+this-PopulateInterfaceProperty(INTERFACE_INCLUDE_DIRECTORIES, te,
+cmGeneratorExpression::BuildInterface,
+properties, missingTargets);
+this-PopulateInterfaceProperty(INTERFACE_COMPILE_DEFINITIONS, te,
+cmGeneratorExpression::BuildInterface,
+properties, missingTargets);
+
+this-GenerateInterfaceProperties(te, os, properties);
}
+ this-GenerateMissingTargetsCheckCode(os, missingTargets);
+
// Generate import file content for each configuration.
for(std::vectorstd::string::const_iterator
ci = this-Configurations.begin();
diff --git a/Source/cmExportInstallFileGenerator.cxx
b/Source/cmExportInstallFileGenerator.cxx
index 2b7937e..bc953c9 100644
--- a/Source/cmExportInstallFileGenerator.cxx
+++ b/Source/cmExportInstallFileGenerator.cxx
@@ -69,6 +69,8 @@ bool
cmExportInstallFileGenerator::GenerateMainFile(std::ostream os)
this-GenerateExpectedTargetsCode(os, expectedTargets);
}
+ std::vectorstd::string missingTargets;
+
// Create all the imported targets.
for(std::vectorcmTarget*::const_iterator
tei = allTargets.begin();
@@ -76,8 +78,23 @@ bool
cmExportInstallFileGenerator::GenerateMainFile(std::ostream os)
{
cmTarget* te = *tei;
this-GenerateImportTargetCode(os, te);
+
+ImportPropertyMap properties;
+
+this-PopulateInterfaceProperty(INTERFACE_INCLUDE_DIRECTORIES,
+ te,
+ cmGeneratorExpression::InstallInterface,
+ properties, missingTargets);
+this-PopulateInterfaceProperty(INTERFACE_COMPILE_DEFINITIONS,
+ te,
+
[Cmake-commits] CMake branch, master, updated. v2.8.10.2-367-g0c1f291
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, master has been updated via 0c1f291a27e3916a62c66d48b37b21e0e5d3ce6e (commit) from 95b74cafed4ba7ce572dc03b11e72d902f4df7ca (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=0c1f291a27e3916a62c66d48b37b21e0e5d3ce6e commit 0c1f291a27e3916a62c66d48b37b21e0e5d3ce6e Author: Kitware Robot kwro...@kitware.com AuthorDate: Sat Jan 5 00:01:14 2013 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Sat Jan 5 00:01:14 2013 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 370c76b..17b2b25 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 10) -set(CMake_VERSION_TWEAK 20130104) +set(CMake_VERSION_TWEAK 20130105) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 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.10.2-1414-gecbc48c
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 ecbc48c2394fbd62e48573f5771b3fd2de999054 (commit)
via 76c44309717adf25ebe5892adc3b4181766868a9 (commit)
via 0c1f291a27e3916a62c66d48b37b21e0e5d3ce6e (commit)
from c26a74cf300772f1e4eaeb0228531b23e3a5e228 (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=ecbc48c2394fbd62e48573f5771b3fd2de999054
commit ecbc48c2394fbd62e48573f5771b3fd2de999054
Merge: c26a74c 76c4430
Author: Peter Kuemmel syntheti...@gmx.net
AuthorDate: Sat Jan 5 02:35:43 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Jan 5 02:35:43 2013 -0500
Merge topic 'ninja-codeblocks-gui' into next
76c4430 Ninja: fix building from Codeblocks GUI
0c1f291 CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76c44309717adf25ebe5892adc3b4181766868a9
commit 76c44309717adf25ebe5892adc3b4181766868a9
Author: Peter Kümmel syntheti...@gmx.net
AuthorDate: Sat Jan 5 08:29:58 2013 +0100
Commit: Peter Kümmel syntheti...@gmx.net
CommitDate: Sat Jan 5 08:29:58 2013 +0100
Ninja: fix building from Codeblocks GUI
Many thx to Chuck Frayman
BUG: 13652
diff --git a/Source/cmExtraCodeBlocksGenerator.cxx
b/Source/cmExtraCodeBlocksGenerator.cxx
index 25b13e5..0cf9cbb 100644
--- a/Source/cmExtraCodeBlocksGenerator.cxx
+++ b/Source/cmExtraCodeBlocksGenerator.cxx
@@ -811,6 +811,11 @@ std::string cmExtraCodeBlocksGenerator::BuildMakeCommand(
command += VERBOSE=1 ;
command += target;
}
+ else if (strcmp(this-GlobalGenerator-GetName(), Ninja)==0)
+{
+command += -v ;
+command += target;
+}
else
{
std::string makefileName = cmSystemTools::ConvertToOutputPath(makefile);
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
Source/cmExtraCodeBlocksGenerator.cxx |5 +
2 files changed, 6 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
