Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: Blue and yellow folders...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Blue and yellow folders...

And another thing... :-)

You may be wondering why you would use a folder ref vs. a group.

In general, I always default to using groups unless I have reason to do otherwise. You must use a group if the things inside it will have to be members of a target (so, for a folder full of source files, you really want a group so that you can add the source files to your target(s)). This is because the things inside a folder ref are not really "part of the project" and therefore cannot be acted on separately.

There are a couple times when a folder ref can be necessary or useful.

The first is when the folder is just one big "Resource" of your project. For example, say I have an application that has a whole directory of online help that it installs within its Resources folder inside its bundle. You might set this up with groups and file refs for each help file, but this is a pain because now you probably have to have several Copy Files build phases that copy the different help files into your bundle with the appropriate hierarchy, basically mimic'ing the structure of the help files folder in your project. Also, as you add or remove these help files, you must update the project as well. Alternatively, you can add the Help folder as a folder reference, then add the folder reference to your Bundle Resources build phase. Now, when the app builds, it will always copy the whole folder into the app's bundle. You can even make the folder ref a localized resource (which will move the entire folder into your English.lproj and allow it to be translated as one unit.)

Another, and possibly more obscure, use for folder refs is when you are using PB as a editor/builder/debugger environment for a legacy project. For example, say you wanted to work on the gcc compiler, but you wanted to do it in an IDE? Well, you don't want to try to convert gcc into a native PB project because it already has a build system that everyone who works on it uses and if you go changing that, you will be out of synch with the rest of the world. So, instead you can make use of a Legacy target and a folder ref to kind of "wrap" the existing build system and project structure so that you do not have to change it, but you can still use PB. You would create a folder reference to the top-level directory of the project. This allows you to browse the whole project structure, open and edit files, do textual or regex based searches from PB, etc... Then you would create a legacy target that executes the native build system for gcc. This allows you to build the project too. Finally, if you set up a custom executable for your legacy target, you can even run and debug. The benefit of a folder ref over a group hierarchy here is that since many people who modify the project do not use ProjectBuilder, you do not have to continually make sure to add and remove files as others add and remove them from the project. The folder ref just shows what's on the disk, even after you resynch with the FSF sources and files appear or disappear. In fact, this is not an idle example... several of the folks on the compiler team here at Apple have done what I describe here and (at least sometimes) use PB to develop gcc.

Mike Ferris

References: 
 >Re: Blue and yellow folders... (From: Mike Ferris <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.