[Cmake] suggestion for FindTclsh

[Bill Hoffman]

Well, to be compatible with older cmakes and several projects I think we have to live with:
1. WIN32 the windows api is available 
2. UNIX the unix api is availaible 
3. CYGWIN and WIN32 and UNIX, you are on cygwin and there is no MFC


I think the vxl CMakeList.txt files should be changed and perhaps add a MFC_SUPPORT variable.

# in the top level vxl file 
# assume no MFC support 
SET(MFC_SUPPORT 0) 
# add MFC support if win32 and not cygwin and not borland 
IF(WIN32) 
IF(NOT CYGWIN) 
IF(NOT BORLAND) 
SET(MFC_SUPPORT 1) 
END(NOT BORLAND) 
ENDIF(NOT CYGWIN) 
ENDIF(WIN32)


Removing WIN32 is a bad idea. cygwin does support the win32 api, just not MFC, they are different things. VTK builds with cygwin using the win32 api, without MFC. At some point, a win32 api gui could be done for vxl and then you would have to add it back.
Then change all of the IF(WIN32) stuff to IF(MVC_SUPPORT) in the vxl cmakelist files. There can not be that many of them can there?

-Bill


At 12:56 PM 6/10/2002 -0400, you wrote:
>Jim,
>
>I'm not suggesting that WIN32 be unset for anyone else against their will.  All I'm saying is that
>for VXL, you can unset WIN32 in Cygwin and get a good clean build that does not use the windows API,
>and I like to do this.  One of the only noticeable side-effects was this problem I had with
>FindTclsh.  I'm not suggesting that FindTclsh be changed for my sake, butt seems to me that it makes
>more intuitive sense to trigger FIND_PROGRAM(TCL_TCLSH cygtclsh80) off of CYGWIN instead of ( WIN32
>&& UNIX ).
>
>Using a cmake MFC variable to control the use of MFC sounds like a good idea.  I started with this
>approach in VXL but abandoned it.  There were too many obscure places where having WIN32 (cmake or C
>preprocessor variable) was taken to mean that MFC was also present.  I didn't think I could fix it
>all without a big risk of messing up other peoples builds.
>
>Fred
>
>> -----Original Message-----
>> From: Miller, James V (Research) 
>> Sent: Monday, June 10, 2002 11:33 AM
>> To: 'Bill Hoffman'; Wheeler, Fred (Research); CMake 
>> developers (E-mail)
>> Subject: RE: [Cmake] suggestion for FindTclsh
>> 
>> 
>> I'd have to look at our code, but I think we use Win32 
>> threads under cygwin
>> instead of using pthreads.  So all our code that triggers off 
>> of WIN32 being set
>> does the right thing under VC and cygwin.
>> 
>> So rather than unsetting WIN32, I would suggest triggering 
>> off an MFC variable
>> for the MFC specific code.
>> 
>> 
>> 
>> -----Original Message-----
>> From: Bill Hoffman [mailto:bill.hoffman at kitware.com]
>> Sent: Monday, June 10, 2002 11:22 AM
>> To: Wheeler, Fred (Research); CMake developers (E-mail)
>> Subject: Re: [Cmake] suggestion for FindTclsh
>> 
>> 
>> The Win32 API is available for cygwin.  It is just MFC that 
>> is not available.  
>> 
>> -Bill
>> 
>> 
>> At 11:14 AM 6/10/2002 -0400, Wheeler, Fred (Research) wrote:
>> >I think that this section from FindTclsh.cmake (indentation added)
>> >
>> >  IF(WIN32)
>> >    IF(UNIX)
>> >      FIND_PROGRAM(TCL_TCLSH cygtclsh80)
>> >    ENDIF(UNIX)
>> >  ENDIF(WIN32)
>> >
>> >should be changed to this
>> >
>> >  IF(CYGWIN)
>> >    FIND_PROGRAM(TCL_TCLSH cygtclsh80)
>> >  ENDIF(CYGWIN)
>> >
>> >I have found it convenient and quite helpful to unset WIN32 
>> to compile VXL in Cygwin.  One
>> >side-effect is that this prevents cygtclsh80 from being 
>> found using the above, since WIN32 is unset.
>> >I realize that unsetting WIN32 may be unusual.  Still, I 
>> think the change suggested makes things more
>> >readable and makes more intuitive sense.  (WIN32 seems to 
>> imply that the Windows api is available.
>> >Same for UNIX.  cygtclsh80 is not in the intersection of the 
>> windows and Unix apis.)
>> >
>> >Just a suggestion.  Take it or leave it.
>> >
>> >Thanks,
>> >Fred Wheeler
>> >_______________________________________________
>> >Cmake mailing list
>> >Cmake at public.kitware.com
>> >http://public.kitware.com/mailman/listinfo/cmake 
>> 
>> _______________________________________________
>> Cmake mailing list
>> Cmake at public.kitware.com
>> http://public.kitware.com/mailman/listinfo/cmake
>> 
>_______________________________________________
>Cmake mailing list
>Cmake at public.kitware.com
>http://public.kitware.com/mailman/listinfo/cmake