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
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:
> 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:
> > 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:
> 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:
> > 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:
> 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
>> >
>>
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
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
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
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_
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
On Thursday 29 November 2012, Stephen Kelly wrote:
...
> The tier1 Config files (after CMake 2.8.11) should only contain this:
>
> set(kwidgetsaddons_VERSION_MAJOR "@KWIDGETSADDONS_VERSION_MAJOR@")
> set(kwidgetsaddons_VERSION_MINOR "@KWIDGETSADDONS_VERSION_MINOR@")
> set(kwidgetsaddons_VERSION
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 project. This is the added
> > threadw
Alexander Neundorf wrote:
>> There is no point in keeping cmake files looking exactly as they do now
>> if we can instead remove noisy/redundant information. That is progress.
>> If it was 2006 what would you choose?
>
> I would prefer if both ways would stay valid and continue to work as they
> d
On Tuesday 04 December 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> >> > Retraining all our users that using include_directories() is wrong
> >> > doesn't sound good to me.
> >>
> >> I think re-training is the cost of simplicity, and it's worth it.
> >>
> >> You only expect to have to
Alexander Neundorf wrote:
>> > Retraining all our users that using include_directories() is wrong
>> > doesn't sound good to me.
>>
>> I think re-training is the cost of simplicity, and it's worth it.
>>
>> You only expect to have to use include_directories() because you have
>> always had to. So
On Tuesday 04 December 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > I still think it is not a good idea that
> >
> > target_link_libraries(foo KF5::widgetsaddons)
> >
> > also sets include dirs for the target foo.
> >
> > Should I discuss that again on cmake-devel ?
>
> It would s
Alexander Neundorf wrote:
> I still think it is not a good idea that
>
> target_link_libraries(foo KF5::widgetsaddons)
>
> also sets include dirs for the target foo.
> Should I discuss that again on cmake-devel ?
It would seem more appropriate than here, but I think it's already decided.
>
>>
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 project. This is the added
> > threadw
20 matches
Mail list logo
