On Dec 18, 2007, at 10:07 AM, James Bigler wrote:
On Dec 18, 2007, at 7:48 AM, Bill Hoffman wrote:
James Bigler wrote:
I also agree that trying to maintain backwards compatibility to
the detriment of the future can become a hinderance. I just had
a collegue who was extreemly frustrated for several hours with
why his build didn't work, only to discover that he should have
been using ADD_SUBDIRECTORIES instead of SUBDIRS. There was no
warning from CMake stating that he shouldn't be using it (I would
argue that CMake should warn about the use of SUBDIRS).
That would be lots of warnings! SUBDIRS was the only way to do
things for a long time. CMake itself still uses them so it can be
bootstrapped with older versions of CMake. SUBDIRS still works,
it just works different. The behavior of both are documented.
"The ADD_SUBDIRECTORY command should be used instead of SUBDIRS
although SUBDIRS will still work."
There isn't a mention in the docs that SUBDIRS behaves differently
to ADD_SUBDIRECTORIES in the man page, just that it should work.
Part of the problem with my collegue is that he was copying code
from another part of the build system. He was new to cmake and
hadn't read the whole man page. He just assumed the one way he
found to traverse subdirectories was the one to use. It's really
confusing to have two ways to do basically the same thing with only
subtle differences.
I guess my argument is that changing syntax shouldn't be shied away
from, but it would be nice to have a way to flush out old code.
Would it be possible to emit a warning when commands like subdirs are
used? The warning is built into cmake and emits every time cmake is
run? This would help motivate people to move to the newer commands?
I know this has ramifications that I am not thinking of..
Mike
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
