floor wax vs. dessert topping chosen via build style
floor wax vs. dessert topping chosen via build style
- Subject: floor wax vs. dessert topping chosen via build style
- From: Joseph Goldstone <email@hidden>
- Date: Mon, 19 Jul 2004 21:28:23 -0700
I am developing libraries and command-line tools for a client who wants
everything statically linked, with delivered libraries in
/usr/local/lib, headers in /usr/local/include/<clientname>, binaries in
/usr/local/bin/<clientname> and sources in /usr/local/src/<clientname>.
To speed development, though, I am trying to start with frameworks that
bundle up headers and dylibs. I'm happy having these development
versions live in my build directory (actually I set my build and
intermediate directory to be below /var/tmp so my nightly backup of my
home directory, wherein exists the projects themselves, doesn't bloat).
That way I can happily use Zerolink, fix 'n' continue, etc and zip
right along.
Since there's no new project type called "BSD framework" I just make a
Cocoa framework and ignore the Cocoa-ness. I modified the stock
development and deployment build styles slightly (using the inspector
UI):
Development:
COPY_PHASE_STRIP = NO;
FRAMEWORK_SEARCH_PATHS = /var/tmp/Xcode;
GCC_DYNAMIC_NO_PIC = NO;
GCC_ENABLE_FIX_AND_CONTINUE = YES;
GCC_GENERATE_DEBUGGING_SYMBOLS = YES;
GCC_OPTIMIZATION_LEVEL = 0;
HEADER_SEARCH_PATHS = "/usr/local/include/OpenEXR
/usr/local/include/WildMagic2 /usr/local/include/boost-1_31
/usr/local/include/cppunit";
LIBRARY_SEARCH_PATHS = "/usr/local/lib
/usr/local/lib/WildMagic2/Debug";
LIBRARY_STYLE = DYNAMIC;
OTHER_CPLUSPLUSFLAGS = "-DLP_DEV";
PREBINDING = NO;
ZERO_LINK = YES;
Deployment:
COPY_PHASE_STRIP = YES;
GCC_ENABLE_FIX_AND_CONTINUE = NO;
GCC_GENERATE_DEBUGGING_SYMBOLS = NO;
HEADER_SEARCH_PATHS = "/usr/local/include/<clientname>
/usr/local/include/lp /usr/local/include/OpenEXR
/usr/local/include/WildMagic2 /usr/local/include/boost-
1_31 /usr/local/include/cppunit";
LIBRARY_SEARCH_PATHS = "/usr/local/lib/<clientname> /usr/local/lib/lp
/usr/local/lib/WildMagic2 /usr/local/lib";
LIBRARY_STYLE = STATIC;
PREBINDING = NO;
ZERO_LINK = NO;
There's a framework target (which was generated when I asked for a new
Cocoa framework project), and then there's a command-line test harness
that I created by first adding a BSD shell tool target, and then adding
a BSD C++ class file to that target. [This is just a Carbon C++ class
with the Carbon refs removed.] The framework is like this:
DYLIB_COMPATIBILITY_VERSION = 1;
DYLIB_CURRENT_VERSION = 1;
FRAMEWORK_VERSION = A;
GCC_GENERATE_DEBUGGING_SYMBOLS = NO;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = Quaternions_Prefix.pch;
HEADER_SEARCH_PATHS = "";
INFOPLIST_FILE = Info.plist;
INSTALL_PATH = "$(HOME)/Library/Frameworks";
LIBRARY_STYLE = DYNAMIC;
PRODUCT_NAME = Quaternions;
WRAPPER_EXTENSION = framework;
isa = PBXNativeTarget;
name = Quaternions;
productInstallPath = "$(HOME)/Library/Frameworks";
productName = Quaternions;
productType = "com.apple.product-type.framework";
and the command-line tool is like this:
INSTALL_PATH = /usr/local/bin;
OPTIMIZATION_CFLAGS = "";
OTHER_CFLAGS = "";
OTHER_LDFLAGS = "";
OTHER_REZFLAGS = "";
PRODUCT_NAME = Harness_Quaternions;
SECTORDER_FLAGS = "";
WARNING_CFLAGS = "-Wmost -Wno-four-char-constants
-Wno-unknown-pragmas";
isa = PBXNativeTarget;
name = Harness_Quaternions;
productName = Harness_Quaternions;
productType = "com.apple.product-type.tool";
I have three questions.
(1) Is it possible to get the target that came as the Cocoa framework's
initial target to produce a dynamic library when compiled with the
development build style, but a static library when compiled with the
deployment build style? The "Xcode Build System" document suggests
that build style settings will trump target settings, but the build
style setting for "deployment" of
LIBRARY_STYLE = STATIC;
seems to have no effect. (There was a message from Brian Barnes to
this list on June 12th - ish #462 - to similar complaint, but with no
answer.) Or does the target productType of
com.apple.product-type.framework trump even build style settings?
(2) Why when I try and build the library target under the deployment
build style do I get
Ld /private/var/tmp/Xcode/Quaternions.framework/Versions/A/Quaternions
cd "/Volumes/Users/joseph/src/lp/C++ experiments/Quaternions"
/usr/bin/g++-3.3 -o
/private/var/tmp/Xcode/Quaternions.framework/Versions/A/Quaternions
-L/private/var/tmp/Xcode -L/usr/local/lib/tdi -L/usr/local/lib/lp
-L/usr/local/lib/WildMagic2 -L/usr/local/lib -F/private/var/tmp/Xcode
-filelist
/private/var/tmp/Xcode/Quaternions.build/Quaternions.build/Objects-
normal/Quaternions.LinkFileList -framework Cocoa -lIex -arch ppc
ld: Undefined symbols:
_main
when I'm building a library? Where's that reference to main coming
from? And shouldn't there be a -static or -static-libgcc in there
somewhere?
(3) Supposing I manage to make this hermaphroditic .dylib/.a target...I
then want to similarly be able to build the command-line tool so that
if built and run under the development build style, it uses the .dylib
library, but if built and run under the deployment build style, it uses
the .a library. If I put the hypothetical .dylib/.a product into the
Frameworks build phase of my command-line tool, can I have the
development and deployment styles use carefully chosen
FRAMEWORK_SEARCH_PATHS and LIBRARY_SEARCH_PATHS to pick out the right
library at build time?
-=-
The alternative seems to be to have separate targets for framework and
static library, and be sure that additions of new headers and sources
are always done in parallel; and separate targets for framework-using
and static-library-using command-line tools. I can go that way (I
think) but it would be nice to have two targets representing the
conceptual objects (library and tool) with build styles doing
everything else.
Thanks, all, for light any of you might be able to shed on this.
--joseph
[apologies if this has been already covered; I trudged fairly carefully
through the last 5 weeks of this list.]
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.