I'm thrilled to see FLTK being cocoa-ized.
- Ian is right that the errors he reports come from
#if MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_5
typedef long NSInteger;
typedef unsigned long NSUInteger;
#endif
being skipped during his compilation. But MAC_OS_X_VERSION_MAX_ALLOWED
is used in Carbon FLTK in file Fl_mac.cxx, so FLTK should already have
found a way to handle these preprocessing directives adequately in make builds?
I had tested Xcode compilations with SDKs from 10.3.9 to 10.6
and make compilations under 10.5 and 10.6, but could not test make
builds under other OS versions.
A secure, but not completely satisfying, solution would be to use long instead
of NSInteger and unsigned long instead of NSUInteger in
file Fl_cocoa.mm.
- Since running make on the new CVS source produces a Cocoa build,
I understand your intention is to have Cocoa builds by default.
Then, shouldn't you add
#define __APPLE_COCOA__
in file ide/Xcode3.1/config.h
As things are now, Xcode builds are Carbon-based because they use the
above-mentionned config.h
- Presently, 64-bit make builds, with
make CC="gcc -arch x86_64" CXX="g++ -arch x86_64"
fail on 2 files: Fl_Preferences.cxx and fl_draw_pixmap.cxx.
The first case is my fault: I had silently modified this file, that is
without flagging changes with #ifdef __APPLE_COCOA__. I upload a corrected
Fl_Preferences.cxx file.
The second is a little mystery because the error occurs only
with make builds and not with Xcode builds, although both use the same
compiler command. The error is at line 339
U32* colors = d.byte1[*p++];
that assigns a pointer to a 64-bit value to a pointer to 32-bit values. This
statement
should be set to
U32* colors = (U32*)d.byte1[*p++];
where the cast is made explicit. This is completely unrelated to
Carbon vs. Cocoa, but related to 32-bit vs. 64-bit compiles, and is the single
place in all of FLTK where such issue arises.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
