Am 29.05.2006 um 07:10 schrieb Richard Koch:
> Fixing these errors gives others. It looks to me like the build
> system is compiling
> TeXShop before putting OgreKit together, and so doesn't yet have
> the header
> files in the framework.
Odd, it works fine over here. I wonder what is causing the problems
over there. I just did a "Clean all", then manually deleted my whole
"build" directory. Then I did a "build all" from the TeXShop project,
and it still worked just fine. Hmm.
(At times like these, I feel it would be very useful for me to have a
2nd mac at hand. Then I would simply make a fresh checkout on my
second machine, and try to build there, from a fully clean
environment. Maybe it's time to get one of those Intel MacMinis, that
way I could test Intel binaries, too ;-).
Did you do a full "svn up" in your SVN checkout? To do that, you
could use the SCM feature of XCode: Open the TeXShop project, go to
the "SCM" menu, and choose "Update Entire Project". Then, after that
finished (you should be able to watch the progress via the "SCM
Results" menu command), delete your "build" dir (just to be safe).
Then build again.
Does it still fail? If so, can you tell me the specific error
message? Maybe you can even copy the full "Build Results" into a file
and send that to me, to check out what's wrong.
If all doesn't help, of course I can always just revert that change
again, not a big deal! The advantage of the current setup simply is
that we don't have to keep binaries of OgreKit / TeX mdimporter
around; that they automatically will be built as universal binaries,
when using the "Release" build configuration; that we are more GPL
compliant (we really ship all the source code required for TeXShop
An alternative strategy would be to not include OgreKit & mdimporter
at all, but rather add a README that explains how to build TeXShop,
and that tells people something like this:
1) Download OgreKit from http://xyz, build it, copy OgreKit.framework
2) Download TeX mdimporter from http://xyz, build it, copy it to /
3) Build TeXShop
Or, we revert to the old scheme were we ship a binary of those along
with the TeXShop source code. Drawback of that is that it's unclear
what version we are using, and debugging doesn't really get any
easier that way either.
Am 06.06.2006 um 06:37 schrieb Richard Koch:
> I conjecture that I didn't quite get the notion of branches.
> Something tells me that I was supposed to fix a source checked out as
> svn co https://svn.sourceforge.net/svnroot/texshop/branches/
> rather than one checked out as
> svn co https://svn.sourceforge.net/svnroot/texshop/tags/
> I conjecture this because on the bug list you claim to have fixed the
> "tags don't populate at open" bug, but I see it is not fixed in the
> version here.
You conjecture correctly.
> So if instead I made a change in the .../tags/texshop-2.10beta
> place, where
> did my change actually go?
They went to the 2.10beta release tag, so now it will look to folks
as if 2.10beta already had that fix in it :-/
As a rule of a thumb, one never wants to touch anything inside tags/
after it has been created. Changes only go to trunk/, or to one of
the branches. But you figured that out by now :-)
Am 29.05.2006 um 19:58 schrieb Richard Koch:
> I downloaded a completely new subversion copy called "texshopnew" =20
> my "texshop" previous copy. I built it. There was a build error and =20=
> is the list of build messages:
> Building target =93TeXShop=94 of project =93TeXShop=94 with =
> =93Default=94 =97 (3 errors)
Ah, I am using the "Debug" configuration. Hmm... I wonder why we have =20=
a "Default" anyway. I'll do some more testing with that, though, =20
maybe I can reproduce the issue then.