Handling External Variables on NT under Yellow Box

By Bill Bumgarner at Codefab, Inc.

 

The WIN32 requires a really brain dead set of declarations to export symbols out of a framework; you can't just use the ANSI standard "extern" keyword... worse, it requires that the variable declaration *change* depending on whether or not you are exporting the variables to the framework containing the variables OR to an external consumer.

Neat, huh?

How to fix:

- drop this file in "Supporting files" in your Framework project: FrameworkDefines.template

- add this target to the end of Makefile.postamble:

$(DERIVED_SRC_DIR)/FrameworkDefines.h: $(DERIVED_SRC_DIR) PB.project Makefile

$(SILENT) $(ECHO) Creating FrameworkDefines.h from template.

$(SILENT) sed 's/<FRAMEWORK_NAME>/$(NAME)/g' < FrameworkDefines.template > $(DERIVED_SRC_DIR)/FrameworkDefines.h

- set these defines [changing as appropriate] in Makefile.preamble... most of these variables are defined in Makefile.preamble, so you will have to modify pre-existing definitions:

OTHER_CFLAGS = -DBUILDING_CodeFabRuntime_DLL

OTHER_PUBLIC_HEADERS = $(DERIVED_SRC_DIR)/FrameworkDefines.h

OTHER_PRODUCT_DEPENDS = $(DERIVED_SRC_DIR)/FrameworkDefines.h

OTHER_SOURCEFILES = $(DERIVED_SRC_DIR)/FrameworkDefines.h

Not exactly the most automated process in the world; we COULD modify Apple's makefiles and make all of the above become automatic-- but I'm hesitant to do so.... The OTHER_CFLAGS could definitely be automatically derived from the $(NAME) variable, but finding the right spot to stick it such that it is added to OTHER_CFLAGS AFTER NAME is defined is non-trivial.

b.bum


NOTE: Neither OTI nor Codefab warrant, guarantee, or otherwise assume any responsibility or accountability for any loss or corruption caused by any of the software or suggestions mentioned or available on this page. If something bad happens as a result of using this software, it's your own fault for using it. Please report any problems to bbum@codefab.com