Philip Lowman wrote:
So a few months back I was bored one night and dug through the CMake bug
tracker looking for something interesting. I came across a request from a
user to have CMake generate warnings when undefined variables are
encountered. I thought, gee, what a great idea. I've often been bitten by
variable name typo bugs before and why doesn't CMake simply give me a
warning like most scripting languages out there when an undefined variable
is used?
So I dove through the source to try to learn a bit more about CMake works
(and see how hard the patch would be to implement). It didn't look that
hard to do in the source so I messed around a little and implemented a small
patch to enable it. The major catch I discovered was that there are a lot
of places where people expect variables to be often undefined and some of
these places (i.e. FIND_LIBRARY) it would be unfeasible for a user to
introduce IF(DEFINED... ) logic so I introduced a variable keyword that
could be used to suppress the warnings. I don't like some of the things I
did in the patch looking back at it, but before I forget about it entirely
or consider working on it again I wanted to get some feedback from users
regarding this idea.
No comments?
I think it would be much better to implement this along with a command
(say, "DECLARE") that creates a list of variables that may be undefined
but shouldn't warn. This way FindXyz would "DECLARE(XYZ_LIBRARIES)".
This is IMO better because users don't get bitten for using a known
variable that is legitimately undefined, but still get the warning if
they misspell "XYZ_LIBRARIES", whereas by changing the means of
dereferencing you can still get bit by typos. (True you can still typo
the name to DECLARE(), but at least it's only in one place, and in the
case of variables set by modules, it's in the module, which is
presumably more maintainable due to having a canonical source.)
(An alternative to an explicit list is having a "defined" variable that
is set up in such a way that it is treated as undefined, but doesn't
warn... but that's an implementation detail that doesn't matter to users.)
--
Matthew
Oh, the double-entendre!
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
