> > > This FL_LIBRARY may be exactly what is needed to solve cleanly this > > issue. But what exactly is it used for at this point ? > > I see it set ONLY in src/CMakeLists.txt. Does it mean that not any > > makefile use it ? > > It is also used in the MSWindows IDE project files. You can read in > documentation/src/intro.dox: > > "When compiling an application or DLL that uses the FLTK DLL, > you will need to define the \p FL_DLL preprocessor symbol > to get the correct linkage commands embedded within the FLTK > header files." > > > It would be useful for this issue if FL_LIBRARY is defined when > > compiling the library, but not when compiling an application > > that uses the FLTK public API. Is it possible to use it this way? > > This is the intention, AFAICT, and I thought that it was used this > way already, but this seems only to be true for the MS ide projects. > > I wonder whether we can successfully build the Windows dll's with > GNU compilers (MinGW) ... > > Anyway, we should document this somewhere, and then we can define > FL_LIBRARY in FLTK source files and #include header files after > this define. The header files can then distinguish whether they > are included in a FLTK source file or in user code. > > I don't know whether it's feasible, but we can also add a macro > definition to FLTK's compiler commands (in the Makefiles or in > makeinclude), but this must /not/ be done in fltk-config. ;-) > We should check this for the next release to do it The Right Way. > Meanwhile you could define it in some specific source files that > might need it. > > But please beware: as Ian said, I would also not be keen on defining > our own system structures in our header files. IMO this mechanism > should *only* be used to /exclude/ some definitions (or #include > statements) from user code. Otherwise we should split the source > and header files that deal with system internals so that these can > include whatever they need, but user code doesn't see it. I can > see similar efforts in the X11 source and header files. > > Sorry, I can't be more concrete at this point, but I hope you get > the idea... > > Albrecht
I have prepared (locally) changes in the Mac OS X support to allow client applications to be compiled without use of the Mac OS- specific #include files. This solves the problem of using non-Apple compilers (which does not seem very important). But it is also an improvement because client applications will typically not use Mac-specific code, so it's not optimal that they have to include all Mac OS #includes. The file FL/mac.H is much modified, but apart from that very few other changes are needed. The symbol FL_LIBRARY is used to differentiate between client and library compilations. Files src/Makefile and makeinclude.in are modified to define FL_LIBRARY during library compilations. The Xcode project has also been modified accordingly. Thus only CMake builds remain to be taken care of. The new FL/mac.H file contains: #ifdef FL_LIBRARY #include <Carbon/Carbon.h> .. all Mac OS-specific declarations ... .. among which the Fl_X class ... #else .. very few declarations needed by the FLTK public API ... #endif The only difficulty is to accomodate for the type of the few variables (such as fl_gc) that are part of the public API, but are typed in a system-specific way. The solution I found is this: #ifdef FL_LIBRARY #include <Carbon/Carbon.h> typedef CGContextRef Fl_CGContextRef; #else typedef struct fl_opaque_context* Fl_CGContextRef; #endif extern FL_EXPORT Fl_CGContextRef fl_gc; This way, client applications don't use any Mac OS-like declarations, and can also include Carbon.H if they use system code. If there's no flaw in this new organization, and if the idea that FL_LIBRARY be defined by build systems before the compilation of any FLTK source file is correct, I would like to commit these changes. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
