* Peter Novodvorsky <nidd@alt-linux.org> [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)
Attachment:
pgp0QlHTHf1N_.pgp
Description: PGP signature