[CMake] ok guys, why is configure_file() so sucky?

[Alexander Neundorf]

On Wednesday 17 August 2011, David Cole wrote:
> On Wed, Aug 17, 2011 at 10:32 AM, Bill Hoffman <bill.hoffman at kitware.com> 
wrote:
> > On 8/17/2011 10:17 AM, Andreas Mohr wrote:
> >> [cue maximally inflammatory subject ;)]
> >> 
> >> Hi,
> >> 
> >> I keep encountering template file processing where
> >> @VAR@ replacements end up empty due to the required template
> >> variable simply not having been set (or empty) [or renamed away].
> >> Doh.
> >> 
> >> I'd strongly vote for configure_file() to fail hard in such cases,
> >> _by default_.
> >> Build system life is already hard enough without all those nice
> >> "features" of incomplete/insufficient commands (especially in the
> >> packaging area I seem to keep hitting more holes
> >> than actual functionality :-P).
> >> 
> >> So:
> >> - change configure_file() behaviour to fail a CMake configure run hard
> >>   in case of unavailable (_not_ "empty") @var@ (and perhaps ${var}?),
> >>   and have this be the _default_ setting
> >> - add configure_file() flag to optionally _disable_ this hard failure
> >>   in case it's actually unwanted
> >> - add configure_file() flag to optionally enable hard failure for the
> >>   other case of existing yet empty variables, too
> >> - add policy around this new highly useful feature
> >> - hmm, but these things {w|sh}ould apply to both ${xx} and @xx@ - do we
> >> need
> >>   to have some configuration to tell behaviour apart?
> >> - anything I've missed that should be added/changed for a more suitable
> >>   implementation?
> >> - add these things to a new bug# for implementation
> >> 
> >> Done Deal?
> > 
> > far from...  :)
> > 
> > If you did that, I am guessing, almost any cmake project using
> > configure_file would hard fail.  Many projects use empty as a value. This
> > is a huge backwards compatibility can of worms... :)
...
> We could do it without a policy and without a can of worms if we
> simply add a new command instead of trying to re-use the existing,
> perfectly reasonable configure_file command.
> 
> Or... by defaulting to the existing behavior and requiring the use of
> a new flag to configure_file or setting a variable to indicate the new
> STRICT behavior. (I assume you'd be more in favor of a new command
> since you said you want this to happen by default.)

I'd vote against a new command. It would be mostly the same as 
configure_file(), with only a small change.
 
> One of the main problems with flagging empty variables as "empty" is
> that sometimes you intend a variable to be empty... So really, only an
> undefined variable should be considered an error.

Yes, I think so too.
Having a variable empty should be fine.
With a policy to fail if a configured variable is not defined, this should be 
safe, shouldn't it ?

An option @FATAL_ERROR or @FAIL_ON_UNDEFINED would be also safe, but I doubt 
many projects will go through their files and add that everywhere.

Alex