On Nov 6, 2007, at 1:52 PM, Steve Mills wrote: Previous versions of Xcode had a horrible bug in that it would not use to the correct subproject executables. Opening project A that is currently set to build the Debug config would not set subproject B to the same config, so if subproject B was set to Release and you built project A, you'd get an error that it couldn't find libProjectBRelease (if that was the name of the executable built by the Release config of subproject B). I reported this as radar://4408351, which was marked as a dupe of radar://4770438.
Now in Xcode 3 it seems to be worse. I currently can NOT get it to figure out which executables to use. It's acting completely stupid. In 2.4 and earlier, I could simply switch to the other config, then back, and it would knock sense into Xcode and it would build against the correct subproject executables. Now that doesn't even work. I've even tried opening the subprojects, setting them to the correct config, and closing. (Of course that doesn't work, because Xcode still insists on having the project.pbxproj checked out in order for it to save changes to the .pbxuser file. How much longer are we going to have to put up with THIS incredibly annoying design flaw?)
Anybody know a way around this? Any way to knock some sense into Xcode 3 without having to open all the subprojects, check them out, change their config, go back to the main project, switch configs, switch back, and build?
I'm going to reopen 4408351, or I guess I should report a new one instead, since Radar doesn't show me the state of the referenced bug (also annoying, as has been discussed many times). radar://5583305 (wrong exec) and radar://5583320 (can't save .pbxuser) now reported.
Arg.
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."
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
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.
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).
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,
Regards,
Chris |