[CMake] BOOL type

Mike Jackson imikejackson at gmail.com
Tue Dec 18 10:14:43 EST 2007



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


More information about the CMake mailing list