---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107791/#review23643
---
IMHO this is wrong.
Not code wise but conceptual. As far as I u
> On Dec. 17, 2012, 10:38 p.m., Kevin Krammer wrote:
> > IMHO this is wrong.
> > Not code wise but conceptual. As far as I understand QSettings is basically
> > deprecated, it is just not official marked as such because there is no
> > replacement. This would be porting away from a fully functi
Alexander Neundorf wrote:
> On Thursday 29 November 2012, Stephen Kelly wrote:
>> Alexander Neundorf wrote:
>> > The code for creating a Config.cmake file is not trivial, but IMO also
>> > not boilerplate, and Stephen agreed in Berlin that this will have to be
>> > done individually be every proje
Alexander Neundorf wrote:
> Please have a look at the current solidConfig.cmake.in.
> This is mostly as I think it should be (the include-guard is still
> missing).
>
> solidConfig.cmake
> # solidConfig.cmake provides information about the installed solid
> # library.
> #is supported solid_
> On Dec. 17, 2012, 10:38 p.m., Kevin Krammer wrote:
> > IMHO this is wrong.
> > Not code wise but conceptual. As far as I understand QSettings is basically
> > deprecated, it is just not official marked as such because there is no
> > replacement. This would be porting away from a fully functi
> On Dec. 17, 2012, 10:38 p.m., Kevin Krammer wrote:
> > IMHO this is wrong.
> > Not code wise but conceptual. As far as I understand QSettings is basically
> > deprecated, it is just not official marked as such because there is no
> > replacement. This would be porting away from a fully functi
> On Dec. 17, 2012, 10:38 p.m., Kevin Krammer wrote:
> > IMHO this is wrong.
> > Not code wise but conceptual. As far as I understand QSettings is basically
> > deprecated, it is just not official marked as such because there is no
> > replacement. This would be porting away from a fully functi
On Tuesday 18 December 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Thursday 29 November 2012, Stephen Kelly wrote:
> >> Alexander Neundorf wrote:
> >> > The code for creating a Config.cmake file is not trivial, but IMO also
> >> > not boilerplate, and Stephen agreed in Berlin that
On Tuesday 18 December 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > Please have a look at the current solidConfig.cmake.in.
> > This is mostly as I think it should be (the include-guard is still
> > missing).
> >
> >
> > solidConfig.cmake
> >
> > # solidConfig.cmake provides info
Alexander Neundorf wrote:
> As providers of a library we should not enforce how people use CMake, i.e.
> whether they use the automatic INSTALL_RPATH_USE_LINK_PATH or whether they
> want to decide manually.
We can
* make the common things easy (we don't need to do anything and people can
use I
Alexander Neundorf wrote:
> On Tuesday 18 December 2012, Stephen Kelly wrote:
>> Alexander Neundorf wrote:
>> > Please have a look at the current solidConfig.cmake.in.
>> > This is mostly as I think it should be (the include-guard is still
>> > missing).
>> >
>> >
>> > solidConfig.cmake
>> >
>>
On Tuesday 18 December 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Tuesday 18 December 2012, Stephen Kelly wrote:
> >> Alexander Neundorf wrote:
> >> > Please have a look at the current solidConfig.cmake.in.
> >> > This is mostly as I think it should be (the include-guard is still
Alexander Neundorf wrote:
> yes, but forgot to answer.
> No strong reason here. The options containing "HAVE" are based on whether
> that thing existed on the system where the library was built. This one is
> independent on whether udisk2 existed on that system, so I thought "USE"
> might be bette
On Tuesday 18 December 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > As providers of a library we should not enforce how people use CMake,
> > i.e. whether they use the automatic INSTALL_RPATH_USE_LINK_PATH or
> > whether they want to decide manually.
>
> We can
>
> * make the common
Alexander Neundorf wrote:
> At work, we set the RPATH manually. We know the limited number of
> libraries we link against, we want to have full control over the RPATH. I
> would be surprised if we would be the only ones.
Anyone handling RPATH manually knows about get_filename_component :).
>
> I
On Tuesday 18 December 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > yes, but forgot to answer.
> > No strong reason here. The options containing "HAVE" are based on whether
> > that thing existed on the system where the library was built. This one is
> > independent on whether udisk2
Alexander Neundorf wrote:
> On Tuesday 18 December 2012, Stephen Kelly wrote:
>> Alexander Neundorf wrote:
>> > yes, but forgot to answer.
>> > No strong reason here. The options containing "HAVE" are based on
>> > whether that thing existed on the system where the library was built.
>> > This one
17 matches
Mail list logo
