On Friday 22 November 2013 10:55:09 David Faure wrote:
> On Tuesday 12 November 2013 22:56:47 Alexander Neundorf wrote:
> > 4)
> > find_package(KArchive)
> > find_package(Solid)
> > find_package(KConfig)
> > find_package(ECM)
> > include(KDECMakeSettings)
> > include(KDEInstallDirs)
> > include(KDE
On Tuesday 12 November 2013 22:56:47 Alexander Neundorf wrote:
> 4)
> find_package(KArchive)
> find_package(Solid)
> find_package(KConfig)
> find_package(ECM)
> include(KDECMakeSettings)
> include(KDEInstallDirs)
> include(KDECompilerSettings)
If all it takes to avoid a "tier0" (kf5umbrella) depen
On Sunday 10 November 2013, Kevin Ottens wrote:
> Hello,
>
> Since there's been several times discussions about having a kind of "Tier
> 0" for building our frameworks containing what is right now in ECM
> kde-modules directory, but the idea was never really on the table because
> of the extra dep
On Sunday 10 November 2013, Kevin Ottens wrote:
> Hello,
>
> Since there's been several times discussions about having a kind of "Tier
> 0" for building our frameworks containing what is right now in ECM
> kde-modules directory, but the idea was never really on the table because
> of the extra dep
On Monday 11 November 2013, Ben Cooksley wrote:
> On Mon, Nov 11, 2013 at 10:48 PM, David Faure wrote:
> > On Monday 11 November 2013 01:06:33 Michael Pyne wrote:
> > > On Sun, November 10, 2013 20:11:07 David Faure wrote:
> > > > On Sunday 10 November 2013 13:44:09 Michael Pyne wrote:
> > > > > I
On Mon, Nov 11, 2013 at 10:48 PM, David Faure wrote:
> On Monday 11 November 2013 01:06:33 Michael Pyne wrote:
> > On Sun, November 10, 2013 20:11:07 David Faure wrote:
> > > On Sunday 10 November 2013 13:44:09 Michael Pyne wrote:
> > > > I would highly recommend doing something similar to what w
On Monday 11 November 2013 01:06:33 Michael Pyne wrote:
> On Sun, November 10, 2013 20:11:07 David Faure wrote:
> > On Sunday 10 November 2013 13:44:09 Michael Pyne wrote:
> > > I would highly recommend doing something similar to what was done for
> > > strigi when it was split into 5 git modules.
On Sun, November 10, 2013 20:11:07 David Faure wrote:
> On Sunday 10 November 2013 13:44:09 Michael Pyne wrote:
> > I would highly recommend doing something similar to what was done for
> > strigi when it was split into 5 git modules.
>
> I think you misunderstood the issue?
>
> A super-repo mig
On Sunday 10 November 2013 17:57:00 Kevin Ottens wrote:
> Hello,
>
> Since there's been several times discussions about having a kind of "Tier 0"
> for building our frameworks containing what is right now in ECM kde-modules
> directory, but the idea was never really on the table because of the ext
On Sunday 10 November 2013 13:44:09 Michael Pyne wrote:
> I would highly recommend doing something similar to what was done for
> strigi when it was split into 5 git modules.
I think you misunderstood the issue?
A super-repo might help automating "building all of KF5", but it doesn't solve
the
On Sun, November 10, 2013 17:57:00 Kevin Ottens wrote:
> Now back to the submodules sha-1 update... The only thing I see to easily
> overcome that for our developers, is to have a hook, which would update the
> submodules for all the frameworks every time someone pushes in the tier 0
> repository.
On Sunday 10 November 2013 19:42:46 Alexander Neundorf wrote:
> this would mean that the 3 KDE* files from ecm plus the KF5 umbrella
> Config.cmake file would be used within KF5 as a git submodule.
> Users of KF5 can get access to it via using the installed KF5 umbrella
> package, or not if they
On Sunday 10 November 2013 18:23:33 Sune Vuorela wrote:
> DCMAKE_BUILD_TYPE=Debug is building with -O2
Oh wow, I always thought this was cmake's doing, but you're right, it's not.
This is an historical bit from the automake/unsermake times.
We had debug (-O2 -g) and debugfull (no optimization, a
On Sunday 10 November 2013, Sune Vuorela wrote:
> On 2013-11-10, Kevin Ottens wrote:
> > --===3596639883239406900==
> > Content-Type: multipart/signed; boundary="nextPart1424144.VkBYIHTjbs";
> > micalg="pgp-sha1"; protocol="application/pgp-signature"
> >
> >
> > --nextPart1424144.VkB
On Sunday 10 November 2013, David Faure wrote:
> On Sunday 10 November 2013 17:57:00 Kevin Ottens wrote:
> > Now back to the submodules sha-1 update... The only thing I see to easily
> > overcome that for our developers, is to have a hook, which would update
> > the submodules for all the framework
On 2013-11-10, Kevin Ottens wrote:
>
> --===3596639883239406900==
> Content-Type: multipart/signed; boundary="nextPart1424144.VkBYIHTjbs";
> micalg="pgp-sha1"; protocol="application/pgp-signature"
>
>
> --nextPart1424144.VkBYIHTjbs
> Content-Transfer-Encoding: quoted-printable
> Conte
On Sunday 10 November 2013 17:57:00 Kevin Ottens wrote:
> Now back to the submodules sha-1 update... The only thing I see to easily
> overcome that for our developers, is to have a hook, which would update the
> submodules for all the frameworks every time someone pushes in the tier 0
> repositor
On Sunday 10 November 2013 17:12:02 Sune Vuorela wrote:
> Why move it out of e-c-m ?
To make e-c-m a neutral ground again, not something purely for KDE needs. I
can understand that positioning.
> And if a distribution need to patch whatever is in the 'submodule', they
> have a enormous useless p
On 2013-11-10, Kevin Ottens wrote:
> Since there's been several times discussions about having a kind of "Ti=
> er 0"=20
> for building our frameworks containing what is right now in ECM kde-mod=
> ules=20
> directory, but the idea was never really on the table because of the ex=
> tra=20
> depend
Hello,
Since there's been several times discussions about having a kind of "Tier 0"
for building our frameworks containing what is right now in ECM kde-modules
directory, but the idea was never really on the table because of the extra
dependency it'd bring, I looked a bit at the git submodule o
20 matches
Mail list logo
