Re: [Solved] Re: Building a class hierarchy in Xcode
Re: [Solved] Re: Building a class hierarchy in Xcode
- Subject: Re: [Solved] Re: Building a class hierarchy in Xcode
- From: Scott Tooker <email@hidden>
- Date: Wed, 11 Aug 2004 21:46:25 -0700
Filing a bug is your best course of action.
Scott
On Aug 11, 2004, at 5:13 PM, Olivier Scherler wrote:
Cross post from the Java Dev list.
Olivier Scherler <email@hidden> wrote:
I am using a shell script build phase *after* the usual Java build
phase, to generate a TINI executable out of the class files for the
TINI. Due to very limited resources, the TINI does not execute class
or jar files but a special, very stripped down kind of file. The
normal (manual) compilation process is therefore:
javac -target 1.1 -d classes sources/*.java java TINIConvertor -f
classes -o tinifile.tini
I'm using a shell build phase only for the second step.
For this, I need Xcode to give me a class hierarchy. Therefore, I
configured the standard Java target to not make a jar file (Java
Archive Settings -> Product type -> Class hierarchy). But the
classes are not updated when I modify the sources and rebuild the
project.
BTW, my guess is that the class-files you're running TINIConvertor on
aren't the latest ones compiled, but are leftovers from some other
part of
the XCode build. To track the problem down, you'll have to look into
the
details of XCode's build-system, especially how it uses
build-variables
(basically, env-vars) to decide where to put files and such:
<http://developer.apple.com/documentation/DeveloperTools/Conceptual/
Build_System
/>
Thanks for the pointer, that was an interesting read. I think I now
understand
what's happening.
I used xcodebuild in the shell to watch the built in more details.
Here's the
parts I found interesting:
/usr/bin/javac [...] -sourcepath [...]/TINITim/. -classpath
/"$classpath" -d
/"[...]/TINITim/build/TINITim.build/TINITim.build/
JavaClasses" /'TINITim.java'
-> Classes are compiled in build/PROJECT_NAME.build/TARGET_NAME.build/
JavaClasses, a.k.a. CLASS_FILE_DIR. These are always up to date.
BuildPhase <JavaArchiveFiles>TINITim
echo Completed phase "<JavaArchiveFiles>" for
"<JavaArchiveFiles>TINITim"
Completed phase <JavaArchiveFiles> for <JavaArchiveFiles>TINITim
Mkdir [...]/TINITim/build/TINITim
/bin/mkdir -p [...]/TINITim/build/TINITim
Ditto [...]/TINITim/build/TINITim
/usr/bin/ditto
[...]/TINITim/build/TINITim.build/TINITim.build/
JavaClasses [...]/TINITim/build/TINITim
-> This step copies the class files in build/TINITim if I chose to
make a class
hierarchy instead of a jar file. When I build the project again,
however, it is
NOT executed. It looks like a bug.
Grepping for ditto in /Developer unveiled this interesting file:
/Developer/Makefiles/pbx_jamfiles/ProjectBuilderJambase
It looks like the instructions for Xcode on how to build a project. The
following bit looks strangely familiar:
if $(JAVA_ARCHIVE_CLASSES) != YES {
# !!!:cmolick:20020123 product class file dir not always made?!
Mkdir $(PRODUCT_CLASS_FILE_DIR) ;
ProductFile $(PRODUCT_CLASS_FILE_DIR) ;
Ditto $(PRODUCT_CLASS_FILE_DIR) : $(CLASS_FILE_DIR) ;
if $(MERGED_ARCHIVES) {
DEPENDS $(PRODUCT_CLASS_FILE_DIR) : $(MERGED_ARCHIVES) ;
}
else {
DEPENDS $(PRODUCT_CLASS_FILE_DIR) : $(JAVA_COMPILE_TARGET)
;
}
}
It's the ditto instruction that's playing hide and seek with us.
Apparently,
it's been bothering someone for a long time too:
# !!!:cmolick:20020123 product class file dir not always made?!
I figured out that Mkdir was interrupting the process if the directory
it's
supposed to create already exists. Indeed, removing the directory was
enough to
make the ditto step run once more. Emptying the directory, however,
was not
sufficient.
Now here's the definition for Mkdir:
# Mkdir <directory>
# Creates <directory>
rule Mkdir
{
# Only existence of the directory matters
NOUPDATE $(1) ;
}
actions together piecemeal Mkdir
{
$(MKDIR) -p $(1:Q)
}
I don't know this language so I have no idea what this means, except
that it
runs "mkdir -p arg" to create a directory. But I can guess from the
comments
that the first part makes it do nothing if the directory already
exists. This
"do nothing" seems to be the culprit. I could have removed it but I
found it
cleaner to define a new action for this particular case. There's
nothing but
programmers on this list so I will spare you the "make sure you backup
the files
you modify" bit.
1. In the first snippet above (line 4269), change
Mkdir $(PRODUCT_CLASS_FILE_DIR) ;
to
ForceMkdir $(PRODUCT_CLASS_FILE_DIR) ;
2. Next, define ForceMkdir (e.g. at line 310):
# ForceMkdir <directory>
# Creates <directory>, even if it already exists.
#
# This modification if for the Ditto step that copies class files
in Java
# projects. The original Mkdir action above seems to prevent ditto
from
# executing when the directory already exists.
#
# Fix on 2004-08-12 by Olivier Scherler, who's quite proud of
having fixed a
# glitch in a program written in a language he does not even know
the
# name of.
actions together piecemeal ForceMkdir
{
$(MKDIR) -p $(1:Q)
}
Tadam, the classes are now copied every time the project is built.
Should I inform someone in particular about this?
Olivier
b B Unicode Ribbon CampaignB b No ASCII, anywhereB b
b B <http://ithink.ch/unicode> B b
:: Olivier Scherler :: NeuchC"tel - Switzerland ::
http://ithink.ch/blog/ ::
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.