Re: Included .rsrc dependencies ignored
Re: Included .rsrc dependencies ignored
- Subject: Re: Included .rsrc dependencies ignored
- From: Allen Cronce <email@hidden>
- Date: Mon, 27 Mar 2006 17:49:08 -0800
Thanks for the response Chris. But I ended up doing something different,
which I'll cover here for closure sake.
Basically since rez dependencies are broken for .rsrc files, but not for
.r files, I extended the shlib projects' existing run script build
phases to call DeRez to create a .r file. Then I changed the
application's .r to # include the resulting generated .r files instead
of the .rsrc.
So I added something like this to the shlib run script:
# Derez the .rsrc file so that other projects can include it. Works
around a dependancy problem where .r files include .rsrc files.
/Developer/Tools/DeRez -useDF ${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.rsrc
> ${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.r
And the app's .r file looks something like this:
#ifdef DEBUG
#include "../../../BuildResults/Debug/shlib0.r"
#include "../../../BuildResults/Debug/shlib1.r"
#else // DEBUG
#include "../../../BuildResults/Release/shlib0.r"
#include "../../../BuildResults/Release/shlib1.r"
#endif // !DEBUG
This way when the shlibs rebuild, they recreate their corresponding .r
files, so the application that includes them gets the latest. And I can
control which set of resources are included by a conditional driven by
the build configuration.
This seemed to be the cleanest solution.
Best,
--
Allen Cronce
Chris Espinosa wrote:
On Mar 27, 2006, at 3:41 PM, Allen Cronce wrote:
Hi all,
It looks like Rez dependencies don't extent to included .rsrc files.
That is, if a .r file includes a .rsrc, and the .rsrc changes, the
dependency is not seen, Rez does not run and the updated resources
from the changed .rsrc file don't make it into the target. After
searching this list it looks like other people have run into this,
although it isn't clear how they worked around the problem.
Specifically in my case I've got a set of Xcode projects that
generate a set of shared libraries, who's executables in turn get
converted to resources for inclusion in another Xcode generated
application. This mimics what we did with CodeWarrior prior to
porting. It's a mechanism that predates packages, and changing it
will be a pretty big pain.
The problem is that we have debug and release variants of the shared
libraries and applications. I want the debug shlib resources to
appear in the debug app, and the release resources in the release app.
At first I thought that maybe I could conditionally include one set
of .rsrc files or another based on the build configuration. But I
can't figure out how to do that. It looks like I'd have to make debug
and release targets, which flies in the face of the build
configuration approach.
So I tried including the "right" set of resources via a conditional
in a .r file that includes either the debug or release .rsrc files.
But that doesn't work reliably because changes made in a shared
library and subsequent generated .rsrc file don't fire the rez
dependancy, so they don't make it into the app.
And I don't want to always touch the .r file because that will mean
an endless stream of meaningless check in's to our source code
control system. I guess I could auto generate the .r file and add a
.cvsignore to prevent it from going into CVS. But I'd have to stop
vomiting first ;-)
Anyway, I'm hoping that I've missed something here and that there's
an easy way to get Xcode to pull in any changed .rsrc files on a per
build config basis.
Unfortunately this is a known problem that isn't fixed in Xcode 2.2.
You can use the "touch" command to touch your master .r and force it
to be recompiled when your backing .rsrc files change.
Another possibility is to write your own Run Script Build Phase that
uses /Developer/Tools/ResMerger to merge your .rsrc files. You can
list them as input files to the script, and the script will run
whenever the input files change.
You could even get clever and just write the script to touch your .r
file, and let the ResourceManager Resources build phase do the rest.
Chris
_______________________________________________
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
_______________________________________________
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