Re: Xcode 3 not switching subproject executables
Re: Xcode 3 not switching subproject executables
- Subject: Re: Xcode 3 not switching subproject executables
- From: Steve Mills <email@hidden>
- Date: Tue, 6 Nov 2007 17:08:09 -0600
On Nov 6, 2007, at 16:49:20, Chris Espinosa wrote:
Steve, as long as you think of them as "subprojects," you're going
to be banging your head against the desk and filing bugs that will
be marked "Behaves Correctly" and returned to you, because Xcode
does not have a notion of "subprojects."
Well, that's really the best name for a project that builds a static
lib or framework that is included in a main project.
Projects can refer to each other and have dependencies on each
other, but this doesn't enforce a hierarchical relationship. When
we say "cross-project dependencies" we're not being mealymouthed or
avoiding trademark infringement. They're not subordinate in any way.
When you build one configuration of a target, any targets on which
it depends (in that or other projects) are automatically build,
using the same configuration if there is a configuration with the
identical name. So building the Debug configuration of your app
target will build the Debug configuration of a framework target if
and only if:
a) the framework needs building
b) the framework target appears as a dependency of the application
target
c) the framework target also has a Debug configuration
That's how our projects have been set up for years. All projects use 2
and only 2 configs of the same names, Debug and Release. Most of what
I will call subprojects build static libraries which the main project
links to and uses. Only one of them builds an OS X PDE .plugin.
The problem is that Xcode has always had a *bug* in that it will not
tell the subprojects to use the config that is currently in use by the
main project when it was opened. Now it seems to be worse in 3.0. I
can no longer simply change to the other config in the main project,
wait for it to go through all the files, switch back to the config I
want, wait again, and build. Doing this does not FIX the product
dependencies. In order to fix it, I have to open all the subprojects,
check them out, change to the correct config, close them, go back to
the main project, switch configs, wait, switch back, wait, and THEN it
will build correctly. With all the waiting going on while Xcode goes
through the files, this can easily kill 5 minutes of my day, 5 minutes
that I can't afford because of a long-standing bug that is now worse.
When it comes to executables, there are no cross-project connections
whatsoever. If you build a framework and want to debug it, you
either have to switch to the app project and launch or debug the
app, or create a custom executable in the framework project that
points to the built app.
This is not what we're doing here.
Custom executables don't follow build configurations in other
projects. That's probably your problem. When you build and launch
your app from the app project, it'll launch the product built by the
current configuration. But when you build a framework and launch
the custom executable that points to the app, it points to something
via absolute path, which may be the Debug version, may be the
Release version, may be the Installed version, whatever you set it
up to be. So you see how you can easily get into a situation where
you build a framework, think you're launching the app that's linked
to it, but be launching something else entirely, and you don't get
the new behavior you just coded (and may not be able to link at all).
I guess we're using the term "executable" in different ways. I mean
"the resulting product, whether it be a static lib (which does execute
at some point) or a framework." Sorry, I guess I should be saying
"product".
We know this is very confusing; it's grown organically over a decade
and needs a complete overhaul (which will break the entire project
model and UI, so we're not eager to spring it on you right away).
We know this is a problem and will have a better solution in the
future,
Hopefully it will be soon. It's been an annoying time waster for a
long time.
Steve Mills
Drummer, Mac geek
http://sjmills5.home.mchsi.com/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden