Hi,

On Sat, 19 Jun 1999, Sven Radej wrote:

> On Sat, 19 Jun 1999, Reginald Stadlbauer wrote:
> >On Sat, 19 Jun 1999, weis@stud.uni-frankfurt.de wrote:
> >>Hi,
> >>
> >>Kay Roemer convinced my yesterday that I should try to strip mico
> >>as good as possible to get a slim version. I was very sceptical
> >>but here is what I did:
> (...)
> >>And here is what I got :-)
> >>
> >>a) An ORB that compiles on a single PII400 in 3min,10secs!!!
> >>b) [weis@teutates weis]$ ls -l /opt/mico/lib/libtinymico2.2.7.so
> >>   -r-xr-xr-x   1 weis     users     1826776
> >>   1.8MB !!!!!
> >>c) The size of the account example is 43kB instead of 100Kb now!
> >>
> >>With the real STL I got 2.6 MB and 100kB accont example.
> >>The rest of the optimization was done with mini-stl.
> >>As you can see STL sucks !!!!!
> >>
> >>I am soooooo happy :-)
> >
> >That's great news! Will we switch to such a tinyMico?
> 
> Er... this means we are kind of forking the tree. Unless Kay  provides some
> kind of #ifdef TINYMICO or --tiny-mico configure option.
>
I put heaps of #ifndef TINY_ORB in the code and Kay promised me
to take the stuff in their CVS:

> If we don't use that STL (mini or true) who does then? Mico itself?

Mico needs a subset of STL and mini-stl is just this subset.
KOffice once used real STL, but since we have the QTL this is
not needed any more.
 
> As far as I understood there still should be change in IDL to make "Qt-like
> source" . Will then (mini) STL still be needed?

Yes. I dont want to change the mico code itself to use Qt since that
would not go in the mico CVS. But skels and stubs will use Qt instead.
Mico core and skels/stubs are very well separated, so that this is
possible.

Bye
Torben

> 
> -- 
> Sven Radej      radej@kde.org
> KDE developer   Visit http://www.kde.org
> 
>