Re: [cmake-developers] CheckSymbolExists is unreliable
Brad King wrote: Can you handle Modules/CheckPrototypeDefinition.cmake too? I think it has the same problem. I have looked into this and I don't think it has. The subject of this thing is to provoke a compile error if the prototype doesn't match. And it even introduced the symbol _itself_, so it could even fail if you would provide the correct libraries the symbol is in using CMAKE_REQUIRED_LIBRARIES. So for me it looks like it could have the optimization problem, but that wouldn't be a problem here as the symbol itself is not what we are interested in at that point. But it's usage of CMAKE_REQUIRED_LIBRARIES is completely wrong in my eyes as it could make the test actually fail when it should be successful. It shouldn't use any libraries at all IMHO. And even then it could go wrong when you reintroduce a symbol from the standard libraries, which could cause an error in the linker because of duplicate symbols. Or one would have to drop the newly introduced symbol in this file at all, using _only_ the symbol from the provided libraries. And then we would have the optimization problem, but if that is solved the whole thing can be made reliable at all. So I will go and fix some small typos I've found in the existing tests, repush and merge to next, so we see if Check*SymbolExists will work. This one needs rework, too, but that should go into a separate topic. Opinions? Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CheckSymbolExists is unreliable
On 1/5/2012 4:47 AM, Rolf Eike Beer wrote: Brad King wrote: Can you handle Modules/CheckPrototypeDefinition.cmake too? I think it has the same problem. I have looked into this and I don't think it has. Okay. As you said the concerns with that one are another topic. So I will go and fix some small typos I've found in the existing tests, repush and merge to next, so we see if Check*SymbolExists will work. Sounds good. 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] CheckPrototypeDefinition concerns
On 1/5/2012 4:47 AM, Rolf Eike Beer wrote: Brad King wrote: Can you handle Modules/CheckPrototypeDefinition.cmake too? I think it has the same problem. I have looked into this and I don't think it has. The subject of this thing is to provoke a compile error if the prototype doesn't match. And it even introduced the symbol _itself_, so it could even fail if you would provide the correct libraries the symbol is in using CMAKE_REQUIRED_LIBRARIES. [snip] But it's usage of CMAKE_REQUIRED_LIBRARIES is completely wrong in my eyes as it could make the test actually fail when it should be successful. It shouldn't use any libraries at all IMHO. And even then it could go wrong when you reintroduce a symbol from the standard libraries, which could cause an error in the linker because of duplicate symbols. Or one would have to drop the newly introduced symbol in this file at all, using _only_ the symbol from the provided libraries. And then we would have the optimization problem, but if that is solved the whole thing can be made reliable at all. I've CCed Andreas, the author of CheckPrototypeDefinition. Andreas, please see the above concerns Eike has raised about the module implementation. 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] libarchive upstream
On 1/3/2012 4:48 PM, Eric Noulard wrote: 3.0.2 does include the feature: Dec 24, 2011: libarchive 3.0.2 released Great. I started the update work less than a week before that ;) Let's wait for you to finish your experiment with 3.0.0-r3950 then may be the first application of your work may be the integration of 3.0.2 (or better depending on the work in-between). Sounds good. Please cherry-pick 41719b7507a70b0c098f652c96693ba7755b397f into the updated branch again and push this upstream, too. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] libarchive upstream
On 1/5/2012 10:05 AM, Rolf Eike Beer wrote: Please cherry-pick 41719b7507a70b0c098f652c96693ba7755b397f into the updated branch again and push this upstream, too. The libarchive-upstream branch must remain pristine w.r.t. upstream. Your fix is already in the update-libarchive topic: http://cmake.org/gitweb?p=cmake.git;a=commit;h=c37c0c78 There are several other fixes in the topic that should go upstream too. Some of them came from fixes to our previous libarchive snapshot and some of them are new. The new way to do the import (enabled by Git) will allow me to identify and extract all of them once the topic has matured. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Multiple fixup_bundle and cpack crash
Could anyone with appropriate knowledge of fixup_bundle internal have a look at this bug: http://public.kitware.com/Bug/view.php?id=12656 It may be windows specific. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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] Generate Xcode projects on a Windows environment
Le 04/01/12 16:16, Eric Noulard a écrit : However, a general rule with CMake is to consider that cmake itself becomes a requirement of your build system. With CMake (at least currently) the developer/user cannot work without CMake if the project (makefiles, IDE project files (Visual Studio, XCode, Eclipse) has been generated with it. see e.g. http://www.cmake.org/Wiki/CMake_FAQ#Why_does_CMake_use_full_paths.2C_or_can_I_copy_my_build_tree.3F or http://www.cmake.org/Bug/view.php?id=11095 Ok, thanks for your response and the links. It shows me another limitation using CMake the way I wanted to. It is clearer for me now. -- 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 force CMake install / CPack to create an empty directory.
Hi, thanks for the help! Vlado On Thu, Jan 5, 2012 at 5:53 AM, Fraser Hutchison fraser.hutchi...@googlemail.com wrote: Hi there, This looks like a single line deletion will fix it. I've added a note to the issue here: http://public.kitware.com/Bug/view.php?id=8767#c28187 - it's probably not worth a patch :-) Cheers, Fraser. On 04/01/2012 14:02, Eric Noulard wrote: 2012/1/4 Vladimir Jaksicvladimir.jak...@gmail.com: Hello, For the purposes of my project i need to create multiple empty directories where my exectuable is located, and I would like to include these directories in the .zip file. I have tried the following: -- ... INSTALL(TARGETS myproject DESTINATION .) INSTALL(DIRECTORY DESTINATION directory) - nothing happends SET(CPACK_GENERATOR ZIP) INCLUDE(CPack) --- but i cannot stick the empty directory inside, only way around i found was creating a dummy file. Is there any other way to to do this? Instruction here http://www.lcfg.org/doc/buildtools/cmake_recipes.html says to do exactly what i did, but it still did not work, has this changed in newer cmake versions? Is it still possible to do it? Looks like an unresolved, but nevertheless known, bug: http://public.kitware.com/Bug/view.php?id=8767 Note however that the problem seems to be with all Archive generators: STGZ TBZ2 TGZ TZ ZIP e.g. DEB and RPM do include the empty. This means that the empty dir is installed (in local CPack temp dir) but not packaged. -- 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] XCode generator hangs when writing build config.
On 4.1.2012. 17:05, David Cole wrote: What project are you running through CMake? Is it available for us to try to reproduce here? I've not heard of anything like this... Actually we've been bitten by this also: ever since 2.8.6 CMake would hang in the generate phase on OS X. However it only happened if/when we included the NT2 library so I wasn't sure whether this was due to a bug in CMake or NT2 CMake project files. It turns out it was the CMake issue Axel identified (we had both -g and -fno-objc-gc options in CMAKE_CXX_FLAGS). Thank you Axel for debugging this yourself so quickly! ;) kind regards, Domagoj Saric www.littleendian.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] XCode generator hangs when writing build config.
On 05/01/2012 01:56, David Cole wrote:
Wow. Nice, quick work.
Thanks for the patch. I'll get it applied and pushed to our 'next'
branch so this can get into the next release...
Thanks,
David
Hmmm. I've downloaded the source from SourceForge, but do not
reproduce the problem here simply by running cmake to
configure/generate. You must be setting the flags explicitly somehow?
(By hand, or with a script?)
You may need to checkout from sourceforge CVS, the tar ball is not that
recent.
Can you tell me exactly how to reproduce the problem so that I can
verify the fix works?
You may need to force your compiler to be gcc (clang or llvm)
I don't have the latter so I don't know whether they pass or not.
You see the logic of setting the compiler flags in
EASDIF_SDIF/SDIF/cmModules/SET_COMPILER_FLAGS.cmake
here
...
IF (GCCVERSIONMAJ EQUAL 4)
ADD_BT_COMPILER_FLAGS(RELEASE -finline-limit=5000 --param
large-function-insns=5000 --param large-function-growth=500 --param
inline-unit-growth=100)
So only gcc will trigger the problem
As far as I remember i did not have this machinery when I published the
last tar ball.
Please find attached a minimal example project (source tt.cc and
CMakeLists.txt) that trigger the problem.
Best
Axel
The ExtractFlags method was modified in this commit to remove
conflicting -g flags when multiple -g flags occur...
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cb22afc0
It's relatively recent and first appeared in 2.8.6 -- I want to make
sure that whatever fix goes in now also honors the intent of that
commit, which fixed http://public.kitware.com/Bug/view.php?id=12377
Thanks,
David
--
Axel Roebel
Head of the Analysis/Synthesis Team, IRCAM
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
// string::rfind
#include iostream
#include string
using namespace std;
int main ()
{
string str (The sixth sick sheik's sixth sheep's sick.);
string key (sixth);
size_t found;
found=str.rfind(key);
if (found!=string::npos)
str.replace (found,key.length(),seventh);
cout str endl;
return 0;
}
project(tt )
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} --param large-function-insns=5000
--param large-function-growth=500 --param inline-unit-growth=100)
add_executable(tt tt.cc)--
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] Problem with set_source_files_properties
I am using code
where f contains the file name
set(MY_PATH -D__RELATIVE_PATH__=\\\ab\\\)
set_source_files_properties(${f} PROPERTIES
COMPILE_FLAGS ${MY_PATH})
I am not able to see -D__RELATIVE_PATH__ inside compilation flags.
What is wrong ?
--
regards
Vivek Goel
--
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] kwstyle
hello, just installed cdash from svn and using ctest with valgrind and codecoverage(bullseye) = it's really great, thanks first of all. Now I would like to test kwstyle but I don't find any recent ctest script that illustrates it. I tried to look at the notes of the kwstyle build for cmake but there aren't any I think? Can someone maybe post one here? Thanks, Best regards Tom -- 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] Problem with set_source_files_properties
On 5 January 2012 12:31, vivek goel goelvivek2...@gmail.com wrote:
I am using code
where f contains the file name
set(MY_PATH -D__RELATIVE_PATH__=\\\ab\\\)
set_source_files_properties(${f} PROPERTIES
COMPILE_FLAGS ${MY_PATH})
I am not able to see -D__RELATIVE_PATH__ inside compilation flags.
You have read the 2nd paragraph of COMPILE_FLAGS section in manual, haven't you.
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] DeployQt4 example
On Wed, Jan 4, 2012 at 2:28 AM, noru...@me.com wrote: Does anyone have a working example for the new DeployQt4 module? I was just looking for the same thing and found this: http://mikemcquaid.com/2012/01/deploying-qt-applications-with-deployqt4/ James -- 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] DeployQt4 example
On Jan 5, 2012, at 11:30 AM, James Sutherland wrote: On Wed, Jan 4, 2012 at 2:28 AM, noru...@me.com wrote: Does anyone have a working example for the new DeployQt4 module? I was just looking for the same thing and found this: http://mikemcquaid.com/2012/01/deploying-qt-applications-with-deployqt4/ James -- Hopefully this will cut out a lot of extra CMake code I have to carry to each of my projects. I'll be trying this out pretty soon. Thanks for the module Mike. --- Mike Jackson -- 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] DeployQt4 example
Great thanks Am 05.01.2012 um 17:30 schrieb James Sutherland james.sutherl...@utah.edu: On Wed, Jan 4, 2012 at 2:28 AM, noru...@me.com wrote: Does anyone have a working example for the new DeployQt4 module? I was just looking for the same thing and found this: http://mikemcquaid.com/2012/01/deploying-qt-applications-with-deployqt4/ James -- 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] DeployQt4 example
On Thursday 05 January 2012, James Sutherland wrote: On Wed, Jan 4, 2012 at 2:28 AM, noru...@me.com wrote: Does anyone have a working example for the new DeployQt4 module? I was just looking for the same thing and found this: http://mikemcquaid.com/2012/01/deploying-qt-applications-with-deployqt4/ I added a link to the wiki: http://www.cmake.org/Wiki/CMake#How_to_use_CMake_with_specific_Libraries Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] problems with DeployQt4 ?
I am eager to use DeployQt4 because of the complexity of creating
applications.
This is a snippet of what I currently have:
-- snip
if( APPLE )
set(GUI_TYPE MACOSX_BUNDLE)
set( app_postfix .app )
set( plugin_dest_dir bin/${appName}${app_postfix}/Contents/MacOS)
set( qtconf_dest_dir bin/${appName}${app_postfix}/Contents/Resources)
set( MACOSX_BUNDLE_ICON_FILE appIcon.icns )
set_source_files_properties(
${CMAKE_CURRENT_SOURCE_DIR}/images/appIcon.icns PROPERTIES
MACOSX_PACKAGE_LOCATION Resource )
endif()
add_executable( ${appName} ${GUI_TYPE}
${util_src}
${gui_src}
${gui_headers}
${gui_headers_moc}
${gui_forms_headers}
${gui_resources_rcc}
)
target_link_libraries( ${appName} ${QT_LIBRARIES} )
install( TARGETS ${appName} COMPONENT Runtime DESTINATION bin )
include(CPack)
include( InstallRequiredSystemLibraries )
if( APPLE OR WIN32 )
# must have CMAKE 2.8.7 or later
string( COMPARE GREATER ${CMAKE_VERSION} 2.8.6 VERSION_OK )
if( ${VERSION_OK} )
include( DeployQt4 ) # requires cmake 2.8.7 or later
set( PLUGINS qico;qtiff;qsvgicon )
message( STATUS QT PLUGINS: ${QTPLUGINS} )
install_qt4_executable( bin/${appName}${app_postfix} ${PLUGINS} )
endif()
endif()
/snip ---
On my Mac, the install completes without errors, but the executable just
pops up a crash dialogue that doesn't mean anything to me.
One interesting observation is that the PLUGINS are not properly set in the
call to install_qt4_executable. Output from cmake:
-- fixup_qt4_executable
-- executable='/Users/james/tmp/expr/bin/CreateExpr_1.0-0.app'
-- qtplugins=''
-- libs=''
-- dirs='/opt/local/lib'
-- plugins_dir=''
-- request_qt_conf=''
-- Writing
/Users/james/tmp/expr/bin/CreateExpr_1.0-0.app/Contents/Resources/qt.conf
-- fixup_bundle
-- app='/Users/james/tmp/expr/bin/CreateExpr_1.0-0.app'
-- libs=''
-- dirs='/opt/local/lib'
I am confused at why qtplugins is empty. I have tried variations of how
I pass PLUGINS to the install_qt4_executable() function, but no joy.
Also, the installed app bundle has a few more things than the locally
built one, but is missing a Frameworks directory, for example.
Any ideas as to what I am doing wrong?
James
--
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] Wiki: version compatibility matrix
Hi David, This is great news! I have updated the matrix to use footnotes, and also added the 2.8.7 changes to it. The whole matrix now looks much more clearly: http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix Cheers, Johannes On Tuesday 03 January 2012 17:25:31 David Cole wrote: The Cite extension is now installed on the CMake wiki. See this page to see what mediawiki extensions are available: http://www.cmake.org/Wiki/Special:Version -- 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] Problem with set_source_files_properties
Using COMPILE_DEFINITIONS is also not working.
set(MY_PATH __RELATIVE_PATH__=ab)
set_source_files_properties(${f} PROPERTIES
COMPILE_DEFINITIONS ${MY_PATH})
On 1/5/12, Mateusz Loskot mate...@loskot.net wrote:
On 5 January 2012 12:31, vivek goel goelvivek2...@gmail.com wrote:
I am using code
where f contains the file name
set(MY_PATH -D__RELATIVE_PATH__=\\\ab\\\)
set_source_files_properties(${f} PROPERTIES
COMPILE_FLAGS ${MY_PATH})
I am not able to see -D__RELATIVE_PATH__ inside compilation flags.
You have read the 2nd paragraph of COMPILE_FLAGS section in manual, haven't
you.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
--
regards
Vivek Goel
--
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] error of mixed dynamic/static link to Boost in windows VS2008
Hi, I am writing a library using boost_regex. For the unit test part, I am using boost_unit_test_framework and needs to be dynamical linked. Everything worked great on Linux but not the Windows VS 2008. I used the BoostPro binary installer, got boost components like: boost_regex-vc90-mt-gd-1_47.dll and .lib, also the libboost_regex-vc90-mt-gd-1_47.lib file. After the FIND_PACKAGE(Boost Components ...) I got the boost_*-vc90-mt-gd-1_47.lib version, (no prefix lib), however, when I compile the unit test executable, it has an error fatal error LNK1104: cannot open file 'libboost_regex-vc90-mt-gd-1_47.lib' If I add its directory C:\Program Files\boost\boost_1_47\lib to the linker's Additional Library Directory in VS2008 everything went OK. My question is 1. Where this libboost* comes from ? all my CMake script are giving boost_* instead of libboost_* libraries. 2. When to set this linker directory so I do not need to add this manually in VS2008. Thanks. Forest. -- 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] Problem with set_source_files_properties
On 01/05/2012 02:42 PM, Mateusz Loskot wrote:
On 5 January 2012 12:31, vivek goel goelvivek2...@gmail.com wrote:
I am using code
where f contains the file name
set(MY_PATH -D__RELATIVE_PATH__=\\\ab\\\)
set_source_files_properties(${f} PROPERTIES
COMPILE_FLAGS ${MY_PATH})
I am not able to see -D__RELATIVE_PATH__ inside compilation flags.
You have read the 2nd paragraph of COMPILE_FLAGS section in manual, haven't
you.
Best regards,
Although COMPILE_FLAGS is not meant to specify definitions,
it usually works; look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
SET_SOURCE_FILES_PROPERTIES(main.c
PROPERTIES COMPILE_FLAGS -D__RELATIVE_PATH__=\\\ab\\\)
Make's output reveals:
.../gcc -D__RELATIVE_PATH__=\ab\ -o .../main.c.o -c .../main.c
Vivek, perhaps a mistake with regard to the variable f? BTW, note
that the COMPILE_DEFINITIONS properties take account for proper
escaping and then some; the COMPILE_FLAGS ones don't, AFAIK.
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
Re: [CMake] Interrupt problems in cmake-gui
On 12/31/2011 02:10 AM, Robert Dailey wrote: I'd like to introduce boost into CMake for this. Whenever I've advocated CMake as build system, one of the strongest selling points has been its self-sufficiency, i.e. the fact that it does not have any external dependencies except for a C++ environment. IMO, each further dependency on external packages - be it Boost, be it Qt or what ever - would compromise CMake's chances to be preferred to other build systems. For this reason, I'd support Bill's position and recommend to be particularly conservative w.r.t. the introduction of additional dependencies into the CMake executable. 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
Re: [CMake] How to install then test?
On 12/29/2011 08:01 PM, Denis Scherbakov wrote:
Dear All!
Maybe someone can help me: I have a project, we compile binaries and then
using various INSTALL directives finish the job by copying files where they
belong: to bin, man, libexec, etc. The point is, we need to run
executables after they got installed into this tree, because otherwise
they won't find all auxiliary files during runtime.
So I am really missing the point here: how to install files (to a temporary
directory, for example) and then run various tests? Maybe someone has ideas...
Sincerely,
Denis
As an alternative to what Eric has already suggested, you might use
installation components or POST_BUILD custom commands to achieve a
temporary installation for testing purposes:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ENABLE_TESTING()
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
# Target main1:
ADD_EXECUTABLE(main1 main.c)
INSTALL(TARGETS main1 DESTINATION bin
COMPONENT main)
INSTALL(TARGETS main1 DESTINATION ${CMAKE_BINARY_DIR}/test/bin
COMPONENT test)
ADD_CUSTOM_TARGET(install.main ${CMAKE_COMMAND}
-DCOMPONENT=main -P ${CMAKE_BINARY_DIR}/cmake_install.cmake)
ADD_CUSTOM_TARGET(install.test ${CMAKE_COMMAND}
-DCOMPONENT=test -P ${CMAKE_BINARY_DIR}/cmake_install.cmake)
ADD_TEST(NAME main1
COMMAND ${CMAKE_BINARY_DIR}/test/bin/$TARGET_FILE_NAME:main1)
# Target main2:
ADD_EXECUTABLE(main2 main.c)
ADD_CUSTOM_COMMAND(TARGET main2 POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different
$TARGET_FILE:main2
${CMAKE_BINARY_DIR}/test/bin/$TARGET_FILE_NAME:main2)
INSTALL(TARGETS main2 DESTINATION bin)
ADD_TEST(NAME main2
COMMAND ${CMAKE_BINARY_DIR}/test/bin/$TARGET_FILE_NAME:main2)
For target main1, there're the installation components main and
test, each one triggered via a custom target as usual. Component
main does the regular installation, and component test installs
to a temporary location where the test main1 looks for the main1
executable. The downside of this approach is that the installation
components are part of the common install target - therefor the
additional install.main component - and you need to trigger the
install.test target before testing because of issue #8438, as
Eric has already pointed out.
The binary built by target main2 is copied to a temporary location
via a POST_BUILD custom command, so the test main2 is able to find
it there. Probably, this approach is less complicated than the first
one and won't compromise the common install target with additional
installation components, but you may lose the benefits of the quite
powerful INSTALL() command for the temporary installation.
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] CPack 2.8.7 RPM: hiding /etc/init.d from %files list
Hi everyone, I've been porting our commercial, in-house, unmaintainable Linux product build process to CMake. It's been remarkably easy, but now I've hit a hurdle. I need to produce an RPM that will install on both Red Hat 5 and Suse 11. For political reasons I can't produce two distinct RPMs. The executables are all happily statically linked so there isn't a problem with differing libraries. The problem is that there is an init script in my product, which wants to go into /etc/init.d/mydaemon. On Red Hat, /etc/init.d is a symlink to /etc/rc.d/init.d, and on Suse, /etc/rc.d/init.d is a symlink to /etc/init.d. (Swift's big-endians and little-endians have nothing on the arbitrariness of this.) Packing with CPack 2.8.7's RPM generator wants to insert /etc/init.d into the %files list. The resulting RPM will install on Suse, but on Red Hat, you get: file /etc/init.d from install of myproduct-1-1.x86_64 conflicts with file from package chkconfig-1.3.30.2-2.el5.x86_64 Naturally, from the symmetry of the situation, if I put my init script in /etc/rc.d/init.d/daemon, I get an RPM that installs on Red Hat but doesn't install on Suse. From a ton of googling, consensus seems to be that for directories that you know are on the target system, you don't have to list them in the %files list. I'm confident that /etc/init.d is in this category. This is where my subject line comes in: How do I prevent /etc/init.d from appearing in the %files list, when I have a file /etc/init.d/mydaemon that has to be packaged? The new CPACK_RPM_USER_FILELIST feature from CPack 2.8.7 *almost* works... SET(CPACK_RPM_daemoncomponent_USER_FILELIST /etc/init.d) ...only it gets added back in a different spot. Darn. I'd like to be able to say something like SET(CPACK_RPM_daemoncomponent_USER_FILELIST %ignore /etc/init.d) but I haven't found the right magic to use instead of %ignore. If there indeed is any magic. I've read the CPackRPM.cmake source and I can see how I can hack it to fix my immediate problem, but I'm not keen on hacks. If there's a Proper Way to do what I want then that's what I'll do. -- 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
