Re: [kopete-devel] kdenetwork - unnecessary find_package(KdepimLibs REQUIRED)

[Maciej Mrozowski-2]

On Thursday 22 of October 2009 18:44:15 Alexander Neundorf wrote:

Sorry for a lag.

> +if(INSIDE_KDENETWORK)
>
> + find_package(KdepimLibs REQUIRED)
> + include_directories(${KDEPIMLIBS_INCLUDE_DIR})
> +
> +else(INSIDE_KDENETWORK)
>
> Why is kdepimlibs only required when kopete is built as part of kdenetwork

It's not exactly like this - if you look at
http://websvn.kde.org/trunk/KDE/kdenetwork/kopete/CMakeLists.txt?revision=1041143&view=markup

there's already indication, that kopete authors used to (not sure whether it
applies anymore) distribute/build kopete as standalone application and check
for kdepimlibs in this case.

> Also, while you are working on this, could you please check which of all
>  the included CheckSomething.cmake files in kopete/CMakeLists.txt and
> krdc/CMakeLists.txt are actually used there ?

Some indeed aren't, and in krdc none are... (see revised patch attached to
this mail).

> And I don't really like this one:
> +if(INSIDE_KDENETWORK)
>
> There are at least two other options:
> +if(NOT ${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
> which will work not only in kdenetwork, but in all other places too,
>
> or, more similar to the first one:
> +if(kdenetwork_SOURCE_DIR)
> This exists only when kopete is built as part of kdenetwork, due to the
> project(kdenetwork)
> call at the top of kdenetwork/CMakeLists.txt, which defines this variable
>  (and also kdenetwork_BINARY_DIR)

I'm not the author of INSIDE_KDENETWORK concept so cannot really comment here,
though I agree with you - the less cmake variables created and the more
universal approach - the better.

Revised patch:
- moved to (${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}) way of
detecting standalone build in kopete
- removed support for standalone krdc compilation - doesn't work well as it
needs cmake modules from kdenework/cmake anyway.
- removed unused CheckXXX.cmake includes from kopete
- moved KdepimLibs check to kopete subdir
- moved kdenetwork toplevel include_directories (KDEPIMLIBS_INCLUDE_DIR) to
kopete/CMakeLists.txt and removed duplicated one from kopete/plugins/bonjour
- removed duplicated find_package(LibVNCServer) as there's
macro_optional_find_package(LibVNCServer) already just below
- minor code style cleanup (FIND_PACKAGE->find_package) in kopete

Any comments on this? (Urs?)
(please keep discussion in kde-buildsystem, thanks)

--
regards
MM

[kdenetwork-trunk.patch]

---

Index: krdc/CMakeLists.txt
===================================================================
--- krdc/CMakeLists.txt (revision 1041373)
+++ krdc/CMakeLists.txt (working copy)
@@ -1,43 +1,10 @@
-
 project(krdc)
 
-if(NOT INSIDE_KDENETWORK)
-    message("Not building inside KDENetwork, loading KDE CMake Macros.")
+set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules ${CMAKE_MODULE_PATH})
 
-    set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/../cmake/modules ${CMAKE_MODULE_PATH})
+macro_optional_find_package(TelepathyQt4)
+macro_log_feature(TELEPATHY_QT4_FOUND "telepathy-qt4" "Telepathy Qt Bindings" "https://telepathy.freedesktop.org" FALSE "0.18" "Needed to build Telepathy Tubes support.")
 
-    find_package(KDE4 REQUIRED)
-
-    include(KDE4Defaults)
-    include(MacroLibrary)
-
-    include(CheckIncludeFile)
-    include(CheckIncludeFiles)
-    include(CheckSymbolExists)
-    include(CheckFunctionExists)
-    include(CheckLibraryExists)
-    include(CheckPrototypeExists)
-    include(CheckTypeSize)
-
-    macro_optional_find_package(TelepathyQt4)
-    macro_log_feature(TELEPATHY_QT4_FOUND "telepathy-qt4" "Telepathy Qt Bindings" "https://telepathy.freedesktop.org" FALSE "0.18" "Needed to build Telepathy Tubes support.")
-
-    set(CMAKE_REQUIRED_DEFINITIONS ${_KDE4_PLATFORM_DEFINITIONS})
-    if(WIN32)
-       set(CMAKE_REQUIRED_LIBRARIES ${KDEWIN32_LIBRARIES})
-       set(CMAKE_REQUIRED_INCLUDES  ${KDEWIN32_INCLUDES})
-    endif(WIN32)
-    add_definitions(${QT_DEFINITIONS} ${QT_QTDBUS_DEFINITIONS} ${KDE4_DEFINITIONS})
-    include_directories(${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ${KDE4_INCLUDES})
-
-    macro_optional_find_package(LibVNCServer)
-    macro_log_feature(LIBVNCSERVER_FOUND "libvncserver" "VNC Server library" "http://libvncserver.sourceforge.net/" FALSE "0.9" "Needed to build Krfb and VNC support in Krdc")
-
-    # NX support is not ready for KDE 4.2; disabled (uwolfer)
-    # macro_optional_find_package(LibNXCL)
-    # macro_log_feature(LIBNXCL_FOUND "libnxcl" "NX X compression client library" "http://svn.berlios.de/svnroot/repos/freenx/trunk/freenx-client/nxcl/" FALSE "1.0" "Needed to build Krdc with NX support")
-endif(NOT INSIDE_KDENETWORK)
-
 include_directories(
     ${CMAKE_CURRENT_SOURCE_DIR}
     ${CMAKE_CURRENT_SOURCE_DIR}/core/
@@ -117,7 +84,3 @@
 
     install(FILES krdc_rfb_handler.client DESTINATION ${SHARE_INSTALL_PREFIX}/telepathy/clients/)
 endif(TELEPATHY_QT4_FOUND)
-
-if(NOT INSIDE_KDENETWORK)
-    macro_display_feature_log()
-endif(NOT INSIDE_KDENETWORK)
Index: kopete/protocols/bonjour/CMakeLists.txt
===================================================================
--- kopete/protocols/bonjour/CMakeLists.txt (revision 1041373)
+++ kopete/protocols/bonjour/CMakeLists.txt (working copy)
@@ -3,8 +3,6 @@
 add_definitions(-DQT3_SUPPORT -DQT3_SUPPORT_WARNINGS)
 add_definitions(-DKDE_DEFAULT_DEBUG_AREA=14220)
 
-include_directories(${KDEPIMLIBS_INCLUDE_DIRS})
-
 add_subdirectory( icons )
 
 ########### next target ###############
Index: kopete/CMakeLists.txt
===================================================================
--- kopete/CMakeLists.txt (revision 1041373)
+++ kopete/CMakeLists.txt (working copy)
@@ -5,7 +5,7 @@
 
 set(CMAKE_MODULE_PATH ${KOPETE_SOURCE_DIR}/cmake/modules ${CMAKE_MODULE_PATH} )
 
-if(NOT INSIDE_KDENETWORK)
+if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
 
  message ("We aren't inside KDENetwork, Loading KDE Macros")
  find_package(KDE4 REQUIRED)
@@ -13,12 +13,8 @@
  include (KDE4Defaults)
  include (MacroLibrary)
 
- include(CheckIncludeFile)
  include(CheckIncludeFiles)
- include(CheckSymbolExists)
- include(CheckFunctionExists)
  include(CheckLibraryExists)
- include(CheckPrototypeExists)
  include(CheckTypeSize)
 
  set(CMAKE_REQUIRED_DEFINITIONS ${_KDE4_PLATFORM_DEFINITIONS})
@@ -27,20 +23,19 @@
    set(CMAKE_REQUIRED_INCLUDES  ${KDEWIN_INCLUDES} )
  endif (WIN32)
 
- find_package(KdepimLibs REQUIRED)
-
  macro_optional_find_package(Sqlite)
  macro_log_feature(SQLITE_FOUND "SQLite" "SQLite is a Binary-Database" "" FALSE "" "Needed for the SQLite-Backend of the KGet-History and the Kopete-Statistic-Plugin")
 
-endif(NOT INSIDE_KDENETWORK)
+endif(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
 
 KDE4_NO_ENABLE_FINAL(kopete)
 
-FIND_PACKAGE(QImageBlitz REQUIRED)
+find_package(QImageBlitz REQUIRED)
+find_package(KdepimLibs REQUIRED)
 
 # Configure checks
 include (TestBigEndian)
-TEST_BIG_ENDIAN(CMAKE_WORDS_BIGENDIAN)
+test_big_endian(CMAKE_WORDS_BIGENDIAN)
 check_type_size("long" SIZEOF_LONG)
 check_type_size("unsigned long" SIZEOF_UNSIGNED_LONG)
 
@@ -112,8 +107,8 @@
 # Generate config-kopete.h
 configure_file(${CMAKE_CURRENT_SOURCE_DIR}/config-kopete.h.cmake ${CMAKE_CURRENT_BINARY_DIR}/config-kopete.h )
 
-# For config-kopete.h
-include_directories( ${CMAKE_CURRENT_BINARY_DIR} )
+# For config-kopete.h and KdepimLibs
+include_directories(${CMAKE_CURRENT_BINARY_DIR} ${KDEPIMLIBS_INCLUDE_DIR})
 
 set(KOPETE_INCLUDES
  ${KDE4_INCLUDES}
@@ -134,6 +129,6 @@
 add_subdirectory( sounds )
 add_subdirectory( styles )
 
-if(NOT INSIDE_KDENETWORK)
+if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
  macro_display_feature_log()
-endif(NOT INSIDE_KDENETWORK)
+endif(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
Index: CMakeLists.txt
===================================================================
--- CMakeLists.txt (revision 1041373)
+++ CMakeLists.txt (working copy)
@@ -1,7 +1,5 @@
 project(kdenetwork)
 
-set(INSIDE_KDENETWORK TRUE)
-
 set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules )
 
 # search packages used by KDE
@@ -28,9 +26,7 @@
    set(CMAKE_REQUIRED_INCLUDES  ${KDEWIN_INCLUDES} )
 endif (WIN32)
 
-find_package(KdepimLibs REQUIRED)
 # find_package(X11VidMode) not used at this time
-find_package(LibVNCServer)
 find_package(Strigi)
 
 macro_optional_find_package(LibVNCServer)
@@ -59,7 +55,7 @@
 macro_log_feature(QCA2_FOUND "QCA2" "Qt Cryptographic Architecture" "http://delta.affinix.com/qca" FALSE "2.0.0" "Needed for the KGet bittorrent-plugin and some Kopete plugins")
 
 add_definitions (${QT_DEFINITIONS} ${QT_QTDBUS_DEFINITIONS} ${KDE4_DEFINITIONS})
-include_directories (${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ${KDE4_INCLUDES} ${KDEPIMLIBS_INCLUDE_DIR})
+include_directories (${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ${KDE4_INCLUDES})
 
 macro_optional_add_subdirectory(kfile-plugins)
 macro_optional_add_subdirectory(kget)

---

_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

[Matt Rogers]

On Tuesday 27 October 2009 19:33:54 Maciej Mrozowski wrote:

> On Thursday 22 of October 2009 18:44:15 Alexander Neundorf wrote:
>
> Sorry for a lag.
>
> > +if(INSIDE_KDENETWORK)
> >
> > + find_package(KdepimLibs REQUIRED)
> > + include_directories(${KDEPIMLIBS_INCLUDE_DIR})
> > +
> > +else(INSIDE_KDENETWORK)
> >
> > Why is kdepimlibs only required when kopete is built as part of
> > kdenetwork
>
> It's not exactly like this - if you look at
> http://websvn.kde.org/trunk/KDE/kdenetwork/kopete/CMakeLists.txt?revision=1
> 041143&view=markup
>
> there's already indication, that kopete authors used to (not sure whether
>  it applies anymore) distribute/build kopete as standalone application and
>  check for kdepimlibs in this case.
>
> > Also, while you are working on this, could you please check which of all
> >  the included CheckSomething.cmake files in kopete/CMakeLists.txt and
> > krdc/CMakeLists.txt are actually used there ?
>
> Some indeed aren't, and in krdc none are... (see revised patch attached to
> this mail).
>
> > And I don't really like this one:
> > +if(INSIDE_KDENETWORK)
> >
> > There are at least two other options:
> > +if(NOT ${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
> > which will work not only in kdenetwork, but in all other places too,
> >
> > or, more similar to the first one:
> > +if(kdenetwork_SOURCE_DIR)
> > This exists only when kopete is built as part of kdenetwork, due to the
> > project(kdenetwork)
> > call at the top of kdenetwork/CMakeLists.txt, which defines this variable
> >  (and also kdenetwork_BINARY_DIR)
>
> I'm not the author of INSIDE_KDENETWORK concept so cannot really comment
>  here, though I agree with you - the less cmake variables created and the
>  more universal approach - the better.
>
> Revised patch:
> - moved to (${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}) way
>  of detecting standalone build in kopete
> - removed support for standalone krdc compilation - doesn't work well as it
> needs cmake modules from kdenework/cmake anyway.
> - removed unused CheckXXX.cmake includes from kopete
> - moved KdepimLibs check to kopete subdir
> - moved kdenetwork toplevel include_directories (KDEPIMLIBS_INCLUDE_DIR) to
> kopete/CMakeLists.txt and removed duplicated one from
>  kopete/plugins/bonjour - removed duplicated find_package(LibVNCServer) as
>  there's
> macro_optional_find_package(LibVNCServer) already just below
> - minor code style cleanup (FIND_PACKAGE->find_package) in kopete
>
> Any comments on this? (Urs?)
> (please keep discussion in kde-buildsystem, thanks)
>

I dislike the STREQUAL stuff. if (NOT INSIDE_KDENETWORK) is about a bazillion
times easier to read. I'd rather use kdenetwork_SOURCE_DIR or whatever it is
that gets generated by the "project(kdenetwork)" call. Seriously, does having
an extra variable actually add that significant of a cost?

Otherwise, I have no problems with this patch.
--
Matt (Not subscribed to kde-buildsystem, please cc me or keep kopete-devel in
the chain)


_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

[Larry Shields-2]

Maciej Mrozowski wrote:

> On Thursday 22 of October 2009 18:44:15 Alexander Neundorf wrote:
>
> Sorry for a lag.
>
>  
>> +if(INSIDE_KDENETWORK)
>>
>> + find_package(KdepimLibs REQUIRED)
>> + include_directories(${KDEPIMLIBS_INCLUDE_DIR})
>> +
>> +else(INSIDE_KDENETWORK)
>>
>> Why is kdepimlibs only required when kopete is built as part of kdenetwork
>>    
>
> It's not exactly like this - if you look at
> http://websvn.kde.org/trunk/KDE/kdenetwork/kopete/CMakeLists.txt?revision=1041143&view=markup
>
> there's already indication, that kopete authors used to (not sure whether it
> applies anymore) distribute/build kopete as standalone application and check
> for kdepimlibs in this case.
>
>  
>> Also, while you are working on this, could you please check which of all
>>  the included CheckSomething.cmake files in kopete/CMakeLists.txt and
>> krdc/CMakeLists.txt are actually used there ?
>>    
>
> Some indeed aren't, and in krdc none are... (see revised patch attached to
> this mail).
>
>  
>> And I don't really like this one:
>> +if(INSIDE_KDENETWORK)
>>
>> There are at least two other options:
>> +if(NOT ${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
>> which will work not only in kdenetwork, but in all other places too,
>>
>> or, more similar to the first one:
>> +if(kdenetwork_SOURCE_DIR)
>> This exists only when kopete is built as part of kdenetwork, due to the
>> project(kdenetwork)
>> call at the top of kdenetwork/CMakeLists.txt, which defines this variable
>>  (and also kdenetwork_BINARY_DIR)
>>    
>
> I'm not the author of INSIDE_KDENETWORK concept so cannot really comment here,
> though I agree with you - the less cmake variables created and the more
> universal approach - the better.
>
> Revised patch:
> - moved to (${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}) way of
> detecting standalone build in kopete
> - removed support for standalone krdc compilation - doesn't work well as it
> needs cmake modules from kdenework/cmake anyway.
> - removed unused CheckXXX.cmake includes from kopete
> - moved KdepimLibs check to kopete subdir
> - moved kdenetwork toplevel include_directories (KDEPIMLIBS_INCLUDE_DIR) to
> kopete/CMakeLists.txt and removed duplicated one from kopete/plugins/bonjour
> - removed duplicated find_package(LibVNCServer) as there's
> macro_optional_find_package(LibVNCServer) already just below
> - minor code style cleanup (FIND_PACKAGE->find_package) in kopete
>
> Any comments on this? (Urs?)
> (please keep discussion in kde-buildsystem, thanks)
>
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> kopete-devel mailing list
> kopete-devel@...
> https://mail.kde.org/mailman/listinfo/kopete-devel

*I have just installed Kopete-4.3.1 and it works fine, since the older
version, did not work anymore after Yahoo changed there protocal...

Check it out...

Larry
*

--
Powered by Debian/GNU/Linux
by Ubuntu ver 9.10 Karmic
73 de Larry/wd9esu 33yr's A.R.O.
Reg# Linux User 484593

"This is Linux Country,
on a quiet night you can hear
WINDOZE ! Systems REBOOTING !!"

GPG Fingerprint: A4D2 BFC2 B21B 8F7A C336 EFDC 7039 3CA5 3332 076E
Public Key available from subkeys.pgp.net

_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

[Alexander Neundorf]

On Wednesday 28 October 2009, Matt Rogers wrote:

> On Tuesday 27 October 2009 19:33:54 Maciej Mrozowski wrote:
> > On Thursday 22 of October 2009 18:44:15 Alexander Neundorf wrote:
> >
> > Sorry for a lag.
> >
> > > +if(INSIDE_KDENETWORK)
> > >
> > > + find_package(KdepimLibs REQUIRED)
> > > + include_directories(${KDEPIMLIBS_INCLUDE_DIR})
> > > +
> > > +else(INSIDE_KDENETWORK)
> > >
> > > Why is kdepimlibs only required when kopete is built as part of
> > > kdenetwork
> >
> > It's not exactly like this - if you look at
> > http://websvn.kde.org/trunk/KDE/kdenetwork/kopete/CMakeLists.txt?revision
> >=1 041143&view=markup
> >
> > there's already indication, that kopete authors used to (not sure whether
> >  it applies anymore) distribute/build kopete as standalone application
> > and check for kdepimlibs in this case.
> >
> > > Also, while you are working on this, could you please check which of
> > > all the included CheckSomething.cmake files in kopete/CMakeLists.txt
> > > and krdc/CMakeLists.txt are actually used there ?
> >
> > Some indeed aren't, and in krdc none are... (see revised patch attached
> > to this mail).
> >
> > > And I don't really like this one:
> > > +if(INSIDE_KDENETWORK)
> > >
> > > There are at least two other options:
> > > +if(NOT ${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
> > > which will work not only in kdenetwork, but in all other places too,
> > >
> > > or, more similar to the first one:
> > > +if(kdenetwork_SOURCE_DIR)
> > > This exists only when kopete is built as part of kdenetwork, due to the
> > > project(kdenetwork)
> > > call at the top of kdenetwork/CMakeLists.txt, which defines this
> > > variable (and also kdenetwork_BINARY_DIR)
> >
> > I'm not the author of INSIDE_KDENETWORK concept so cannot really comment
> >  here, though I agree with you - the less cmake variables created and the
> >  more universal approach - the better.
> >
> > Revised patch:
> > - moved to (${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}) way
> >  of detecting standalone build in kopete

See at the enmd of this mail.

> > - removed support for standalone krdc compilation - doesn't work well as
> > it needs cmake modules from kdenework/cmake anyway.

The krdc developers should comment on this.

> > - removed unused CheckXXX.cmake includes from kopete
> > - moved KdepimLibs check to kopete subdir
> > - moved kdenetwork toplevel include_directories (KDEPIMLIBS_INCLUDE_DIR)
> > to kopete/CMakeLists.txt and removed duplicated one from
> >  kopete/plugins/bonjour
> >  - removed duplicated find_package(LibVNCServer) as there's
> > macro_optional_find_package(LibVNCServer) already just below
> > - minor code style cleanup (FIND_PACKAGE->find_package) in kopete

Ok from my side.

> > Any comments on this? (Urs?)
> > (please keep discussion in kde-buildsystem, thanks)
>
> I dislike the STREQUAL stuff. if (NOT INSIDE_KDENETWORK) is about a
> bazillion times easier to read. I'd rather use kdenetwork_SOURCE_DIR or
> whatever it is that gets generated by the "project(kdenetwork)" call.
> Seriously, does having an extra variable actually add that significant of a
> cost?

No, but it would be nicer to use one of the two more generic methods, where
you don't create a new mechanism.

Alex
_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

On Wednesday 28 October 2009 18:47:38 Alexander Neundorf wrote:
> On Wednesday 28 October 2009, Matt Rogers wrote:
> > On Tuesday 27 October 2009 19:33:54 Maciej Mrozowski wrote:
> > > On Thursday 22 of October 2009 18:44:15 Alexander Neundorf wrote:
[...]
> > > - removed support for standalone krdc compilation - doesn't work well
> > > as it needs cmake modules from kdenework/cmake anyway.
>
> The krdc developers should comment on this.

It's supposed to work... Probably it got broken with one of the recent chagnes
(telepathy?). Anyway, I would like to keep this "feature" since it makes it
easier work with a IDE. It's not fundamental IMHO, but a nice feature. I will
try to fix it in a nice way ASAP (probably this weekend?). If anyone has a
better way to fix KRDC standalone build, feel free to work on it.

[...]
> > I dislike the STREQUAL stuff. if (NOT INSIDE_KDENETWORK) is about a
> > bazillion times easier to read. I'd rather use kdenetwork_SOURCE_DIR or
> > whatever it is that gets generated by the "project(kdenetwork)" call.
> > Seriously, does having an extra variable actually add that significant of
> > a cost?
>
> No, but it would be nicer to use one of the two more generic methods, where
> you don't create a new mechanism.

What's the "best practice" for such standalone-builds? What do you suggest?

Bye
urs
_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

[Maciej Mrozowski-2]

On Wednesday 28 of October 2009 21:53:00 Urs Wolfer wrote:

> On Wednesday 28 October 2009 18:47:38 Alexander Neundorf wrote:
> > On Wednesday 28 October 2009, Matt Rogers wrote:
> > > On Tuesday 27 October 2009 19:33:54 Maciej Mrozowski wrote:
> > > > On Thursday 22 of October 2009 18:44:15 Alexander Neundorf wrote:
>
> [...]
>
> > > > - removed support for standalone krdc compilation - doesn't work well
> > > > as it needs cmake modules from kdenework/cmake anyway.
> >
> > The krdc developers should comment on this.
>
> It's supposed to work... Probably it got broken with one of the recent
>  chagnes (telepathy?). Anyway, I would like to keep this "feature" since it
>  makes it easier work with a IDE. It's not fundamental IMHO, but a nice
>  feature. I will try to fix it in a nice way ASAP (probably this weekend?).
>  If anyone has a better way to fix KRDC standalone build, feel free to work
>  on it.
>
> [...]

Well, apart from it mainly lacks cmake modules (that are provided by toplevel
kdenetwork/cmake, because they are shared), so making really standalone build
would require:
- either duplicating them to project cmake subdirectory (and maybe some
recently moved to kdelibs as well if one is paranoid about kdelibs
compatibility) - the easiest, but leaves a little maintenance burden
- moving most commonly used (or maybe all of them?) to kdelibs, after they
pass some QA, and depend on particular kdelibs version at build time.

Alternative approach (rather feature request for cmake) - create mechanism to
fetch (and update) all cmake modules from some online repository, so that
there's no need to depend on particular kdelibs version just to have cmake
modules available to use.

> > > I dislike the STREQUAL stuff. if (NOT INSIDE_KDENETWORK) is about a
> > > bazillion times easier to read. I'd rather use kdenetwork_SOURCE_DIR or
> > > whatever it is that gets generated by the "project(kdenetwork)" call.
> > > Seriously, does having an extra variable actually add that significant
> > > of a cost?

If it was up to me, if any, I'd prefer STREQUAL way as it is the most generic
and will work like everywhere. It does not need module_SOURCE_DIR nor any
other external variables to be defined, thus it can serve as a good copy/paste
example to be used elsewhere.
I think the best way of getting just some subdirectory to build/develop is to
fetch whole module (like kdenetwork), then remove every subdir that is not
'cmake' and not 'krdc' for instance. It will be 'standalone' in terms it won't
build unnecessary stuff, yet it doesn't need separate cmake codepaths to get
it done (easier maintenance, no duplicated code - win-win if you ask me).

--
regards
MM


_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

[Alexander Neundorf]

On Thursday 29 October 2009, Maciej Mrozowski wrote:

> On Wednesday 28 of October 2009 21:53:00 Urs Wolfer wrote:
> > On Wednesday 28 October 2009 18:47:38 Alexander Neundorf wrote:
> > > On Wednesday 28 October 2009, Matt Rogers wrote:
> > > > On Tuesday 27 October 2009 19:33:54 Maciej Mrozowski wrote:
> > > > > On Thursday 22 of October 2009 18:44:15 Alexander Neundorf wrote:
> >
> > [...]
> >
> > > > > - removed support for standalone krdc compilation - doesn't work
> > > > > well as it needs cmake modules from kdenework/cmake anyway.
> > >
> > > The krdc developers should comment on this.
> >
> > It's supposed to work... Probably it got broken with one of the recent
> >  chagnes (telepathy?). Anyway, I would like to keep this "feature" since
> > it makes it easier work with a IDE. It's not fundamental IMHO, but a nice
> > feature. I will try to fix it in a nice way ASAP (probably this
> > weekend?). If anyone has a better way to fix KRDC standalone build, feel
> > free to work on it.
> >
> > [...]
>
> Well, apart from it mainly lacks cmake modules (that are provided by
> toplevel kdenetwork/cmake, because they are shared), so making really
> standalone build would require:
> - either duplicating them to project cmake subdirectory (and maybe some
> recently moved to kdelibs as well if one is paranoid about kdelibs
> compatibility) - the easiest, but leaves a little maintenance burden
> - moving most commonly used (or maybe all of them?) to kdelibs, after they
> pass some QA, and depend on particular kdelibs version at build time.

Which modules are that ?
Maybe they are used only by krdc ?

> Alternative approach (rather feature request for cmake) - create mechanism
> to fetch (and update) all cmake modules from some online repository, so
> that there's no need to depend on particular kdelibs version just to have
> cmake modules available to use.

Hmm, would that be different from installing them along with kdelibs ?
I mean from the compatibility POV...

We could download them from somewhere using wget or file(DOWNLOAD ...), but
this would place the compatibility burden on that remote network repository.

> > > > I dislike the STREQUAL stuff. if (NOT INSIDE_KDENETWORK) is about a
> > > > bazillion times easier to read. I'd rather use kdenetwork_SOURCE_DIR
> > > > or whatever it is that gets generated by the "project(kdenetwork)"
> > > > call. Seriously, does having an extra variable actually add that
> > > > significant of a cost?
>
> If it was up to me, if any, I'd prefer STREQUAL way as it is the most
> generic and will work like everywhere. It does not need module_SOURCE_DIR
> nor any other external variables to be defined, thus it can serve as a good
> copy/paste example to be used elsewhere.

Either STREQUAL or the <project>_SOURCE_DIR, from my POV both are ok.

> I think the best way of getting just some subdirectory to build/develop is
> to fetch whole module (like kdenetwork),

You could also check out kdenetwork non-recursively and then only update
cmake/ and krdc/

Alex
_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

[Matt Rogers]

On Thursday 29 October 2009 08:59:12 Maciej Mrozowski wrote:

> On Wednesday 28 of October 2009 21:53:00 Urs Wolfer wrote:
> > On Wednesday 28 October 2009 18:47:38 Alexander Neundorf wrote:
> > > On Wednesday 28 October 2009, Matt Rogers wrote:
> > > > On Tuesday 27 October 2009 19:33:54 Maciej Mrozowski wrote:
> > > > > On Thursday 22 of October 2009 18:44:15 Alexander Neundorf wrote:
> >
> > [...]
> >
> > > > > - removed support for standalone krdc compilation - doesn't work
> > > > > well as it needs cmake modules from kdenework/cmake anyway.
> > >
> > > The krdc developers should comment on this.
> >
> > It's supposed to work... Probably it got broken with one of the recent
> >  chagnes (telepathy?). Anyway, I would like to keep this "feature" since
> > it makes it easier work with a IDE. It's not fundamental IMHO, but a nice
> > feature. I will try to fix it in a nice way ASAP (probably this
> > weekend?). If anyone has a better way to fix KRDC standalone build, feel
> > free to work on it.
> >
> > [...]
>
> Well, apart from it mainly lacks cmake modules (that are provided by
>  toplevel kdenetwork/cmake, because they are shared), so making really
>  standalone build would require:
> - either duplicating them to project cmake subdirectory (and maybe some
> recently moved to kdelibs as well if one is paranoid about kdelibs
> compatibility) - the easiest, but leaves a little maintenance burden
> - moving most commonly used (or maybe all of them?) to kdelibs, after they
> pass some QA, and depend on particular kdelibs version at build time.
>
> Alternative approach (rather feature request for cmake) - create mechanism
>  to fetch (and update) all cmake modules from some online repository, so
>  that there's no need to depend on particular kdelibs version just to have
>  cmake modules available to use.
>
> > > > I dislike the STREQUAL stuff. if (NOT INSIDE_KDENETWORK) is about a
> > > > bazillion times easier to read. I'd rather use kdenetwork_SOURCE_DIR
> > > > or whatever it is that gets generated by the "project(kdenetwork)"
> > > > call. Seriously, does having an extra variable actually add that
> > > > significant of a cost?
>
> If it was up to me, if any, I'd prefer STREQUAL way as it is the most
>  generic and will work like everywhere. It does not need module_SOURCE_DIR
>  nor any other external variables to be defined, thus it can serve as a
>  good copy/paste example to be used elsewhere.

I don't care as long as the use case I mention below can still be supported.

> I think the best way of getting just some subdirectory to build/develop is
>  to fetch whole module (like kdenetwork), then remove every subdir that is
>  not 'cmake' and not 'krdc' for instance. It will be 'standalone' in terms
>  it won't build unnecessary stuff, yet it doesn't need separate cmake
>  codepaths to get it done (easier maintenance, no duplicated code - win-win
>  if you ask me).
>

Except that it doesn't work for the more common use case of using git-svn to
mirror a single directory, so it's not the best way for me (and others). That
was what the whole INSIDE_KDENETWORK thing was trying to address, if we can
use the STREQUAL way or some other more generic way, then whatever, as long as
I can still use it like I want.
--
Matt


_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel