Thread: [Camelbones-devel] ANN: CamelBones 0.3-pre2
Brought to you by:
shermpendley
From: Sherm P. <sh...@do...> - 2003-07-03 13:32:15
|
I've posted a new release at <http://www.dot-app.org>. Share and enjoy! Now that the basic framework is working - more or less - I've started to assemble a TODO list of things that I think should be done before a wider 0.3.0 release: * Find and squash the "variable has become un-blessed" bug. * Think about what can be done to simplify the framework build - use autoconf & make? * Add support for currently-unsupported argument/return types. * Add support for Cocoa constants, globals, and enums. * Convert the 0.2 sample projects, file and project templates to 0.3 and test them. * Create new project template for document-based apps. * Create new file templates for common subclasses - NSDocument, NSWindowController Some things that I think should be done before 1.0: * Use subroutine attributes to replace ugly OBJC_EXPORT. * Implement CBPerlString as a mutable member of the NSString class cluster. * Add more export tags to Cocoa.pm * Add classes for NSPoint, NSRange, NSRect, and NSSize. * Create an IB palette to instantiate Perl objects. * Figure out how to allow IB to read Perl classes. * More project templates - IB Palette, preference pane, screen saver. Things that would be nice, but 1.0 shouldn't wait for them: * An IB palette with data-aware controls that use DBI. * A nice Aqua-fied CPAN front end. Time to figure out Tracker on SourceForge... ;-) sherm-- When the program is being tested, it is too late to make design changes. -- The Tao of Programming |
From: Thilo P. <thi...@us...> - 2003-07-14 05:53:15
|
Hi all, > I've posted a new release at <http://www.dot-app.org>. Share and enjoy! the list has been awfully quiet after this announcement. Did anyone manage to make it work on Jaguar? I had the exact same error messages (or rather compile warnings) as with pre1, and the pre-compiled binary did not work either. I am also uncertain if libffi works for me at all. Sherm says it should be included in Jaguar's gcc, but I could not find header files for it. So I installed the one provided with pre1. Is there some simple test I could run to ensure that it does what it is supposed to do? Curious, Thilo |
From: Sherm P. <sh...@do...> - 2003-07-14 14:16:06
|
On Monday, July 14, 2003, at 01:53 AM, Thilo Planz wrote: > the list has been awfully quiet after this announcement. Maybe a new announcement will shake things up... ;-) I've uploaded a new -pre3 release to my site: <http://www.dot-app.org>. > I had the exact same error messages (or rather compile warnings) as > with pre1 I downloaded the April 2002 beta tools for 10.1, which are as close as I can get to the Jaguar tools. After closely reading the license, I found that the licensing wasn't as restrictive as I'd feared - The GCC3.1 that's included with that release is considered a beta, and releasing binaries built with it isn't allowed, but that's the only restriction. I can release .pbprj projects that were created with that release of Project Builder 2. Using that release of GCC 3.1, I was able to duplicate and address the build problems you reported - namely, the complaints about variables being automatically promoted when passed through a varargs call, and the precompiled header warnings. It now compiles cleanly for me, using either 2.95.2 or 3.1. I haven't tried 3.3 yet - although I did receive an email from Apple telling me that a Panther CD is on its way... ;-) I silenced the warnings about precompiled headers by the simplest means possible - I added a compiler option that disables precompiled headers. The source of the problem is a conflict between the Perl headers and Carbon.h, neither of which I can easily fix. Since the problem caused precompiled headers to be unusable anyway, I didn't see a noticable difference in build time. > I am also uncertain if libffi works for me at all. > Sherm says it should be included in Jaguar's gcc, but I could not find > header files for it. This is bordering on the bizarre - I couldn't find it in the GCC 3.1 libraries I installed either. And yet, the code for the libffi version I included in the last release was obtained from the GCC3 folder in opendarwin.org's CVS. The web site for the stand-alone libffi distribution indicates that it is only needed versions of GCC prior to 3.0. And, the last time I installed GNUStep under Linux, the docs for that indicated that a separate libffi install was only needed if one were not using GCC 3 or newer. All of the documentation that I can find implies that it should be there. Whatever. Irrespective of whether or not it *should* be installed, all the evidence seems to indicate that it's not. So, I've integrated it into the CamelBones build tree - it's no longer necessary to build and install it as a separate library. > So I installed the one provided with pre1. You probably should delete that, to avoid conflicts. Delete ${prefix}/lib/libffi* and ${prefix}/include/ffi.h, where $prefix is the installation prefix you used - /usr/local is the default. I'm flying out to CA early tomorrow (Tuesday) for a job interview, and I won't be back home until very late Friday night. I'll probably have a pile of email waiting for me, so you may not hear from me until this time next week. sherm-- "I have no special gift, I am only passionately curious." - Albert Einstein |
From: Thilo P. <thi...@us...> - 2003-07-15 02:32:31
|
> I've uploaded a new -pre3 release to my site: <http://www.dot-app.org>. It does not quite work... I get the following errors: 1) Compile Collections against included CB binary: I had to move the included Framework around a little, because ProjectBuilder did not find it. I put it in the /Library/Frameworks Maybe we can run a quick poll about putting it back there by default. It is not that much trouble (at least for me) to rename the old version to put it out of the way for hacking on 0.3 and rename it back when I need it again. > Build failed (2 warnings) > > ld: warning -F: directory name (/Users/sherm/Projects) does not exist > ld: warning prebinding disabled because dependent library: > /Users/sherm/Projects/CamelBones/build/UninstalledProducts/ > CamelBones.framework/Versions/0.3/CamelBones is not prebound 2) Run Collections (although it said it failed to build) > 2003-07-15 10:59:27.925 Collections[2108] Perl error: Can't locate > auto/Foundation/CBRegisterP.al in @INC (@INC contains: > /System/Library/Perl/darwin /System/Library/Perl /Library/Perl/darwin > /Library/Perl /Library/Perl /Network/Library/Perl/darwin > /Network/Library/Perl /Network/Library/Perl . /usr/lib/Resources > /System/Library/Frameworks/Foundation.framework/Resources > /System/Library/Frameworks/AppKit.framework/Resources > /Library/Frameworks/CamelBones.framework/Resources > /Users/planz/Perl/CamelBones-0.3-pre3/Collections/build/ > Collections.app/Contents/Resources) at > /Library/Frameworks/CamelBones.framework/Resources/CBWrapper.pm line > 133 > BEGIN failed--compilation aborted at > /Library/Frameworks/CamelBones.framework/Resources/Cocoa.pm line 7. > Compilation failed in require at (eval 6) line 4. > BEGIN failed--compilation aborted at (eval 6) line 4. > > Collections has exited with status 0. This is the same error as with the previous releases. I suppose there is not really supposed to be a file " auto/Foundation/CBRegisterP.al" and this is some autoloading magic which is beyond me. In any case, I have no such file. 3) Run included ShuX > 2003-07-15 11:06:29.033 ShuX[2110] Perl error: Can't locate > auto/Foundation/CBRegisterP.al in @INC (@INC contains: > /System/Library/Perl/darwin /System/Library/Perl /Library/Perl/darwin > /Library/Perl /Library/Perl /Network/Library/Perl/darwin > /Network/Library/Perl /Network/Library/Perl . /usr/lib/Resources > /System/Library/Frameworks/AppKit.framework/Resources > /System/Library/Frameworks/Foundation.framework/Resources > /Library/Frameworks/CamelBones.framework/Resources > /Users/planz/.Trash/CamelBones-0.3-pre3/ShuX.app/Contents/Resources) > at /Library/Frameworks/CamelBones.framework/Resources/CBWrapper.pm > line 133 > BEGIN failed--compilation aborted at > /Library/Frameworks/CamelBones.framework/Resources/Cocoa.pm line 7. > Compilation failed in require at (eval 6) line 11. > BEGIN failed--compilation aborted at (eval 6) line 11. Same error. 4) Compile Camelbones myself That went fine, no errors, just warnings about prebinding. :-) Compiled, touch *.xs, compiled again 5) Compile and run Collections against new CB binary Same as before Cheers, Thilo PS: I wish I could offer some more constructive feedback than just posting compile errors, but I really do not know where to start looking to fix things. |
From: Sherm P. <sh...@do...> - 2003-07-15 02:57:26
|
On Monday, July 14, 2003, at 10:32 PM, Thilo Planz wrote: > I get the following errors: > > 1) Compile Collections against included CB binary: > > I had to move the included Framework around a little, because > ProjectBuilder did not find it. > I put it in the /Library/Frameworks As it states on the distribution page, that's where it should be. > Maybe we can run a quick poll about putting it back there by default. That's where it belongs - the *only* reason I compiled the previous release for embedding was to allow it to co-exist peacefully with a copy of 0.2 installed in /Library/Frameworks. >> Build failed (2 warnings) >> >> ld: warning -F: directory name (/Users/sherm/Projects) does not exist >> ld: warning prebinding disabled because dependent library: In the "Frameworks" section in the "Files" tab of the project, delete the "CamelBones" framework. Then, add it again using "Project/Add Frameworks...". The reason that this keep cropping up is, I often build these projects against a test build of CamelBones that I haven't installed in /Library/Frameworks. Sometimes I forget to point them back at /Library/Frameworks/. Sorry! :-( > 4) Compile Camelbones myself > > That went fine, no errors, just warnings about prebinding. :-) If no one objects to it, I'll silence those the same way I silenced the precompiled headers warnings - by disabling prebinding. It doesn't do much for a Perl app anyway, where most of the startup time is spent loading and parsing Perl modules. sherm-- If you listen to a UNIX shell, can you hear the C? |