Thought about a Qt port

[Lubomir I. Ivanov]

On 30 March 2013 18:38, Thiago Macieira <thiago at macieira.org> wrote:
> On sábado, 30 de março de 2013 07.20.50, Dirk Hohndel wrote:
>> We don't use autotools now, we won't move to them for a Qt build. Right
>> now we have a hacked together Makefile that does a lot of fun things for
>> us.
>>
>> I have never tried to use qmake but hear even less love for it than for
>> autotools (and that is saying a lot). Maybe we can start with qmake for
>> the initial exploration / prototype and as we move towards a first
>> buildable version that maps out the UI and links it with the existing
>> logic we can revisit this question as well?
>
> I took a look at it and I'd propose the following:
>  - hack the Makefile a little more and give it basic Qt support
>  - in parallel, if someone is interested, try porting to qmake
>
> Adding basic C++ and Qt support to the Makefile isn't difficult. Adding support
> for Qt resource files is also trivial, if that feature is ever needed. Support
> for moc and uic can be done, but without a good dependency scanner, subsurface
> will have to obey some strict rules about where the #includes can be placed
> for the generated files. Or manually adjust the Makefile to declare the
> dependencies.
>
> qmake is easy to use and good at *building*, but not at *detecting* stuff. If
> you have hard dependencies you just want to use, qmake can do it. To detect,
> the code will be a great deal uglier. Even for installation, it might be ugly.
>
> In fact, maybe the ideal solution is hybrid: leave the current Makefile for
> detecting and installing, but ask qmake to generate another Makefile for
> building. Or if we can get the install rules working with qmake, create a
> simple configure script.
>

my understanding of qmake is bit limited, but i think the hybrid
solution sounds good.
- we distribute some sort of a default .pro file.
- we leave the compiler/linker stage to qmake and the Makefile it
generates, but there is a default Makefile that handles dependencies
and install
- pulling the repo and calling `make` would call the default Makefile,
which will gather what is available and (for example) SED into the
.pro file the macros libs and lib headers if possible
- qmake -o Makefile.qmake will then be called generating the
compile/link makefile, and then Makefile.qmake can be called with
`make -f` again from that main Makefile rule

not sure how well will that work though...

also i would like to point out that for the native Win32 build of
Subsurface i'm not using POSIX shell commands and pkg-config at all,
but a custom Makefile.win32 that has a bunch of paths hardcoded and
works with `cmd.exe`. i find the use of pkg-config pointless on Win32
given there are no real package managers except the one for cygwin
(which is kind of good) and also for the fact a lot of libraries
simply do not distribute .pc files for something like the MSYS shell,
so one has to write his own. so checking if a -dev package is
available on Win32 is a non-trivial in my experience.

lubomir
--