[Cmake] EXEC_PROGRAM and subdirs
klaas.holwerda
kholwerd at xs4all.nl
Tue Sep 14 11:56:53 EDT 2004
Brad King wrote:
>
> Most cmake commands are "inherited" into subdirectories, but certain
> commands such as EXEC_PROGRAM are not. The idea is that any command
> that actually performs an action outside CMake such as EXEC_PROGRAM or
> CONFIGURE_FILE is not inherited because we do not want it to execute
> from the subdirectories. Other commands such as IF and SET are
> inherited so that their results are available for subdirectories to use.
Indeed i want to use the result, which looks like a normal variable. How
this type of result can be inherited or not depending on the command
that produces it, is not really clear to me.
The statement is not used in subdirs. But it must be some kind of
"inherited: feature as you say ;-)
>
> All of this is due to historical reasons. It was not originally
> expected that EXEC_PROGRAM would be used in a way that would affect
> the flow of CMake code evaluation. The original version of the
> command did not have an OUTPUT_VARIABLE argument. When the argument
> was added the command was not made inherited.
>
> Eventually there will be a new methodology in place for listfile
> evaluation
What is meant by that?
> order which will resolve this problem. For now you will have to find
> a work-around for the problem. You can probably save some information
> in an internal cache entry so that it is available from the
> subdirectories also.
I tried copying the EXEC_PROGRAM its OUTPUT_VARIABLE into an internal
variable.
But the there is no change in behaviour. As soon as i make it a normal
variable, the Makefile contain exactly what is expected. But with the
result is coming from the EXEC_PROGRAM, the top Makefile is oke,
but the lower level subdirectories or wrong ( taking the wrong part of
an IF ).
The IF is not in a subdir either, it is all happening in the
topdirectory, so it stays really strange to me :-(
For the moment if added an option to make it work without using
EXEC_PROGRAM.
And i wait until this problem is resolved eventually ;-)
Thanks for the help!
Klaas
More information about the Cmake
mailing list