[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summery [was OpenOffice]



and for the third-time... hi :)

On Sun, Aug 12, 2001 at 01:23:40PM +0200, Bernhard R. Link wrote:
>
>> Then, a few people diskussed, whether OpenOffice will be suitable for sid or
>> not. The result is, that we put OpenOffice, when it is ready, into sid.
>If something usable is finished, before sid is only in archive... I do not
>think that it may go that quick.

:)

>> The next problem is the stupid buildsystem. I depends on autoconfig and
>> libtool, but the buildsystem is created to build OpenOffice on
>> Windows/MacOS, too.
>I thinkg autoconf is not the problem there. Is is only used to create
>dmake an others and with minor changes they work well. (I have the
>beginning of an package for dmakge here (currently only potato), but I do
>not think that working with dmake will give any good).

I will make a dmake- packege tomorrow for sid.

>I'm of the opinion, that we should leave their build system where it is,
>and create buildscripts for our own. (Preferably using autoconf und
>helpers, as they tend to make it the right way).

There are autoconf in use, but in a strange way I'd never seen it. Perhaps,
we could take it and change for our advance. :)

And, of course, we have to include a (d)make (dist)clean), because there
isn't one! :)

>This would make it possible to split opennoffice in different packages,
>which can compiled of their own. ( Openoffice is highly modular and it
>would be a pitty to not map modules to packages, because their buildsystem
>want to build all at once. Ecspecially as they have many infrastructure
>like sal or uno, that could be seen in future in other programs, too).

Did you compile it successfully on your mashine once a time? Do you have an
overview what things openoffice wants to install?

This I think would give us a clue to plan the severel packages.

>This would it IMHO also make is easier to package it according to
>policy. Their build system is largly centered to build it in an way it
>is instalable by an user. And even for system-installs there seem to be
>loud voices within the upstream developers to only support it in
>subsystems i.e under /usr/local or /opt but not in /usr and with
>parts of config everything else in in /etc.

But this schould be an autoconf-thing and when we fix it, we will fix the
place place of the files :)

>It may also help the porters, as upstream seems to take the CPU-tags
>as subtypes of the operating system, and not as an independent thing.
>(so that it checks for LinuxPPC, Linux/Alpha,Linux/ARM, FreeBSD, Irix and
>NetBSD/Sparc...

Yes...

>> You have to use csh to set env- vars to compile it and for compiling, you
>> must in the csh, too.
>> And, there is no make (dist)clean, did anyone find it, me not.
>This are some other disadvantages, but I think they migh have fixed this,
>before we have some usable debian packages.

Ooooh yeah!!!

>> The next problem is, that the source of OpenOffice includes some of libs,
>> which are built as deb's for debian, for example libxmltok1.
>the list in external is:
>atl     cpp.lcc   dt        glibc  makefile.rc  odbc  psprint  twain   zlib
>X11  audio   dmake     expat     gpc    neon         pgp   sane     util
>ado  common  download  freetype  jpeg   npsdk        prj   std2     w4w

>most of them have patches ( ecspecially within the header files ), which
>may become an major pain in the ass to get this right, ecspecially as
>I do not see any reason except lazyness, why OO.o should have special
>version of such common libs.

Are they really different to our common-libs or do they put them with
OpenOffice to make it able to compile under Windows/Mac? 

On OpenOffice.org it was said, that zip and X11-dev will e required, but why
should I install it, when they will bring it with OpenOffice?

That had to be checked, I think, we can save a lot of time, if these libs
are similar with our common libs. :)

So, I will go to bed...

	Cheers...
			Jan
-- 
One time, you all will be emulated by linux!

----
Jan- Hendrik Palic
Url:"http://www.billgotchy.de";
E-Mail: "palic@billgotchy.de"

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s: a-- C++ UL++ P+++ L+++ E W++ N+ o+ K- w--- 
O- M- V- PS++ PE Y+ PGP++ t--- 5- X+++ R-- tv- b++ DI-- D+++ 
G+++ e+++ h+ r++ z+ 
------END GEEK CODE BLOCK------

Attachment: pgpnjyh3K6S_G.pgp
Description: PGP signature


Reply to: