[Cmake] Re: Carbon, Cocoa, X

[William A. Hoffman]

I like the idea of CMAKE_WINDOWING_API:
   X11, CARBON, COCOA, WIN32

The platform file could list the available types for the OS.
This would fix both cygwin and OSX with one solution.
Of course, it would also be useful to add an option type variable
into cmake so the cmake gui's could limit the choices presented
to users.



-Bill


At 01:42 PM 4/3/2004, Yves Starreveld wrote:
>Folks,
>
>I'm glad that we may be finally converging on an optimum solution.
>
>What about the BUILD_TYPE approach, such as that used to choose between 
>the Debug, Release, RelWithDeb... etc.
>
>That way one could define a CMAKE_OSX_BUILD_TYPE:STRING
>Which could be either X11, Carbon, or Cocoa.
>
>Comments?
>
>Yves
>On 2-Apr-04, at 12:35 PM, Chris Scharver wrote:
>
>>On Apr 2, 2004, at 10:40 AM, Bill Hoffman wrote:
>>
>>>Here is cvs cmake:
>>>   IF (OPENGL_gl_LIBRARY)
>>>     INCLUDE( ${CMAKE_ROOT}/Modules/FindX11.cmake )
>>>     IF (X11_FOUND)
>>>       IF (NOT APPLE)
>>>         SET (OPENGL_LIBRARIES ${X11_LIBRARIES})
>>>       ENDIF (NOT APPLE)
>>>     ENDIF (X11_FOUND)
>>>   ENDIF (OPENGL_gl_LIBRARY)
>>
>>This does prevent X11 libraries from linking even if they're found. 
>>However, this also presents a problem when I DO want to link with X11. I 
>>like to choose whether to use X11 or not via CMake without having to 
>>manually edit the CMakeCache.txt file. When working with windowing code, 
>>I routinely build both x11 and Cocoa versions. Leave it to us Mac users 
>>to make everything screwy. ;)
>>
>>>However, a more consistent approach to the multi-platform platform is 
>>>needed.
>>>It is almost like  cygwin on windows, but that requires a different cmake.
>>>We could have an environment variable, but I really hate them...
>>
>>It is a little uglier with cygwin since that can qualify as a completely 
>>different environment. X11 on MacOS X isn't the same since it can be 
>>considered part of the OS. I find that having a simple CMake option that 
>>I can toggle whether I want to use X11 or not works pretty well. This 
>>still requires the user to do something extra, but I think that's a lot 
>>better than resorting to environment variables. It's cleaner than digging 
>>into CMakeCache.txt too.
>>
>>>Any ideas on how to best do this are welcome...
>>
>>A while ago there was some mention of future support for multiple-choice 
>>OPTIONs. Rather than setting USE_CARBON, USE_COCOA, and USE_X11 variables 
>>exclusively, it would be great to have just a single option that can only 
>>be set to one of a specific set of values. Any CMake modules that require 
>>drawing into a GUI could then reference some kind of WINDOW_GUI variable. 
>>Available values could be X11, Win32, Carbon, or Cocoa. This would make 
>>it easy for modules to check the current build type. FindTclTk could thus 
>>make sure that Carbon is being used rather than Cocoa. Cygwin builds 
>>could check whether to use X11 or mingw.
>>
>>In summary, I think that the flexibility available on current systems 
>>makes it reasonable to separate the choice of windowing API from the 
>>platform since several platforms can target multiple APIs. CMake and any 
>>modules could then follow a uniform process for checking the current 
>>target's windowing system.
>>
>>Chris
>>
>>--
>>Chris Scharver
>>Electronic Visualization Laboratory
>>The University of Illinois at Chicago
>>Ph: 312-996-3002   FAX: 312-413-7585
>><http://www.evl.uic.edu/scharver/>