Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Jul 24, 2005 11:56 am Post subject:
Did you be sure to cvs update HEAD to get the latest updates to the stlport patch and the new sal patch file? I'm also building with Patrick's latest Java 1.4.2 work.
My build on HEAD has gotten past the udkapi module and now is in offapi. I'm building on 10.4.2 with XCode 2.1, but the XCode version shouldn't make much of a difference as the gcc 3.3 compiler hasn't been updated since 2003 IIRC.
Note that if you rebuild the OOo portion of the Neo/J build, you will need to do the following:
1. Rename build/<module>/unxmaxp.pro.oo directories to build/<module>/unxmacxp.pro and delete any build.neo_*_patch files before you invoke make. If you don't do this, the OOo build will choke on the Neo/J build files.
2. I updated the patches/openoffice/stlport.patch file a few days ago as the same fix for Tiger is required for Panther. So, if you pull in Ed's patch, you might want to delete the build/stlport/STLport-4.5-macxp-panther.patch file, cvs update build/stlport, and delete build.oo_stlport_patch file before you invoke make.
Note that if you rebuild the OOo portion of the Neo/J build, you will need to do the following:
1. Rename build/<module>/unxmaxp.pro.oo directories to build/<module>/unxmacxp.pro and delete any build.neo_*_patch files before you invoke make. If you don't do this, the OOo build will choke on the Neo/J build files.
I'm using different build spaces for HEAD and the Release code to build in.
pluby wrote:
2. I updated the patches/openoffice/stlport.patch file a few days ago as the same fix for Tiger is required for Panther. So, if you pull in Ed's patch, you might want to delete the build/stlport/STLport-4.5-macxp-panther.patch file, cvs update build/stlport, and delete build.oo_stlport_patch file before you invoke make.
Will keep this in mind if I decide to rebuild OOo after building Neo/J if I need the space.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Jul 24, 2005 12:41 pm Post subject:
Patrick's not referring to the separate OOo...what he's referring to needs to be done for the NeoJ build itself.
The sal patch and stlport patches are against the fundamental OOo checkout that's incorporated into the NeoJ build process as they're needed for the build tools themselves. Any of the changes that we make that go into the "patches/openoffice" directory will require this base OOo build to recompile, requiring the moving of the .oo directories and removal of the neo_*_patch files.
This is one of the reasons that most of the changes are done through the more amenable process of a module-level patch.
The theory behind the NeoJ build process is that the underlying OOo compile only needs to occur once. These latest 10.4 patches, though, are affecting that underlying build requiring these extra manual steps.
Patrick's not referring to the separate OOo...what he's referring to needs to be done for the NeoJ build itself.
The sal patch and stlport patches are against the fundamental OOo checkout that's incorporated into the NeoJ build process as they're needed for the build tools themselves. Any of the changes that we make that go into the "patches/openoffice" directory will require this base OOo build to recompile, requiring the moving of the .oo directories and removal of the neo_*_patch files.
Ok. I'm checking those patches against what is working on my OOo/NeoJ builds and if necessary replacing them. I've also added a few patches that I found makes the OOo build complete with Tiger, gcc 3.3 and Java 1.3.1.
OPENSTEP wrote:
This is one of the reasons that most of the changes are done through the more amenable process of a module-level patch.
Thanks for the explanation. Module level patches are better than a complete code replacement.
[quote="OPENSTEP"}The theory behind the NeoJ build process is that the underlying OOo compile only needs to occur once. These latest 10.4 patches, though, are affecting that underlying build requiring these extra manual steps.[/quote]
So these steps are done after the OOo build or after the NeoJ build finishes (and fails to complete??)
Are there any other items that I should watch for while compiling the code for Java 1.4? I don't want to report a problem that is solved.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Jul 24, 2005 3:42 pm Post subject:
jjmckenzie51 wrote:
So these steps are done after the OOo build or after the NeoJ build finishes (and fails to complete??)
In theory, if your HEAD Neo/J checkout never got past the idlc error, you shouldn't have to do any of these steps. The idlc crash was in the first OOo compilation portion.
If the build failures were in the "build.oo_all" step then you don't need to do these steps. You can simply ls the neojava module directory to see if you have a "build.oo_all" file, generated when the OOo build is successful. If you don't have one, no worries as none of the Neo/J modules built.
It's if you do have one of these files in your module directory, then you'll need to do the steps Patrick mentioned above to allow the embedded X11 OOo code to recompile successfully. When the Neo/J specific modules are built, we go into that X11 build/ directory, move the X11 binary unxmacxp.pro folder to unxmacxp.pro.oo, then compile the Neo/J patched code into a new unxmacxp.pro directory (with successful builds indicated by the presence of build.neo_*_patch files in the neojava module directory). So to rebuild an X11 module that's already been processed for one of the Neo/J patches that directory needs to be moved back and the build.neo_*_patch file removed to force a recompilation of the Neo/J module after the X11 module completes.
jjmckenzie51 wrote:
Are there any other items that I should watch for while compiling the code for Java 1.4? I don't want to report a problem that is solved.
Right now I don't know of any myself, but my build is just through stoc and has a ways to go. I'm still using gcc 3.3 as well; if I can get a fully functional build with 3.3 I'll start moving to 4.0 (most likely just stlport and ABI work).
So these steps are done after the OOo build or after the NeoJ build finishes (and fails to complete??)
In theory, if your HEAD Neo/J checkout never got past the idlc error, you shouldn't have to do any of these steps. The idlc crash was in the first OOo compilation portion.
It does, but I'm replacing the sal patch with one that I know works for me. I may send it to you so that you can look at it. I have an ongoing discussion with Eric B. and Maho N. on the dev@porting mailing list at OOo about the JCA. I have to deal with this.
OPENSTEP wrote:
If the build failures were in the "build.oo_all" step then you don't need to do these steps. You can simply ls the neojava module directory to see if you have a "build.oo_all" file, generated when the OOo build is successful. If you don't have one, no worries as none of the Neo/J modules built.
I have one of those...
OPENSTEP wrote:
It's if you do have one of these files in your module directory, then you'll need to do the steps Patrick mentioned above to allow the embedded X11 OOo code to recompile successfully. When the Neo/J specific modules are built, we go into that X11 build/ directory, move the X11 binary unxmacxp.pro folder to unxmacxp.pro.oo, then compile the Neo/J patched code into a new unxmacxp.pro directory (with successful builds indicated by the presence of build.neo_*_patch files in the neojava module directory). So to rebuild an X11 module that's already been processed for one of the Neo/J patches that directory needs to be moved back and the build.neo_*_patch file removed to force a recompilation of the Neo/J module after the X11 module completes.
[qoute="OPENSTEP"]
Right now I don't know of any myself, but my build is just through stoc and has a ways to go. I'm still using gcc 3.3 as well; if I can get a fully functional build with 3.3 I'll start moving to 4.0 (most likely just stlport and ABI work).[/quote]
Let me know when you are ready for test builds.
Actually I spoke to soon, as the build breaks but not in an area that I expected:
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed Jul 27, 2005 8:37 am Post subject:
Hmmm...that build breakage I didn't get. My build just finished (!) with the sal patch and all of the command-line build tools for register and the like went along just fine. The ReadMe.rtf should be in the neojava/etc subdirectory. My guess is that perhaps your checkout isn't complete? I'm able to assemble the full .pkg without a problem and just break at the source tarball.
Anyway, HEAD should now build on 10.4 with gcc3.3. Step one of getting to mactel complete. Step two is to get gcc 4 support going on, but I'll poke around at the 10.4 built binary a bit to make sure nothing's shot itself in the head.
Since the error is "sed: etc/ReadMe.rtf: No such file or directory", it seems to me that this is a simple case of James' workspace is only partially updated. James should do a "cvs update -d" to ensure that he has the latest code for whatever branch he is working on.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed Jul 27, 2005 10:43 am Post subject:
A stock trick I use is actually to make an alias for "cvs update -d -P" (get new directories, prune empty directories).
I don't think we rely on any empty directories during the packaging process, so it's worked for me.
I'll start taking a look at the Java 1.4 stuff now. I'll probably see if I can shift the 1.4 based build into my day to day environment so I can try trapping some issues. Patrick, would you rather have help on that or would it be better for me to start diving in at the gcc4 support?
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed Jul 27, 2005 12:33 pm Post subject:
jjmckenzie51 wrote:
I also attempted to update my 1.1.5rc code and ran into a problem with the CVS at OpenOffice. Who do I advise of this?
If you're having problems with the OpenOffice.org cvs, you should file an issue in the OOo IssueZilla system against the "www" module as that's the one the CollabNet admins read.
The OOo anoncvs used to be really really flaky, but it's gotten better over the years. The non-anonymous cvs server there is really the one they focus on, though, as that's the one that all the Sun engineers need.
Anyway, HEAD should now build on 10.4 with gcc3.3. Step one of getting to mactel complete. Step two is to get gcc 4 support going on, but I'll poke around at the 10.4 built binary a bit to make sure nothing's shot itself in the head.
This is exciting news! Way to go Ed!
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
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
