2007/6/9, Oliver Kullmann <[EMAIL PROTECTED]>:
Eric Noulard wrote:> I think, that with some amount of time (not so much) for defining > your own WHATEVER_EXECUTE CMake MACROs > you'll get the power of what you add before > with shell running in Makefile. Should be possible; definitely it looks better than macro definition in makefiles. > You may try my example with the attached file > and run > cmake -P python_execute.cmake > This example is a toy example, I am sure you > may accomplish something far better and useful. When using "/usr/bin/python" in the script, I get MYVAR = todays year is:2007 ERROR = however with the script as given, which doesn't find a python interpreter, > /usr/sfw/bin/python bash: /usr/sfw/bin/python: No such file or directory I just get MYVAR = ERROR = > echo $? 0 No error? (Apparently error output didn't work?)
Yes it does but I did not do all the check I need to do. The fact in my example ERROR contains stderr of the EXECUTED process but here the error is th EXECUTION ITSELF failed. So you get that in RESULT_VARIABLE of the EXECUTE_PROCESS and not in ERROR_VARIABLE, which is simply void because the process didn't run. Sorry about MY poor example. You'll find attached the modified CMake script which handles RESULT_VARIABLE as expected.
I know, it's always possible to write such scripts, but it's quite some work to make it work under many circumstances.
You are right but I think that you may take some time to write 1 to 5 robust CMake macros and then 'escape' the 'real' dynamic and tricky parts in your favorite programming language be it python, ruby, [t|z|ba]sh,
But I guess writing all kinds of "subroutines" should be much easier in cmake than in make.
This is definitely my opinion. -- Erk
python_execute.cmake
Description: Binary data
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
