Re: Dependency Checking Woes - Solution not quite right
Re: Dependency Checking Woes - Solution not quite right
- Subject: Re: Dependency Checking Woes - Solution not quite right
- From: Rush Manbert <email@hidden>
- Date: Fri, 17 Mar 2006 12:18:18 -0800
Rush Manbert wrote:
Scott Fraser wrote:
On Mar 17, 2006, at 03:44 AM, email@hidden wrote:
Perhaps something similar can be done in your case: have another
target that does nothing but touch one of your source files (a small
one, preferably) and have your main target depend on that. Every time
you press build, it should build one small file (mine is a two line
file containing two global variables, the date--in a particular
format--and the build number) and then link with your modified
libraries.
I used to do something similar in a multi-step MPW build script. The
intermediate target could touch, not one of your source files, but a
fake, empty source file that is part of your App target, and whose
only job is to be touched. Sounds like it should work.
Thank you Scott and Steve for your responses. That's a clever workaround.
I have been thinking about this approach for a bit and I think I can
almost get what I really want (relink when the library is rebuilt, not
every time) by doing this:
Add a Run Script build phase to the end of my library target. The script
would just touch a file called MyLibBuildProxy.cpp that lives in the
MyLib project directory. The script definition panel specifies no output
files, so it runs every time. This file is NOT added to the library
project, it just gets touched every time the library builds (in either
Debug or Release).
I add MyLib/MyLibBuildProxy.cpp to the MyApp target.
Every time MyLib gets rebuilt, the file gets touched. This triggers a
rebuild of MyApp. The remaining issue is that the build proxy file can't
be specific to the build configuration. Any time the file gets touched
it triggers a recompile and link for all build configurations of the app
target. If I could make the proxy files be specific to the build
configuration, I would probably get the same effective behavior. If I
changed a file in the library project, I need to rebuild both versions
of the library, so would need to relink both versions of the app.
I have added this to one of my app/library project pairs and it works as
described. Now I have more work to do, because my top level library
depends on two other libraries that I build. Adding all this is going to
be a tedious exercise.
It turns out that this workaround is not more selective than yours. I
neglected to test the case where I just build MyApp twice in succession.
When I do that, the file gets touched by MyLib, even though nothing else
is done in that project. This ALWAYS triggers a relink in MyApp.
That's not the worst thing in the world. Better to link when you don't
need it than to not link when you do need it, but it's really annoying,
and can get to be a big pain if link times get long.
I'm going to keep tinkering with this. The script could do a Make that
only touches the file if either of the library versions have been
rebuilt. I guess I can just do that in the script too. Sigh.
- Rush
_______________________________________________
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