Appendix L - FBtoC
FBtoC is the translation component of the FutureBasic package. Before using FutureBasic version 5 onwards along with FBtoC, you should have installed Apple's free Developer Tools (a.k.a. Xcode Tools), from your MacOS X install CDs or DVD.
The cross-development SDKs must be installed to create universal binaries. Also, only the native architecture of your Mac can be built unless the SDKs for prior (meaning releases prior to the one active where FutureBasic is installed) MacOS X releases are installed. The Finder view (below) of the Developer folder shows the optional MacOS X 10.4 and MacOS X 10.5 SDKs after installation on MacOS X 10.6. Cross-development is an optional part of the Xcode Tools install (from the MacOS X DVD or CDs):
See Apple Documentation for more information about cross-development.
The FBtoC settings dialog is self-documenting by virtue of the titles, help tags, and grouping of the controls.
- What should I do with all those build_temp folders created by FBtoC?
Command-delete works well for me. But why delete them so soon? If you have the 'Use precompiled header' checkbox ON, build_temp folders contain, er, the precompiled header. It's that huge file FBtoC.h.gch, used by the compiler as a cache.
- Why do I get warnings like this from the compiler?
/Volumes/HD2/FBtoC/build_temp/Blah.c: In function 'SendHandleMessageToLog':
/Volumes/HD2/FBtoC/build_temp/Blah.c:3027: warning: passing argument 1 of 'BlockMoveData' makes pointer from integer without a cast
/Volumes/HD2/FBtoC/build_temp/Blah.c: In function 'FBToCResourcesCopy':
/Volumes/HD2/FBtoC/build_temp/Blah.c:3955: warning: passing argument 4 of 'GetResInfo' from incompatible pointer type
FutureBasic version 4 and its predecessor releases were weakly typed; and made little distinction between pointers and other 4-byte vars such as longs. C is more strongly typed, and the compiler complains when the wrong 4-byte type is used. These warnings are nearly always harmless and can nearly always be ignored. These warnings can be eliminated by typing variables correctly and not relying on FutureBasic's weak typing. Cleaning up the compiler warnings helps identify (often there is a long list of warnings) any warnings that DO need to be addressed, so cleaning up even harmless warnings can be beneficial.
- I know my compilation failed because it says so at the end, but I can't find the compiler error among the horrible spew of warnings.
Suppress the spew by typing this into 'More compiler options' in FBtoC's settings dialog:
- Sometimes I get two sets of identical warnings from the compiler. Why?
A Universal app is built by compiling the C source twice: once with -arch ppc and the other with -arch i386.
- Namespace collision
Q: For some reason there is a problem with FN InstallControlEventHandler for the attached demo. The compiler keeps complaining that there are supposed to be six parameters and it only has one. I've looked at the C code and there are six parameters. I have no idea why it won't take it.
A: InstallControlEventHandler is the name of macro in Carbon. You have a function in your code with the same name. You'll have to rename it, for instance to MyInstallControlEventHandler.
- WTF does "void value not ignored as it ought to be" mean?
/Volumes/HD2/FBtoC/Test Files/build_temp/Demo.c: In function 'main':
/Volumes/HD2/FBtoC/Test Files/build_temp/Demo.c:1680: error: void value not ignored as it ought to be
You are trying to get a return value from a pure procedure. Here's an example from CoreGraphics.
include "Tlbx CoreGraphics.incl"
dim as CGImageRef myImage
// legal but pointless in FutureBasic; illegal in FBtoC
something = fn CGImageRelease( myImage ) // <-- void value not ignored as it ought to be
// this syntax avoids the error and is legal in both FutureBasic and FBtoC
fn CGImageRelease( myImage )
// illegal in FutureBasic; legal in FBtoC
call CGImageRelease( myImage )
CGImageRelease( myImage )
- My program won't quit
Change your event loop.
until 0 // never quits
until ( gFBQuit ) // ah, that's better
- Compiling C code Independent of FBtoC (not recommended but possible)
Is it possible to make minor changes to the C code in the "build_temp" folder using XCode and then have FBtoC run directly from the modified "build_temp" folder without going through the original FutureBasic code?
There's no official way, but this workaround isn't especially challenging.
 Turn on the 'Log UNIX commands' checkbox in FBtoC preferences settings.
 In FBtoC, open your project and wait until compilation finishes.
 Optionally edit the *.c files in the relevant build_temp folder.
 From your FBtoC Log window, copy the 3 consecutive blue lines beginning with cd, gcc, and touch. For example:
gcc -I/FutureBasic/FBtoC/FBtoC_Preview1a117/build_goodies /Users/username/Desktop/build_temp/untitled_1.c -fpascal-strings -framework Carbon -framework QuickTime -framework IOKit -o /Users/username/Desktop/untitled\ 1.app/Contents/MacOS/untitled\ 1 -mdynamic-no-pic -trigraphs -Wall -Wno-trigraphs -Wno-sequence-point -Wno-multichar -Wno-deprecated-declarations -Wno-unused-label -Werror-implicit-function-declaration -O0 -pipe -gused -Wl,-dead_strip 2>&1
touch /Users/username/Desktop/untitled\ 1.app
 Paste these lines into Terminal.app to replicate the compilation step of the FBtoC build.
- FlushWindowBuffer with FBtoC
Window flushing is very different in a Mach-O app (as produced by FBtoC) compared with a legacy CFM app (as produced by FBCompiler.app). A Mach-O app takes advantage of a Carbon optimization called "coalesced updates".
The special first parameters for FlushWindowBuffer (_FBAutoFlushOff, _FBAutoFlushOn and _AutoFlushPrint) are therefore neither defined nor needed in FBtoC.
Please change your code to:
#if ndef _FBtoC
FlushWindowBuffer _FBAutoFlushOff // FutureBasic sees this; FBtoC does not
- Why aren't all the error messages this good?
... Not yet implemented by FBtoC in line 25 of Demo.bas: use #if/#else/#endif instead
25: compile long if 1
No answer has been received for this FAQ.