cmollekopf added a comment.
FWIW, I have meanwhile used this patch to build all kube dependencies on
linux and osx as well, and it seems like it doesn't break anything.
I think clang-cl should receive all arguments it understands with this patch.
REPOSITORY
R240 Extra CMake Modules
cmollekopf added a comment.
There was already an earlier (abandoned) attempt at this:
https://git.reviewboard.kde.org/r/128779
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D20059
To: cmollekopf
Cc: kde-frameworks-devel, kde-buildsystem, michaelh,
cmollekopf created this revision.
Herald added projects: Frameworks, Build System.
Herald added subscribers: kde-buildsystem, kde-frameworks-devel.
cmollekopf requested review of this revision.
REVISION SUMMARY
clang-cl is an MSVC compatible frontend for clang, and as such
takes MSVC style
Thanks!
I'll be there.
Cheers,
Christian
On Thu, Jul 2, 2015, at 11:57 AM, Kevin Ottens wrote:
Hello,
Since the discussion on mailing lists regarding the Future frameworks
releases thread couldn't get to a proper conclusion and we agreed on
discussing the matter at Akademy, I took the
On Sun, Jun 14, 2015, at 07:53 PM, Alexander Potashev wrote:
2015-06-11 21:20 GMT+03:00 Sebastian Kügler se...@kde.org:
Introducing exceptions increases the complexity of dealing with frameworks,
their value really is in shared processes and requirements.
I am strongly against watering
On Tue, May 12, 2015, at 09:22 AM, David Faure wrote:
On Monday 11 May 2015 15:51:20 Christian Mollekopf wrote:
I think there are two possibilities:
* master is the development branch and we have a separate release
branch
= contributors have it easier because that is perhaps more common
On Mon, May 11, 2015, at 12:31 AM, David Faure wrote:
On Monday 11 May 2015 00:13:27 Christian Mollekopf wrote:
Are you volunteering, or just making demands for others to do work for
you?
I'm volunteering to do the maintenance and release engineering for the
libraries that matter
On Mon, May 11, 2015, at 02:42 PM, David Faure wrote:
On Monday 11 May 2015 11:57:02 Christian Mollekopf wrote:
But that doesn't necessarily mean they can't be part of the same
distribution mechanism.
If you simply take a snapshot of all frameworks every month, then it
shouldn't matter
On Mon, May 11, 2015, at 12:05 AM, Albert Astals Cid wrote:
El Diumenge, 10 de maig de 2015, a les 23:47:32, Christian Mollekopf va
escriure:
On Sun, May 10, 2015, at 11:23 PM, Albert Astals Cid wrote:
El Diumenge, 10 de maig de 2015, a les 22:31:10, Alexander Neundorf va
escriure
On Sun, May 10, 2015, at 11:13 PM, David Faure wrote:
On Sunday 10 May 2015 22:31:10 Alexander Neundorf wrote:
There I have Qt available, as Christian says, it feels like a system
library, our application is built on it.
Well, I wish you would see KF5 as a natural extension of Qt,
On Sun, May 10, 2015, at 03:39 PM, David Faure wrote:
On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote:
* I'd consider Qt to be a lower level library. Qt mostly provides
fundamentals just like libc or the STL,
and it's therefore okay for me to just work with what I have available
On Sat, May 9, 2015, at 01:27 PM, David Faure wrote:
On Saturday 09 May 2015 13:08:35 Alexander Neundorf wrote:
we pretend it's all independent libraries but still they all depend on the
latest version of all other libs.
It's a question of the definition of independent.
E.g.
On Tue, May 5, 2015, at 05:38 PM, Martin Gräßlin wrote:
On Tuesday 05 May 2015 17:30:05 Mario Fux wrote:
Am Dienstag, 05. Mai 2015, 13.46:16 schrieb Martin Gräßlin:
If master is always releasable, you should indeed only merge into master
with a change of a version number.
If you
On Wed, May 6, 2015, at 01:42 PM, Jan Kundrát wrote:
Hi Christian,
Hi Jan,
I think that the stuff you're looking for (reducing version churn) can
also
be provided by having stable branches for selected parts of KF5.
IMHO this can be quite an elegant solution given the usual cat-herding
On Tue, May 5, 2015, at 01:31 PM, Martin Gräßlin wrote:
On Tuesday 05 May 2015 13:20:25 Christian Mollekopf wrote:
On Tue, May 5, 2015, at 12:09 PM, Martin Gräßlin wrote:
On Tuesday 05 May 2015 11:33:03 Christian Mollekopf wrote:
What the regular releases IMO should be doing
Hey David,
Sorry for the late response.
On Wed, Apr 29, 2015, at 08:34 PM, David Faure wrote:
On Tuesday 28 April 2015 12:17:00 Christian Mollekopf wrote:
Our dependency tree is now indeed reduced, but if we want to update a
single library, we are forced to update all libraries, due
On Wed, Apr 29, 2015, at 09:45 PM, David Faure wrote:
On Wednesday 29 April 2015 15:00:32 Christian Mollekopf wrote:
You don't have to maintain any other combinations that what you already
do.
Just because the cmake versions aren't automatically bumped doesn't mean
you suddenly have
On Tue, May 5, 2015, at 12:11 PM, Martin Gräßlin wrote:
On Tuesday 05 May 2015 11:45:19 Christian Mollekopf wrote:
On Wed, Apr 29, 2015, at 09:45 PM, David Faure wrote:
On Wednesday 29 April 2015 15:00:32 Christian Mollekopf wrote:
You don't have to maintain any other combinations
On Tue, May 5, 2015, at 12:09 PM, Martin Gräßlin wrote:
On Tuesday 05 May 2015 11:33:03 Christian Mollekopf wrote:
What the regular releases IMO should be doing, is to take the latest
version from the always releasable master branch,
and be done with it (and that means not touching
On Wed, Apr 29, 2015, at 11:03 AM, Martin Gräßlin wrote:
On Wednesday 29 April 2015 09:35:12 Christian Mollekopf wrote:
On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote:
On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf
chrig...@fastmail.fm wrote:
Hi Christian,
I
On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote:
On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf
chrig...@fastmail.fm wrote:
Hi Christian,
I understand your needs, I've seen similar complaints before.
Letting frameworks depend on different versions could make sense, but
I
On Wed, Apr 29, 2015, at 01:29 PM, Martin Gräßlin wrote:
On Wednesday 29 April 2015 12:19:18 Christian Mollekopf wrote:
On Wed, Apr 29, 2015, at 11:03 AM, Martin Gräßlin wrote:
On Wednesday 29 April 2015 09:35:12 Christian Mollekopf wrote:
On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol
Hey,
For the Kolab Groupware Server we use some KDE libraries on the server.
Servers being what they are, the libraries we require are often not
available by default because the systems are too old, and we end-up
backporting what we need. To make this feasible in pre-framework times I
had to
Hi,
Is there a nameing convention for frameworks? I'd like to name the kimap
library, which isn't yet a framwork but will eventually become one,
KIMAP (all upper-case), instead of the current KImap, since IMAP is
an acronym. Same goes for KLAP.
This would of course only apply to namespaces, the
24 matches
Mail list logo
