Re: the bloody Omni frameworks
Re: the bloody Omni frameworks
- Subject: Re: the bloody Omni frameworks
- From: Ryan Dingman <email@hidden>
- Date: Fri, 2 Aug 2002 21:20:16 -0700
On Friday, August 2, 2002, at 08:26 PM, James Winetke wrote:
I'm intrigued by the alleged OACalendarView class, but I just wasted my
whole afternoon trying and failing to get the Omni frameworks built.
I'm not coming at this blind -- I've written some frameworks of my own
and loaded them into my own projects' bundles successfully, so I know
about the "@executable_path/../Frameworks"/SKIP_INSTALL=YES hack, and
I've been over the archives of both cocoa-dev and macosx-dev trying
to find people with similar failures (there are plenty of Omni
framework failures in the archives to choose from).
At every turn, OmniBase builds successfully, and then OmniFoundation
fails to compile its first file because it can't find
<OmniBase/rcsid.h>.
I haven't reached OmniAppkit yet.
In Project Builder, go to Preferences. Select the "Building" section.
Under "Build Results", choose "Separate location for build products"
and set it to something like:
~/BuildOutput
The second radio button can be set to which ever you like. This is how
Omni (along with many other developers) build their source and it will
allow the Omni frameworks to correctly find their dependencies (since
the are reference "build product relative"). It keeps your source tree
free from build output and allows you to build source which depends on
source without having to install the built product on which it depends
first.
To prove I wasn't crazy, I created a tiny project from scratch, dragged
in the OmniBase framework, imported <OmniBase/rcsid.h> and it built
flawlessly.
Your new project is likely reference OmniBase in which OmniFoundation
references it. OmniFoundation references OmniBase "build product
relative". Your new project was likely referencing it as an "absolute
path". If you were to move OmniBase to another location and then build
your new project from clean then your project would also fail to build.
So I'm not crazy, but I'm completely frustrated, not least by
Omni's indifference to documentation.
They aren't indifferent to documentation. They released this source
code for free as a service to the community. They likely have a lot on
their plate and cannot justify writing documentation for source code
from which they derive no income. After all, it is free ;)
I'd love to save myself the trouble of building my own calendar view,
but
if this horror show has been any indication of how much care Omni puts
into its code, I'd be much better off starting from scratch.
Omni's code is generally pretty good. I think that you are
over-reacting. Much of your trouble is due to some misunderstandings
with Project Builder's reference styles and how things get built.
I'm using the December 2001 developer tools, but I tried building these
frameworks on a friend's 10.2 6C105 system, where OmniBase itself
wouldn't build. That's wasn't a dependency problem as far as I could
see.
If the April tools will fix this problem I'll gladly update, with 10.2
just around the corner anyway.
As for OmniBase not building on 6C105, this is due to the use of gcc3
on 6C105. OmniBase defines a macro in a manner which works around some
strangeness in cpp-precomp. gcc3 doesn't use cpp-precomp and this
workaround breaks. The macro should be defined as follows on 6C105:
#define NSSTRINGIFY(name) @ ## #name
Hope this helps,
ryan
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.