On 21.12.2010 18:45, Manolo Gouy wrote: >> Problem: >> 1. On OSX, FLTK (1.3) includes draw in OSX specific Objective-C/C++ 2.0 = >> include files, that can only be compiled with Apple supplied GCC = >> variants. Apple-GCC seems to be stuck at versions 4.0 and 4.2. >> >> 2. The included OSX headers also cause name collisions with some = >> software that has not been designed to include OSX-specific header = >> files. For example, there is a name collision with "Cell" as defined by = >> the included OSX headers and "Cell" defined in GNU Octave. This at least = >> when compiling 64-bit, have not tested this with 32-bit. >> >> 3. It would be great if it was possible to use FLTK also with non-Apple = >> GCC versions, especially when compiling portable (non-OSX) code, that = >> relies on FLTK for UI portability (which I presume is the whole point = >> with FLTK !) >> >> Solution: >> > > The point you raise is interesting.
Yes, I also read it with interest. It reminded me of the name clashing problems with X11, namely 'Window', especially, but IIRC not only in fltk 2.0. > We would need sort of 2 mac.H, > one included by FLTK client applications, and one included > when compiling the library itself. I'm not sure how to do that > properly. If it is only because something should not included, this would be easy to achieve with the definition of a macro. We do even have such a macro already (FL_LIBRARY), see FL/Fl_Export.H: # if defined(FL_DLL) # ifdef FL_LIBRARY # define FL_EXPORT __declspec(dllexport) # else # define FL_EXPORT __declspec(dllimport) # endif /* FL_LIBRARY */ ... > But I want to point out that client applications don't include > any objective-c (or objective-c++) header files. As you report, > they include<Carbon/Carbon.h>. Do you see problems in compiling this > with non Apple-supplied compilers? If no, the problem would > only be of name collisions. I can't tell what it's all about here, but I think that the way that was chosen to avoid similar problems with X11 was to split the source (and maybe header) files so that X-specific headers are only included in files that are compiled for the library, but not in header files that are included by/in user code... Albrecht _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
