On Monday 25 March 2013, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Sunday 24 March 2013, Stephen Kelly wrote:
> >> Alexander Neundorf wrote:
> >> > kcodecs doesn't build for me because it doesn't get the QtCore include
> >> > dirs.
> >> >
> >> > It has this code:
> >> > target_link_l
On Sunday 24 March 2013, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > kcodecs doesn't build for me because it doesn't get the QtCore include
> > dirs.
> >
> > It has this code:
> > target_link_libraries(KCodecs LINK_PUBLIC ${QT_QTCORE_LIBRARY} )
> >
> > This should get it the include dirs
Alexander Neundorf wrote:
>> That superbuild directory doesn't seem to work for me. Although I run
>> cmake on it with cmake master, it seems to try to use cmake 2.8.9 from my
>> distro when building the subprojects.
>
> Hmm, for me it works as expected.
> What exactly did you do ?
The problem w
Alexander Neundorf wrote:
> kcodecs doesn't build for me because it doesn't get the QtCore include
> dirs.
>
> It has this code:
> target_link_libraries(KCodecs LINK_PUBLIC ${QT_QTCORE_LIBRARY} )
>
> This should get it the include dirs, right ?
No idea, what's in the QT_QTCORE_LIBRARY variable?
On Sunday 24 March 2013 15:06:26 Alexander Neundorf wrote:
> Can somebody please add information on how to keep Qt up-to-date here ?
>
> http://community.kde.org/Frameworks/Building
Done. Although don't be surprised if it doesn't bring anything new yet,
qt5.git dev hasn't been updated in a very
On Sunday 24 March 2013, Alexander Neundorf wrote:
> On Sunday 24 March 2013, Stephen Kelly wrote:
> > Alexander Neundorf wrote:
> > > currently this breaks the stand-alone build of the libraries in tier1/
> > > and tier2/.
> >
> > http://quickgit.kde.org/?p=kdelibs.git&a=commitdiff&h=56d571a223e0
On Sunday 24 March 2013, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > currently this breaks the stand-alone build of the libraries in tier1/
> > and tier2/.
>
> http://quickgit.kde.org/?p=kdelibs.git&a=commitdiff&h=56d571a223e00ffed4cb6
> 82eb098c5b1e347fa70
>
> > E.g. due to removing
> >
Alexander Neundorf wrote:
> currently this breaks the stand-alone build of the libraries in tier1/ and
> tier2/.
>
>
http://quickgit.kde.org/?p=kdelibs.git&a=commitdiff&h=56d571a223e00ffed4cb682eb098c5b1e347fa70
>
> E.g. due to removing
> include_directories(${kdeqt5staging_INCLUDE_DIRS})
> fro
On Saturday 16 March 2013, Stephen Kelly wrote:
> Hi there,
>
> == What happened? ==
>
> I've pushed a commit which removed much of the CMake code which calls
> include_directories().
>
> http://commits.kde.org/kdelibs/56d571a223e00ffed4cb682eb098c5b1e347fa70
>
> This mail is an explanation of
On 03/21/2013 04:47 PM, Alexander Neundorf wrote:
> At least for me it is also easier to differentiate between "use this when
> building foo" and "use this when using foo" vs. the three options.
Then don't use PUBLIC in your code.
Others have the opposite view. When something does need to be in
On 03/21/2013 02:47 PM, Alexander Neundorf wrote:
> Still, is the "PUBLIC" part necessary ?
> IMO PRIVATE and INTERFACE suffice, and for me it seems more straighforward to
> separate only between these two.
PRIVATE and INTERFACE are sufficient but need to be duplicated
to produce the equivalent o
On 03/20/2013 04:31 PM, Alexander Neundorf wrote:
>> The keywords won't interact well with PUBLIC/PRIVATE/INTERFACE keywords.
>
> Let's assume there would be only PRIVATE, INTERFACE_BUILD and
> INTERFACE_INSTALL.
> I'll use PRIVATE for building the target.
> I'll add INTERFACE_BUILD if I want to
On Thursday 21 March 2013, Brad King wrote:
> On 03/21/2013 02:47 PM, Alexander Neundorf wrote:
> > Still, is the "PUBLIC" part necessary ?
> > IMO PRIVATE and INTERFACE suffice, and for me it seems more
> > straighforward to separate only between these two.
>
> PRIVATE and INTERFACE are sufficien
On Thursday 21 March 2013, Brad King wrote:
> On 03/20/2013 04:31 PM, Alexander Neundorf wrote:
...
> > So e.g. I could do
> > tid(hello
> >
> >PRIVATE ${Foo_INCLUDE_DIRS} ${Bar_INCLUDE_DIRS}
> >${CMAKE_SOURCE_DIR}/blub INTERFACE_BUILD ${CMAKE_SOURCE_DIR}/blub
> >${Bar_INCLUDE_DIRS}
>
On Tuesday 19 March 2013, Brad King wrote:
> On 03/19/2013 04:02 PM, Alexander Neundorf wrote:
> > On Tuesday 19 March 2013, Stephen Kelly wrote:
> >> I don't mind renaming it, but it's a topic for the cmake list.
> >
> > So, I think the variable name CMAKE_BUILD_INTERFACE_INCLUDES is to
> > gener
On 03/19/2013 04:02 PM, Alexander Neundorf wrote:
> On Tuesday 19 March 2013, Stephen Kelly wrote:
>> I don't mind renaming it, but it's a topic for the cmake list.
>
> So, I think the variable name CMAKE_BUILD_INTERFACE_INCLUDES is to general.
> Since it is similar to the effect of CMAKE_INCLUDE_
On Tuesday 19 March 2013, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> >> which automatically adds
> >>
> >> "$ >>
> >> ${CMAKE_CURRENT_SOURCE_DIR}>"
> >>
> >> to the INTERFACE_INCLUDE_DIRECTORIES of each target.
> >
> > Since cmake 2.4.0. the global cmake variable CMAKE_INCLUDE_CURRENT_
Alexander Neundorf wrote:
>> which automatically adds
>>
>> "$> ${CMAKE_CURRENT_SOURCE_DIR}>"
>>
>> to the INTERFACE_INCLUDE_DIRECTORIES of each target.
>
> Since cmake 2.4.0. the global cmake variable CMAKE_INCLUDE_CURRENT_DIR
> exists. When set to TRUE, cmake automatically adds
> CMAKE_CURREN
On Saturday 16 March 2013, Stephen Kelly wrote:
> Hi there,
>
> == What happened? ==
>
> I've pushed a commit which removed much of the CMake code which calls
> include_directories().
>
> http://commits.kde.org/kdelibs/56d571a223e00ffed4cb682eb098c5b1e347fa70
>
> This mail is an explanation of
19 matches
Mail list logo
