Hi,
I have been searching this and similar newsgroup, googled, and read
developer.apple.com docs, but I still have what I believe to be a very
simple newbie problem, so I'm posting here.
I'm running XCode 1.5 on OSX 10.3.9, and I'd like to create a very basic
Framework, let's say, with a single simple class like this one:
/* Test.h */
class Test {
public:
Test( );
};
/* Test.cpp */
#include "Test.h"
Test::Test( ) { }
To accomplish this, I'm performing the following steps:
1. Create a new "Cocoa Framework" project, named TestFramework;
2. Create two Empty Files in the Classes group, Test.h and Test.cpp, as
above;
3. Build.
The building process terminates successfully.
After that, I was expecting to have, in the freshly created
TestFramework.framework directory, my header file somewhere within
Versions/A/Headers, and the linkable object somewhere around there too.
Instead I get nothing, actually no Headers directory even.
Can anybody please tell me what am I missing/doing wrong?
Thanks in advance.

Signature
Salvatore Iovene
Chris Hanson - 26 Nov 2005 20:48 GMT
> 1. Create a new "Cocoa Framework" project, named TestFramework;
> 2. Create two Empty Files in the Classes group, Test.h and Test.cpp, as
> above;
> 3. Build.
>
> The building process terminates successfully.
So far so good, though I'm not sure why you would be creating a Cocoa
framework and exposing a C++ API from it. But it shouldn't work any
differently from a Carbon framework.
> After that, I was expecting to have, in the freshly created
> TestFramework.framework directory, my header file somewhere within
> Versions/A/Headers, and the linkable object somewhere around there too.
> Instead I get nothing, actually no Headers directory even.
That's because you didn't tell Xcode that the framework had any public
headers. I'm assuming you're using the default interface layout for
Xcode. You want to select your target in the Groups & Files tree at
the left of the window. In the detail view to the right, you'll see
all of the members of that target, including your header file. Your
header file will have a pop-up menu in the "Role" column in the detail
view; it will be set to "project" indicating that the header is
strictly for use in-project. Change this to "public" and the header
will be copied to the built framework's "Headers" directory. Xcode
works this way because often, you only want to expose a subset of your
framework as API, you don't want to expose all of its internals.
Also, if you're building C++ dynamic libraries (including frameworks)
you need to know that Mac OS X did not get a stable user-level C++ ABI
until GCC 4. If you create a C++ dynamic library with an older
compiler, you will only be able to build clients of the library with
that compiler. If you want to support a dynamic library with a C++
API, I would recommend that you use GCC 4 with Xcode 2.x on Tiger to
create it.
-- Chris
Chris Baum - 27 Nov 2005 02:16 GMT
> Also, if you're building C++ dynamic libraries (including frameworks)
> you need to know that Mac OS X did not get a stable user-level C++ ABI
[quoted text clipped - 3 lines]
> API, I would recommend that you use GCC 4 with Xcode 2.x on Tiger to
> create it.
Can you pls. elaborate on the definition of 'stable' now that we
supposedly have a 'stable' ABI? What kind of timeframe are we talking
without breakage.
Sherm Pendley - 27 Nov 2005 04:51 GMT
>> Also, if you're building C++ dynamic libraries (including frameworks)
>> you need to know that Mac OS X did not get a stable user-level C++ ABI
[quoted text clipped - 7 lines]
> supposedly have a 'stable' ABI? What kind of timeframe are we talking
> without breakage.
Here's what the release notes say:
C++ applications compiled with GCC 4.0 will run only on systems where
libstdc++.dylib is installed. It is installed on all user systems that
run Mac OS X 10.4, or that run 10.3.9 or later. To target earlier systems,
use Xcode's SDK feature.
GCC 4.0 conforms to a multi-vendor C++ ABI, and Apple guarantees that
this ABI will be maintained in future compiler releases. However, this
ABI covers the core C++ langauge only, not the C++ runtime. Classes
defined in libstdc++ may change in an incompatible way in some future
compiler release, so for maximum compatibility, a dylib that is designed
to be compatible far into the future must avoid using libstdc++ features
anywhere in its exported interface.
Have a look at the release notes here:
<http://developer.apple.com/releasenotes/DeveloperTools/GCC4.html>
Also, the "C++ Runtime Environment Programming Guide":
<http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntimeEnv
/CPPRuntimeEnv.html>
<http://tinyurl.com/8f7w7>
sherm--

Signature
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
Chris Baum - 27 Nov 2005 09:32 GMT
> Have a look at the release notes here:
>
> <http://developer.apple.com/releasenotes/DeveloperTools/GCC4.html>
Thanks, this is really good news - once I can ditch 3.3.