Re: FreeBSD build problem

2008-07-07 Thread David Johnson 
On Sunday 06 July 2008 07:45:46 pm Thiago Macieira wrote:
 David Johnson wrote:
 target_link_libraries(kfind  ${KDE4_KDE3SUPPORT_LIBS} )
 
 This results in the the following library
 locations: -L/usr/local/lib/qt4 -L/usr/local/lib -L/usr/local/kde4/lib
 
 However, changing that line to add a dependency:
 
 target_link_libraries(kfind ${KDE4_KDEUI_LIBS}  ${KDE4_KDE3SUPPORT_LIBS}
  )

 Those libraries link directly to kdeui anyways, so the change is harmless.
 It can easily be done.

But can anyone tell me how those library lists get generated? It seems very 
arbitrary and random. I would be much more comfortable writing these patches 
if I knew what was happening under the surface.

-- 
David Johnson
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: FreeBSD build problem

2008-07-07 Thread Thiago Macieira 
David Johnson wrote:
On Sunday 06 July 2008 07:45:46 pm Thiago Macieira wrote:
 David Johnson wrote:
 target_link_libraries(kfind  ${KDE4_KDE3SUPPORT_LIBS} )
 
 This results in the the following library
 locations: -L/usr/local/lib/qt4 -L/usr/local/lib
  -L/usr/local/kde4/lib
 
 However, changing that line to add a dependency:
 
 target_link_libraries(kfind ${KDE4_KDEUI_LIBS}
   ${KDE4_KDE3SUPPORT_LIBS} )

 Those libraries link directly to kdeui anyways, so the change is
 harmless. It can easily be done.

But can anyone tell me how those library lists get generated? It seems
 very arbitrary and random. I would be much more comfortable writing
 these patches if I knew what was happening under the surface.

It wasn't generated. It was written by hand like above.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: FreeBSD build problem

2008-07-07 Thread David Faure 
On Monday 07 July 2008, Thiago Macieira wrote:
 David Johnson wrote:
 On Sunday 06 July 2008 07:45:46 pm Thiago Macieira wrote:
  David Johnson wrote:
  target_link_libraries(kfind  ${KDE4_KDE3SUPPORT_LIBS} )
  
  This results in the the following library
  locations: -L/usr/local/lib/qt4 -L/usr/local/lib
   -L/usr/local/kde4/lib
  
  However, changing that line to add a dependency:
  
  target_link_libraries(kfind ${KDE4_KDEUI_LIBS}
    ${KDE4_KDE3SUPPORT_LIBS} )
 
  Those libraries link directly to kdeui anyways, so the change is
  harmless. It can easily be done.
 
 But can anyone tell me how those library lists get generated? It seems
  very arbitrary and random. I would be much more comfortable writing
  these patches if I knew what was happening under the surface.
 
 It wasn't generated. It was written by hand like above.

Thiago, I think you're not understanding David Johnson's question :)
The -L parameters are definitely generated, by cmake.
The question is how. And the answer is complex AFAIK, and depends on the cmake 
version.

-- 
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: FreeBSD build problem

2008-07-07 Thread Brad King 
David Faure wrote:
 The -L parameters are definitely generated, by cmake.
 The question is how. And the answer is complex AFAIK, and depends on the 
 cmake version.

In CMake 2.4 the set of -L paths come from arguments to the
link_directories() command and the locations of libraries given to
target_link_libraries() by full path.  In CMake 2.6 the latter case is
usually handled just by passing the full path to the library file
directly to the linker with no searching, but there are still some cases
where it behaves similarly to 2.4.

The input to the ordering algorithm is the original list of
user-specified library search paths (given to link_directories) plus
some set of library file full paths.  The output is an ordered linker
search path.  We try to preserve the original order of user-specified
directories, but the main rule is that the order is such that the
libraries whose full paths are known will be found first if the linker
searches for them with a -lfoo option.  This guarantees that when a
library is specified by full path that the copy of the library is
favored over any other copy of the library at another place in the
linker search path.

CMake actually inspects all the linker search path locations to look for
possibly conflicting files and builds a constraint graph.  A topological
sort on the resulting constraint graph produces the order.  The order
among an unconstrained group of paths is that in the original
user-specified order.  This is done much more formally in CMake 2.6 than
in 2.4.

-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: FreeBSD build problem

2008-07-07 Thread David Johnson 
On Monday 07 July 2008 05:21:48 am Thiago Macieira wrote:
 But can anyone tell me how those library lists get generated? It seems
  very arbitrary and random. I would be much more comfortable writing
  these patches if I knew what was happening under the surface.

 It wasn't generated. It was written by hand like above.

I must learn to write English better. What I meant was, how does *cmake* 
generate the list of libraries sent to the linker, and what determines their 
order? I've looked at FindKDE4Internal.cmake, but I don't fully understand 
it.

-- 
David Johnson
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: FreeBSD build problem

2008-07-07 Thread David Johnson 
On Monday 07 July 2008 08:00:10 am David Faure wrote:
 Thiago, I think you're not understanding David Johnson's question :)
 The -L parameters are definitely generated, by cmake.
 The question is how. And the answer is complex AFAIK, and depends on the
 cmake version.

Thanks. And thanks to Brad King for his detailed explanation. The upshot is 
that I can't guarantee the order of search paths, as they may change through 
a variety of causes.

I guess I'll have to bite the bullet and give KDE3 its own hierarchy. As 
painful as that is, it will upset far fewer users than telling them they 
can't have KDE3 and KDE4 on the same system.

-- 
David Johnson
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: FreeBSD build problem

2008-07-07 Thread Alexander Neundorf 
On Monday 07 July 2008, Brad King wrote:
 David Faure wrote:
  The -L parameters are definitely generated, by cmake.
  The question is how. And the answer is complex AFAIK, and depends on the
  cmake version.

 In CMake 2.4 the set of -L paths come from arguments to the
 link_directories() command and the locations of libraries given to
 target_link_libraries() by full path.  In CMake 2.6 the latter case is
 usually handled just by passing the full path to the library file
 directly to the linker with no searching, but there are still some cases
 where it behaves similarly to 2.4.

 The input to the ordering algorithm is the original list of
 user-specified library search paths (given to link_directories) plus
 some set of library file full paths.  The output is an ordered linker
 search path.  We try to preserve the original order of user-specified
 directories, but the main rule is that the order is such that the
 libraries whose full paths are known will be found first if the linker
 searches for them with a -lfoo option.  This guarantees that when a
 library is specified by full path that the copy of the library is
 favored over any other copy of the library at another place in the
 linker search path.

 CMake actually inspects all the linker search path locations to look for
 possibly conflicting files and builds a constraint graph.  A topological
 sort on the resulting constraint graph produces the order.  The order
 among an unconstrained group of paths is that in the original

Yes.
If you use this:

target_link_libraries(kfind  ${KDE4_KDE3SUPPORT_LIBS} )

the kde3support library and all libs it depends on will be linked to kfind.
The kde3support library itself is found using a FIND_LIBRARY() call and so 
will be given to cmake with the full path, 
e.g. /opt/kde4/lib/libkde3support.so.
Additionally all the libs from kde3support_LIB_DEPENDS will also be linked, 
which looks (on my system) like this:
 
SET(kde3support_LIB_DEPENDS 
/opt/qt-copy/lib/libQtCore.so;-lpthread;kdecore;kdeui;kio;kparts;/opt/qt-copy/lib/libQtCore.so;
-lpthread;kdecore;kpty;/opt/qt-copy/lib/libQtXml.so;/opt/qt-copy/lib/libQt3Support.so;/opt/qt-copy/lib/libQtCore.so;-lpthread;kdecore;
kdeui;kio;kfile;)

Here kdecore, kdeui etc. are given without full path. This is because when 
building kdelibs they are only the target names, not file names of the 
not-yet-installed libraries.
So when cmake checks the order of the library dirs, it probably doesn't see a 
problem: libkde3support.so is unique (only in the KDE4 lib dir), kdeui, 
kdecore etc. exist in both dirs, but nobody told cmake that we would like to 
have the one in the KDE4 dir, so it doesn't complain.

Now if you add ${KDE4_KDEUI_LIBS}, kdeui will be added with the full path (as 
above with kde3support), so now cmake will detect the problem (libkdeui.so 
both in the KDE3 and KDE4 lib dirs) and order them so that you get 
libkdeui.so from the KDE4 lib dir.

Short version: this is an ugly situation

I think we can fix this for KDE 4.2 with cmake 2.6.
What do we do in the meantime ?
We could add ${KDE4_KDECORE_LIBRARY} (which comes with the full path and 
features the same name as the one from KDE3) as a direct dependency for all 
libs from kdelibs (in FindKDE4Internal.cmake), so this conflict would be 
always detected.
Does that make sense ?

Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Qt4 shouldn't require X11, even on Unix

2008-07-07 Thread Alexander Neundorf 
On Monday 07 July 2008, Thiago Macieira wrote:
 This section of FindQt4.cmake seems bogus to me:

   IF(UNIX)
 # on OS X X11 may not be required
 IF (Q_WS_X11)
   FIND_PACKAGE(X11 REQUIRED)
 ENDIF (Q_WS_X11)

 It's not necessary to have X11 headers in order to compile Qt4
 applications or KDE 4 ones. There are no X11 headers included in any
 public Qt4 application.

I just checked, a check for X11 is part of FindQt4.cmake since rev 1.1 in 
cmake cvs, almost exactly 3 years old.
Do you think it's worth changing this ?
(adds a difference to the version from cmake and might break some builds which 
accidentially use the X11 vars defined by this FIND_PACKAGE(X11) )

Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Qt4 shouldn't require X11, even on Unix

2008-07-07 Thread Thiago Macieira 
Alexander Neundorf wrote:
I just checked, a check for X11 is part of FindQt4.cmake since rev 1.1
 in cmake cvs, almost exactly 3 years old.
Do you think it's worth changing this ?
(adds a difference to the version from cmake and might break some builds
 which accidentially use the X11 vars defined by this FIND_PACKAGE(X11)
 )

This would be akin to a source-incompatible change in CMake, I understand. 
But this isn't beyond the gcc developers, though: with gcc 4.3, they've 
made their headers a lot more strict, meaning you cannot assume that 
#including a file will bring another along. (For example, #include 
string will not #include string.h anymore, so no memcpy will be 
defined)

But that requirement there makes using Qt require the X11 headers, which 
isn't always so. You're fully allowed to do development with Qt without 
X11 headers installed (provided you're not using static builds). You 
can't build Qt without them -- but once you have, you can remove them.

Of course, this means you can't pass -lX11 on the linking command-line 
when linking to QtGui... and qmake itself isn't generating the proper 
Makefiles yet.

This again goes back to what I've been saying: all applications must 
declare all of its direct dependencies. It uses X11? FIND_PACKAGE + 
TARGET_LINK_LIBRARIES and whatever else.

I posted this here because someone on IRC was having issues: after 
removing the Qt4 dependency, his X11 code no longer compiled (Xss macros 
not defined). He should've had the Find_Package, but he didn't.
-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

KDE/kdelibs/cmake

2008-07-07 Thread Alexander Neundorf 
SVN commit 829250 by neundorf:

-make automoc4 required finally (... 4.1 is not too far away)

Alex

CCMAIL: kde-buildsystem@kde.org
CCMAIL: [EMAIL PROTECTED]



 M  +4 -4  CMakeLists.txt  
 M  +10 -37modules/FindKDE4Internal.cmake  
 M  +4 -81 modules/KDE4Macros.cmake  


--- trunk/KDE/kdelibs/cmake/CMakeLists.txt #829249:829250
@@ -1,8 +1,8 @@
 
-if(NOT AUTOMOC4_EXECUTABLE)
-   # this is just a fallback in case automoc4 from kdesupport isn't found, Alex
-   add_subdirectory(automoc)
-endif(NOT AUTOMOC4_EXECUTABLE)
+#if(NOT AUTOMOC4_EXECUTABLE)
+#   # this is just a fallback in case automoc4 from kdesupport isn't found, 
Alex
+#   add_subdirectory(automoc)
+#endif(NOT AUTOMOC4_EXECUTABLE)
 
 add_subdirectory(modules)
 
--- trunk/KDE/kdelibs/cmake/modules/FindKDE4Internal.cmake #829249:829250
@@ -16,7 +16,7 @@
 # compile KDE software:
 #
 #  KDE4_KCFGC_EXECUTABLE- the kconfig_compiler executable
-#  KDE4_AUTOMOC_EXECUTABLE  - the kde4automoc executable
+#  KDE4_AUTOMOC_EXECUTABLE  - the kde4automoc executable, deprecated, use 
AUTOMOC4_EXECUTABLE instead
 #  KDE4_MEINPROC_EXECUTABLE - the meinproc4 executable
 #  KDE4_MAKEKDEWIDGETS_EXECUTABLE - the makekdewidgets executable
 #
@@ -238,9 +238,10 @@
 #this line includes FindQt4.cmake, which searches the Qt library and headers
 find_package(Qt4 REQUIRED)
 
-# automoc4 (from kdesupport) is not yet required, but will be in June
-# until then still automoc from kdelibs is used as fallback, Alex
-find_package(Automoc4)
+# automoc4 (from kdesupport) is now required, Alex
+find_package(Automoc4 REQUIRED)
+# use automoc4 from kdesupport
+set(KDE4_AUTOMOC_EXECUTABLE${AUTOMOC4_EXECUTABLE} )
 
 # Perl is required for building KDE software,
 find_package(Perl REQUIRED)
@@ -287,26 +288,12 @@
   # CMAKE_CFG_INTDIR is the output subdirectory created e.g. by XCode and 
MSVC
   set(KDE4_KCFGC_EXECUTABLE  
${EXECUTABLE_OUTPUT_PATH}/${CMAKE_CFG_INTDIR}/kconfig_compiler )
 
-  # use automoc4 from kdesupport if it has been found
-  if(AUTOMOC4_EXECUTABLE)
- set(KDE4_AUTOMOC_EXECUTABLE${AUTOMOC4_EXECUTABLE} )
-  else(AUTOMOC4_EXECUTABLE)
- set(KDE4_AUTOMOC_EXECUTABLE
${EXECUTABLE_OUTPUT_PATH}/${CMAKE_CFG_INTDIR}/kde4automoc )
-  endif(AUTOMOC4_EXECUTABLE)
-
   set(KDE4_MEINPROC_EXECUTABLE   
${EXECUTABLE_OUTPUT_PATH}/${CMAKE_CFG_INTDIR}/meinproc4 )
   set(KDE4_MAKEKDEWIDGETS_EXECUTABLE 
${EXECUTABLE_OUTPUT_PATH}/${CMAKE_CFG_INTDIR}/makekdewidgets )
else (WIN32)
   set(LIBRARY_OUTPUT_PATH${CMAKE_BINARY_DIR}/lib )
   set(KDE4_KCFGC_EXECUTABLE  
${EXECUTABLE_OUTPUT_PATH}/${CMAKE_CFG_INTDIR}/kconfig_compiler.shell )
 
-  # use automoc4 from kdesupport if it has been found
-  if(AUTOMOC4_EXECUTABLE)
- set(KDE4_AUTOMOC_EXECUTABLE${AUTOMOC4_EXECUTABLE} )
-  else(AUTOMOC4_EXECUTABLE)
- set(KDE4_AUTOMOC_EXECUTABLE
${EXECUTABLE_OUTPUT_PATH}/${CMAKE_CFG_INTDIR}/kde4automoc.shell )
-  endif(AUTOMOC4_EXECUTABLE)
-
   set(KDE4_MEINPROC_EXECUTABLE   
${EXECUTABLE_OUTPUT_PATH}/${CMAKE_CFG_INTDIR}/meinproc4.shell )
   set(KDE4_MAKEKDEWIDGETS_EXECUTABLE 
${EXECUTABLE_OUTPUT_PATH}/${CMAKE_CFG_INTDIR}/makekdewidgets.shell )
endif (WIN32)
@@ -318,19 +305,12 @@
set( _KDE4_MAKEKDEWIDGETS_DEP makekdewidgets)
set( _KDE4_MEINPROC_EXECUTABLE_DEP meinproc4)
 
-   if(AUTOMOC4_EXECUTABLE)
-  set( _KDE4_AUTOMOC_EXECUTABLE_DEP)
-   else(AUTOMOC4_EXECUTABLE)
-  set( _KDE4_AUTOMOC_EXECUTABLE_DEP kde4automoc)
-   endif(AUTOMOC4_EXECUTABLE)
-
set(KDE4_INSTALLED_VERSION_OK TRUE)
 
 else (_kdeBootStrapping)
 
   # ... but NOT otherwise
set( _KDE4_KCONFIG_COMPILER_DEP)
-   set( _KDE4_AUTOMOC_EXECUTABLE_DEP)
set( _KDE4_MAKEKDEWIDGETS_DEP)
set( _KDE4_MEINPROC_EXECUTABLE_DEP)
 
@@ -455,13 +435,6 @@
find_program(KDE4_KCFGC_EXECUTABLE NAME kconfig_compiler PATHS 
${KDE4_BIN_INSTALL_DIR} NO_DEFAULT_PATH )
find_program(KDE4_KCFGC_EXECUTABLE NAME kconfig_compiler )
 
-   if (AUTOMOC4_EXECUTABLE)
-  set(KDE4_AUTOMOC_EXECUTABLE ${AUTOMOC4_EXECUTABLE})
-   else (AUTOMOC4_EXECUTABLE)
-  find_program(KDE4_AUTOMOC_EXECUTABLE NAME kde4automoc PATHS 
${KDE4_BIN_INSTALL_DIR} NO_DEFAULT_PATH )
-  find_program(KDE4_AUTOMOC_EXECUTABLE NAME kde4automoc )
-   endif (AUTOMOC4_EXECUTABLE)
-
find_program(KDE4_MEINPROC_EXECUTABLE NAME meinproc4 PATHS 
${KDE4_BIN_INSTALL_DIR} NO_DEFAULT_PATH )
find_program(KDE4_MEINPROC_EXECUTABLE NAME meinproc4 )
 
@@ -1091,11 +1064,11 @@
   message(STATUS Didn't find the KDE4 kconfig_compiler preprocessor)
endif(KDE4_KCFGC_EXECUTABLE)
 
-   if(KDE4_AUTOMOC_EXECUTABLE)
-  message(STATUS Found KDE4 automoc: ${KDE4_AUTOMOC_EXECUTABLE})
-   else(KDE4_AUTOMOC_EXECUTABLE)
-  message(STATUS Didn't find the KDE4 automoc)
-   endif(KDE4_AUTOMOC_EXECUTABLE)
+   if(AUTOMOC4_EXECUTABLE)
+  message(STATUS Found automoc4: ${AUTOMOC4_EXECUTABLE})
+