Quassel IRC Repository - quassel.git/atom - src/client/CMakeLists.txt history Quassel IRC https://git.quassel-irc.org/?p=quassel.git Quassel IRC static/git-favicon.png static/git-logo.png 2018-11-18T10:06:43Z gitweb modernize: Remove old-style slot usage in NetworkModelController 2018-09-19T19:05:08Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2018-09-19T19:05:08Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=61f33c7895e324f6e95034d86897ad2e963653f1
modernize: Remove old-style slot usage in NetworkModelController

Use member function pointers in NetworkModelController and related
classes, instead of old-style slots and invokeMethod().
  • [D] src/client/CMakeLists.txt
src: Mark symbols to be exported where needed 2018-09-02T21:34:36Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2018-09-02T21:34:36Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=92fc8c5b119111a35ab8423c3cbde5b2a022badf
src: Mark symbols to be exported where needed

Generate export headers for the Quassel modules, and mark all
relevant classes and function to be exported so that shared libraries
can be linked against without globally exporting all symbols.
This is a hard requirement for Windows DLLs, and more efficient on
other platforms, too.

For now, this was done incrementally until everything linked properly.
In the future, we may consider explicitly defining the public
interfaces for each module, and trying to minimize the linker
interface e.g. by PIMPLing.
  • [D] src/client/CMakeLists.txt
cmake: Link resources statically, and init locally 2018-08-29T16:15:47Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2018-08-29T16:15:47Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=d4b64322860b0dfcc9e1340a3b3a0b0df3e2eb81
cmake: Link resources statically, and init locally

Link resource libraries statically in order to avoid problems with
symbol exporting. Move resource initialization from main() into the
respective libraries.
  • [D] src/client/CMakeLists.txt
cmake: Autogenerate most of the .qrc resource files 2018-08-15T23:35:09Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2018-08-15T23:35:09Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=1a45f16a9734820fba42fe1db3f38dd1eee49df6
cmake: Autogenerate most of the .qrc resource files

With the CMake support from the previous commit, resource files
can now be autogenerated. Do this for almost all resources;
the hicolor one is special because it uses aliases, and the i18n
one requires more work that is going to be added in a follow-up
commit.

Combine several of the previous resources (e.g. different icon sets)
to reduce complexity. This wasn't possible previously due to the
various configuration-specific combinations, but can now be done
dynamically by extending the glob patterns accordingly.
  • [D] src/client/CMakeLists.txt
cmake: Modernize build system 2018-08-02T21:16:22Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2018-08-02T21:16:22Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=4ce53949ab7d52a49ae79b8817bd3aa50fada0d1
cmake: Modernize build system

Move to the modern, property-based way of using CMake. This
simplifies a lot of things:
 - No need to manually specify interface include dirs and libraries
   of dependencies
 - No need to carry around variables
 - Clear separation of local and global dependencies and definitions
 - No need for hacks to make the triple-executable thing work

Provide convenience functions to set up library and executable
targets. This will make it very easy in the future to split up
some modules, as well as move towards using shared libraries.

Use the modern, property-based way of using Qt, too. This removes
the need for the deprecated qt5_use_modules() macro, and a bunch
of manual things we had to do to get the compile flags right
for the different Quassel executables.
Also make use of CMake's AUTOUIC and AUTORCC to avoid a bunch of
boilerplate for dealing with .ui files and Qt resources.

Move the .ui files from their subdirectory into the qtui directory,
since the separation doesn't really make too much sense. We'd rather
want to split the QtUi module into smaller parts/libraries.

Remove a bunch of unnecessary stuff from the CMake files.
  • [D] src/client/CMakeLists.txt
cmake: Remove build system support for Qt4/KDE4 2018-07-16T22:11:57Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2018-07-16T22:11:57Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=0216d4a650c02155b5bcd517567209f674d8a120
cmake: Remove build system support for Qt4/KDE4

In our quest to modernize the codebase, remove support for the
long-dead Qt4 libraries (and consequently, also for integration
into KDE4) from the build system.
  • [D] src/client/CMakeLists.txt
Automatically synchronize CoreInfo when on connect and disconnect 2018-03-02T03:04:50Z Janne Koschinski janne@kuschku.de Manuel Nickschas sputnick@quassel-irc.org 2018-03-02T03:04:50Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=bd5414d8bfe2be18ba051d4bbf936e9ead0cdf66
Automatically synchronize CoreInfo when on connect and disconnect

This refactors CoreInfo to be a single common class rather than
separate classes for the core and client, adjusts it to properly
use the SyncableObject infrastructure, and adds support for
dynamically updating the list on both the client and core when a
client connects or disconnects, keeping the list up-to-date at all
times.  Forwards and backwards compatibility is maintained, though
the updated client is required in order for the automatic updating
to work.

Signed-off-by: Janne Koschinski <janne@kuschku.de>

Co-authored-by: Janne Koschinski <janne@kuschku.de>
Co-authored-by: Michael Marley <michael@michaelmarley.com>
  • [D] src/client/CMakeLists.txt
dcc: Introduce TransferModel for DCC file transfers 2016-06-08T20:18:14Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2016-06-08T20:18:14Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=7b8a28df7c0dfab0d5691e75b1932be9f4209c17
dcc: Introduce TransferModel for DCC file transfers

This model serves as input for a yet-to-come widget for displaying
the current list of transfers.
  • [D] src/client/CMakeLists.txt
Remove support for network detection via Solid 2015-02-06T21:22:21Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2015-02-06T21:22:21Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=165298e0c0ef4666ed9c29f529e35fb4a37913ce
Remove support for network detection via Solid

Now that we rely on Qt 4.8 and up, we can use QNCM on all platforms.
Solid::Networking didn't do anything else, and is deprecated in
KDE Frameworks in favor of QNCM anyway.

Also improved the core connection settings dialog a bit.
  • [D] src/client/CMakeLists.txt
Use link dependencies between Quassel modules 2015-01-03T00:19:10Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2015-01-03T00:19:10Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=1d3537dca504cb52ff0434471537a96ca4432007
Use link dependencies between Quassel modules

Rather than expressing build dependencies between the Quassel
modules through add_dependency, we should treat those as link
dependencies instead. This has the added advantage that transitive
deps work properly (including properties like include dirs).
  • [D] src/client/CMakeLists.txt
Avoid race conditions in the build system 2014-03-28T23:57:22Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2014-03-28T23:57:22Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=9e21879f361dfe9978fb5159664cae352301064b
Avoid race conditions in the build system

Adding resource files in multiple targets is a bad idea, because CMake
will happily generate them multiple times too, and unfortunately also
in the same location. With Qt5, this actually lead to a misgenerated
oxygen_kde.qrc some times.

Now we add the resources in the module they belong to, which not only
avoids these race conditions, but also saves some time during compile,
because every resource file is only processed once now.

Changing this triggered yet another race condition, where not all translations
would be generated by the time the corresponding .qrc was needed. Adding
a fugly add_dependencies(mod_common po) fixes this; however we may want to
find a cleaner way to properly express deps between the language files and the
qrc.
  • [D] src/client/CMakeLists.txt
Completely rework the dependency handling in the build system 2014-03-23T01:39:38Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2014-03-23T01:39:38Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=2273a95ba9c277ce6dd7a67158a3d3ed9f161182
Completely rework the dependency handling in the build system

Traditionally, optional build dependencies are handled in CMake via
offering options and conditionally searching for the needed packages.
This leads to having lots of options, boilerplate for telling the user
which features are enabled or not, unclear handling of automagic
dependencies, and so on.

These days, CMake offers a much nicer way: feature_summary() and friends.
To make use of this, one calls find_package unconditionally and then sets
properties on the package that tell CMake if the dependency is optional
or required, its purpose, a description of the package etc. At the end
of configuration, CMake then displays a nice summary of all the packages
searched for and (not) found, as well as other features.

Quassel now makes use of this modern way of specifying dependencies, replacing
most of the former options (they're still there, but unused now, and will
be removed soon). Note that one can still disable an optional dependency Foo by
passing -DCMAKE_DISABLE_FIND_PACKAGE_Foo=TRUE to CMake.

I also took the opportunity to radically clean up and fix how we handle
dependencies throughout the build system:

* We no longer set an extra CMake variable to indicate that a package was
  found, but use the Foo_FOUND variable directly
* Compile definitions and include directories are no longer set globally
  in the root CMakeLists.txt, but in the Quassel modules where they're
  actually needed; this should speed up compiling ever so slightly and
  generally make things much cleaner
* Libraries are now linked directly to the Quassel modules that use them,
  rather than to the executable. This prepares us for making the modules
  shared libraries at some point, and is anyway The Right Thing™ to do
* Fully support Qt5 in the build system, including finding the proper version
  of dependencies where appropriate and available

Note that the changes to the build system are not complete yet, and some things
may be broken now. Note also that while Qt5 is now supported in the build system,
the code itself still requires many changes to actually compile with Qt5,
so don't even try.
  • [D] src/client/CMakeLists.txt
Improve the CMake option stuff 2014-03-20T21:29:42Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2014-03-20T21:29:42Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=3d3a6b8d34b9d0ab3a2502936c49c0d0d5e91617
Improve the CMake option stuff

We now use cmake_dependent_option() to express dependencies between
the various options that you can give to CMake for configuring Quassel;
for example, enabling KDE4 now forces some options to OFF regardless
of the user-selected value (which will, however, be preserved in case
KDE integration is disabled again later).

This also renames WITH_QT5 to USE_QT5 (and adds a USE_QT4, too); this seems
to have emerged as the standard way to select a Qt version for dual-Qt
packages. However, Qt4 is still selected by default unless you force Qt5
by setting the USE_QT5 flag. BTW, don't get your hopes up, Qt5 support is
still broken... Once it's working, we may select Qt5 as default for certain
platforms.

Additionally we renamed QT to QT_PATH to make the function of this flag
more clear.
  • [D] src/client/CMakeLists.txt
Simplify handling of (dual-)Qt in the build system 2014-03-19T20:00:07Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2014-03-19T20:00:07Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=5b43f2776fa53bfe15a5b3b4398dfe3e931d5802
Simplify handling of (dual-)Qt in the build system

We've used a somewhat complex way to link the various targets to the
required Qt libraries (and use the correct defines and CFLAGS...), because
when that stuff was written, there were no target properties in CMake, and
thus it was not easily possible to build targets within the same scope with
different settings. Therefore, we couldn't use the QT_USE_FILE and had to
write our own library handling.

These days, target properties exist, and Qt5 came up with a nice way to attach
the needed properties based on the Qt modules in use: qt5_use_modules()
This was later backported to Qt4, too, replacing the old way of having to
include QT_USE_FILE which would then set global variables.

We now make use of this; because qt4_use_modules() only showed up in
CMake 2.8.10, we've copied that function. It will be used only if it's
not present in CMake proper.

As a bonus, I've also wrapped all the qt-related macros into functions
that do the check for the Qt version we want to build against, and select
the proper macro to call, thus removing lots of WITH_QT5 conditionals
from the rest of the build system. Note that Qt5 support is still incomplete,
anyway.
  • [D] src/client/CMakeLists.txt
Enable automoc 2014-03-17T22:15:57Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2014-03-17T22:15:57Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=0de0a17782cf478d638a532f36898197af88e0bc
Enable automoc

Finally we can make use of this very convenient CMake feature and have
the moc stuff handled automagically. No need to list the headers anymore
for feeding them into the long-deprecated qt4_wrap_cpp macro.

Also, this should compile a bit faster and lead to slightly better optimized
code, because automoc will combine all the generated moc stuff for a target
into a single translation unit.

Note that we could get rid of various empty .cpp files (where all the code
is in the header) by just adding the header to the sources list; that way,
automoc will pick them up. There is no need to have a dummy .cpp file for
that.
  • [D] src/client/CMakeLists.txt
Refactor the transfer stuff 2013-12-28T21:26:27Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2013-12-28T21:26:27Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=0d7b511c8510d7fd05d3a704114e34ff37f7a995
Refactor the transfer stuff

Well, sometimes refactorings come sooner than usual. While thinking
about the next steps, I decided to handle the actual transfer logic
inside Transfer rather than TransferManager - now that we can have
selective (peer-based) sync calls as well, that makes more sense than
outsourcing that to TransferManager. Thus, it now makes lots of sense
to have ClientTransfer and CoreTransfer, as the logic will be quite
different.

I also took the opportunity to clean up the accessors and make them
safer; you can now get a non-const CoreTransfer pointer, for example,
but still only a const ClientTransfer pointer.

Also, some useful signals have been added.
  • [D] src/client/CMakeLists.txt
Basic infrastructure for file transfers 2013-12-26T19:57:34Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2013-12-26T19:57:34Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=100a2678adf2016b7b4753d09d868929de83294e
Basic infrastructure for file transfers

This introduces the Transfer class as well as TransferManager and the
specialized versions for client and core. It also adds the needed accessors
in Client and CoreSession as well as the SyncableObject stuff to make it all
work together.

To make something happen, a Transfer needs to be created on the core side with
the appropriate attributes; it needs then to be synchronized and handed over
to CoreTransferManager::addTransfer(). This will trigger the creation of the
appropriate Transfer object on the client side, adding this to the
ClientTransferManager as soon as synchronization is complete (meaning, the
transferAdded() signal will be fired with a fully synchronized Transfer object).

Note that the list of transfers is not synchronized (yet?), so there won't be a
transfer history on re-sync.
  • [D] src/client/CMakeLists.txt
Abstract away the protocol handshake code 2013-11-07T19:35:55Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2013-11-07T19:35:55Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=64cf9f9b8a737dad5f29447805d4004cfd03c454
Abstract away the protocol handshake code

This continues (and hopefully mostly concludes) the work begun
in 0e1b154 - abstracting away everything protocol-related from the
rest of the code, so we can later add another protocol. It's also
nice to not have all sorts of network- and protocol-related stuff
intertwined into central classes like Core and CoreConnection.

Note that nothing should change for end-users, modulo bugs. So new
and old client and core should work together in all combinations,
with and without SSL and/or compression. Please let me know if
something's wonky. That's also true for things like connection failure
handling and reconnects, as there have been many changes in those areas.

Turns out that abstracting the handshake stuff was much harder and
much more invasive than the previous work in SignalProxy. Turns also
out that the legacy handshake protocol is not the best ever. So
this touches lots of places in the code; sorry for a diff with over
3000 lines, but there was no way to sanely split the commits.

Anyway, here's the gist of it:

* Add auth handlers on both core and client side that process the
  handshake based on the generic message types in protocol.h - lots
  of code moved from CoreConnection and Core into the new classes.
  Note that "AuthHandler" is a stupid name for what it does, so we'll
  probably rename it to HandshakeHandler or something later.

* Extend LegacyPeer to translate the new message types to and from the
  legacy format, moving protocol-specific code out of the existing classes.
  Right now only "compat mode" is supported, i.e. the handshake we've
  been using for what feels like a decade. In the future, some of that
  should be done much nicer whilst keeping the same wire format. For now,
  there's several quirks in LegacyPeer to somehow map the insanities in
  the existing protocol to something that won't bite us in the future once
  we want to clean up that mess.

* Auth handlers will create the peer now - this is because later on the
  peer we need will be determined by protocol detection, which is part
  of the handshake.

* Use the generic protocol message types directly where it makes sense
  (in particular for things like SessionState) - instead of QVariantMaps.

* Lots of cleanups, API changes etc. were done in passing.

* Probably more that I choose to not remember right now.
  • [D] src/client/CMakeLists.txt
Fix buildsys to work without DBus 2012-07-07T10:34:45Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2012-07-07T10:34:45Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=2398c7e042503af664864a83a3cf1bced99448ab
Fix buildsys to work without DBus
  • [D] src/client/CMakeLists.txt
Add support for Qt5 in the build system 2012-03-30T23:17:14Z Manuel Nickschas sputnick@quassel-irc.org Manuel Nickschas sputnick@quassel-irc.org 2012-03-30T23:17:14Z https://git.quassel-irc.org/?p=quassel.git;a=commitdiff;h=ff81aaec156b8dc2e12f49286fd69e55f215af29
Add support for Qt5 in the build system

Support for building against Qt5 can now be enabled by passing -DWITH_QT5=1 to CMake.
Note that your Qt5 installation (the qmake location) needs to be in your PATH, unless
it's already in one of the standard system locations.

Needless to say that Qt5 support in Quassel is highly experimental, though surprisingly
it seems to work mostly fine already. A README.Qt5 with known issues is forthcoming.

As a side effect, I've cleaned up the build system a bit and got rid of QT_USE_FILE and the related
fugly hacks for Qt4 (so that the -I and -D options now actually match the modules we're building
against).
  • [D] src/client/CMakeLists.txt