On 22.12.2010 08:34, Manolo Gouy wrote (in fltk.bugs):
>>> 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 */

> 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
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to