On 2012-06-20, Sune Vuorela wrote:
> On 2012-02-18, Alexander Neundorf wrote:
GMane had here put in a couple of delays in the transmissions.
/Sune
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listi
On 2012-02-18, Alexander Neundorf wrote:
> set_target_properties(Foo PROPERTIES VERSION ${VERSION_NUMBER}
> SOVERSION ${SOVERSION_NUMBER} )
>
> These two version numbers should always have sensible values.
> I didn't test, but I'm not sure a libfoo.so.3dea0a0c6
On Wednesday 11 April 2012 20:44:32 Alexander Neundorf wrote:
> So, what I currently have in mind of how "KDE frameworks libraries" will
> install and how they will be usable:
>
> * each KDE frameworks library will install a KFooConfig.cmake file
> * by using find_package(KFoo CONFIG_MODE) this Con
On Wednesday 11 April 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Saturday 10 March 2012, Alexander Neundorf wrote:
> > ...
> >
> >> Also, this means the term "KDE frameworks" doesn't actually mean a lot.
> >> I mean, what would make a library a "KDE frameworks library" ?
> >> Be
Alexander Neundorf wrote:
> On Saturday 10 March 2012, Alexander Neundorf wrote:
> ...
>> Also, this means the term "KDE frameworks" doesn't actually mean a lot.
>> I mean, what would make a library a "KDE frameworks library" ?
>> Being part of the KDE SC releases ?
>>
>> But I'm really not sure
On Saturday 10 March 2012, Alexander Neundorf wrote:
...
> Also, this means the term "KDE frameworks" doesn't actually mean a lot.
> I mean, what would make a library a "KDE frameworks library" ?
> Being part of the KDE SC releases ?
>
> But I'm really not sure this will result in a pleasant exper
On Saturday 10 March 2012 12:18:06 Alexander Neundorf wrote:
> To summarize: do you say it is ok to let every KDE frameworks git
> repository decide for its own which versions of Qt and CMake it requires ?
No, not if there is no good reason for it.
I'm being pragmatic. konversation wants to keep
On Sun, Mar 11, 2012 at 12:18 AM, Alexander Neundorf wrote:
> On Saturday 10 March 2012, David Faure wrote:
>> On Monday 27 February 2012 17:48:44 Alexander Neundorf wrote:
>> > A common setup will be that "core" developers are building all frameworks
>> > libraries.
>> > Let's say some tier1 libr
On Saturday 10 March 2012, David Faure wrote:
> On Monday 27 February 2012 17:48:44 Alexander Neundorf wrote:
> > A common setup will be that "core" developers are building all frameworks
> > libraries.
> > Let's say some tier1 library, e.g. kcore needs Qt 5.1.2 and cmake 2.8.9.
> > Another tier1 l
On Monday 27 February 2012 17:48:44 Alexander Neundorf wrote:
> A common setup will be that "core" developers are building all frameworks
> libraries.
> Let's say some tier1 library, e.g. kcore needs Qt 5.1.2 and cmake 2.8.9.
> Another tier1 library, let's say solid, maybe says it needs Qt 5.1.0 a
On Friday 24 February 2012, Sune Vuorela wrote:
> On 2012-02-24, Alexander Neundorf wrote:
> > * the version numbers of the projects themselves
> > * the required Qt version
>
> This might differ across frameworks. I see no reason to artificial bump
> required version.
If this is handled properl
On 2012-02-24, Alexander Neundorf wrote:
> * the version numbers of the projects themselves
> * the required Qt version
This might differ across frameworks. I see no reason to artificial bump
required version.
> * the required CMake version
similar.
> * the required extra-cmake-modules version
On Friday 24 February 2012, Kevin Ottens wrote:
> On Thursday 23 February 2012 21:23:00 Alexander Neundorf wrote:
> > On Thursday 23 February 2012, Kevin Ottens wrote:
...
> Which I never advocated to remove... Now ideally this should be contained
> in a small single file, so that *later on* we can
On Friday 24 February 2012, Sune Vuorela wrote:
> On 2012-02-23, Alexander Neundorf wrote:
> >> I'd be fine with a "find_package(KF5BuildSpecs 5.3.0)", assuming the
> >> version number would be mandatory, as now there'd be no risk of a
> >> kwhatever 5.3.0 claiming to be a kwhatever 5.10.0.
> >
>
On 2012-02-23, Alexander Neundorf wrote:
>> I'd be fine with a "find_package(KF5BuildSpecs 5.3.0)", assuming the
>> version number would be mandatory, as now there'd be no risk of a
>> kwhatever 5.3.0 claiming to be a kwhatever 5.10.0.
>
> This can be done.
> Then this line has to be kept in sync
On Thursday 23 February 2012 21:23:00 Alexander Neundorf wrote:
> On Thursday 23 February 2012, Kevin Ottens wrote:
> > On Wednesday 22 February 2012 21:52:24 Alexander Neundorf wrote:
> ...
> > And having that in a common dependency creates the problems already
> > highlighted ("version lies").
>
On Thursday 23 February 2012, Kevin Ottens wrote:
> On Wednesday 22 February 2012 21:52:24 Alexander Neundorf wrote:
...
> > I interpret both so that they both say they want to rely on the fact that
> > a git pull from different libraries of KDE frameworks at the same time
> > will give a working c
On Wednesday 22 February 2012 21:52:24 Alexander Neundorf wrote:
> On Wednesday 22 February 2012, Kevin Ottens wrote:
> > On Sunday 19 February 2012 20:10:05 Stephen Kelly wrote:
> > > Alexander Neundorf wrote:
> > > > Can KDE frameworks libraries of different versions be mixed together ?
> > >
> >
On Wednesday 22 February 2012, Kevin Ottens wrote:
> Hello,
>
> On Sunday 19 February 2012 20:10:05 Stephen Kelly wrote:
> > Alexander Neundorf wrote:
> > > Can KDE frameworks libraries of different versions be mixed together ?
> >
> > I would say that's unsupported (by us). The ones that work to
Hello,
On Sunday 19 February 2012 20:10:05 Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > Can KDE frameworks libraries of different versions be mixed together ?
>
> I would say that's unsupported (by us). The ones that work together are
> released together.
>
> We're not going to test all po
On Sunday 19 February 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
...
> > KF5 package, as small as it may be. A library containing only a function
> > which returns the version, or something like this.
> > Depending on this small (header only ?)
>
> It would have to be compiled in proba
Alexander Neundorf wrote:
> On Saturday 18 February 2012, Kevin Ottens wrote:
>> On Saturday 18 February 2012 18:13:00 Alexander Neundorf wrote:
>> > On Saturday 18 February 2012, Kevin Ottens wrote:
>> > > So the other possibility would be to have the version number in the
>> > > main CMakeLists.
On Saturday 18 February 2012, Kevin Ottens wrote:
> On Saturday 18 February 2012 18:13:00 Alexander Neundorf wrote:
> > On Saturday 18 February 2012, Kevin Ottens wrote:
> > > So the other possibility would be to have the version number in the
> > > main CMakeLists.txt of each framework
> >
> > Th
On Saturday 18 February 2012 18:13:00 Alexander Neundorf wrote:
> On Saturday 18 February 2012, Kevin Ottens wrote:
> > So the other possibility would be to have the version number in the main
> > CMakeLists.txt of each framework
>
> This is the clean and obvious way to do it.
> Each library define
On Saturday 18 February 2012, Kevin Ottens wrote:
> On Saturday 18 February 2012 17:50:28 Alexander Neundorf wrote:
> > On Saturday 18 February 2012, Kevin Ottens wrote:
> > > On Friday 17 February 2012 20:37:12 Sune Vuorela wrote:
> > > > On 2012-02-17, Alexander Neundorf wrote:
> > > > > Do we s
On Saturday 18 February 2012 17:50:28 Alexander Neundorf wrote:
> On Saturday 18 February 2012, Kevin Ottens wrote:
> > On Friday 17 February 2012 20:37:12 Sune Vuorela wrote:
> > > On 2012-02-17, Alexander Neundorf wrote:
> > > > Do we still want a such a common version number ?
> > > > If yes, w
On Saturday 18 February 2012, Kevin Ottens wrote:
> On Friday 17 February 2012 20:37:12 Sune Vuorela wrote:
> > On 2012-02-17, Alexander Neundorf wrote:
> > > Do we still want a such a common version number ?
> > > If yes, who (which file/package) should define it ?
> >
> > No. It basically doesn
On Friday 17 February 2012 20:37:12 Sune Vuorela wrote:
> On 2012-02-17, Alexander Neundorf wrote:
> > Do we still want a such a common version number ?
> > If yes, who (which file/package) should define it ?
>
> No. It basically doesn't make sense. Also not in its current usage.
>
> if I e.g. tak
On Friday 17 February 2012, Friedrich W. H. Kossebau wrote:
> Am Freitag, 17. Februar 2012, 19:48:33 schrieb Alexander Neundorf:
> > Hi,
> >
> > right now the common version number for libraries in kdelibs/KDE is
> > defined in KDE4Defaults.cmake:
> >
> > # define the generic version of the libra
On 2012-02-17, Alexander Neundorf wrote:
> Do we still want a such a common version number ?
> If yes, who (which file/package) should define it ?
No. It basically doesn't make sense. Also not in its current usage.
if I e.g. take a kdepimlibs 4.3 and build against kdelibs 4.8, all my
pimlibs lib
Am Freitag, 17. Februar 2012, 19:48:33 schrieb Alexander Neundorf:
> Hi,
>
> right now the common version number for libraries in kdelibs/KDE is defined
> in KDE4Defaults.cmake:
>
> # define the generic version of the libraries here
> # this makes it easy to advance it when the next KDE release c
Hi,
right now the common version number for libraries in kdelibs/KDE is defined in
KDE4Defaults.cmake:
# define the generic version of the libraries here
# this makes it easy to advance it when the next KDE release comes
# Use this version number for libraries which are at version n in KDE
# ver
32 matches
Mail list logo
