Hi, a couple of comments:
- The tests should be built by default. That's the whole point of them --
whenever someone compiles Trojita (and *especially* when someone makes any
change), the tests must be run.
- The build should abort when someone attempts to build with KDE and Qt5
support at the same time; there are no KDE libraries with support for Qt5
yet.
- I'm not sure about the WITH_RAGEL option -- I'd prefer to have it
tri-state, "force on", "force off" and "autodetect" with defaulting to
"autodetect". The same applies to WITH_ZLIB.
- WITH_KDE, WITH_AKONADI and WITH_KONTACT should not default to "on";
either use an automagic detection or leave them off by default. I do not
plan to deal with "but now it requires KDE" support e-mails.
- The plugin directory must not be something overly generic like /usr/lib.
Please use configure.cmake.in (you might have to rebase on top of current
master for that) and use something like
"@CMAKE_INSTALL_PREFIX@/libexec/trojita" as the path.
- It seems that the cmake options do not work at all; when I run `cmake
-DWITH_KDE=1` in a clean build dir, no cmake messages about QtKeychain are
output and the build later dies with an error when including it. I don't
have that library on my system.
- I see that FindKDE4Internal.cmake is rather creative in its clobbering of
CMAKE_CXX_FLAGS (which you partially undo when enabling exceptions). I have
mixed opinions here -- the increased warnings are OK, both -fno-check-new
and -fno-common are either harmless or good, and only the exceptions are a
problem. Still, I'm considering building the KDE-specific plugins within a
subdirectory so that these KDE-specific flags do not affect the rest of
Trojita.
- There should be a way of building *just the plugins*, or even better,
just a single plugin at a time. This will be important for packaging where
each plugin should go into a separate package.
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
