From alan.schmitt at polytechnique.org Thu Mar 13 05:52:00 2008 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Thu, 13 Mar 2008 10:52:00 +0100 Subject: [Unison-hackers] Could someone compile a Tiger/intel binary of 2.27? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I'm receiving many requests for a Tiger/intel binary of 2.27, but I don't have access to such a machine. Has someone on the list such a machine and could compile Unison on it? Thanks a lot, Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFH2PlANIAqM4hFUWgRAh3xAJ0SAO6UVFsXXrKVuBEDWUetOQSJQQCeL8r+ CCkW+ZlQRX5cjLoiK4AS70g= =/J/g -----END PGP SIGNATURE----- From alan.schmitt at polytechnique.org Fri Mar 21 15:41:38 2008 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Fri, 21 Mar 2008 20:41:38 +0100 Subject: [Unison-hackers] XCode expert needed Message-ID: <11DC566B-D035-4CCB-849C-F5D9ED611F58@polytechnique.org> Hello, As you may know, there is currently a somewhat random bug in the OS X GUI that typically exhibits itself as: Uncaught exception: *** -[NSCFArray objectAtIndex:] index(0) beyond bounds (0) I'm think it's something related to initialization order, as changing binaries sometimes fixes it. But it's still a bug, and I've found someone who can reproduce it and who is ready to help us try to debug it. The main problem is that I don't know XCode well enough (read: at all) to guide him. My current issue is that building with XCode fails because it cannot find the path to the caml include file. Building with xcodebuild, as done in the Makefile, does work: schmitta at charm uimacnew % xcodebuild OCAMLLIBDIR="/Users/schmitta/godi/ lib/ocaml/std-lib" === BUILDING NATIVE TARGET uimac WITH THE DEFAULT CONFIGURATION (Default) === Checking Dependencies... CompileC build/uimac.build/Default/uimac.build/Objects-normal/i386/ main.o /Users/schmitta/src/unison/branches/2.27/src/uimacnew/main.m normal i386 objective-c com.apple.compilers.gcc.4_0 cd /Users/schmitta/src/unison/branches/2.27/src/uimacnew /Developer/usr/bin/gcc-4.0 -x objective-c -arch i386 -pipe -Wno- trigraphs -fpascal-strings -fasm-blocks -Os -mdynamic-no-pic -fmessage- length=0 -fvisibility=hidden -gdwarf-2 -I/Users/schmitta/src/unison/ branches/2.27/src/uimacnew/build/uimac.build/Default/uimac.build/ Unison.hmap -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -F/ Users/schmitta/src/unison/branches/2.27/src/uimacnew/build/Default -F/ Users/schmitta/src/unison/branches/2.27/src/uimacnew -I/Users/schmitta/ src/unison/branches/2.27/src/uimacnew/build/Default/include -I/Users/ schmitta/godi/lib/ocaml/std-lib -I/Users/schmitta/src/unison/branches/ 2.27/src/uimacnew/build/uimac.build/Default/uimac.build/DerivedSources -c /Users/schmitta/src/unison/branches/2.27/src/uimacnew/main.m -o / Users/schmitta/src/unison/branches/2.27/src/uimacnew/build/uimac.build/ Default/uimac.build/Objects-normal/i386/main.o As you can see, somehow, the -I/Users/schmitta/godi/lib/ocaml/std-lib is passed to the compiler. My questions are: - how can I set OCAMLLIBDIR in the XCode interface to make it able to build? - where is the black magic that adds this path to the building? - does someone know how to extend the XCode project to include a phase that figures out what this path is (as in the Makefile)? The first question is crucial, as it is the first step to do some debugging of the GUI, which is something I really want to be able to do ;-) Thanks for any help with this, Alan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20080321/21054903/PGP-0001.sig From steve at kalkwarf.com Fri Mar 21 16:02:48 2008 From: steve at kalkwarf.com (Steve Kalkwarf) Date: Fri, 21 Mar 2008 16:02:48 -0400 Subject: [Unison-hackers] XCode expert needed In-Reply-To: <11DC566B-D035-4CCB-849C-F5D9ED611F58@polytechnique.org> Message-ID: >My questions are: >- how can I set OCAMLLIBDIR in the XCode interface to make it able to build? >- where is the black magic that adds this path to the building? >- does someone know how to extend the XCode project to include >a phase that figures out what this path is (as in the Makefile)? I don't have the time to check out all the assorted project trees, but if you can point me at a disk image the source tree you work from, I can probably sort out the Xcode dependencies for you. Steve From alan.schmitt at polytechnique.org Sat Mar 22 04:29:42 2008 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Sat, 22 Mar 2008 09:29:42 +0100 Subject: [Unison-hackers] XCode expert needed In-Reply-To: References: Message-ID: On 21 mars 08, at 21:02, Steve Kalkwarf wrote: >> My questions are: >> - how can I set OCAMLLIBDIR in the XCode interface to make it able >> to build? >> - where is the black magic that adds this path to the building? >> - does someone know how to extend the XCode project to include >> a phase that figures out what this path is (as in the Makefile)? > > I don't have the time to check out all the assorted project > trees, but if you can point me at a disk image the source tree > you work from, I can probably sort out the Xcode dependencies > for you. Great, thanks a lot. I put the sources for the 2.27 branch here: http://alan.petitepomme.net/2.27.tar.gz You don't need to have OCaml to help me, as the issue is purely in the XCode part, which is in the src/uimacnew directory. The problem is: we use xcodebuild to build Unison from the command line, typically like this (in the src/uimacnew directory): xcodebuild OCAMLLIBDIR="/Users/schmitta/godi/lib/ocaml/std-lib" the argument given is when the include files for caml are, which are needed to compile MyController.c. With such invocation, the gcc calls look like: /Developer/usr/bin/gcc-4.0 -x objective-c -arch i386 -pipe -Wno- trigraphs -fpascal-strings -fasm-blocks -Os -mdynamic-no-pic -fmessage- length=0 -fvisibility=hidden -gdwarf-2 -I/Users/schmitta/src/unison/ branches/2.27/src/uimacnew/build/uimac.build/Default/uimac.build/ Unison.hmap -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -F/ Users/schmitta/src/unison/branches/2.27/src/uimacnew/build/Default -F/ Users/schmitta/src/unison/branches/2.27/src/uimacnew -I/Users/schmitta/ src/unison/branches/2.27/src/uimacnew/build/Default/include -I/Users/ schmitta/godi/lib/ocaml/std-lib -I/Users/schmitta/src/unison/branches/ 2.27/src/uimacnew/build/uimac.build/Default/uimac.build/DerivedSources -c /Users/schmitta/src/unison/branches/2.27/src/uimacnew/ MyController.m -o /Users/schmitta/src/unison/branches/2.27/src/ uimacnew/build/uimac.build/Default/uimac.build/Objects-normal/i386/ MyController.o (deep in the middle there is the "-I/Users/schmitta/godi/lib/ocaml/std- lib") Now when using the "Build" button of XCode, compilation fails because these include files are not found, which makes sense as I do not say where they are. In order to debug, I want to build from XCode GUI, so I would like to either: - specify OCAMLLIBDIR such that it is correctly set when building with XCode's GUI, or - add an include path to the project If you can explain me why positioning this variable result in adding the include path, it would even be better! Thanks again, Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20080322/5b457402/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20080322/5b457402/PGP.sig From steve at kalkwarf.com Sat Mar 22 23:06:04 2008 From: steve at kalkwarf.com (Steve Kalkwarf) Date: Sat, 22 Mar 2008 23:06:04 -0400 Subject: [Unison-hackers] XCode expert needed In-Reply-To: Message-ID: Alan, >Now when using the "Build" button of XCode, compilation fails >because these include files are not found, which makes sense as >I do not say where they are. In order to debug, I want to build >from XCode GUI, so I would like to either: >- specify OCAMLLIBDIR such that it is correctly set when >building with XCode's GUI, or >- add an include path to the project I think the easiest thing to do is make sure you have a copy of ocaml installed in /usr/local/lib/ocaml. The GUI shows this argument to gcc: -I/usr/local/lib/ocaml If for some reason that's not possible, the next choice would be to set an additional Header directory. Using Xcode 3.0: Open the project file; Select "uimac" (the top node) in the Groups and Files column; Choose Project->Edit Project Settings (Command-I, build tab); Ensure that All Configurations is chosen from the Configuration menu; Double Click Header Search Paths in the Search Paths section; Fill in the path to your includes directory. While looking at the project file, there are a couple recommendations I'd like to make: This project file uses "Current Mac OS" as its target SDK. For more predictable build results across multiple machines, I'd recommend choosing either the 10.4u SDK or the 10.5 SDK. Second, if this were my project, I'd change the architecture settings to $(NATIVE_ARCH) for development and "i386 ppc" for deployment. I'd also rename Deployment to Release, and Development to Debug, and delete Default. Those are the new blessed build styles Apple uses, and I've always found that moving to newer Xcodes works better with the new default names. >If you can explain me why positioning this variable result in >adding the include path, it would even be better! I don't understand the question: I think a word got dropped or mistyped. Hope this is enough to get you moving. Feel free to write if what I suggested isn't helpful for you. I don't have enough parts here to build Unison, but the files that needed ocaml to build do successfully build with /usr/lib populated as suggested Steve From alan.schmitt at polytechnique.org Sun Mar 23 02:59:02 2008 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Sun, 23 Mar 2008 07:59:02 +0100 Subject: [Unison-hackers] XCode expert needed In-Reply-To: References: Message-ID: On 23 mars 08, at 04:06, Steve Kalkwarf wrote: > I think the easiest thing to do is make sure you have a copy of > ocaml installed in /usr/local/lib/ocaml. The GUI shows this > argument to gcc: > > -I/usr/local/lib/ocaml Thanks a lot, this worked and I was able to build it. > If for some reason that's not possible, the next choice would be > to set an additional Header directory. Using Xcode 3.0: > > Open the project file; > Select "uimac" (the top node) in the Groups and Files column; > Choose Project->Edit Project Settings (Command-I, build tab); > Ensure that All Configurations is chosen from the > Configuration menu; > Double Click Header Search Paths in the Search Paths section; > Fill in the path to your includes directory. I also tried this but it did not work, but it's okay as creating a symbolic link to the headers did work. > While looking at the project file, there are a couple > recommendations I'd like to make: > > This project file uses "Current Mac OS" as its target SDK. For > more predictable build results across multiple machines, I'd > recommend choosing either the 10.4u SDK or the 10.5 SDK. OK. If targeting 10.4, would this also run on 10.5? > Second, if this were my project, I'd change the architecture > settings to $(NATIVE_ARCH) for development and "i386 ppc" for > deployment. OK, the only issue is that the caml code is not compiled universally. So to build a UB I need to compile it on several machines. > I'd also rename Deployment to Release, and Development to Debug, > and delete Default. Those are the new blessed build styles Apple > uses, and I've always found that moving to newer Xcodes works > better with the new default names. Thank you for the suggestions. >> If you can explain me why positioning this variable result in >> adding the include path, it would even be better! > > I don't understand the question: I think a word got dropped or > mistyped. My question was: why does calling xcodebuild with the variable OCAMLLIBDIR set work? It must be configured somewhere in the project (to add this variable to the list of header paths) but searching yielded nothing. In any way, I'm now able to launch unison from XCode, so I should be able to debug things better. Thanks again, Alan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20080323/90d1811f/PGP.sig From steve at kalkwarf.com Mon Mar 24 09:20:30 2008 From: steve at kalkwarf.com (Steve Kalkwarf) Date: Mon, 24 Mar 2008 09:20:30 -0400 Subject: [Unison-hackers] XCode expert needed In-Reply-To: Message-ID: >>This project file uses "Current Mac OS" as its target SDK. For >>more predictable build results across multiple machines, I'd >>recommend choosing either the 10.4u SDK or the 10.5 SDK. > >OK. If targeting 10.4, would this also run on 10.5? Yes, the SDK version reflects the available APIs for the build, not a minimum system version. You could also target 10.5, and it would run on 10.4. If you look at NSApplication.h, you'll see: #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_5 It's this macro (and other ones like it) that honor the SDK version. >>Second, if this were my project, I'd change the architecture >>settings to $(NATIVE_ARCH) for development and "i386 ppc" for deployment. > >OK, the only issue is that the caml code is not compiled >universally. So to build a UB I need to compile it on several machines. I would have assumed that the build was universal. There's a technote: that explains how to make a traditional makefile-type project build universally. >My question was: why does calling xcodebuild with the variable >OCAMLLIBDIR set work? It must be configured somewhere in the >project (to add this variable to the list of header paths) but >searching yielded nothing. Ah. Because several of the makefiles used that environment variable to prefix some paths. For example, the top level Makefile, likes 243:244 >tools/%: tools/%.ml >ocamlc -o tools/$* -I $(OCAMLLIBDIR)/labltk labltk.cma tools/$*.ml >In any way, I'm now able to launch unison from XCode, so I >should be able to debug things better. Good luck. Steve From alan.schmitt at polytechnique.org Mon Mar 24 11:53:39 2008 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Mon, 24 Mar 2008 16:53:39 +0100 Subject: [Unison-hackers] XCode expert needed In-Reply-To: References: Message-ID: <1442413F-26B0-4608-AC7A-1B92E1FFE865@polytechnique.org> On 24 mars 08, at 14:20, Steve Kalkwarf wrote: >>> OK. If targeting 10.4, would this also run on 10.5? > > Yes, the SDK version reflects the available APIs for the build, > not a minimum system version. You could also target 10.5, and it > would run on 10.4. > > If you look at NSApplication.h, you'll see: > > #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_5 > > It's this macro (and other ones like it) that honor the SDK version. Thank you, this is clear no. >>> Second, if this were my project, I'd change the architecture >>> settings to $(NATIVE_ARCH) for development and "i386 ppc" for >>> deployment. >> >> OK, the only issue is that the caml code is not compiled >> universally. So to build a UB I need to compile it on several >> machines. > > I would have assumed that the build was universal. There's a technote: > > > > > that explains how to make a traditional makefile-type project > build universally. Thank you very much for the link, it's very interesting. Unfortunately, I don't know how to produce ocaml ppc binaries on an intel machine. (I think there was a post about how to cross-compile using ocaml, but I'd need to dig it out.) >> My question was: why does calling xcodebuild with the variable >> OCAMLLIBDIR set work? It must be configured somewhere in the >> project (to add this variable to the list of header paths) but >> searching yielded nothing. > > Ah. Because several of the makefiles used that environment > variable to prefix some paths. For example, the top level > Makefile, likes 243:244 > >> tools/%: tools/%.ml >> ocamlc -o tools/$* -I $(OCAMLLIBDIR)/labltk labltk.cma tools/$*.ml Ah, I see. What confused me is that the Makefile does not appear in Xcode, and inspecting the Target does not seem to reveal anything. Do you have links to the interaction between Xcode and Makefiles? Thanks again, it was very helpful. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20080324/4063f09a/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20080324/4063f09a/PGP-0001.sig From alan.schmitt at polytechnique.org Mon Mar 24 12:00:58 2008 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Mon, 24 Mar 2008 17:00:58 +0100 Subject: [Unison-hackers] XCode expert needed In-Reply-To: <1442413F-26B0-4608-AC7A-1B92E1FFE865@polytechnique.org> References: <1442413F-26B0-4608-AC7A-1B92E1FFE865@polytechnique.org> Message-ID: <05FFD6FF-1B9A-4A4A-9E84-1B52E8CF98B4@polytechnique.org> On 24 mars 08, at 16:53, Alan Schmitt wrote: > Thank you, this is clear no. Read "This is clear now" ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20080324/3039a5e6/PGP.sig From steve at kalkwarf.com Mon Mar 24 17:59:38 2008 From: steve at kalkwarf.com (Steve Kalkwarf) Date: Mon, 24 Mar 2008 17:59:38 -0400 Subject: [Unison-hackers] XCode expert needed In-Reply-To: <1442413F-26B0-4608-AC7A-1B92E1FFE865@polytechnique.org> Message-ID: >Ah, I see. What confused me is that the Makefile does not >appear in Xcode, and inspecting the Target does not seem to >reveal anything. Do you have links to the interaction between >Xcode and Makefiles? Well, taking another look at the project, I probably misspoke about the environment variable and makefiles, and in fact, I'm not sure how it builds successfully. If you were to sit at a new machine, set up source, then build, what would the steps be? I'm guessing there's at least one build that has to be done before the xcodebuild in the uimacnew folder? If so, I think what's happening is that depending on how you perform the build, intermediate objects (*.o files) are being written to different locations. Xcode itself has a set of preferences under the Building tab which dictate where stuff goes. On my machine, Build Products goes to ~/Projects/build, and Intermediate files go with the build products. In addition to this, each project file can override this setting (in the General tab of the project settings). If you have phases that are build with make, then those files are typically intermingled with the source until you run an install phase. Is there a list of instructions for building Unison entirely from scratch? Now you've got my curiosity. :-) Steve From bcpierce at cis.upenn.edu Mon Mar 24 18:08:54 2008 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Mon, 24 Mar 2008 18:08:54 -0400 Subject: [Unison-hackers] XCode expert needed In-Reply-To: References: Message-ID: <697EF6DD-32B7-43E5-B649-7737EE796493@cis.upenn.edu> >> Is there a list of instructions for building Unison entirely > from scratch? Now you've got my curiosity. :-) 1) Install XCode tools and ocaml compiler. 2) Unpack Unison sources and cd to /src directory 3) Type "make" (or, if it tries to build just the text UI, maybe "make UISTYLE=macnew") :-) From alan.schmitt at polytechnique.org Tue Mar 25 04:38:43 2008 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Tue, 25 Mar 2008 09:38:43 +0100 Subject: [Unison-hackers] XCode expert needed In-Reply-To: References: Message-ID: <1C1827A3-915A-4040-986F-09A69CABF730@polytechnique.org> On 24 mars 08, at 22:59, Steve Kalkwarf wrote: > If you were to sit at a new machine, set up source, then build, > what would the steps be? I'm guessing there's at least one build > that has to be done before the xcodebuild in the uimacnew folder? Yes, for at least two reasons: - the info.plist file is generated from the template file adding the version number - linking fails because some file built from the unison source fails Just for fun, I created the info.plist, and I was able to compile except from the linking error. So somehow Xcode figures everything out. (That is, what to link with...) > If so, I think what's happening is that depending on how you > perform the build, intermediate objects (*.o files) are being > written to different locations. > > Xcode itself has a set of preferences under the Building tab > which dictate where stuff goes. On my machine, Build Products > goes to ~/Projects/build, and Intermediate files go with the > build products. > > In addition to this, each project file can override this setting > (in the General tab of the project settings). > > If you have phases that are build with make, then those files > are typically intermingled with the source until you run an > install phase. > > Is there a list of instructions for building Unison entirely > from scratch? Now you've got my curiosity. :-) If you do a "make", like Benjamin suggested, everything will compile. The GUI part is compiled calling "xcodebuild" in the "uimacnew" directory with an argument corresponding to where the caml headers are. To build from scratch using the GUI, you first need to generate the Info.plist file: schmitta at charm src % sed -e's/@@VERSION@@/2.27.57/' uimacnew/ Info.plist.template > uimacnew/Info.plist Then you need to build the unison object file (from the Caml code) schmitta at charm src % make unison-blob.o Finally, just open the project in Xcode and compile the GUI Alan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20080325/f2a52bf3/PGP.sig