Re: Deleting build products & intermediates for all projects on a volume
Re: Deleting build products & intermediates for all projects on a volume
- Subject: Re: Deleting build products & intermediates for all projects on a volume
- From: "Louis C. Sacha" <email@hidden>
- Date: Thu, 8 Apr 2004 05:58:23 -0700
Hello...
As Scott mentioned, you can change the default location for either or
both the intermediate build files and the built products. This can
either be a really cool feature, or the ultimate incarnation of hell
on earth, depending on the way you work. Specifically, using a shared
location for the intermediate build files can result in all kinds of
bizarre results if you tend to make copies of existing projects,
either for versioning or as stationary.
* * * at the moment, almost all of my projects are ProjectBuilder
projects updated by XCode which still use the old style targets...
it's possible that using XCode native targets will avoid this problem
(I really hope so) * * *
For example, you have a project for YourApplication 1.0d1, and you
decide to save a copy of that version, and start working on
YourApplication 1.0d2... At some point, you go back to the 1.0d1 copy
of the project, change a couple of lines of code in one file and
build it to check something. The resulting built product will be a
hybrid version of the two projects, using mostly the compiled code
from the 1.0d2 version with just the 1.0d1 version for the particular
file that you changed and any files that don't exist in the 1.0d2
version. Then, if you go back to version 1.0d2 of your project,
unless you make changes to the 1.0d2 version of the file you changed
in 1.0d1, when you build the 1.0d2 version it will keep using the
existing compiled 1.0d1 version of that file.
If you use a base project that you make copies of for new projects,
for example a shell app for testing specific bits of code, every test
app that is a copy of that project will use the same folder to store
its files in the shared intermediate build location. Unless you make
an effort to fix each test app after copying the project (see below),
or make sure to clean any test app project you use each time you
build it, the built product will be a combination of all of those
projects, whichever version of each file was most recently compiled
since the last time any of those projects were cleaned.
This can be prevented by changing the "Base Product Name" for each
and every copy you make (which must be done within XCode, not just
renaming the project file), which results in a new folder being
created in the intermediate build location, but you have to remember
to do it for every version or copy you make. If you are making new
projects, as long as the name you use when creating the project is
different from your existing projects you won't have a problem, but
if you make a new project with the same name as an existing project
you might run into some of the same issues.
Again, at this point, nearly all of my Xcode projects still use the
old style targets from PB and not new native targets. I'm hoping that
these issues don't exist with new projects using XCode native
targets, but it's going to be a while before I'm ready to tackle
converting most of my projects.
The moral of this story -- if you are going to use a shared
intermediate build location, make sure to clean your projects
frequently, especially if are using projects originally created in
project builder or if you like to make copies...
Louis
Notes:
(1) ProjectBuilder had several similar issues when using a shared
location for intermediate builds, except they were more of a random
thing. Most of the time things would work exactly how they were
supposed to and it was relatively rare that problems would occur, but
when they did it would usually cause significant problems... For
example, sometimes specific files would not be recompiled even though
they had been changed, which would sometimes result in truly bizarre
behavior that made it nearly impossible to figure out what was
happening. So most of the time everything would work just fine, and
then occasionally everything would blow up (or sometimes fail so
subtly that it would result in a bunch of wasted time trying to debug
a nonexistent problem). At least with XCode the behavior is
consistent :)
(2) If you are still running ProjectBuilder 2.01 (and possibly 2.1,
but I haven't checked, since a 300MB download would take way too long
just to confirm a bug), it's a good idea to clean any project you
download from an untrusted source before building it and running the
result. ProjectBuilder 2.01 has an interesting "feature" where you
can remove a .m file from a target (and even delete the source files
for it) but the compiled code from that file will still be included
in the built product unless the project was cleaned. This could
allow a malicious person to execute arbitrary code on your computer
without your knowledge, even if you have read every line of source in
the project. There are people out there who think this kind of thing
is fun (ie "My view class is really simple with just a few lines of
code, and it compiles fine, but it doesn't draw correctly... Could
you please look at the project and tell me what I'm doing wrong?"...
+ (void)load {[PhatB0Y allURfilezBg0ne];}), although it is far more
likely that you'll end up screwing yourself up because of this (ie "I
know I removed that category, but somehow my _insert_expletive_
here_ code is still broken !!!"). This particular exploit does not
seem to exist in XCode.
the simplest way to do this is to keep them in a central
location (XCode allows for this).. then you can cull that directory
anytime you need.
your test scripts and stuff probably shouldn't be kept in the
build directory, but in a subdirectory of the source, and you can
even add them to the project if you want.
_______________________________________________
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.