Re: [CMake] EXECUTE_PROCESS too good at running programs
Brandon J. Van Every wrote: Ok, the CMake 2.4.2 documentation for the projectName version of TRY_COMPILE is only 3 short sentences. IIUYC, you are saying I'm going to have to write a CMakeLists.txt wrapper, and a subdirectory, for each and every tool like "makeinfo," if I want to prove that they work in the build. You can create a macro to wrap this all up. The source tree for the TRY_COMPILE can be created with FILE(WRITE) and FILE(MAKE_DIRECTORY). -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMakeSetup broken, fails in the root directory
At 02:57 AM 7/22/2006, Dataflow wrote: >I have several small utilities and trial programs, each zipped up nicely with >its own CMakeLists.txt file and stashed away for a rainy day. >Say: >-- >project(test) > >add_executable(test >test.cpp >) >-- >When needed, these are unzipped in the RAMDRIVE and compiled there. Use of >ramdrive makes it easy to just copy the resulting exe and do the cleanup. > >With 2.4.2, the CMakeSetup has started to fail while recognizing the source >files, saying that "can not find file g:test.cpp", where g: is the ramdrive. >This happens for within-source & out-of-source builds. I have tried using >'g:\', 'g:/', 'g:' >I have verified that this fails also in the other root directories, such as >c:\, d:\ etc. > >This used to work with the earlier versions, that's why I have several of >these. We need more information to debug this. Can you post a complete example and instructions on how to run CMakeSetup to cause the failure? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] EXECUTE_PROCESS too good at running programs
At 08:17 AM 7/22/2006, Brad King wrote: >Brandon J. Van Every wrote: >>Ok, the CMake 2.4.2 documentation for the projectName version of TRY_COMPILE >>is only 3 short sentences. IIUYC, you are saying I'm going to have to write >>a CMakeLists.txt wrapper, and a subdirectory, for each and every tool like >>"makeinfo," if I want to prove that they work in the build. > >You can create a macro to wrap this all up. The source tree for the >TRY_COMPILE can be created with FILE(WRITE) and FILE(MAKE_DIRECTORY). Regardless of the documentation, try-compile and not exec_process is what is supposed to be used for system introspection. The build time environment is often different than the cmake time environment, and if you are testing programs that will be run at build time, try-compile/try_run is the only way to do that. I assume that you are planning to run makeinfo at build time, so it should be tested at build time. Remember cmake is not a build tool, but rather a build generator, and is not running during the build. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMakeSetup broken, fails in the root directory
Ok.
1. Please put the following in CMakeLists.txt:
project(test)
add_executable(test test.cpp)
2. Please put the following in 'test.cpp'
void main(){}
3. Please put both these directly in c:\ (not in a subdirectory. You can put
in d:\, e:\ etc, but in the root directory.)
4. Run CMakeSetup, specify source dir as 'c:', binary dir as 'c:\winbuild'.
5. Press Configure.
6. With 2.4, you will get the error (after compiler detection etc): "can not
find file c:test.cpp". You put it there, didn't you?! Note that there is no
\ in the file name shown.
Obviously, no one will build projects in Linux root directory, but it is
commonly done in windows ramdrive (at least by me!). The workaround of
creating a sub directory in ramdrive works, but is simply painful to do
every time and easy to forget. Besides, this worked smoothly earlier.
Thanks for the great tool!
- Rajiv Bhagwat
- Original Message -
From: "William A. Hoffman" <[EMAIL PROTECTED]>
To: "Dataflow" <[EMAIL PROTECTED]>;
Sent: Sat, 22 Jul 2006 6:18 PM
Subject: Re: [CMake] CMakeSetup broken, fails in the root directory
> At 02:57 AM 7/22/2006, Dataflow wrote:
> >I have several small utilities and trial programs, each zipped up nicely
with its own CMakeLists.txt file and stashed away for a rainy day.
> >Say:
> >--
> >project(test)
> >
> >add_executable(test
> >test.cpp
> >)
> >--
> >When needed, these are unzipped in the RAMDRIVE and compiled there. Use
of ramdrive makes it easy to just copy the resulting exe and do the cleanup.
> >
> >With 2.4.2, the CMakeSetup has started to fail while recognizing the
source files, saying that "can not find file g:test.cpp", where g: is the
ramdrive. This happens for within-source & out-of-source builds. I have
tried using 'g:\', 'g:/', 'g:'
> >I have verified that this fails also in the other root directories, such
as c:\, d:\ etc.
> >
> >This used to work with the earlier versions, that's why I have several of
these.
>
> We need more information to debug this. Can you post a complete example
and instructions on
> how to run CMakeSetup to cause the failure?
>
> -Bill
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] EXECUTE_PROCESS too good at running programs
William A. Hoffman wrote: At 08:17 AM 7/22/2006, Brad King wrote: Brandon J. Van Every wrote: Ok, the CMake 2.4.2 documentation for the projectName version of TRY_COMPILE is only 3 short sentences. IIUYC, you are saying I'm going to have to write a CMakeLists.txt wrapper, and a subdirectory, for each and every tool like "makeinfo," if I want to prove that they work in the build. You can create a macro to wrap this all up. The source tree for the TRY_COMPILE can be created with FILE(WRITE) and FILE(MAKE_DIRECTORY). Regardless of the documentation, try-compile and not exec_process is what is supposed to be used for system introspection. The build time environment is often different than the cmake time environment, and if you are testing programs that will be run at build time, try-compile/try_run is the only way to do that. I assume that you are planning to run makeinfo at build time, so it should be tested at build time. Remember cmake is not a build tool, but rather a build generator, and is not running during the build. Ok, but given the shenanigans that must occur just to test if a tool works, the wrapped up functionality really should make it into CMake. I just can't abide that a user should have to do this much stuff to test a tool. I will write a macro and put it on the wiki. What is the process for getting user contributed macros into the Standard CMake Modules? That would be good information to have on the wiki, on this page: http://www.cmake.org/Wiki/CMake_User_Contributed_Macros Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMakeSetup broken, fails in the root directory
At 11:38 AM 7/22/2006, Dataflow wrote:
>Ok.
>1. Please put the following in CMakeLists.txt:
>project(test)
>add_executable(test test.cpp)
>
>2. Please put the following in 'test.cpp'
>void main(){}
>
>3. Please put both these directly in c:\ (not in a subdirectory. You can put
>in d:\, e:\ etc, but in the root directory.)
OK, found the problem. It seems to have been broken for some time now,
but the fix should make it in 2.4.3 when that is ready. It should be in
cvs soon, after I run all the tests.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] RPATH questions
I build modules with cmake which depend on external libraries which may be installed in non-standard locations. The modules also depend on cmake targets. These modules are checked at build time with a small application that dynamically loads them. These modules are also installed (possibly using a non-standard install prefix). Thus, the build-tree version and installed version of the modules need different rpaths. For the build-tree version I want to set an RPATH to access the directories of external libraries and the build-tree targets. For the installed version I want to set an RPATH to access the directories of the external libraries and the install-tree targets. If I simply specify the cmake targets and the fullpathname of the external libraries which the module depends on using TARGET_LINK_LIBRARIES will CMake automatically do what I want with RPATH? Or do I have to use some combinations of the RPATH-related properties specified in the man page for SET_TARGET_PROPERTIES. Or some combination of the two approaches? Any help to point me in the right direction would be appreciated. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMakeSetup broken, fails in the root directory
At 06:09 PM 7/22/2006, William A. Hoffman wrote: >OK, found the problem. It seems to have been broken for some time now, >but the fix should make it in 2.4.3 when that is ready. It should be in >cvs soon, after I run all the tests. I spoke to soon the fix worked with makefiles but not visual studio projects. It may take a bit longer... -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
