* Peter Novodvorsky <[EMAIL PROTECTED]> [020131 11:58]: > But still it is long term way and I think we need to keep doing to > branches for packaging: > > 1. Bad ugly huge openoffice package. I'm not sure that we need to make > some big modifications for it. This is rather simple work and I'd > like Jan to reserve some night to spend it on IRC and I'll try to > teach him all tricks in this package, so he will be able to update > this huge package with new versions coming. > > If anyone else intrested in this job, you're welcome.
Yes, this is quite a heavy load. There have been many written offers to
help compiling here lately. I hope there will be some useable packages
early. (Though it might be hard to determine which source has which
copyright and which licence, escpecially the external code like gpc
and so on).
> 2. Bernhard's packages.
> Bernhard, can you send some status of work to the list? What are
> you working on, how's your progress?
I normally have only time when there are no courses in university.
Last time I have looked around sylvester in OO.o source.
When you look into the dependencies in the OO.o modules[1], you
will see quite some chaos[2]. This picture is also quite
confusing, as some important depencies are missing and many
depencies are dependencies for the "make test" rules.
It also is quite confusing, as modules seem to be placed
by some algorithm without using human intervention, so that
modules belonging together are sometimes quite far away and
vice versa.
In the middle of the bottom row, you see some of the most important
parts: sal (System Abstraction layer) and some helper libs.
This library encapsulates most of the communication with the operating
system. (Though not all and not very clean, see e.g. runtime-argument
handling via /proc and the like).
The top of this local group is idlc, which parsed the .idl-files
desribing types and interfaces in an very C++-like language.
Following the lines upwards you will find vos on the right side,
which is some other os-abstraction layer, this time written in C++.
On the left you will find codemaker, which creates header-files
for C++ (and for java) using the output of idlc.
Therefore I think these modules sal salhelper store registry vos idlc
and codemaker are the essential basis, as they contain os-abstraction
and the abilities to cope with the ".idl"s. I've put them to
a package with working-name "udk-basics-cvs".
The module udkapi contains the type-declarations for udk and therefor
for the whole OO.o. I've put them into udkapi-cvs which creates
the header-files for the rest and some basic libraries cppu and
cppuhelper)
The next level is more complex. Here upstream has seperated some code
and called it udk (UNO Development Kid). This is essential what the
module "product" (left side over the first block).
There is much java things in this, but I think this could be excluded
very well. (Almost everything in the lower left edge like javaunohelper
and ridjar belong to this).
Leaving these modules out is so easy, because on this level and above
modules are loaded as dynamic libraries on runtime. (normally using
cppuhelper)
I tried to put the modules bridges io and stoc into udk-components-cvs,
which creates these libraries. The bridges code is quite a mess.
Any trible of architecture-os-compiler needs its own bridge. There I
have till now only did an quick hack to for i386 gcc2 linux to be used.
If somebody knows which variables to look best for which is which,
writing the chosing code would be very good. (Every tripel is in an
own subdirectory under source/cpp_uno). Remotebridges may be added too,
but this bridge-thingies are that ugly that I can not stand their view
very long.
I think the next would be some packages I thought of naming
udk-tools-cvs, oo-api-cvs and oo-ucb-cvs.
Candidates for the first are cpputools rdbmaker and unotools. (First
two are already autoconfed)
Like udkapi contains the idl's for the udk, offapi and drafts contain
those for the rest. Drafts is for those not stabiliesed, but I do not
thing seperating them helps very much, as there are only one or two
modules only needing udkapi and not drafts.
An problem here is the generation of the header files. cppumaker seem
to have no modus to make only the headers for offapi and drafts but not
those of the udk again. (It only has a switch for not overwriting
existing files, but this is not option when making an new package).
When I have time I will look into this. Either deleting the already
existing files or changing cppumaker.
The next logical part would be oo-ucb-cvs. UCB (Universal Context
Broker) is some way of accsessing data. Many backends are in the
chaos package, which gives an translation tto an older system.
(Though there are currently thought upstream to drop these as most
are not needed any more (like imap and things like this))
The core build ucb and ucbhelper and some others. But I have not
investigated in this direction very much.
Hochachtungsvoll,
Bernhard R. Link
[1] I'm to lazy to search the original URL, for those who
do not have it, I've put a copy under
http://pcpool00.mathematik.uni-freiburg.de/~brl/o/oo-components-depends.ps
[2] I'm talking of the overall chaos, not of ucb's predecassor also
called chaos and found in this tree as module.
--
The man who trades freedom for security does not deserve
nor will he ever receive either. (Benjamin Franklin)
pgpZ7f9DGpBj2.pgp
Description: PGP signature
