Question About XCode and Static Carbon Libraries
Phil Rogers
the inevitable switch to XCode. I will spare everyone the gory details
but let it suffice to say that I almost threw up my hands in frustration
and simply gave up. This was not really an option so after putting it
off for 18 months I am finally making the attempt to get switched over
to XCode. One thing that I have always noticed about Apple's
documentation is that it is very good at getting a new user from a dead
stop up to 1-2 mph and it is exquisitely superb once you get up to
cruising speed but it is totally lacking in the needed documentary
descriptions and tutorials to take you from that first start up to the
point where you can actually use their software effectively for
something useful. It is not just XCode but I have also noticed the same
problem with DVDSP and FCP documentation. Hello World is simply
not enough to get a start in using XCode so something else is needed.
In my case, most of my projects depend on the use of 15-20 of my
75 some odd static libraries that I have developed over the years.
With a fair amount of effort I was able to get the largest and most
essential of these to compile as an XCode project but so far I have not
found any place in the XCode documentation that describes in simple
terms how to include libraries into a main project (Carbon app).
After several months of trial and error I finally figured this out and
was able to come up with a test app and dependent library that was in
reality just an enhanced version of Hello World. (Its too bad that Apple
doesn't provide a series of intermediate tutorials like this to show how
to do things in the real world like they do with their exhaustive
samples of using Carbon itself). What I am uncertain of is whether
I am actually doing this correctly. Before I get too far down the road,
I want to find out because unlike CodeWarrior, I get the impression
that with XCode it is easier to start out with a new project than it is to
modify, rename and reconfigure an existing project (I could be wrong
but have not gotten far enough to know yet).
With CodeWarrior I set up two folders where I always placed the top
level header and library files respectively for all of my libraries.
Then it was s simple matter to include these folders in the CW search
paths. I see that XCode also has provisions for specifying search paths
but still have not figured out how to use this (It includes symbolics
that I do not yet understand). I tried the same thing with XCode and by
individually dragging each header file and library to the main project
I was able to get the project to build and run properly. Then came the
need to include the library project as a main project dependency. Using
the same piecemeal approach I was able to get the main project to depend
on the library subproject but something I encountered along the way gave
me the impression that when adding a dependent subproject to a main
project, XCode had the capability to import all header and library
references and file locations from the subproject. If this were the case
then it would be simpler to just leave all my headers and libraries in
their respective project folders and to just let XCode find them at the
time of the addition of each subproject to a main project. I gave this a
try with my simple enhanced version of Hello World (dragging the
subproject file into the main project) but XCode could not find the
dependent header and library files. Afterwards I finally found the
section in the XCode documentation on "The Build System" but as usual,
Apple's documentation moved so quickly into the tiny details that I
never did find what I was looking for. Still later I tried building my
enhanced Hello World as a CodeWarrior project and then tried to import
it into XCode so that I could see how it established the dependencies
but that import failed probably because the CW project was not a Mach
project. At this point I think that it is going to be easier to just
start from scratch in XCode than to have to take the time figure out how
to convert everything in CW to be Mach projects but I still need to find
out how dependencies really work in XCode.
I'm sorry for my windy description (brevity is not my strong point)
but I think it all boils down to the following questions:
1) Is XCode capable of extracting subproject header and library file
references from added subprojects and if so where in the documentation
are the basics of this capability described?
2) Can anyone suggest any good tutorials, books or examples (I always
prefer examples over books) that take the learning XCode user from a
very slow walk up to a trot?
For the record I am using XCode 1.5 on 10.3.9 (can't go with XCode 2
or 10.4 yet because I still rely heavily on half a dozen Classic apps that
have no X counterparts and I was never able to get Classic to run on
10.4 - I wasted several weeks trying too). After spending 20 years
developing with MPW and CodeWarrior and 15 years before that with
development systems on a variety of mainframe and mini OSes I am finding
that XCode, while apparently very powerful and versatile, is the most
difficult to learn development system that I have ever encountered.
If I am having difficulty with this switch then I can only imagine how
difficult it must be for the real newbies who are just starting out from
the very beginning. I suppose that is the price we pay for something
that is free though. My thanks to anyone who can help get me moving
in the right direction.
Phil Rogers
--
Patrick Machielse
[]
> I'm sorry for my windy description (brevity is not my strong point)
> but I think it all boils down to the following questions:
>
> 1) Is XCode capable of extracting subproject header and library file
> references from added subprojects and if so where in the documentation
> are the basics of this capability described?
First off, Xcode is mainly a gui around the GCC tool chain. (although it
does provide its own native build system). Having some basic knowledge
on GCC will help you figure out what Xcode is doing, and will also help
you understand the build settings.
Xcode doesn't use the terminology 'sub-projects'. Instead, an Xcode
project can contain multiple 'targets' (f.i. an application target, a
static library target, etc.). You can specify the dependencies between
targets in each target's settings.
If you have installed your static libs in /usr/local/lib and your
headers in /usr/local/include you can just point to those locations in
your target's build settings (Search Paths). When the lib is a target in
your project, you can simply add the lib and the header files directly
to your application target.
> 2) Can anyone suggest any good tutorials, books or examples (I always
> prefer examples over books) that take the learning XCode user from a
> very slow walk up to a trot?
Surprisingly there are quite a number of Xcode books. I don't own any of
them, but at least one of them should suit you.
> For the record I am using XCode 1.5 on 10.3.9 (can't go with XCode 2
> or 10.4 yet because I still rely heavily on half a dozen Classic apps that
> have no X counterparts and I was never able to get Classic to run on
> 10.4 - I wasted several weeks trying too).
This should work just fine. Works for me at least...
> After spending 20 years
> developing with MPW and CodeWarrior and 15 years before that with
> development systems on a variety of mainframe and mini OSes I am finding
> that XCode, while apparently very powerful and versatile, is the most
> difficult to learn development system that I have ever encountered.
A while back there was an ugly thread here with the same theme, but with
a lot of mud flying around. I'm glad that you are so much more eloquent
;-)
Xcode is a work in progress (esp. the old version you use). Apple is
under pressure to make it work better, esp. for large projects. Having
the latest version really helps a lot.
patrick
Phil Rogers
> Phil Rogers <pro...@nospam.com> wrote:
>
> []
Thanks for your reply. It wasn't quite what I had expected but as such
it may get me to looking at the things I had overlooked.
> > I'm sorry for my windy description (brevity is not my strong point)
> > but I think it all boils down to the following questions:
> >
> > 1) Is XCode capable of extracting subproject header and library file
> > references from added subprojects and if so where in the documentation
> > are the basics of this capability described?
>
> First off, Xcode is mainly a gui around the GCC tool chain. (although it
> does provide its own native build system). Having some basic knowledge
> on GCC will help you figure out what Xcode is doing, and will also help
> you understand the build settings.
I think I already grabbed a copy of the GCC docs from the ADC site when
I was looking for how-to info. I was saving it for later when I needed to
get down to the nitty-gritty details but will go ahead and take a look now.
That may also be where the symbolics I was talking about are described.
> Xcode doesn't use the terminology 'sub-projects'. Instead, an Xcode
> project can contain multiple 'targets' (f.i. an application target, a
> static library target, etc.). You can specify the dependencies between
> targets in each target's settings.
This explanation may be the greatest help of all and is a real departure
from the CodeWarrior way of thinking. Up until now I had thought that
I already knew what a target was and just skipped over those parts of
the XCode documentation as something that could wait until later.
It looks like I need to go back and take another look at the XCode docs
looking in particular at the parts concerning targets and also to look
again at the XCode from a CodeWarrior perspective document with
this same new knowledge in mind.
> If you have installed your static libs in /usr/local/lib and your
> headers in /usr/local/include you can just point to those locations in
> your target's build settings (Search Paths). When the lib is a target in
> your project, you can simply add the lib and the header files directly
> to your application target.
I really do like that a lot. It looks like a pair of ready made directories
for the same purpose as the header and libraries folders I had created
for use in CodeWarrior. This may have to wait until later though since
it isn't readily obvious how the hidden Unix directories can be accessed
via either the Finder or file dialogs (such as placing a given header file
into /usr/local/include for the first time). The GCC docs may help here.
> > 2) Can anyone suggest any good tutorials, books or examples (I always
> > prefer examples over books) that take the learning XCode user from a
> > very slow walk up to a trot?
>
> Surprisingly there are quite a number of Xcode books. I don't own any of
> them, but at least one of them should suit you.
I have seen many of them that concentrate on the Cocoa approach but
few that deal mostly with Carbon. I originally came into programming
after working as a mainframe hardware engineer for many years so
I definitely have a procedural mentality since everything at the hardware
level is strictly procedural. The object oriented approach is built as an
abstraction on top of that and as such does not fit well with my natural
way of thinking. Maybe I can find a suitable book by looking back at all
the ADC newsletters over the past few years.
> > For the record I am using XCode 1.5 on 10.3.9 (can't go with XCode 2
> > or 10.4 yet because I still rely heavily on half a dozen Classic apps that
> > have no X counterparts and I was never able to get Classic to run on
> > 10.4 - I wasted several weeks trying too).
>
> This should work just fine. Works for me at least...
It certainly does seem that it should work since Apple has not yet officially
dropped Classic support. Actually you are the first person I have encountered
who has actually said that they have made Classic work under Tiger. There
are many web sites describing problems of getting Classic to work under Tiger.
It seems that there are two main problems, 1) the presence of a MacTCP DNR
file in the OS 9.22 system folder and 2) the presence of aliases in the Apple
Menu Items folder. My problem seems to be somewhat different, especially
after eliminating the above as possible problem sources. The above causes
are supposed to result in a Classic crash midway during Classic startup but
what I am seeing is that Classic gets to the point just before the first extension
icon is displayed on the startup screen and it freezes permanently. After
first encountering this problem, I tried again with clean installs of 4 different
versions of Tiger from 10.4.0 to 10.4.6 combined with all possible variants
of 4 different 9.22 system folders and the results were always the same.
This included the system folder I had been using for years, a stripped down
9.22 Base version of the same, a clean copy of the 9.22 folder on disk 3
of the 10.3.7 disks that came with my G5 and one other bare bones 9.22
folder that I had gotten from somewhere unknown. I tried each of them
as is and also with MacTCP DNR and all aliases stripped out with the same
results. What are you using as your 9.22 folder and where did you get it?
Maybe I will have better luck with Leopard but my intuition tells me that if
an unknown problem has arisen with no solution found then it will probably
continue to exist in future versions of X. It would certainly solve a few
problems if I actually could get Classic to run under Tiger and beyond.
> > After spending 20 years
> > developing with MPW and CodeWarrior and 15 years before that with
> > development systems on a variety of mainframe and mini OSes I am finding
> > that XCode, while apparently very powerful and versatile, is the most
> > difficult to learn development system that I have ever encountered.
>
> A while back there was an ugly thread here with the same theme, but with
> a lot of mud flying around. I'm glad that you are so much more eloquent
> ;-)
>
> Xcode is a work in progress (esp. the old version you use). Apple is
> under pressure to make it work better, esp. for large projects. Having
> the latest version really helps a lot.
I've been away from this newsgroup for a couple of years but have taken
a look from time to time and think I know the type of discussion that you
are referring to. Trolls and prima donnas are present in every newsgroup
and always exist for such ugliness just to hear themselves complain but in
many cases I'm sure that some of the comments were probably sincere
expressions of frustration at something that is obviously vastly different
from CodeWarrior. Apple is no longer the small friendly company that it
was 20 years ago (I was told that my 1987 letter to Apple about the dealer
where I bought my first Mac went all the way to John Sculley's desk)
and they do have problems that they continue to ignore such as that
infuriating spinning beach ball. They do seem to be trying however and
as you point out, Xcode is a work in progress. Personally I do not find
XCode to be nearly as intuitive as CodeWarrior at a first glance but all
things new seem unfamiliar until you have spent enough time with them
to understand them better. I am really trying to keep an open mind about
XCode until I can reach that point because with the death of CodeWarrior,
XCode is really the only open path to the future. When I started out with
the Mac OS I was spending about 25% of my time staying about 5 years
behind Apple, but now I am spending 95-98% of my time doing the same
thing with precious little time to go into the truly creative side of software
development that makes it so rewarding. I may still become yet another
casualty of Apple's repeated and frequent reinvention of the wheel but
for now I am going to try to make one more attempt to get going again.
Thanks again for your help.
Phil Rogers
********
David Phillip Oster
In article <260820061616461912%pro...@nospam.com>,
Phil Rogers <pro...@nospam.com> wrote:
> It certainly does seem that it should work since Apple has not yet officially
> dropped Classic support. Actually you are the first person I have encountered
> who has actually said that they have made Classic work under Tiger. There
> are many web sites describing problems of getting Classic to work under
> Tiger.
I have never had any trouble with Classic on Tiger on multiple PPC
machines, some upgrade installs, some factory-installed with Tiger.
http://www.uneasysilence.com/archive/2006/08/7352/ documents using free
software to get Classic to run in a window on Intel Macs.
Reinder Verlinde
> This may have to wait until later though since
> it isn't readily obvious how the hidden Unix directories can be accessed
> via either the Finder or file dialogs (such as placing a given header file
> into /usr/local/include for the first time).
In the Finder, do Go => Go to Folder..., type the full path to the
directory you want to see (e.g. "/usr"), and hit Return.
From the terminal, the command "open {path}" will instruct the Finder to
open a window on {path}. {path} can be relative; "open ." will open a
window showing the contents of the current directory.
> The GCC docs may help here.
I doubt it. gcc does not even know about the existence of the Finder.
Reinder
Ralph Wickenhöfer
Try "Cocoa Programming for MAC OS X" from Aaron Hillegass. It did a
good job for me.
ralph
Phil Rogers
> My apologies, since htis s getting off topic.
>
> In article <260820061616461912%pro...@nospam.com>,
> Phil Rogers <pro...@nospam.com> wrote:
>
> > It certainly does seem that it should work since Apple has not yet officially
> > dropped Classic support. Actually you are the first person I have encountered
> > who has actually said that they have made Classic work under Tiger. There
> > are many web sites describing problems of getting Classic to work under
> > Tiger.
>
> I have never had any trouble with Classic on Tiger on multiple PPC
> machines, some upgrade installs, some factory-installed with Tiger.
I will keep this brief since you are right that it getting a bit off topic.
Here are three links I have bookmarked regarding the Classic on Tiger
problems that other people have experienced:
> http://www.computing.net/mac/wwwboard/forum/10967.html
I really did think that I had many more than just three of these bookmarked
but the following Google search link returns over 500 links to various
other Classic on Tiger problems (not all of which are applicable).
They do indeed exist:
> http://www.google.com/search?hl=en&q=%2B%22classic+problems%22+%2B%22tiger%22&btnG=Google+Search
The first of these Google links shown below is one that I had not seen
before and sounds much more like the problem I was having than some
of the others. The suggested solution of trashing the Classic prefs file
sounds like a good move although it may not work in my case since
I was doing clean installs of everything as mentioned before and thus
the Classic prefs file would probably not have had a chance to become
corrupted. Still it is worth a try and I am usually open to try almost
anything. Will try this next time around.
> http://www.macworld.com/forums/ubbthreads/showflat.php?Cat=0&Number=363033&an=0&page=4
Phil Rogers
--
Phil Rogers
> In article <260820061616461912%pro...@nospam.com>,
> Phil Rogers <pro...@nospam.com> wrote:
>
> > This may have to wait until later though since
> > it isn't readily obvious how the hidden Unix directories can be accessed
> > via either the Finder or file dialogs (such as placing a given header file
> > into /usr/local/include for the first time).
>
> In the Finder, do Go => Go to Folder..., type the full path to the
> directory you want to see (e.g. "/usr"), and hit Return.
That is really beautiful... so simple and easy. I had completely forgotten
about that Finder command since the days when I was new to OS X and
got the impression that it was somewhat out of place in a GUI environment.
Evidently there really is a good use for it. Thanks for the reminder.
Phil Rogers
--
Patrick Machielse
> Patrick Machielse wrote:
>
> > If you have installed your static libs in /usr/local/lib and your
> > headers in /usr/local/include you can just point to those locations in
> > your target's build settings (Search Paths). When the lib is a target in
> > your project, you can simply add the lib and the header files directly
> > to your application target.
>
> I really do like that a lot. It looks like a pair of ready made directories
> for the same purpose as the header and libraries folders I had created
> for use in CodeWarrior.
This is the way it has been (forever?) in UNIX. Maybe that's another
shift you have to make in your mind: (Classic) Mac -> UNIX
> I definitely have a procedural mentality since everything at the hardware
> level is strictly procedural. The object oriented approach is built as an
> abstraction on top of that and as such does not fit well with my natural
> way of thinking.
Depending on how low level your applications work, procedural
programming will not go away. However, if you want to develop a gui
programs for the Mac, it is strongly advised to move to Cocoa. If so, it
seems you have a number of 'paradigm shifts' on you plate:
(Classic)Mac -> UNIX underpinnings
Procedural (C) -> Object-oriented (Objective-C)
CodeWarrior -> Xcode
Carbon -> Cocoa
Bon appetit!
> > > For the record I am using XCode 1.5 on 10.3.9 (can't go with XCode 2
> > > or 10.4 yet because I still rely heavily on half a dozen Classic apps that
> > > have no X counterparts and I was never able to get Classic to run on
> > > 10.4 - I wasted several weeks trying too).
> >
> > This should work just fine. Works for me at least...
>
> It certainly does seem that it should work since Apple has not yet officially
> dropped Classic support. Actually you are the first person I have encountered
> who has actually said that they have made Classic work under Tiger.
I don't have it installed _now_, but it has always worked flawlessly,
and because it is OS 9, it's only a drag and drop install away (love
that feature!). I think it may even be 9.2.1. My situation is different
from yours though, because I have a G4 machine that can run OS 9
natively. I simply installed the OS direclty from the system disk.
> I may still become yet another casualty of Apple's repeated and frequent
> reinvention of the wheel but for now I am going to try to make one more
> attempt to get going again.
I'd say: move to Xcode first, then learn Cocoa. Carbon isn't going away
(most software sales are still Carbon based, I think), but you won't
have a front seat on the trip to future. I've seen a bit of the (near)
future, and both Xcode and Cocoa/Obj-C won't disappoint you by spring
;-)
patrick