[Okular-devel] Building on Windows

[Albert Astals Cid]

El Wednesday 09 March 2016, a les 17:16:10, Thomas Friedrichsmeier va 
escriure:
> Hi,
> 
> well, I was curious what this would result in. I subscribed just now,
> so breaking the threading...
> 
> Albert wrote:
> > Damn, the thing is what you're saying (except the "1" bit) seems more
> > of a windows thing than an okular thing.
> > 
> > Not sure if someone here can actually help with those, i know i can't.
> > 
> > But keep us informed of your progress :)
> 
> Sounds a bit like this won't be going anywhere, which would be sad,
> considering that we're actually pretty close to a working port.
> 
> Of course it _is_ difficult the problem is specific to "that other
> OS", somehow, but it's also often difficult to resolve such problems
> without good knowledge of the project-specific parts. (There
> are definitely more knowledgeable people on kde-windows, but it's
> not like they are just sitting idle, waiting for something to do...)

The knowledgeable people here are not just sitting iddle, waiting for 
somethign to do either.

> Do note that it is not excessively hard to get started on building on
> Windows, currently. If you don't want to build from scratch, there's
> actually a relatively fresh pre-built snapshot. Doesn't take much
> besides a Windows VM to get started. See
> https://mail.kde.org/pipermail/kde-windows/2016-February/009586.html
> 
> Alternatively, I guess Jonathan will be happy to test-build any patches
> you sugggest.
> 
> On the specifics of this problem:
> The visibility-problem is roughly that settings.cpp (kconfig-compiler
> generated) has visibility for okularpart, only, but is also linked into
> plugins. For that purpose, mobile/components/CMakeLists.txt adds a
> custom definition to the (generated) settings.cpp. That apparently does
> not work, but I have no first hand-experience with KConfig-Compiler and
> visibility don't understand half of how this is supposed to work.
> Probably what is needed is something similar to the platform #ifdef in
> interfaces/viewerinterface.h, but I have no clue how to get that into
> the generated source.

If the problem is the mobile part, you may as well leave it out for now.

> 
> Part 3, name of the lib probably just needs some cmake setting, but
> actually, ui/shell.cpp has a code-comment wrt loading the plugin that
> might just point to a cleaner solution.

Nice :)

Cheers,
  Albert

> 
> Regards
> Thomas