Hi Rüdiger,
Rüdiger Timm wrote:
Armin Le Grand wrote:
[...]
I haven't read that restriction anywhere. Kays proposal was about any
incompatible change below binfilter.
It's not a restriction, it's logic. Why else should code be moved to
binfilter ATM? Kay is right because incompatible changes below binfilter
are a good indication for such cases.
See above: i understand Kays recipe as not to do so. And that I consider
wrong. That's why I wrote about duplicating code, not just moving it.
Duplicating ATM is always a necessity when the original code changes so
much that it cannot be used/shared with binfilter anymore. When we would
have made it independent, all the necessary code would have been
duplicated (most already is), but potential changes would just not need
to take notice about binfilter and may be changed in the living modules
as required...
I do not think that we would save so much. We still would need binfilter
on our master workspace just to get part in all changes to linker
switches, baseline, and so on. So, everyone doing full builds would
still have to check out and build binfilter, it just would be bigger.
Of course, costs for adapting and maintaining would vanish. But would
that outweigh the initial transformation work?
It would. With original plans, binfilter would be a module in the 8.0
release and be link-incompatible from the other modules. It is used as a
UNO component anyways, so it would be usable with offices up to today,
how incompatible and changed they may ever be (thatÄs the UNO API
definition).
Think about it: All the compiler changes, environment stuff, includes,
incompatible builds, adding to CWSes, would not have happened. This is
what i call man-Years and ressources...
Rüdiger
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
