Armin Le Grand wrote:
[...]
That's the right way to go.
Please take in mind what kind of code is/will be moved to binfilter:
- code that is no longer used in the 'living' office modules, but needed
by the old binary filter mechanisms
- code that is completely rearranged and cannot be adapted to also keep
up the needed (C++) APIs and functionalities for binfilter
I haven't read that restriction anywhere. Kays proposal was about any
incompatible change below binfilter.
Both cases happen, BECAUSE binfilter allows us to do things like that at
all and to enhance the 'living' office modules, not to expand binfilter.
The expansion of binfilter is the price to pay to keep the old binary
filters running, and that price was intended and is accepted ATM.
Do not forget that it is even DANGEROUS to change functionality/code
without noticing that binfilter is still using it. Binfilter may well
need controlled fixes from time to time in shared code regions which may
also enhance the living modules, but the other way around You risk to
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.
break binfilter functionality which cannot/is rarely tested anymore.
That's (one of the reasons, there were many others) why my initial plan
always was to freeze binfilter on a defined state.
Defined state means: Let it rest on a published version, this is never
deleted and stays buildable (if fixes are needed).
Freeze means: Add all still missing and urgently necessary C++
dependencies methodically: Link without the standard modules and add
missing code. Yes, this might take a while and is not easy but might
have been done by one person methodically, not costing man-years of
bandwidth, service, maintaining, bulding, adapting, developer time, ...
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?
Rüdiger
With the suggested steps we move to that target, so i am happy about them.
Comparing the costs spent up to now by all and that will be spent until
the goal is reached, i again have to suggest (as years ago) to do it
once, by one person and for the next public release. The resulting
binfilter module will be an UNO-API only module, independent of 'living'
C++ code and can then rest on that version.
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
