Re: XCode usable? Part I
Re: XCode usable? Part I
- Subject: Re: XCode usable? Part I
- From: Dix Lorenz <email@hidden>
- Date: Wed, 5 Nov 2003 09:53:32 +0100
My post was too big, so I divided it...
On 04.11.2003, at 19:22, Scott Tooker wrote:
Distributed compiling sometimes works, then it's awesome. Mostly it
doesn't and I have no clue why. It seems to hate being stopped and
machines that go to sleep, regardless if they are used for compiling
at that moment or not. Right now, if I use DC, it spawns 6 compiles
(correct: 3 machines with dual procs available), but the other
machines are idle and my machine is compiling only 1 file. I have no
idea how to fix that other than restarting machines and don't even
know if I should restart my machine or the others. So I've switched it
off until the next release.
Two things to check. First make sure you are using native targets.
Second, I believe the same version of gcc needs to be used on all the
machines.
I am using native targets, I have seen the same problems no matter if I
was just updating an old PB-Project or starting a new XCode-Project.
And the Installation is the same on all Macs, I wouldn't even know how
to put other versions of gcc on there. As I said: in principle it
works. With all computers freshly restarted and building from a clean
start, it works fine. It just starts deteriorating from then on: For
example when one machine goes to sleep, it vanishes in the Preferences,
but XCode still starts 6 compiles, it should start 4. Stopping compiles
seems to leave either the server or the client or some deamon (oh yeah,
some better documentation would be nice, too) in some kind of state
where it still thinks it is compiling, and doesn't accept new
compile-tasks. I have some source files on a mounted disk image and
even when I quit XCode and wait for all visible action (according to
top) to cease (and longer), I can't eject the image: using fstat there
is always some process distccsched (or something like that) accessing a
file on the image, which it shouldn't, IMHO. I can kill it and then
eject the image. But the problems start way before that...
CodeSense is better, but from time to time it inserts invisible text
in my code, making compiles fail.
Known bug that is fixed for the next version.
Good. As I said: I am not worried too much about bugs, they'll get
fixed over time. But these two things I was really looking forward to
and are so far only partially usable, especially distributed compiles.
For example I can't have the settings for my build styles next to each
other to see if I forgot a flag somewhere. It's a lot of switching
back and forth.
You could do this by bringing up two 'Get Info' windows, one on the
target and one on the project
How would an info panel on the *target* help me comparing the settings
for buildstyle A and buildstyle B? I can sort of workaround here and
open one Inspector and one info panel on the project (it just crashed
on me when I tried it, the second time it worked... <sigh>). But as
soon as I click anything in the Info panel the Inspector goes to its
"nothing-selected-mode". Very awkward to work with, can't crosscompare
3 buildstyles... I say, give the buildstyles it's own entry in the
project-tree (right under the Project) and their own info-windows. They
are important enough to warrant that and will be a lot easier to work
with.
Search Paths used to be a nice table, where you could actually see
more than just a few characters of the first path, now it's a one-line
textfield. I hated it in MSVC and used to point to Mac: Neither CW nor
PB would ever dare use such an unusable UI. Of course it's a lot
easier to program, but if you already had the code, why trash it?
We realize we need a much better UI for dealing with lists of strings
and text field where you enter paths. This is something we want to fix
in a future release.
Ok, I guess with that done, complete help texts, a very exhaustive list
of checkboxes/fields for compiler/linker/... settings and a pretty
easy/obvious way to set the unusual settings I can accept the UI in
principle. Just give each object/style/target/file/whatever it's own
Info-Windows and I might find over time it is better than the PB-way...
:-)
It used to be very easy to add a flag in a build-style, just click on
the "=" and it turns to "+=". Maybe not obvious, but once you knew
about it, very easy, efficient and crystal-clear. Now it needs text
that says I have to use "$(value)". I don't see the progress. Plus, I
assume it is supposed to be (for example) "$(OTHER_CFLAGS)" and it not
really obvious, what I should put there for "Other linker flags". Just
an example, I don't need it right now.
Actually it really is supposed to be just '$(value)'.
Ok, too obvious :-)
It represents the
value of the build setting on the "previous level" (i.e. for a build
style, $(value) will point to the build settings value in the target.
We went to this model since we have gotten requests to be able to
prepend or both prepend and append (which the += just couldn't do).
I see the reasoning, but why not combine the two? Put back the "="/"+="
which should cover most cases, and if somebody puts in "$(value)" honor
that, too... Once I found out about the "="/"+="-switch I was totally
amazed by such a simple and efficient way to do that and I think it is
a lot more obvious for novice users and also simpler to use for expert
users...
At some places I am just stumped, where a setting comes from. Maybe
that's because I am not yet used to it, maybe because it is still in
flux, but I found it very nice in PB to just go to Expert View and see
and edit all the settings in a pretty raw format. Especially when it
does some things behind my back which I don't want but can't find a
way to reverse. I have one target called "libdlclmmcl", which should
build a lib called "libdlclmmcl.a". I haven't changed anything yet,
but the lib is called "liblibdlclmmcl.a" and I can't find why it would
do that. I certainly didn't tell it to and there is no setting I can
see.
In this particular case there is a bug (fixed) that we were not showing
an entry for PRODUCT_NAME.
Actually, there is an entry "PRODUCT_NAME" (I didn't put it there).
That says "libdlclmmcl". It just seems not to be honored. Yet another
bug...
In general, for the next release we have
tried to make it easier to find settings (in the next version you can
search on the build setting name or gcc flag).
Then please make it possible to also look for values. In this case for
example I'd much rather search for "libdlclmmcl" which might show 2-3
entries instead of thinking of all names for settings which might have
to do with setting the name and trying them one by one.
The one thing we would
like to see for a future release is an "All Settings" collection, so
that you don't have to muck around in the drawer so often.
Sounds good.
continued...
_______________________________________________
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.