I could not recreate the problem this morning, but I noticed that the Neo_Tag in the makefile was set to HEAD, not the experimental path. Was this deliberate or should this be changed?
This was an oversight. However, that tag only affects the creation of the source bundle in the build so I will wait to update it later. I will have to change a bunch of other make macros as I think that I will switch the application name back to NeoOffice/J for this release. I'm also thinking of calling it NeoOffice/J 1.1.5 to be in sync with the OOo release number.
I could not recreate the problem this morning, but I noticed that the Neo_Tag in the makefile was set to HEAD, not the experimental path. Was this deliberate or should this be changed?
This was an oversight. However, that tag only affects the creation of the source bundle in the build so I will wait to update it later. I will have to change a bunch of other make macros as I think that I will switch the application name back to NeoOffice/J for this release. I'm also thinking of calling it NeoOffice/J 1.1.5 to be in sync with the OOo release number.
Ok. I would agree that it should be 1.1.5. There is work ongoing on 1.1.6 (see the OOo's IZ).
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed Oct 12, 2005 9:16 pm Post subject:
Back on the gcc4 debugging front after my weekend recovery is complete. I think I just found some more getCppuType to static_type conversions in cppuhelper in queryinterface.hxx and stdidlclass.hxx that I may have missed. This may be why some of the type lookups are coming through as weak references in the gcc4 system but not the gcc3. Am recompiling now.
I'm also thinking of calling it NeoOffice/J 1.1.5 to be in sync with the OOo release number.
I understand the desire to keep the in sync with the OOo release number as it lessens some confusion, but, as I understand it, it's bad software release practice to drop support for a major version of an operating system in a minor (hundredth, 0.0.1) point release, and doing so causes confusion and sometimes ire from the users whose OS version got dumped unexpectedly.
(And we do have some 10.2 users still out there; a couple of them have reported bugs in 1.1 final in the past two weeks....)
I've also argued before that the next version of Neo/J (at least as I understand it) will be a significantly different product from 1.1 final; in addition to the bug fixes and ODF import from OOo 1.1.5, we have a ton of bug-fixes enabled by switching from Java 1.3.1 to Java 1.4.2 plus performance benefits and lower RAM usage and what-not from that upgrade, improved compatibility with 3rd-party products (the folks who can now dictate into Neo/J from iListen, and that other product we no longer hang up by virtue of ditching 1.3.1). I'm not sure what the timetables or plans are, but it looks like there's an outside chance we'll have Intel Mac compatibility (maybe?). All of which is to say that on features and fixes and changes alone, I think we have enough to warrant an honest 0.1 increase to Neo/J 1.2.
This is really just semantics (even assuming the planned features for the release are still the same), but it is something to consider/keep in mind.
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
I've also argued before that the next version of Neo/J (at least as I understand it) will be a significantly different product from 1.1 final;
I agree. I think there is sufficient similarity between OOo 1.1.5 and Neo 1.5 for people to intuitively grasp what they are working with. Considering that many big software packages have been changing their versioning recently (NetBSD, Java), we'll just be another blip on the radar screen.
For me, personally, just as good an opportunity to drop the /J as is the switch to OO 2.0. But that might be just me... _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
I've also argued before that the next version of Neo/J (at least as I understand it) will be a significantly different product from 1.1 final;
I agree. I think there is sufficient similarity between OOo 1.1.5 and Neo 1.5 for people to intuitively grasp what they are working with. Considering that many big software packages have been changing their versioning recently (NetBSD, Java), we'll just be another blip on the radar screen.
I agree with this annotation for the Neo/J with OOo 1.1.5 included.
ovvldc wrote:
For me, personally, just as good an opportunity to drop the /J as is the switch to OO 2.0. But that might be just me...
I would say to hold off on Neo 2.0, because folks would assume that it includes the full functionality of OOo 2.0, which it will not.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat Oct 22, 2005 2:01 pm Post subject:
news on the gcc4 front...
I found and replaced some more getCppuType template invocations with static_type() invocations to match OOo2/gcc3.4 patches. Some of these were in interface querying code that may have an impact.
These latest changes aren't checked into CVS on the branch as it seems no one other than I am rying to look into this
If I can't resolve the type system junk soon on the branch I'll just revert back to using gcc3.3 on Mactel. I've been avoiding this more since the compilers aren't "official" from Apple, so there may be ABI issues when linking against system libraries compiled with gcc4. I have a gcc3.3 x86 mactel build I made so I could get g77 binaries compiling, but I've only been linking against libSystem and not any of the higher level frameworks yet.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat Oct 22, 2005 4:08 pm Post subject:
Recompiling after nuking udkapi. There very well may be stale object files. dmake does not apparently track changes to compmaker tools or other derived tools as being requirements to trigger recompilation of dependencies.
If I can't resolve the type system junk soon on the branch I'll just revert back to using gcc3.3 on Mactel. I've been avoiding this more since the compilers aren't "official" from Apple, so there may be ABI issues when linking against system libraries compiled with gcc4.
I dimly recall reading somewhere that OOo 2.0 was compiling on gcc4. Eric and Ed, I'm sure you know more about this than I do. Any comments?
I don't know how much closer 2.0 would be to working on MacTel than 1.1.5, but if it is further along, would there be a point in just moving to the 2.0 codebase for MacTel? That would kill two birds with one stone, and might be preferable over putting so much time in 1.1.x and then abandon it almost right after it is finished?
Just a thought.
Best wishes,
Oscar _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
I dimly recall reading somewhere that OOo 2.0 was compiling on gcc4. Eric and Ed, I'm sure you know more about this than I do. Any comments?
You are correct in that the MacOSX/X11 version is compiling with gcc 4 (take a look at the child work space macosxgcc4 or SRC680_m134).
ovvldc wrote:
I don't know how much closer 2.0 would be to working on MacTel than 1.1.5, but if it is further along, would there be a point in just moving to the 2.0 codebase for MacTel? That would kill two birds with one stone, and might be preferable over putting so much time in 1.1.x and then abandon it almost right after it is finished?
The X11 team HAS abandoned 1.1.x. 1.1.5 is as far as this branch will go. I think that the OpenOffice.org team wants to go forward with the 2.0.x and 3.x branches.
ovvldc wrote:
Just a thought.
Same here. One last thought. It may be time to move to 2.0.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Oct 23, 2005 9:08 am Post subject:
OOo 2's codebase will recompile with gcc4 and it is something I've thought about as a potential solution. The problem with that, of course, is that it is a much larger amount of work to adapt neoj's vcl to 2.0 then to try and backport the gcc4 support.
I may be encountering difficulties in the dependency system, though. After triggering a full recompile of all of the idl files the regmerge crash with failed type lookup no longer occurs. The cppuhelper tests seem to be running just fine, but yet the type system is still failing in setup.bin. Bizarre.
OOo 2's codebase will recompile with gcc4 and it is something I've thought about as a potential solution. The problem with that, of course, is that it is a much larger amount of work to adapt neoj's vcl to 2.0 then to try and backport the gcc4 support.
Of course. You and Patrick will have your hands very, very full.
But it will tackle two problems at once. Personally, I have been pleasantly surprised by the speed at which OOo 2 milestones seem to have become somewhat usable on the Mac so if we are in a bind now, the jump might be worth it. Better than having you frustrated with 1.1.x conversions.
And from a process perspective, it might help if both teams are working on the same code . We'll all be in this together, as it were - friends out of necessity..
Of course, the release of a 1.5 version with working Java 1.4 routines and the ability to read ODF is needed in the meantime. I would expect that, being an intelligent, forward looking fellow, Patrick is making his new code gcc4 proof as much as possible.
Best wishes,
Oscar _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Oct 23, 2005 10:59 am Post subject:
The problems aren't actually in any of the code Patrick or I have written...it's all legacy issues with OOo itself. There was only one file in neoj that wasn't gcc4 compliant, and the problems were in the code replicated from OOo.
I'm probably going to do a complete recompile from scratch today of the gcc4 code with the latest round of fixes. As all of the test applications for cppu and cppuhelper are functioning, I suspect that some of the IDL generated files may be stale or were not properly recompiled as I've fixed up cppu and codemaker. The dmake dependency analysis doesn't seem to trigger properly for indirect header changes and definitely doesn't trigger based upon modification dates to the compile tools themselves. Since the underlying system seems to be OK now, a full recompile will eliminate the possibiity that some of the idl derived headers weren't properly regenerated.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Mon Oct 24, 2005 10:20 pm Post subject:
Latest patches should now be in sync on anoncvs. The full recompile is presently in Neo's sw module. Hopefully I should find out by tomorrow morning whether or not it was a stale idl file or not.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed Oct 26, 2005 8:16 pm Post subject:
Well, stale idl is not the problem. There is still something wrong in the type system regarding interfaces with weak multiple inheritance.
Having spent nearly two months on this (!) I am now considering scrapping it as a viable experiment and moving onto the 2.0 migration. The 2.0 migration solves gcc4 compilation issues, so eventually all of this work would be useless anyway. If next May comes around, the Mactel release looms, and we can't get the 2.0 stuff stable, we can go to the fallback position of using gcc 3.3 to do an intermediate x86 compile (and I already have the set of patches to get gcc 3.3 for x86...mostly just Darwin-x86 patches).
Spending my time on 2.0 at this point is probably more worthwhile in the long term then a stopgap solution.
Still, I hate giving up...it really doesn't jive with my big-a** ego
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
. We'll all be in this together, as it were - friends out of necessity..
