relocatable kdoctools

[Ralf Habacker]

Hi,

I'm using the following patch to cross build kdoctools for windows

https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:KF536/mingw32-kdoctools/0001-Generate-xml-files-containing-relative-pathes-to-dtd.patch?expand=1

It requires only a little platform specific code - may be it helps.

Ralf


Am 22.08.2017 um 22:18 schrieb 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