Brandon J. Van Every wrote:
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
I am finding it nearly impossible to write such a macro in practice.
The problem is that a custom COMMAND has no understanding of native
CMake paths. So I must convert the paths to a native format, and
FILE(TO_NATIVE_PATH ...) does not properly escape and quote the path
for use by COMMAND. Also, the COMMAND string needs to be saved
somehow. It needs to be used by TRY_COMPILE, and again by my
CMakeLists.txt, so that I'm doing exactly the same thing each time.
Saving the string is problematic because passing the string around
tends to destroy the quoting. I have put a full work day into this,
for what should be a fairly trivial tool test, and I still don't quite
have something that works. I may yet come up with an interface that
does work, but I definitely wouldn't expect most CMake users (even
experienced ones) to go through all this pain.
What I'm saying is, tool testing is very weak in CMake, and a better
way is needed. When/if I get to the end of this tunnel, I will make a
specific recommendation rather than just complaining.
Cheers,
Brandon Van Every
|
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
