[CMake] help with variable usage in target_link_libraries
Hi there, using cmake-2.6.4-Linux-i386, I'd like to use set(LIBS lib1) set(LIBS $LIBS lib2) [...] set(LIBS $LIBS libN) target_link_libraries(target $LIBS) instead of writing explicitely target_link_libraries(target lib1 lib2 [...] libN) but while cmake gives no error messages, the library dependencies are not honored during link. I tried to vary the usage of ''s but to no avail. How to do it correctly? Thanks in advance, 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] help with variable usage in target_link_libraries
2009/8/31 Eike Kroemer eike-michael.kroe...@atlas-elektronik.com:
Hi there,
using cmake-2.6.4-Linux-i386, I'd like to use
set(LIBS lib1)
set(LIBS $LIBS lib2)
[...]
set(LIBS $LIBS libN)
target_link_libraries(target $LIBS)
instead of writing explicitely
target_link_libraries(target lib1 lib2 [...] libN)
but while cmake gives no error messages, the library dependencies are
not honored during link.
I tried to vary the usage of ''s but to no avail.
How to do it correctly?
Variable values shoud be retrieve with curly brace, i.e.
$LIBS -- ${LIBS}
Then when you have a list of something you usually use LIST(APPEND
LIST(APPEND LIBS libN)
even if
SET(LIBS ${LIBS} libN) should work as well.
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency in custom command?
On 31. Aug, 2009, at 7:08, King, Steven R wrote:
Can't you put all executables and shared libraries in one
directory, so they
are all local to each other?
In the top level CMakeLists.txt file just add
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
The executables you specify in ADD_TEST() will have a working
directory that
is ${CMAKE_CURRENT_BINARY_DIR}
Thanks Clint and Tyler and others for your patient help. The
consolidated binary directory didn't work.
I now put all my binaries and libraries in ${CMAKE_BINARY_DIR}/bin
as Clint suggested. This caused ctest to fail for lack of knowing
where the test binary went. I made this adjustment:
add_test(
test_my_module
${CMAKE_BINARY_DIR}/bin/test_my_module
)
This will only work on Unix like systems. Doesn't CTest figure out
that the program name is a target? I.e. doesn't this work (provided
you did add_executable(test_my_module ...)):
add_test(test_my_module test_my_module)
which allowed ctest to find the executable. However, the executable
still can't find the dll, since ctest runs the test from $
{CMAKE_CURRENT_BINARY_DIR} which is apparently not equal to $
{CMAKE_RUNTIME_OUTPUT_DIRECTORY}. As we've just belabored, putting
the dll in ${CMAKE_CURRENT_BINARY_DIR} is neither easy nor well
advised.
Well, how about passing the ${CMAKE_RUNTIME_OUTPUT_DIRECTORY} as an
argument to your test program, and then in the test program construct
the full path to the plugin library? Or as an alternative, configure a
source file defining the path to the CMAKE_RUNTIME_OUTPUT_DIRECTORY as
a variable:
CMakeLists.txt:
--8---
# construct the file name of the loadable module (could also use the
deprecated LOCATION property)
set(MODULE_PATH CMAKE_RUNTIME_OUTPUT_DIRECTORY/$
{CMAKE_SHARED_MODULE_PREFIX}my_module${CMAKE_SHARED_MODULE_SUFFIX})
file(TO_NATIVE ${MODULE_PATH} MODULE_PATH)
# configure the test source
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/test_my_module.c.in $
{CMAKE_CURRENT_BINARY_DIR}/test_my_module.c @ONLY)
# create the test executable
add_executable(test_my_module ${CMAKE_CURRENT_BINARY_DIR}/
test_my_module.c)
# add a test named test_my_module, running test_my_module
add_test(test_my_module test_my_module)
--8---
test_my_module.c.in:
--8--
/* TODO make this work cross-platform */
#include dlfcn.h
#define MODULE_PATH @MODULE_PATH@
int main() {
void* my_module = dlopen(MODULE_PATH, RTLD_NOW | RTLD_LOCAL);
/* whatever you want to do */
return 0;
}
--8---
OK, now I'm actually getting worried. Any other ideas, please?
I hope you get the idea from above...
Again my goal is to simply bring a dll and it's test program
together so they run happily ever after.
Thanks,
-steve
HTH
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] help with variable usage in target_link_libraries
Hi Eric,
Variable values shoud be retrieve with curly brace, i.e.
$LIBS -- ${LIBS}
Yick, I had done that but not cited it correctly in my mail, sorry about
that.
Then when you have a list of something you usually use LIST(APPEND
LIST(APPEND LIBS libN)
even if
SET(LIBS ${LIBS} libN) should work as well.
list(APPEND ...) does the trick (while set doesn't), thanks!
___
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] Issue with CPack and component installation
Thanks, I'll try the latest version this evening as soon as I'm back home from work. BTW, can you point me to the mainteiners / contributors of the PackageMaker? thanks again, toto -- Antonio Bulgheroni, PhD http://unico-lab.blogspot.com “There are 10 kinds of people. Those that understand binary and those that don’t.” On Mon, Aug 31, 2009 at 8:33 AM, Eric Noulard eric.noul...@gmail.comwrote: 2009/8/31 Antonio Bulgheroni antonio.bulgher...@gmail.com: Dear Eric, thanks for the fast reply. In the example the selected generator for the Mac was PackageMaker, and this is what I'm using. Yes, it is working w/o components. Then I think the PackageMaker generator maintainer/contirbutors may be the right person to anwser to yor questions. Howerver, from the CVS log I would say that you ought to try either CMake 2.6.4 (or even CMake CVS) because there seems to be some bug fixes in those later release that wasn't there in CMake 2.6.0. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Issue with CPack and component installation
2009/8/31 Antonio Bulgheroni antonio.bulgher...@gmail.com: Thanks, I'll try the latest version this evening as soon as I'm back home from work. BTW, can you point me to the mainteiners / contributors of the PackageMaker? In fact I don't know :-(, but I thought they must be reading the list and may jump into the discussion as soon as they think it's useful :-) The only thing I know is that late commiters on this (CVS HEAD) are David Cole who refers to Doug Gregor work, see http://public.kitware.com/Bug/view.php?id=6847 Note that it's usually not necessary to ping maintainer directly they usually read the list and answer the topic they are concerned with, that was the purpose of my previous message. -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] CPACK and NSIS
Hello, Currently, I'm exploring the facilities of CPack and NSIS on Windows. Thereby I ran into some small troubles. First, the executables are installed in the /bin subdirectory of the CPACK_PACKAGE_INSTALL_DIRECTORY. When the variable CPACK_NSIS_MODIFY_PATH is set to ON, it will add CPACK_PACKAGE_INSTALL_DIRECTORY to the Windows PATH environment. While the executables are located in the subdirectory, they cannot be found when they are executed on the command line (without omiting the path to the executable). Therefore I have the following question: Is there a way to add a subdirectory to the PATH environment variable, instead of the CPACK_PACKAGE_INSTALL_DIRECTORY? Second, the message to add CPACK_PACKAGE_INSTALL_DIRECTORY to the system path is shown, prior to selecting the path where the CPACK_PACKAGE_NAME is installed. This might be confusing for people that need to install the tool. Therefore, I suggest to 1) either display CPACK_PACKAGE_INSTALL_DIRECTORY after selecting a path for CPACK_PACKAGE_NAME or 2) display CPACK_PACKAGE_NAME instead of CPACK_PACKAGE_INSTALL_DIRECTORY. (Can be found at L6 of NSIS.InstallOptions.ini.in). Kind Regards, Frank -- == F.P.M (Frank) Stappers Eindhoven University of Technology Department of Mathematics and Computer Science OAS Group, HG 6.82 P.O.Box 513, 5600 MB Eindhoven The Netherlands Phone: +31-40-2472714 E-mail: f.p.m.stapp...@tue.nl URL:http://www.win.tue.nl/~fstapper == ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: generating CTest tests
Hi John, How do you get these CPU times printed. I've never seen these before. Or is that a Windows thingy, that doesn't work on Linux? Best regards, Marcel Loose. On Fri, 2009-08-28 at 14:14 -0400, John Drescher wrote: 1Performing Post-Build Event... 1Start processing tests 1Test project X:/32Bit/VC.80/Qt/QtBasicUtils 1 1/ 48 Testing FileCMD0 . Passed0.55 sec 1 2/ 48 Testing FileCMD1 . Passed1.58 sec 1 3/ 48 Testing Test0 Passed0.17 sec 1 4/ 48 Testing Test1 Passed0.16 sec ... 1100% tests passed, 0 tests failed out of 48 1Total CPU time = 11.78 sec 1Build log was saved at file://x:\32Bit\VC.80\Qt\QtBasicUtils\RUN_TESTS.dir\RelWithDebInfo\BuildLog.htm 1RUN_TESTS - 0 error(s), 0 warning(s) == Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped == ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] add_definitions affects rc.exe call
Hi all,
I'm using cmake-2.6.4 to build a project using Visual C++ 2005 and the
Unix Makefile generator. At the beginning of my main CMakeLists.txt I
have something like that:
add_definitions(/Zc:wchar_t- /nologo /wd4996 /wd4290)
Everything compile fine except the build of the RC object of my
binary. I get this error:
fatal error RC1212: invalid option - /z argument missing substitute font name
It seems that /Zc:wchar_t- and /nologo are not understood by rc.exe.
So I've fixed the probleme by writting
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /Zc:wchar_t- /nologo /wd4996 /wd4290)
I'm not sure if it is the right way to do it but it works.
Does add_definitions supposed to affects the list of argument passed to rc.exe ?
Cheers,
--
Nicolas Desprès
___
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] add_definitions affects rc.exe call
On 31. Aug, 2009, at 11:42, Nicolas Desprès wrote:
Hi all,
I'm using cmake-2.6.4 to build a project using Visual C++ 2005 and the
Unix Makefile generator. At the beginning of my main CMakeLists.txt I
have something like that:
add_definitions(/Zc:wchar_t- /nologo /wd4996 /wd4290)
Everything compile fine except the build of the RC object of my
binary. I get this error:
fatal error RC1212: invalid option - /z argument missing substitute
font name
It seems that /Zc:wchar_t- and /nologo are not understood by rc.exe.
So I've fixed the probleme by writting
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /Zc:wchar_t- /nologo /
wd4996 /wd4290)
I'm not sure if it is the right way to do it but it works.
Does add_definitions supposed to affects the list of argument passed
to rc.exe ?
Cheers,
--
Nicolas Desprès
AFAIK rc.exe does preprocessing, so you could use include files and do
macro expansion, so yes: add_definitions stuff should be passed to
rc.exe.
If I were you, I would do it like this:
set(CMAKE_EXTRA_CXX_FLAGS /Zc:wchar_t- /nologo /wd4996 /wd4290 CACHE
STRING Extra CXX options)
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${CMAKE_EXTRA_CXX_FLAGS})
This way the user then has still the option to edit the
CMAKE_EXTRA_CXX_FLAGS variable in the cache if he wants to, without
having to change the CMake code.
HTH
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] add_definitions affects rc.exe call
2009/8/31 Michael Wild them...@gmail.com:
On 31. Aug, 2009, at 11:42, Nicolas Desprès wrote:
Hi all,
I'm using cmake-2.6.4 to build a project using Visual C++ 2005 and the
Unix Makefile generator. At the beginning of my main CMakeLists.txt I
have something like that:
add_definitions(/Zc:wchar_t- /nologo /wd4996 /wd4290)
Everything compile fine except the build of the RC object of my
binary. I get this error:
fatal error RC1212: invalid option - /z argument missing substitute font
name
It seems that /Zc:wchar_t- and /nologo are not understood by rc.exe.
So I've fixed the probleme by writting
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /Zc:wchar_t- /nologo /wd4996
/wd4290)
I'm not sure if it is the right way to do it but it works.
Does add_definitions supposed to affects the list of argument passed to
rc.exe ?
Cheers,
--
Nicolas Desprès
AFAIK rc.exe does preprocessing, so you could use include files and do macro
expansion, so yes: add_definitions stuff should be passed to rc.exe.
According the rc.exe /help you are right. But rc.exe does not
understand all flags you can pass to cl.exe through add_definitions.
If I were you, I would do it like this:
set(CMAKE_EXTRA_CXX_FLAGS /Zc:wchar_t- /nologo /wd4996 /wd4290 CACHE
STRING Extra CXX options)
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${CMAKE_EXTRA_CXX_FLAGS})
This way the user then has still the option to edit the
CMAKE_EXTRA_CXX_FLAGS variable in the cache if he wants to, without having
to change the CMake code.
Thx for the tips :-)
--
Nicolas Desprès
___
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] add_definitions affects rc.exe call
On 31. Aug, 2009, at 13:23, Nicolas Desprès wrote:
2009/8/31 Michael Wild them...@gmail.com:
On 31. Aug, 2009, at 11:42, Nicolas Desprès wrote:
Hi all,
I'm using cmake-2.6.4 to build a project using Visual C++ 2005 and
the
Unix Makefile generator. At the beginning of my main
CMakeLists.txt I
have something like that:
add_definitions(/Zc:wchar_t- /nologo /wd4996 /wd4290)
Everything compile fine except the build of the RC object of my
binary. I get this error:
fatal error RC1212: invalid option - /z argument missing
substitute font
name
It seems that /Zc:wchar_t- and /nologo are not understood by rc.exe.
So I've fixed the probleme by writting
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /Zc:wchar_t- /nologo /wd4996
/wd4290)
I'm not sure if it is the right way to do it but it works.
Does add_definitions supposed to affects the list of argument
passed to
rc.exe ?
Cheers,
--
Nicolas Desprès
AFAIK rc.exe does preprocessing, so you could use include files and
do macro
expansion, so yes: add_definitions stuff should be passed to rc.exe.
According the rc.exe /help you are right. But rc.exe does not
understand all flags you can pass to cl.exe through add_definitions.
Well, add_definitions is just for that: adding preprocessor
definitions! That means flags, that get passed to the preprocessor
using either -D or /D (or whatever your compiler happens to use).
Nothing else. Although http://cmake.org/cmake/help/cmake2.6docs.html#command
:add_definitions says that it can also be used for any flags, I
really only would use it for that purpose. Especially as doing it the
way I showed gives the user of your build system a fighting chance,
e.g. when he wants to use a different compiler.
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] Fwd: generating CTest tests
That feature (printing the timings) is in CVS HEAD of ctest. It's not in a cmake release yet On Mon, Aug 31, 2009 at 5:34 AM, Marcel Loose lo...@astron.nl wrote: Hi John, How do you get these CPU times printed. I've never seen these before. Or is that a Windows thingy, that doesn't work on Linux? Best regards, Marcel Loose. On Fri, 2009-08-28 at 14:14 -0400, John Drescher wrote: 1Performing Post-Build Event... 1Start processing tests 1Test project X:/32Bit/VC.80/Qt/QtBasicUtils 1 1/ 48 Testing FileCMD0 . Passed0.55 sec 1 2/ 48 Testing FileCMD1 . Passed1.58 sec 1 3/ 48 Testing Test0 Passed0.17 sec 1 4/ 48 Testing Test1 Passed0.16 sec ... 1100% tests passed, 0 tests failed out of 48 1Total CPU time = 11.78 sec 1Build log was saved at file://x:\32Bit\VC.80\Qt\QtBasicUtils\RUN_TESTS.dir\RelWithDebInfo\BuildLog.htm 1RUN_TESTS - 0 error(s), 0 warning(s) == Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped == ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency in custom command?
On Mon, Aug 31, 2009 at 1:08 AM, King, Steven R steven.r.k...@intel.comwrote:
I now put all my binaries and libraries in ${CMAKE_BINARY_DIR}/bin as Clint
suggested. This caused ctest to fail for lack of knowing where the test
binary went. I made this adjustment:
add_test(
test_my_module
${CMAKE_BINARY_DIR}/bin/test_my_module
)
which allowed ctest to find the executable. However, the executable still
can't find the dll, since ctest runs the test from
${CMAKE_CURRENT_BINARY_DIR} which is apparently not equal to
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}. As we've just belabored, putting the dll
in ${CMAKE_CURRENT_BINARY_DIR} is neither easy nor well advised.
OK, now I'm actually getting worried. Any other ideas, please?
What we do at work is generate the test binaries in
CMAKE_RUNTIME_OUTPUT_DIRECTORY as well. This does tend to clutter up that
directory but they don't get make installed so it's not a huge issue for us.
You might be able to use the ENVIRONMENT test property to append to the PATH
environment variable CMAKE_RUNTIME_OUTPUT_DIRECTORY. This would allow the
test binaries (in theory) to find their dependent DLLs while not existing in
CMAKE_RUNTIME_OUTPUT_DIRECTORY.
--
Philip Lowman
___
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] dependency in custom command?
On Mon, Aug 31, 2009 at 8:20 AM, Philip Lowman phi...@yhbt.com wrote:
On Mon, Aug 31, 2009 at 1:08 AM, King, Steven R
steven.r.k...@intel.comwrote:
I now put all my binaries and libraries in ${CMAKE_BINARY_DIR}/bin as
Clint suggested. This caused ctest to fail for lack of knowing where the
test binary went. I made this adjustment:
add_test(
test_my_module
${CMAKE_BINARY_DIR}/bin/test_my_module
)
which allowed ctest to find the executable. However, the executable still
can't find the dll, since ctest runs the test from
${CMAKE_CURRENT_BINARY_DIR} which is apparently not equal to
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}. As we've just belabored, putting the dll
in ${CMAKE_CURRENT_BINARY_DIR} is neither easy nor well advised.
OK, now I'm actually getting worried. Any other ideas, please?
What we do at work is generate the test binaries in
CMAKE_RUNTIME_OUTPUT_DIRECTORY as well. This does tend to clutter up that
directory but they don't get make installed so it's not a huge issue for us.
You might be able to use the ENVIRONMENT test property to append to the
PATH environment variable CMAKE_RUNTIME_OUTPUT_DIRECTORY. This would allow
the test binaries (in theory) to find their dependent DLLs while not
existing in CMAKE_RUNTIME_OUTPUT_DIRECTORY.
Sorry forgot to mention, I believe this property is available only in CMake
CVS.
--
Philip Lowman
___
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] weird output with ctest
It should print when you specify -V or -VV. Can you post a small example that does not print? Bill On Sun, Aug 30, 2009 at 9:14 PM, Alex Haditya15...@hotmail.com wrote: Well problem is why doesn't it print the std::cout that I've put inside main? while it's running main Date: Sun, 30 Aug 2009 17:20:26 -0400 Subject: Re: [CMake] weird output with ctest From: dresche...@gmail.com To: aditya15...@hotmail.com; cmake@cmake.org I have the following command in my CMakeLists.txt and I run the test using the command ctest -VV -R test. However the test results doesn't print anything that I defined on the test code, it just shows the test passed. add_test(test ../build/gbc 0.1 0.3 0.5 0.7 0.9) That is all it is supposed to do. John Party with Buddy! Bling out your Messenger with free winks emoticons. Click here ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Mac OS 10.6 i386 architecture
Hi, Despite setting CMAKE_OSX_ARCHITECTURES as i386, cmake builds x86_64 binaries on Snow Leopard, as default setting for gcc version 4.2.1 is now x86_64. Yves ___ 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] .vfproj with cmake
Hi,
I don't have the file cmLocalVisualStudio7Generator.cxx in my CMake directories.
What should I do? Should I add it, if yes, could you send it to me?
Thank you for help.
lokmane.abbas-turki wrote:
Hi,
I have already sent this email but I still don't receive an answer.
Could you please tell me what should I do to build a simple .vfproj with
cmake without a version conflict.
CMake does not support this version currently.
To fix it temporarily you can hack this method:
Source/cmLocalVisualStudio7Generator.cxx
void
cmLocalVisualStudio7Generator
::WriteProjectStartFortran(std::ostream fout,
const char *libName,
cmTarget target)
{
cmGlobalVisualStudio7Generator* gg =
static_cast(this-GlobalGenerator);
fout \n
\tProjectCreator=\Intel Fortran\\n
\tVersion=\9.10\\n;
const char* keyword = target.GetProperty(VS_KEYWORD);
Make this change in the file:
Version=9.10 to Version=11.0
-Bill
***
Lokmane ABBAS-TURKI
13 Résidence Hautes Bergères
91940 Les Ulis, FRANCE
Tel: 01 69 07 02 91
***
Laposte.net fête ses 10 ans !
Gratuite, garantie à vie et déjà utilisée par des millions d'internautes...
vous aussi, pour votre adresse e-mail, choisissez laposte.net.
Laposte.net, bien + qu'une messagerie
___
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] [New Module] FindHDF5.cmake
James C. Sutherland wrote: I have a question about the static library option. I did: set( HDF5_USE_STATIC_LIBRARIES 1 ) which should trigger linkage with static libraries, right? But what I see in the link line is: /usr/lib/libz.dylib /usr/lib/libm.dylib /jcs/apps/hdf5_serial/lib/libhdf5_cpp.dylib /usr/lib/libz.dylib /usr/lib/libm.dylib /jcs/apps/hdf5_serial/lib/libhdf5_cpp.dylib Okay - it appears that was due to an out of date cache. It now tries to link static HDF5 libraries, but is still trying to link dynamic z and m libraries: /usr/lib/libm.dylib /jcs/apps/hdf5_serial/lib/libhdf5_cpp.a /usr/lib/libz.dylib /usr/lib/libm.dylib /jcs/apps/hdf5_serial/lib/libhdf5_cpp.a Previously, I was adding these via target_link_libraries( ... z ) Are these two equivalent? Hi James, Thanks for the feedback. I'm actually surprised it found the static libraries for you at all, as it looks like you're on OSX. The USE_STATIC_LIBRARIES switch was placed in there for Unix systems and is wrapped in an if( UNIX ) flag in the module itself. Where on your system are the static libm and libz? For the static option to work, they need to be in one of the default search paths, one of the paths deduced from the HDF5 wrapper compilers, or somewhere in the path specified in the HDF5_ROOT environment variable. My solution for this is somewhat suboptimal, but it appears to be the recommended solution for now. For more details, take a look at http://www.cmake.org/Bug/view.php?id=1643. One other question: if one requests the CXX component for HDF5, the hdf5_cpp library is linked in, but the hdf5 library is also required. Adding C and CXX as components fixes this problem. Perhaps the FindHDF5.cmake file could automatically activate C if CXX is requested? That might be more robust... You're right. That was an oversight. I checked a fix into CVS for that this morning. Thanks again for the contribution! James -- Will Dicharry Software Developer Stellar Science Ltd Co smime.p7s Description: S/MIME Cryptographic Signature ___ 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] Mac OS 10.6 i386 architecture
On 8/31/09 6:53 AM, Yves Starreveld said: Despite setting CMAKE_OSX_ARCHITECTURES as i386, cmake builds x86_64 binaries on Snow Leopard, as default setting for gcc version 4.2.1 is now x86_64. Which version of CMake? gcc 4.2 on 10.6 now defaults to x86_64 whereas on 10.5 it defaulted to i386, as you noticed. I recall CMake used to (still does?) ignore CMAKE_OSX_ARCHITECTURES is there was only 1 item listed. If you try specifying say 'ppc;i386' do you get such a binary? Could you try CMake CVS? -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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 on Snow Leopard
On 8/30/09 8:26 PM, Celil Rufat said: CMAKE_OSX_ARCHITECTURES i386 CMAKE_OSX_SYSROOT /Developer/SDKs/android-sdk-mac_x86-1.5_r2 Hmm, the last variable is strange. I don't know why it is detecting my android installation as the system root. I will try to delete it, and test again. CMake's detection should probably be more robust, I'd suggest filing a bug suggesting that it only consider .sdk folders. OTOH, Mike is right that all of /Developer is Apple-only. No other software should be installing anything in there. I think the problem is in the fact that Snow Leopard no longer supports powerpc binaries and cmake is still trying to build my application as universal binaries instead of just building intel binaries. The compilers included in 10.6 can still build 4-way universal binaries (ppc32, ppc64, intel32, intel64). 10.6 however cannot _run_ on a PowerPC. I've been using CMake in 10.6 for over a year, and it's been (basically) trouble free. -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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] Mac OS 10.6 i386 architecture
This was CMake CVS from this AM. Despite specifying i386, x86_64 was built. Yves On 2009-08-31, at 08:34 , Sean McBride wrote: On 8/31/09 6:53 AM, Yves Starreveld said: Despite setting CMAKE_OSX_ARCHITECTURES as i386, cmake builds x86_64 binaries on Snow Leopard, as default setting for gcc version 4.2.1 is now x86_64. Which version of CMake? gcc 4.2 on 10.6 now defaults to x86_64 whereas on 10.5 it defaulted to i386, as you noticed. I recall CMake used to (still does?) ignore CMAKE_OSX_ARCHITECTURES is there was only 1 item listed. If you try specifying say 'ppc;i386' do you get such a binary? Could you try CMake CVS? -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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] Mac OS 10.6 i386 architecture
On 31. Aug, 2009, at 16:45, Yves Starreveld wrote: This was CMake CVS from this AM. Despite specifying i386, x86_64 was built. Yves On 2009-08-31, at 08:34 , Sean McBride wrote: On 8/31/09 6:53 AM, Yves Starreveld said: Despite setting CMAKE_OSX_ARCHITECTURES as i386, cmake builds x86_64 binaries on Snow Leopard, as default setting for gcc version 4.2.1 is now x86_64. Which version of CMake? gcc 4.2 on 10.6 now defaults to x86_64 whereas on 10.5 it defaulted to i386, as you noticed. I recall CMake used to (still does?) ignore CMAKE_OSX_ARCHITECTURES is there was only 1 item listed. If you try specifying say 'ppc;i386' do you get such a binary? Could you try CMake CVS? What happens if you pass '-arch i386' in the CMAKE_C_FLAGS and CMAKE_CXX_FLAGS? 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] dependency in custom command?
On 08/30/2009 11:08 PM, King, Steven R wrote:
Can't you put all executables and shared libraries in one directory, so they
are all local to each other?
In the top level CMakeLists.txt file just add
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
The executables you specify in ADD_TEST() will have a working directory that
is ${CMAKE_CURRENT_BINARY_DIR}
Thanks Clint and Tyler and others for your patient help. The consolidated
binary directory didn't work.
I now put all my binaries and libraries in ${CMAKE_BINARY_DIR}/bin as Clint
suggested. This caused ctest to fail for lack of knowing where the test binary
went. I made this adjustment:
add_test(
test_my_module
${CMAKE_BINARY_DIR}/bin/test_my_module
)
which allowed ctest to find the executable. However, the executable still
can't find the dll, since ctest runs the test from ${CMAKE_CURRENT_BINARY_DIR}
which is apparently not equal to ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}. As we've
just belabored, putting the dll in ${CMAKE_CURRENT_BINARY_DIR} is neither easy
nor well advised.
OK, now I'm actually getting worried. Any other ideas, please?
How about this:
add_test (test_my_module test_my_module ${CMAKE_BINARY_DIR}/bin)
Then in your main(int, char*[]), you can use argv[1] as the path to load
the shared/dynamic library from.
Clint
___
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] Mac OS 10.6 i386 architecture
On 8/31/09 8:45 AM, Yves Starreveld said: This was CMake CVS from this AM. Despite specifying i386, x86_64 was built. That is a serious bug then. As I said, my memory is hazy, but I do recall something about CMake doing something different if only 1 arch is specified. I wonder what happens on 10.5 if you only specify x86_64? I'm always building 4-way, so I haven't hit this... -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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] .vfproj with cmake
On Mon, Aug 31, 2009 at 03:17:34PM +0200, lokmane.abbas-turki wrote:
I don't have the file cmLocalVisualStudio7Generator.cxx in my CMake
directories.
What should I do? Should I add it, if yes, could you send it to me?
That's a source file (see the .cxx extension?). If you want to use the
fix below, you'll need to download the CMake source, make the change,
and rebuild CMake. Luckily, this process is actually pretty
straightforward!
gl,
tyler
To fix it temporarily you can hack this method:
Source/cmLocalVisualStudio7Generator.cxx
void
cmLocalVisualStudio7Generator
::WriteProjectStartFortran(std::ostream fout,
const char *libName,
cmTarget target)
{
cmGlobalVisualStudio7Generator* gg =
static_cast(this-GlobalGenerator);
fout \n
\tProjectCreator=\Intel Fortran\\n
\tVersion=\9.10\\n;
const char* keyword = target.GetProperty(VS_KEYWORD);
Make this change in the file:
Version=9.10 to Version=11.0
___
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] Mac OS 10.6 i386 architecture
Thats how I got it to work, but clearly CMake should be sorting things out purely based on CMAKE_OSX_ARCHITECTURES. The previous gcc default setting allowed things to work, but with 10.6 its no longer an appropriate assumption. Yves On 2009-08-31, at 8:49 AM, Michael Wild wrote: On 31. Aug, 2009, at 16:45, Yves Starreveld wrote: This was CMake CVS from this AM. Despite specifying i386, x86_64 was built. Yves On 2009-08-31, at 08:34 , Sean McBride wrote: On 8/31/09 6:53 AM, Yves Starreveld said: Despite setting CMAKE_OSX_ARCHITECTURES as i386, cmake builds x86_64 binaries on Snow Leopard, as default setting for gcc version 4.2.1 is now x86_64. Which version of CMake? gcc 4.2 on 10.6 now defaults to x86_64 whereas on 10.5 it defaulted to i386, as you noticed. I recall CMake used to (still does?) ignore CMAKE_OSX_ARCHITECTURES is there was only 1 item listed. If you try specifying say 'ppc;i386' do you get such a binary? Could you try CMake CVS? What happens if you pass '-arch i386' in the CMAKE_C_FLAGS and CMAKE_CXX_FLAGS? 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] Unable to run cmake using absoft f95 Fortran compiler
Hi Everyone, I am using CMake 2.6.4 on Linux 64 bit platform. We are using absoft f95 compiler. I am trying to build cgns3.0 which uses CMake for building the package. Now when I enable Fortran and try running cmake, I get the following error : -- The Fortran compiler identification is GNU -- Check for working Fortran compiler: /opt/absoft/bin/f95 -- Check for working Fortran compiler: /opt/absoft/bin/f95 -- broken CMake Error at /usr/share/cmake/Modules/CMakeTestFortranCompiler.cmake:25 (MESSAGE): The Fortran compiler /opt/absoft/bin/f95 is not able to compile a simple test program. . . . /opt/absoft/bin/f95 -fPIC CMakeFiles/cmTryCompileExec.dir/testFortranCompiler.f.o -o cmTryCompileExec -rdynamic ERROR: Unrecognized arguments: -rdynamic could someone please help me how to circumvent this problem/error? I also tried setting set(CMAKE_SHARED_LIBRARY_Fortran_Flags ) but it didn't help me. I also saw one similar problem which said that this problem occurs when the system has multiple Fortran compilers. Is it true? if so, what is the solution. Thanks in advance. Regards, Venugopal Gudimetla EMAILING FOR THE GREATER GOOD Join me___ 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] triggering rebuild on windows
On Sunday 30 August 2009 12:20:51 pm Philip Lowman wrote: On Tue, Aug 25, 2009 at 1:32 PM, j s j.s4...@gmail.com wrote: I am using the Visual Studio generator from the cmake binary distribution. If I change flags using ADD_DEFINITIONS, I notice that it doesn't trigger a rebuild of all the affected files. Is this by design? I've known and worked around this limitation for a few years now. The easiest thing to do is clean the entire solution if you change any compile flags whatsoever (unless you know exactly what you changed and the impact of doing it). The problem is that VS doesn't remember the old flags when you open up a project file with new flags so isn't capable of cleaning the project for you. This issue could probably be worked around in CMake itself one way or another but it's never been worked on to my knowledge. Or how about putting it into a configured header file instead? Visual Studio rebuilds correctly if you do it that way. Clint ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unable to run cmake using absoft f95 Fortran compiler
venugopal gudimetla wrote: I am using CMake 2.6.4 on Linux 64 bit platform. We are using absoft f95 compiler. I am trying to build cgns3.0 which uses CMake for building the package. FYI, to my knowledge no one has ever used CMake with that compiler. We need to teach CMake about the compiler's flags. Now when I enable Fortran and try running cmake, I get the following error : -- The Fortran compiler identification is GNU ^^^ Is the compiler derived from a GNU compiler? Somehow its preprocessor claims that the compiler is GNU. Do you know if the compiler documents a preprocessor symbol to identify it? ERROR: Unrecognized arguments: -rdynamic could someone please help me how to circumvent this problem/error? I also tried setting set(CMAKE_SHARED_LIBRARY_Fortran_Flags ) but it didn't help me. The workaround is: set(CMAKE_SHARED_LIBRARY_LINK_Fortran_FLAGS ) # I also saw one similar problem which said that this problem occurs when the system has multiple Fortran compilers. Is it true? I don't think that has anything to do with it. -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] dependency in custom command?
add_test(
test_my_module
${CMAKE_BINARY_DIR}/bin/test_my_module
)
This will only work on Unix like systems. Doesn't CTest figure out
that the program name is a target? I.e. doesn't this work (provided
you did add_executable(test_my_module ...)):
add_test(test_my_module test_my_module)
Hi Michael,
I have the add_executable just as you show, but CTest gives up immediately
since it can't find the test_my_module executable in
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}.
Here are the bugs I think I've encountered with your collective help:
Bug 1: Cmake ignores ${CMAKE_RUNTIME_OUTPUT_DIRECTORY} in the add_test()
command. Consequently ctest reports a failure due to not finding the test
binary.
Bug 2: Locating a build output using the LOCATION property of a target is
deprecated, but commands cannot substitute the target name for build output
location. In other words, commands like this fail:
add_executable( foo foo.cpp )
add_custom_command( OUTPUT new_foo COMMAND $(CMAKE_COMMAND) -E copy foo
new_foo )
Cmake should recognize 'foo' as a target and implicitly substitute foo's build
output.
But back to the dll test problem: Changing ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
forces me to hack all the ctests in my whole build tree, which I'm unwilling to
do. I will stick with Clint's copy_if_different idea to move the dll to the
binary directory of the test program.
Thanks Clint, Michael, Philip Tyler and the list. Community support here has
been great even if the answers weren't what I hoped to hear.
Cheers,
-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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unable to run cmake using absoft f95 Fortran compiler
Hi Brad, Thank you very much for your quick response. Yeah I noticed too that for some reason Cmakes is assuming f95 to be a GNU compiler. In the file /cmake/Modules/CMakeDetermineFortranCompiler.cmake, I didn't see any reference to Absoft compilers, even though f90/f95 compilers are being listed as possible compilers. 1. Inorder to recognize the f95 compiler I did this : %f95 -v gave me Absoft 64-bit Fortran 95 9.0 with Service Pack 1 so perhaps 'Absoft' can be greped to recognize the compiler. I don't think it is derived from GNU compiler. 2. I also set(CMAKE_SHARED_LIBRARY_LINK_Fortran_FLAGS ) in my CMakeLists.txt, which made no difference to the error message. Thanks a lot for your help again. Regards, Venu EMAILING FOR THE GREATER GOOD Join me Date: Mon, 31 Aug 2009 12:55:37 -0400 From: brad.k...@kitware.com To: gudimet...@hotmail.com CC: cmake@cmake.org Subject: Re: [CMake] Unable to run cmake using absoft f95 Fortran compiler venugopal gudimetla wrote: I am using CMake 2.6.4 on Linux 64 bit platform. We are using absoft f95 compiler. I am trying to build cgns3.0 which uses CMake for building the package. FYI, to my knowledge no one has ever used CMake with that compiler. We need to teach CMake about the compiler's flags. Now when I enable Fortran and try running cmake, I get the following error : -- The Fortran compiler identification is GNU ^^^ Is the compiler derived from a GNU compiler? Somehow its preprocessor claims that the compiler is GNU. Do you know if the compiler documents a preprocessor symbol to identify it? ERROR: Unrecognized arguments: -rdynamic could someone please help me how to circumvent this problem/error? I also tried setting set(CMAKE_SHARED_LIBRARY_Fortran_Flags ) but it didn't help me. The workaround is: set(CMAKE_SHARED_LIBRARY_LINK_Fortran_FLAGS ) # I also saw one similar problem which said that this problem occurs when the system has multiple Fortran compilers. Is it true? I don't think that has anything to do with it. -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] triggering rebuild on windows
That wouldn't be good for what I am trying to do. I just need: _USE_MATH_DEFINES for all files so that Visual C++ recognizes M_PI. Creating a header file dependency could trigger a huge storm of recompilations just by touching the file. I'll just have to be careful around Visual C++. Juan On Mon, Aug 31, 2009 at 11:16 AM, Clinton Stimpson clin...@elemtech.comwrote: On Sunday 30 August 2009 12:20:51 pm Philip Lowman wrote: On Tue, Aug 25, 2009 at 1:32 PM, j s j.s4...@gmail.com wrote: I am using the Visual Studio generator from the cmake binary distribution. If I change flags using ADD_DEFINITIONS, I notice that it doesn't trigger a rebuild of all the affected files. Is this by design? I've known and worked around this limitation for a few years now. The easiest thing to do is clean the entire solution if you change any compile flags whatsoever (unless you know exactly what you changed and the impact of doing it). The problem is that VS doesn't remember the old flags when you open up a project file with new flags so isn't capable of cleaning the project for you. This issue could probably be worked around in CMake itself one way or another but it's never been worked on to my knowledge. Or how about putting it into a configured header file instead? Visual Studio rebuilds correctly if you do it that way. Clint ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unable to run cmake using absoft f95 Fortran compiler
venugopal gudimetla wrote: Thank you very much for your quick response. BTW, Fortran support is greatly improved in CMake's development version. If you can try the latest version from CVS HEAD, please do so. Yeah I noticed too that for some reason Cmakes is assuming f95 to be a GNU compiler. CMake is not assuming anything. It actually compiles a test source file with the .F extension so that the preprocessor runs. The source uses preprocessor definitions to detect the compiler identification. I think the compiler is defining __GNUC__. This brings us back to my question: does the compiler identify itself with any documented preprocessor symbol? In the file /cmake/Modules/CMakeDetermineFortranCompiler.cmake, I didn't see any reference to Absoft compilers, even though f90/f95 compilers are being listed as possible compilers. Many Fortran compiler vendors provide tools called 'f90' and 'f95'. 2. I also set(CMAKE_SHARED_LIBRARY_LINK_Fortran_FLAGS ) in my CMakeLists.txt, which made no difference to the error message. What is the actual link line that is failing? You can see it by running make VERBOSE=1. -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] triggering rebuild on windows
Your original question was about why not everything was recompiling... Then, when a solution is offered, you say but if I do that everything will recompile! We thought that's what you wanted... :-) On Mon, Aug 31, 2009 at 2:22 PM, j s j.s4...@gmail.com wrote: That wouldn't be good for what I am trying to do. I just need: _USE_MATH_DEFINES for all files so that Visual C++ recognizes M_PI. Creating a header file dependency could trigger a huge storm of recompilations just by touching the file. I'll just have to be careful around Visual C++. Juan On Mon, Aug 31, 2009 at 11:16 AM, Clinton Stimpson clin...@elemtech.comwrote: On Sunday 30 August 2009 12:20:51 pm Philip Lowman wrote: On Tue, Aug 25, 2009 at 1:32 PM, j s j.s4...@gmail.com wrote: I am using the Visual Studio generator from the cmake binary distribution. If I change flags using ADD_DEFINITIONS, I notice that it doesn't trigger a rebuild of all the affected files. Is this by design? I've known and worked around this limitation for a few years now. The easiest thing to do is clean the entire solution if you change any compile flags whatsoever (unless you know exactly what you changed and the impact of doing it). The problem is that VS doesn't remember the old flags when you open up a project file with new flags so isn't capable of cleaning the project for you. This issue could probably be worked around in CMake itself one way or another but it's never been worked on to my knowledge. Or how about putting it into a configured header file instead? Visual Studio rebuilds correctly if you do it that way. Clint ___ 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 on Snow Leopard
Simply reinstalling XCode for 10.6 fixed the problem. Thanks for the help. Celil On Sun, Aug 30, 2009 at 10:49 PM, Michael Jackson mike.jack...@bluequartz.net wrote: MAKE_OSX_SYSROOT /Developer/SDKs/android-sdk-mac_x86-1.5_r2 Yep, there is the problem. CMake looks in the /Developer/SDKs for all available SDKs and then greps for some information to try and figure out which one to use. Get rid of anything OTHER than official Apple SDKs that are in /Developer/SDKs/*, just consider that directory off limits to anything other than Apple stuff and you should be OK. Mike On Aug 30, 2009, at 11:26 PM, Celil Rufat wrote: this person also has the problem http://stackoverflow.com/questions/1349886/cmake-settings-on-snow-leopard Yup, that was also me :-) Please post the following variables from your project after a first run of cmake on your project from a clean build directory. CMAKE_OSX_ARCHITECTURES CMAKE_OSX_SYSROOT CMAKE_OSX_ARCHITECTURES i386 CMAKE_OSX_SYSROOT /Developer/SDKs/android-sdk-mac_x86-1.5_r2 Hmm, the last variable is strange. I don't know why it is detecting my android installation as the system root. I will try to delete it, and test again. Celil ___ 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] Issue with CPack and component installation
Thanks a lot Eric. Installing 2.6.4 made the trick. We should consider updating the wiki and saying that a newer version (than 2.6.0) is required for the component installation. thanks again for helping, toto -- Antonio Bulgheroni, PhD http://unico-lab.blogspot.com “There are 10 kinds of people. Those that understand binary and those that don’t.” Sent from Alzate Brianza, Lombardia, Italia On Mon, Aug 31, 2009 at 9:18 AM, Eric Noulard eric.noul...@gmail.comwrote: 2009/8/31 Antonio Bulgheroni antonio.bulgher...@gmail.com: Thanks, I'll try the latest version this evening as soon as I'm back home from work. BTW, can you point me to the mainteiners / contributors of the PackageMaker? In fact I don't know :-(, but I thought they must be reading the list and may jump into the discussion as soon as they think it's useful :-) The only thing I know is that late commiters on this (CVS HEAD) are David Cole who refers to Doug Gregor work, see http://public.kitware.com/Bug/view.php?id=6847 Note that it's usually not necessary to ping maintainer directly they usually read the list and answer the topic they are concerned with, that was the purpose of my previous message. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Mac OS 10.6 i386 architecture
On 8/31/09 9:26 AM, Yves Starreveld said: Thats how I got it to work, but clearly CMake should be sorting things out purely based on CMAKE_OSX_ARCHITECTURES. Agreed. Can you create a bug and tell me the number? -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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 on Snow Leopard
I am experiencing still another problem. I can no longer link to any of the older libraries. The compilation fails with the following error message: ld: warning: in /Library/Frameworks//Python.framework/Python, missing required architecture x86_64 in file Undefined symbols: _PyErr_Occurred, referenced from: _SWIG_Python_AddErrorMsg in TMPathPYTHON_wrap.c.o ... From the above it would appear that cmake is building x86_64 files and trying to link them my old i386 libraries, however the variable CMAKE_OSX_ARCHITECTURES is still equal to i386. What else could be causing the linker to fail in this way? Celil On Mon, Aug 31, 2009 at 11:49 AM, Celil Rufat celil.ru...@gmail.com wrote: Simply reinstalling XCode for 10.6 fixed the problem. Thanks for the help. Celil On Sun, Aug 30, 2009 at 10:49 PM, Michael Jackson mike.jack...@bluequartz.net wrote: MAKE_OSX_SYSROOT /Developer/SDKs/android-sdk-mac_x86-1.5_r2 Yep, there is the problem. CMake looks in the /Developer/SDKs for all available SDKs and then greps for some information to try and figure out which one to use. Get rid of anything OTHER than official Apple SDKs that are in /Developer/SDKs/*, just consider that directory off limits to anything other than Apple stuff and you should be OK. Mike On Aug 30, 2009, at 11:26 PM, Celil Rufat wrote: this person also has the problem http://stackoverflow.com/questions/1349886/cmake-settings-on-snow-leopard Yup, that was also me :-) Please post the following variables from your project after a first run of cmake on your project from a clean build directory. CMAKE_OSX_ARCHITECTURES CMAKE_OSX_SYSROOT CMAKE_OSX_ARCHITECTURES i386 CMAKE_OSX_SYSROOT /Developer/SDKs/android-sdk-mac_x86-1.5_r2 Hmm, the last variable is strange. I don't know why it is detecting my android installation as the system root. I will try to delete it, and test again. Celil ___ 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] triggering rebuild on windows
I am doing cross-platform compilation. I don't want everything to recompile on all platforms. That is a risk with having a configuration header file. If I remember correctly, cmake would ignore conditional include guards when doing dependency scanning. Therefore: #ifdef WIN32 #include config.hh #endif would trigger a compilation on all platforms if config.hh changed. I want everything to recompile on Windows, but not on my linux builds. Regards, Juan On Mon, Aug 31, 2009 at 1:30 PM, David Cole david.c...@kitware.com wrote: Your original question was about why not everything was recompiling... Then, when a solution is offered, you say but if I do that everything will recompile! We thought that's what you wanted... :-) On Mon, Aug 31, 2009 at 2:22 PM, j s j.s4...@gmail.com wrote: That wouldn't be good for what I am trying to do. I just need: _USE_MATH_DEFINES for all files so that Visual C++ recognizes M_PI. Creating a header file dependency could trigger a huge storm of recompilations just by touching the file. I'll just have to be careful around Visual C++. Juan On Mon, Aug 31, 2009 at 11:16 AM, Clinton Stimpson clin...@elemtech.comwrote: On Sunday 30 August 2009 12:20:51 pm Philip Lowman wrote: On Tue, Aug 25, 2009 at 1:32 PM, j s j.s4...@gmail.com wrote: I am using the Visual Studio generator from the cmake binary distribution. If I change flags using ADD_DEFINITIONS, I notice that it doesn't trigger a rebuild of all the affected files. Is this by design? I've known and worked around this limitation for a few years now. The easiest thing to do is clean the entire solution if you change any compile flags whatsoever (unless you know exactly what you changed and the impact of doing it). The problem is that VS doesn't remember the old flags when you open up a project file with new flags so isn't capable of cleaning the project for you. This issue could probably be worked around in CMake itself one way or another but it's never been worked on to my knowledge. Or how about putting it into a configured header file instead? Visual Studio rebuilds correctly if you do it that way. Clint ___ 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] triggering rebuild on windows
On Mon, Aug 31, 2009 at 8:02 PM, j s j.s4...@gmail.com wrote:
I am doing cross-platform compilation. I don't want everything to
recompile on all platforms. That is a risk with having a configuration
header file. If I remember correctly, cmake would ignore conditional
include guards when doing dependency scanning. Therefore:
#ifdef WIN32
#include config.hh
#endif
would trigger a compilation on all platforms if config.hh changed.
I want everything to recompile on Windows, but not on my linux builds.
I think when he meant a config file he meant one created by CMake
dynamically (which would only affect one build anyways).
In other words:
config.h.in:
#cmakedefine FOO
CMakeLists.txt:
set(FOO true)
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/config.h.in
${CMAKE_CURRENT_BINARY_DIR}/config.h)
include_directories(${CMAKE_CURRENT_BINARY_DIR})
config.h now includes #define FOO 1
Of course if all you need is the unborkify MSVC so it supports math.h
define then it's probably not worth it. :)
--
Philip Lowman
___
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] triggering rebuild on windows
According to Microsoft, the math macros are not part of standard C/C++:
http://msdn.microsoft.com/en-us/library/4hwaceh6(VS.80).aspx
I'm not going to quibble with them on that point, as they were nice enough
to provided them with:
_USE_MATH_DEFINES
as an alternative. The problem is the config.h approach is I now have to
include a config.h everywhere I want to use a math macro. Even worse is if
I put all my platform dependent options in that file. If I put an unrelated
macro change in that file, I just retriggered a rebuild for many files not
requiring a rebuild.The potential for triggering unnecessary rebuilds
anytime that file is regenerated is just not worth it.
I will quibble with Microsoft that Visual Studio does not detect when the
compilation options change.
Regards,
Juan
On Mon, Aug 31, 2009 at 8:45 PM, Philip Lowman phi...@yhbt.com wrote:
On Mon, Aug 31, 2009 at 8:02 PM, j s j.s4...@gmail.com wrote:
I am doing cross-platform compilation. I don't want everything to
recompile on all platforms. That is a risk with having a configuration
header file. If I remember correctly, cmake would ignore conditional
include guards when doing dependency scanning. Therefore:
#ifdef WIN32
#include config.hh
#endif
would trigger a compilation on all platforms if config.hh changed.
I want everything to recompile on Windows, but not on my linux builds.
I think when he meant a config file he meant one created by CMake
dynamically (which would only affect one build anyways).
In other words:
config.h.in:
#cmakedefine FOO
CMakeLists.txt:
set(FOO true)
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/config.h.in
${CMAKE_CURRENT_BINARY_DIR}/config.h)
include_directories(${CMAKE_CURRENT_BINARY_DIR})
config.h now includes #define FOO 1
Of course if all you need is the unborkify MSVC so it supports math.h
define then it's probably not worth it. :)
--
Philip Lowman
___
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] triggering rebuild on windows
On Mon, Aug 31, 2009 at 10:12 PM, j s j.s4...@gmail.com wrote: According to Microsoft, the math macros are not part of standard C/C++: http://msdn.microsoft.com/en-us/library/4hwaceh6(VS.80).aspxhttp://msdn.microsoft.com/en-us/library/4hwaceh6%28VS.80%29.aspx I'm not going to quibble with them on that point, as they were nice enough to provided them with: _USE_MATH_DEFINES Interesting, didn't know that. -- Philip Lowman ___ 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] dependency in custom command?
In case it's useful, here's a macro to copy an arbitrary file form the source
directory to the binary directory. The dependencies work such that the file is
not copied if the destination is up-to-date.
This is working fine for me, but suggested improvements are very welcome.
Thanks,
-steve
#-
# Macro to copy an arbitrary file from the source directory to the binary
directory.
macro( copy_file_from_src_to_bin file_arg )
# Always put the name of a custom command's output into a variable otherwise
# dependency checking doesn't seem to work.
set( SRC_OF_${file_arg} ${CMAKE_CURRENT_SOURCE_DIR}/${file_arg} )
set( DEST_OF_${file_arg} ${CMAKE_CURRENT_BINARY_DIR}/${file_arg} )
# Copy the configuration file to the build directory for use by the test
add_custom_command(
OUTPUT ${DEST_OF_${file_arg}}
COMMAND ${CMAKE_COMMAND} -E copy
${SRC_OF_${file_arg}} ${DEST_OF_${file_arg}}
DEPENDS ${SRC_OF_${file_arg}}
COMMENT CUSTOM COMMAND: Copy ${file_arg} to build
directory.
)
add_custom_target (
copy_file_from_src_to_bin_${file_arg} ALL
DEPENDS ${DEST_OF_${file_arg}}
)
endmacro( copy_file_from_src_to_bin )
___
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
