neooffice/j on intel: death or glory?

[fabrizio venerandi]

After the ed message, someone on italian newsgroup tells me that neooffice/j (and openoffice 2.0 porting) is death with the new intel macintosh.

I'd like to know if this is true, and if the porting of neooffice from ppc to intel is a dream or a nightmare.

thank you.

f.

[jakeOSX]

(ed and patrick can correct me)

off hand, i'd say it is probably too early to tell. if this rosetta thing works as well as theSteve says, then current versions of N/J should be fine (which is a big FAT if)

[pluby]

We won't know until someone tries to run Neo/J on the new Intel machines.

Since I'd have to pay $1500 to get access to one of these machines, I have sent a request to Apple to donate a Mac Intel Developer Transition Kit to us. I don't know if my request will go anywhere, but I figured I'd ask them.

Patrick

[sardisson]

[fabrizio venerandi]

thank you for the answer, I hope apple could give you a pentium 4.

But you think about use neooffice via rosetta (if it works), or recompile all with xcode?

I fear neooffice/rosetta could be really slow, and recompile neooffice could mean re-start the work from the beginning.


f.

[pluby]

If we have to recompile, we won't be using XCode. We will need to update the makefiles and source code to compile directly with gcc 4.0. This is no trivial task, but it is far easier than trying to force the OOo build into XCode. Plus, XCode provides no advantage for us. If we have to recompile, Neo/J is so large that we would have a separate download so XCode's "universal binary" feature (which essentially means two sets of binaries in one application bundle) is not something that we can use.

Patrick

[fabrizio venerandi]

I understand. So if rosetta fails we'll have* a neooffice/j ppc and a neooffice/j x86.


f.


* "we'll have" means " if pluby and ed could find energy to recompile all the stuff under gcc 4.0"

[Guest]

[OPENSTEP]

Like Patrick said, the universal binary approach is right out. There's really no point in starting until the ABI settles down from Apple and after we see if there are any gcc 4 failures. Also, like I mentioned in another thread, the way that the OOo process bootstraps into itself (it runs its own binaries), I don't expect it to be easy to get it to "cross-compile" either (and I certainly don't want to do the build system work for it ).

I am still unsure if the PPC emulator on the Intel machines will run the Java 1.3.1 VM in emulation. If it does, then we should be golden. If it doesn't, then we'll need to move. There's some caveats in the Universal Binary guidelines about bundled Java applications failing to launch or ones with incompatible JNIs. I suspect this may imply that they're not planning on shipping PowerPC Java virtual machines with it so apps like Neo which are "pseudo-Java" may have a tough time. Like Patrick, I don't have $1500 to plunk down for a machine I can't even keep just to find out

ed

[Guest]

Listening to the TWIT podcast special, last night, Leo and Patrick interviewed a couple of small developers [and much smaller packages than NeoOffice/J] about their experience, so far, with Rosetta and the package for converting software to MacIntel.

Leo asked, "How long do you think it will take to convert your main product?"

The answer -- "It took about 20 minutes. Most of which was spent looking for the checkbox for Universal Binary."

Their trial with Rosetta before conversion was seamless and invisible with no apparent speed degradation.

[jjmckenzie51]

[OPENSTEP]

If you want more great testimonials you can just to to the ADC website and see them splashed across the banner. The one I liked was that it took longer to copy the files over then to produce the binary.

A real testimonial is going to be to head on to the Mac BU and ask them how painful the transition's going to be for them. They're in the same boat I was in at my real job...they're still compiling with Metrowerks. To move requires moving development environments and switching compilers. This took me a whole week for a < 500000 line program. Things that compiled just fine under Metrowerks for MachO broke in GCC as errors. Warnings became errors. And I haven't even gotten into the endian issues yet.

It really ticks me off that the line coming out of Apple is being heard by end users and is now giving everyone the assumption that it's no big hassle at all for developers to produce Mactel binaries.

It isn't. Go ask Microsoft.

ed

[sardisson]

[OPENSTEP]

To be fair, it is a lot easier for developers who have drunk the Apple koolaid and jumped onto their grand dev tool Objective C + Cocoa binge. Using the regular Apple frameworks and development tools makes life a lot easier. Unfortunately, a lot of big apps don't follow the Apple route for any number of reasons (legacy code, portability, tool preference). I think it's more those that will be the ones that may not survive the transition unless they're niche enough to justify the effort. Heck, I can't even get print drivers from Lexmark that are compatible with 10.4 and it's not like they're a small company.

ed

[jjmckenzie51]