Joined: Jun 21, 2003 Posts: 173 Location: Selmer, Tennessee
Posted: Mon Jun 23, 2003 6:18 am Post subject: Getting Started
I've been using the beta version of OOo for Mac OSX. It works well, and appears to be reliable. I susbscribe to the OOo Users mailing list. When someone asks "How do you...." or "Why doesen't OOo ..." or "I wish you could XXX with OOo like you can with YYY", shortly thereafter somebody else posts a how-to showing that the requested behavior is there. I like this program.
There are fewer than 40 people registered in Trinity. I'd like to help with some of the coding, but I've never, ever worked on a project of this magnitude. I have the Developer Tools, a slow G-4, a G-3 iMac, and a G-3 icebook. I also have two books on Cocoa programming by O'Reilly.
Can anyone tell me a good way to get started in coding for OOo? (Or is it NeoOffice now?) How does one become familiar with the coding, object definitions, conventions, etc. to the point where he can make a meaningful contribution to the coding effort? If that learning curve is too steep, how else can I help?
Posted: Tue Jun 24, 2003 12:59 am Post subject: Re: Getting Started
Jim wrote:
I'd like to help with some of the coding, but I've never, ever worked on a project of this magnitude. I have the Developer Tools, a slow G-4, a G-3 iMac, and a G-3 icebook. I also have two books on Cocoa programming by O'Reilly.
Can anyone tell me a good way to get started in coding for OOo? (Or is it NeoOffice now?) How does one become familiar with the coding, object definitions, conventions, etc. to the point where he can make a meaningful contribution to the coding effort? If that learning curve is too steep, how else can I help?
Your help would be appreciated. It is quite a large learning curve IMHO, but everyone has to start somewhere.
other then having to have X 11 running BEFORE you run the app it does work as advertised! Allows a native X11 app hook directly to carbon/cocoa/corefoundation....just have to enable some flags in project builder.
So it begs the question...can the source for OO be built IN project builder? And if so... who wants to be the brave soul to give it a shot?
Unfortunately, PB uses its own build system and dependency tracking, and doesn't integrate well with the dynamic nature of OOo/Neo's makefile system. It might be possible at some point, but would take a major re-architecting of the build system. Anyone is welcome to start that though...
oh that completely chews!!! Inches away from a semi clean solution to a problem and argh.... But isn't that always the way it goes?
I wonder if PB needs source files or could it use precompiled.... I don't use PB so don't know...I would guess that it would need uncompiled source code so that it could do the make..
what I was hoping is that if you had an app like OO already built you could just take the components import into PB make sure the links are still linked to the originals add the new header flags and hit the button...
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Jul 01, 2003 10:21 pm Post subject:
If you can be sure the defines are set up right according to the MacosxEnv.Set file, it should be fine to create projects linking against binaries from OOo just using headers in ProjectBuilder...as long as the compiler is set to gcc 2.95. It turns out gcc2.95, 3.1, and 3.3 all use different ABIs, breaking C++ cross-library compatibility.
I'm hoping to try using project builder based projects to devise a prototype filter framework for use by other programs.
I really hope we don't have to stay on makefiles forever and would love to wriggle out all the issues, but the folks who have tried already to do this (thanks, those of you who have!) ran into tool limitations. The makefile and dependency generation/encoding stuff is so complex that it's a difficult logical jump to make. The command-line build system wants the user to define all dependencies for it. ProjectBuilder almost assumes that it can auto-generate dependencies.
The last viable approach we had going was to use the "makefile" invocation feature of projectbuilder to create projects that simply invoked our existing makefile system. Unfortunately this would require the authoring and maintenance of a single pbx per module directory. I doubt we have the leverage into getting Hamburg to maintain our pbxs when they add new files into the program or remove old ones. Without a maintainer volunteer, I fear this approach may be left in the dust due to lack of manpower
Can anyone think of a way to do pbx generation in an automated fashion from our makefiles or do strongarm Hamburg into giving us a little help for a change?
well I am reading the PB help files to try and get a handle on it but frankly learning curve is vertical at the moment (did I mention previously that I have zip experience in coding). If I can puzzle out what to do I will give it a shot using the binaries from the GM installer, if it looks like I can do it without bombarding the list with questions (if I have to ask a bajillion questions and counter questions it would be a waste of your guys's time since it would prolly be easier for you to do it then walk me thru holding my hand). Maybe I can get my old man to lend a hand as a sort of father son cross continent project...
I figure what the heck if I am going to learn anything it might as well be in helping out on something that I USE everyday...
Posted: Wed Jul 02, 2003 12:39 am Post subject: Re: Getting Started
OPENSTEP wrote:
I really hope we don't have to stay on makefiles forever and would love to wriggle out all the issues, but the folks who have tried already to do this (thanks, those of you who have!) ran into tool limitations. The makefile and dependency generation/encoding stuff is so complex that it's a difficult logical jump to make. The command-line build system wants the user to define all dependencies for it. ProjectBuilder almost assumes that it can auto-generate dependencies.
The last viable approach we had going was to use the "makefile" invocation feature of projectbuilder to create projects that simply invoked our existing makefile system. Unfortunately this would require the authoring and maintenance of a single pbx per module directory. I doubt we have the leverage into getting Hamburg to maintain our pbxs when they add new files into the program or remove old ones. Without a maintainer volunteer, I fear this approach may be left in the dust due to lack of manpower
Can anyone think of a way to do pbx generation in an automated fashion from our makefiles or do strongarm Hamburg into giving us a little help for a change?
As one of the people who looked at this, I didn't really come up with a satisfactory solution. I was working with a 3rd party developer to automate the generation of the OOo project(s), and he got quite a bit of it working, but we never did complete that work.
I will probably take another whack at it now that some improvements such as GCC 3.3 and Xcode have been made. My problem is finding time...
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed Jul 02, 2003 2:02 pm Post subject:
Yes, if anyone at WWDC would like to play with XCode, *please* do. While we can't publicly exchange info on features and all that, I can say that it contains some things that could revolutionize develop of large collaborative projects.
Posted: Fri Jul 04, 2003 12:47 am Post subject: Re: Getting Started
Terry Teague wrote:
As one of the people who looked at this, I didn't really come up with a satisfactory solution. I was working with a 3rd party developer to automate the generation of the OOo project(s), and he got quite a bit of it working, but we never did complete that work.
I just got an update from the developer I was working with - he has the C++ projects almost building successfully now. If we can get rid of the static member data template hack with GCC 3.3, that should fix any remaining problems. He is looking for GCC 3.3 patches to OOO_STABLE1_PORTS, but I suspect you guys are probably applying patches against either OOo 1.1 or NeoOffice at this time. I have told him he will probably have to wait until we have the entire OOo building successfully with GCC 3.3. I will direct him to the umbrella GCC 3.3 patches IZ issue.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri Jul 04, 2003 7:48 am Post subject:
I don't think we're applying our gcc3.1 patches against anything right now and, durn, I don't think they're in CVS either. I know we were swapping them around via e-mail...Dan may have a copy of them, and I may have some too. Worse comes to worse, I can always regenerate them off of my gcc 3.1 compiling checkout on my other machine
The kicker, IIRC, was stlport. After that compiled the rest was a lot easier.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
