relocatable kdoctools

[Harald Sitter]

On Tue, Aug 22, 2017 at 11:32 AM, Ben Cooksley <bcooksley at kde.org> wrote:
> On Tue, Aug 22, 2017 at 9:25 PM, Harald Sitter <sitter at kde.org> wrote:
>> Ahoy ahoy
>
> Hi Harald,
>
>>
>> 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.
>>
>> 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?
>
> The CI system relocates binaries and other resources on FreeBSD, so
> this should be working on other platforms as well (otherwise anything
> that depends on KDocTools would fail to compile on CI) unless i've
> missed something.

>From what I see this only affects resolution of external assets
actually (e.g. shared schemas from docbook-xml), so this wouldn't
affect CI as /usr/share/xml/ doesn't change location between jobs.

> In general though: relocation is always a good thing. Hardcoded paths
> are a bad thing.

Indeed :)

HS