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
RE
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, ngrah
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 arg
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
On Sun, Jun 14, 2015, at 07:53 PM, Alexander Potashev wrote:
> 2015-06-11 21:20 GMT+03:00 Sebastian Kügler :
> > Introducing exceptions increases the complexity of dealing with frameworks,
> > their value really is in shared processes and requirements.
> >
> > I am strongly against watering it do
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
> >
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
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 rel
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 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,
On Sun, May 10, 2015, at 11:23 PM, Albert Astals Cid wrote:
> El Diumenge, 10 de maig de 2015, a les 22:33:30, Christian Mollekopf va
> escriure:
> > On Sun, May 10, 2015, at 03:39 PM, David Faure wrote:
> > > On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote:
>
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 Sunday, May 10, 2015 15:39:02 David Faure wrote:
> > > On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote:
> &g
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 m
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 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-he
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.
> >
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 regula
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 d
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 do
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 bumpe
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 li
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
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
> > > wrote:
> > >
On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote:
> On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf
> wrote:
>
> Hi Christian,
> I understand your needs, I've seen similar complaints before.
>
> Letting frameworks depend on different versions could make s
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 creat
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, t
26 matches
Mail list logo
