Excessive dependancies for OpenOffice 2.0 port

[Mikhail T.]

= > "Feeding them back" to OOo is a good idea, but it should not be
= > holding back the progress of the FreeBSD port. And that is my point.
= > In "lawyers' speak", the goals of the OOo and the FreeBSD are
= > similar, but not identical. Maho has a "conflict of interest" -- and
= > I feel the FreeBSD port is under-represented.

= IMHO there is no conflict of interest. (I shouldn't speak for Maho
= here, sorry for that.) There /should/ be no conflict as we all should
= only want a working and easily buildable OOo.

"Working and easily buildable" _on FreeBSD_, please.

= And "under-representation" is obviously not solved by working on ports
= and not contributing back the patches to OOo. The mysterious "someone"
= that represents the evil OOo can only be Maho in this case.

There is a conflict, of course. There is nothing "evil" about OOo, but
FreeBSD is just one of the platforms for them. They would not accept a
patch if it breaks something on another OS, obviously. So the fixes need
to be ifdef-ed properly, and sometimes configure-glue needs to be added,
etc.

Whenever one is working on that, one is working on OOo, not on the
FreeBSD port. I'm not saying, either one is good or bad, but the
distinction needs to be made, and the priorities better be acknowledged.

I think that -- ensuring, that a patch is acceptable to OOo -- should be
secondary in importance. If OOo builds and works on FreeBSD easily and
cleanly, then OOo people can take the patches from the port's files/ and
see about integrating them. May even be the same person doing it, just
wearing an OOo hat.

= > => Building a special version of C compiler is, AFAIK,
= > =unprecedented. Feel free to work around the bugs that prohibit the
= > =use of *old* gcc
= >
= > I do feel very free, thank you. But you are not really countering my
= > point here... Requiring a port-specific C-compiler is unprecedented.
= > You stated the problem, but the lang/ooo-gcc is NOT a solution to
= > it.
= Well, for a lot of linux distributions it was a solution to apply the
= patch to their system gcc. I assume the current FreeBSD system gcc is
= free of additional patches, so that would be unprecedented. ;)

Dunno... I built OOo using the system compiler on 6.0/i386 (with a
slightly modified port) and it seems to work...

= > Yes, OF COURSE, I did "ever look". Very nice of OOo to finally wise
= > up to this (1.x releases had very little flexibility in this). Too
= > bad, FreeBSD port does not use this, even where it can.
= As Maho said, there are problems (Bugs) with some of them. Maybe worth
= fixing?

If it is, then the Right Thing is to add the fixe to the FreeBSD ports
of these packages.

= > I don't have the time (to re-write makefiles into BSD or GNU make),
= > but I don't object to using dmake per se. I object to using the
= > bundled one instead of the devel/dmake.
= Hmm, the OOo configure checks for an installed version of dmake, yes,
= platform independent, if it doesn't use the installed one and builds
= the included version this is a bug. But maybe just another dependency
= is needed. (Didn't check)

There is a trivial bug in configure's dmake detection -- it only works
on Linux (I think). On FreeBSD sed needs the ``-E'' flag to do, what
they are trying to do... Yes, I have a (FreeBSD-specific) patch.

=[...]
= #endif
=
= constructs are likely to be rejected. It is a maintainance nightmare.

It is not the form of his patches, it is their intentions -- like
removing the "registration" dialog, for example, that make them
unacceptable. My point, however, was, that Kendy does not mind making
changes, that OOo will never accept. I think, it is because, owning both,
he wears a Debian hat more often than an OOo hat.

As for the ifdef-nightmare, it is happily perpetuated by OOo themselves.
Whenever a 3rd-party header is included, it looks like:

	#ifdef SYSTEM_FOO
	#	include "foo.h"
	#else
	#	include "foo/foo.h"
	#endif

Spot two mistakes... And these are _new_ additions. But I'm drifting
off-topic...

	-mi