Re: [CMake] ok guys, why is configure_file() so sucky?
On Wednesday 17 August 2011, David Cole wrote:
On Wed, Aug 17, 2011 at 10:32 AM, Bill Hoffman bill.hoff...@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
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] ok guys, why is configure_file() so sucky?
[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?
Thanks,
Andreas Mohr
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ok guys, why is configure_file() so sucky?
Agree on all points!
-Johan
On Wed, Aug 17, 2011 at 4:17 PM, Andreas Mohr a...@lisas.de 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?
Thanks,
Andreas Mohr
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ok guys, why is configure_file() so sucky?
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... :)
-Bill
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
