relocatable kdoctools

[Luigi Toscano]

Harald Sitter wrote:
> Ahoy ahoy
> 
> I've just stumbled upon a rather puzzling situation with kdoctools. It
> has code branching to turn its assets relocatable [1] (i.e. resolve
> paths relative rather than hardcode their location). Now the weird bit
> about this is that it is only used on windows.

Hi,

it's not so puzzling: the main code assume a fixed position for the docbook
resources (which has been for long the case, if we consider them system
libraries). The windows code has been added (long time ago, and thanks to the
windows people for that!) as special case because the path required when
building and the path required when installing are a bit different.

See for reference when it was introduced:
https://commits.kde.org/kdelibs/38b5e7f937b5d2c291c5b20a0c8648632084dde5

And this revision when I tried to simplify it:
https://git.reviewboard.kde.org/r/120324/
https://bugs.kde.org/show_bug.cgi?id=293610

> The reason this puzzles me is that the relocatable code for Windows
> would work just fine for Linux and OSX, from what I can tell there is
> no real downside to it besides the additional code, which we need
> anyway. On the other hand, the conditional treatment of Windows gives
> the Windows code branch substantially less implicit run exposure (i.e.
> most devs/testers aren't on Windows, so fewer people build the
> relevant if-branch).
> 
> With that in mind: how about we drop the harcoding code path and make
> the Windows code path the default and have kdoctools assets always be
> relocatable?

No problem with relocatable code, in general, but my personal problem with
that code is that I have to rethink every time what it's doing and think twice
when I had to change it (as I did now with the review above), because of the
way it works. It may be a limitation of mine, but is there some way to make
what it's trying to do in a more simple way?

Ciao
-- 
Luigi