Re: Custom build rule always rebuilding
Re: Custom build rule always rebuilding
- Subject: Re: Custom build rule always rebuilding
- From: Allen Cronce <email@hidden>
- Date: Tue, 28 Mar 2006 13:06:46 -0800
That's a good idea. But it doesn't seem to work.
I added a run script build phase with the following script:
# Touch the file, to try and prevent CreateUniversalBinary from running
over and over.
touch ${BUILT_PRODUCTS_DIR}/${EXECUTABLE_PATH}
And the following input files:
${OBJECT_FILE_DIR_normal}/ppc/${EXECUTABLE_PATH}
${OBJECT_FILE_DIR_normal}/i386/${EXECUTABLE_PATH}
And the following output files:
${BUILT_PRODUCTS_DIR}/${EXECUTABLE_PATH}
What happens is the first time I build, CreateUniversalBinary is called,
then my script is called touching the resulting universal .lib and
setting the current date/time as the mod date. The next time I build,
CreateUniversalBinary is called again, setting the date/time back to the
constituent libs.
So I can't find a way to prevent CreateUniversalBinary from being called
every time. I've reported this as Radar #4493644.
If anyone has other ideas, I'm all ears.
Best,
--
Allen Cronce
Rush Manbert wrote:
I have recently "discovered" that lipo's output file carries the
earliest file modification timestamp of all of the input files. Is
this what causes the libraries to be lipo'd every time? What happens
if you run a build, then touch the fat libraries by hand?
- Rush
Allen Cronce wrote:
We've been seeing the same problem here for months, but I hadn't
gotten around to posting the issue yet. CreateUniversalBinary always
runs for all of our static library projects that produce a universal
binary. The projects where we see this problem do not have any custom
build phase.
This can cause a significant build performance problem. Usually
CreateUniversalBinary runs in a few seconds. But sometimes (perhaps
due to available memory) it can take tens of seconds. If you have any
significant number of dependent static library sub projects, the
build can take minutes to essentially do nothing.
Unfortunately, there are lots of cases where we need to build
universal binaries even for our debug builds, so we don't have a good
work around.
It would really be nice if CreateUniversalBinary was only invoked as
needed and not all the time. We could spend less time building and
more time developing.
Best,
--
Allen Cronce
Mark Lentczner wrote:
On Mar 7, 2006, at 8:48 AM, James Bucanek wrote:
$(INPUT_FILE_BASE).y.h
not
$(INPUT_FILE_BASE).h
Good catch! Thanks. That partially cleared up the problem: On
single architecture builds, this made it work perfectly.
However, on universal builds it didn't, still yacc'ing twice and
compiling twice on every build.
But it gave me an idea: Make the derived files be architecture
dependent (is this what the normal yacc rule does?). So now the
yacc rule looks like:
-- Yacc source files using Script --
Process: Yacc source files
using: Custom script:
mkdir -p "${DERIVED_FILES_DIR}/${CURRENT_ARCH}"
/usr/bin/yacc -d -o
"${DERIVED_FILES_DIR}/${CURRENT_ARCH}/${INPUT_FILE_BASE}.y.cpp"
"${INPUT_FILE_PATH}"
with output files:
$(DERIVED_FILES_DIR)/${CURRENT_ARCH}/$(INPUT_FILE_BASE).y.cpp
$(DERIVED_FILES_DIR)/${CURRENT_ARCH}/$(INPUT_FILE_BASE).y.h
Works like a charm....
NOW the only problem is that the "CreateUniversalBinary" step runs
every time, even if there is nothing to do:
Checking Dependencies
CreateUniversalBinary ...
Is that normal? This is a static library.
_______________________________________________
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