Created attachment 73480 [details] [review] cross compile fixes
Comment on attachment 73480 [details] [review] cross compile fixes Review of attachment 73480 [details] [review]: ----------------------------------------------------------------- When attaching patches please tick the "is a patch" box so the "Splinter Review" link shows up. I'd have preferred this as several changes with suitable commit messages - in particular, the change in defaults from meinproc to xmlto can be merged already. ::: cmake/CMakeLists.txt @@ +433,4 @@ > set (DBUS_USER ) > > > +if (WIN32 OR CMAKE_CROSSCOMPILING) This assumes that all cross-compiled builds of D-Bus will be run on Windows, which seems wrong - it's equally valid to cross-build a copy of D-Bus on Linux/x86 that will run on Linux/ARM, for instance. I think you need to define what WIN32 means. Does it mean that the machine where you're building D-Bus runs Windows, or that the machine where you intend to run D-Bus runs Windows? Ideally, there'd be a variable that means "the machine where I'll run D-Bus runs Windows" - perhaps WIN32 can be that variable, or perhaps you need a new one? - and you could use that, and make sure that when cross-compiling, it's set appropriately. In Autotools terminology, the machine where you're building D-Bus is the "build architecture" and the machine where you intend to run it is the "host architecture". We set DBUS_WIN, DBUS_WINCE, DBUS_CYGWIN and DBUS_UNIX according to the *host* architecture only. I think you're going to need to supplement DBUS_WIN, etc. (facts about the host) with something like DBUS_BUILD_WIN/DBUS_BUILD_UNIX (facts about the build machine). ::: cmake/cross-compile.sh @@ +12,5 @@ > if test -f /usr/bin/i686-pc-mingw32-gcc; then > cross_cc=i686-pc-mingw32 > elif test -f /usr/bin/i586-mingw32msvc-gcc; then > cross_cc=i586-mingw32msvc > +elif test -f /usr/bin/i686-w64-mingw32-gcc-4.7.2; then Ugh. Don't you have an i686-w64-mingw32-gcc without a suffix? I don't want to add a special case for every minor release of gcc... @@ -98,5 @@ > - -DCMAKE_C_COMPILER="/usr/bin/$cross_cc-gcc" \ > - -DCMAKE_CXX_COMPILER="/usr/bin/$cross_cc-g++" \ > - -DCMAKE_FIND_ROOT_PATH="$cross_root" \ > - -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY \ > - -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY \ Why is this FIND_ROOT_PATH stuff no longer necessary? @@ +108,5 @@ > -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY \ > -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY \ > $xml_library \ > -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER \ > + -DDBUS_SESSION_BUS_DEFAULT_ADDRESS="autolaunch:" \ Shouldn't this have the same logic and defaults as in a native build? ::: cmake/doc/CMakeLists.txt @@ +27,5 @@ > + set (DOCBOOK_GENERATOR_NAME "xmlto" PARENT_SCOPE) > + set(DBUS_XML_DOCS_ENABLED 1) > + set(MEINPROC4_EXECUTABLE 0) > + MESSAGE(STATUS "xmlto docbook generator found") > +elseif (MEINPROC4_EXECUTABLE) This looks like a good change - the Autotools build system can only use xmlto at the moment, so defaulting to xmlto (if available) on CMake seems consistent. Do we need to support meinproc at all? Does it have advantages over xmlto? ::: cmake/modules/Macros.cmake @@ +2,2 @@ > MACRO(TIMESTAMP RESULT) > + IF(WIN32 AND NOT CMAKE_CROSSCOMPILING) This genuinely does need to switch according to (in Autotools' terminology) the build architecture, not the host architecture. I don't think you're going to be able to avoid having a separate WIN32_BUILD and WIN32_HOST, or something like that.
Comment on attachment 73480 [details] [review] cross compile fixes Review of attachment 73480 [details] [review]: ----------------------------------------------------------------- will update the patch ::: cmake/CMakeLists.txt @@ +437,2 @@ > set (DBUS_SYSTEM_BUS_DEFAULT_ADDRESS "nonce-tcp:" CACHE STRING "system bus default address") > set (DBUS_SESSION_BUS_DEFAULT_ADDRESS "nonce-tcp:" CACHE STRING "session bus default address") the patch has been build on dbus-1.6 where this is the default, on master autolaunch: is already the default, so this hunk will be obsolate. ::: cmake/cross-compile.sh @@ +12,5 @@ > if test -f /usr/bin/i686-pc-mingw32-gcc; then > cross_cc=i686-pc-mingw32 > elif test -f /usr/bin/i586-mingw32msvc-gcc; then > cross_cc=i586-mingw32msvc > +elif test -f /usr/bin/i686-w64-mingw32-gcc-4.7.2; then The reason for this that normal mingw gcc on opensuse 12.2 is broken. An alternative would be to provide an option to cross-compile.sh for example CC=/usr/bin/i686-w64-mingw32-gcc-4.7.2 ../dbus/cmake/cross-compile.sh @@ -98,5 @@ > - -DCMAKE_C_COMPILER="/usr/bin/$cross_cc-gcc" \ > - -DCMAKE_CXX_COMPILER="/usr/bin/$cross_cc-g++" \ > - -DCMAKE_FIND_ROOT_PATH="$cross_root" \ > - -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY \ > - -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY \ these are duplicated entries, which has been removed; see below @@ +108,5 @@ > -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY \ > -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY \ > $xml_library \ > -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER \ > + -DDBUS_SESSION_BUS_DEFAULT_ADDRESS="autolaunch:" \ the patch has been generated on dbus-1.6, rebasing to master will make this hunk obsolate. ::: cmake/doc/CMakeLists.txt @@ +27,5 @@ > + set (DOCBOOK_GENERATOR_NAME "xmlto" PARENT_SCOPE) > + set(DBUS_XML_DOCS_ENABLED 1) > + set(MEINPROC4_EXECUTABLE 0) > + MESSAGE(STATUS "xmlto docbook generator found") > +elseif (MEINPROC4_EXECUTABLE) meinproc is there because of the lack of xmlto on windows. The common base would be in using xsltproc, for which a migration has already been started with bug 59807 ::: cmake/modules/FindLibExpat.cmake @@ +12,4 @@ > SET(LIBEXPAT_FOUND TRUE) > > else (LIBEXPAT_INCLUDE_DIR AND LIBEXPAT_LIBRARIES) > + IF (CMAKE_CROSSCOMPILING) this will be refactored by using CMAKE_HOST_SYSTEM_NAME ::: cmake/modules/Macros.cmake @@ +2,2 @@ > MACRO(TIMESTAMP RESULT) > + IF(WIN32 AND NOT CMAKE_CROSSCOMPILING) Here only the host system is relevant, therefore CMAKE_HOST_SYSTEM_NAME will be used. Thanks for this pointer
Created attachment 73683 [details] [review] cmake cross compile fixes (update 1)
Having thought about this some more over the weekend, I'm starting to lean towards thinking we should document cross-compilation via Autotools, and have that as the only supported cross-compilation. Autotools cross-compilation is well-understood, and is relatively uniform between projects: in particular, given a set of projects (e.g. D-Bus, GLib and dbus-glib), it's often possible to put together a shared set of configure flags that will work for all of them. As far as I'm aware, cmake's major advantage over Autotools is that it can produce MS Visual Studio "solutions", and has fewer dependencies than Autotools when run on Windows; but that's only applicable to builds with build=Windows, host=Windows, i.e. not cross-building anyway. If you're using Linux for the build, MSVC isn't relevant and it's trivial to obtain D-Bus' dependencies. Here's how I cross-build libdbus: ${srcdir}/configure \ --enable-maintainer-mode --enable-developer \ --build=x86_64-pc-linux-gnu --host=i686-w64-mingw32 \ build_alias=x86_64-pc-linux-gnu host_alias=i686-w64-mingw32 \ --prefix=/opt/i686-w64-mingw32 \ LDFLAGS=-L/opt/i686-w64-mingw32/lib \ CPPFLAGS=-I/opt/i686-w64-mingw32/include \ PKG_CONFIG_LIBDIR=/opt/i686-w64-mingw32/lib/pkgconfig \ PKG_CONFIG_PATH= ... and that's it. This is not specific to Windows at all: substituting arm-linux-gnueabi for i686-w64-mingw32 would give you ARM EABI Linux binaries. That set of options (apart from the first two which are D-Bus-specific, but not cross-specific) are common to basically all Autotools projects. Needing to specify build_alias and host_alias is probably a bug somewhere; I should check whether that's still needed. Automake automatically knows that when building with --host=i686-w64-mingw32, it needs to use architecture-prefixed tools like i686-w64-mingw32-gcc, so there's no need for a separate "here is my C compiler" option. It will even use i686-w64-mingw32-pkg-config if available, which can be used to avoid needing the last two options.
Comment on attachment 73683 [details] [review] cmake cross compile fixes (update 1) Review of attachment 73683 [details] [review]: ----------------------------------------------------------------- ::: cmake/cross-compile.sh @@ +1,3 @@ > #!/bin/sh > # > # cross compile script for cmake Philosophically, I don't like having to have a precarious shell script like this in every cross-compilable project; in principle, you should just be able to read "info automake Cross-Compilation" (or perhaps the cmake equivalent) and follow that for every project. In practice, things have dependencies, so a couple more options are needed to tell configure where you put their pkg-config metadata (for dependencies that have it) or libraries and headers (for dependencies that don't). @@ +18,5 @@ > +# > +cc_postfix= > +if test -n "$CC"; then > + cross_cc=$(echo $CC | sed 's,^/usr/bin/,,g;s,-gcc-.*$,,g') > + cc_postfix=$(echo $CC | sed 's,^.*gcc,,g') Have you opened an OpenSUSE bug requesting that they provide a ${cross_cc}-gcc binary? (If they don't, "normal" Autotools cross-compilation won't work either.)
Created attachment 73789 [details] [review] check for xmlto first in cmake build systems this patch makes previous partly obsolate, remaining update will follow
Created attachment 73790 [details] [review] time stamp generating fixes
Created attachment 73791 [details] [review] cmake cross compile fixes for libexpat find package
Comment on attachment 73789 [details] [review] check for xmlto first in cmake build systems Review of attachment 73789 [details] [review]: ----------------------------------------------------------------- I'd prefer the commit message to mention what we've discussed here, for the benefit of future maintainers. Perhaps something like this? > CMake build system: only check for meinproc if we don't have xmlto > > We shouldn't try to build the documentation with meinproc *and* xmlto. > Prefer xmlto, since it's also the one we use under Autotools. > We still need to support meinproc as a fallback, because xmlto isn't > available on Windows. review+ with or without that change.
Comment on attachment 73790 [details] [review] time stamp generating fixes Review of attachment 73790 [details] [review]: ----------------------------------------------------------------- ::: cmake/modules/Macros.cmake @@ +1,3 @@ > > MACRO(TIMESTAMP RESULT) > + IF(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows") CMake's CMAKE_SYSTEM is Autoconf's "host", and CMake's CMAKE_HOST_SYSTEM is Autoconf's "build", right? (For instance if I use my Linux laptop to compile dbus-daemon.exe for Windows, my CMAKE_HOST_SYSTEM_NAME is Linux and my CMAKE_SYSTEM_NAME is Windows?) @@ +5,5 @@ > string(REGEX REPLACE "(..)[/.](..)[/.](....).*" "\\3\\2\\1" DATE ${DATE}) > EXECUTE_PROCESS(COMMAND "cmd" " /C time /T" OUTPUT_VARIABLE TIME) > string(REGEX REPLACE "(..):(..)" "\\1\\2" TIME ${TIME}) > set (${RESULT} "${DATE}${TIME}") > + ELSEIF(CMAKE_HOST_SYSTEM_NAME STREQUAL "Linux") What if it's neither Linux nor Windows? I think this should just be an "else". D-Bus only supports Windows and "Unix", where Unix includes Linux, Solaris, *BSD, GNU Hurd and so on. If you pick a random operating system that is still halfway relevant, it probably looks a lot like Unix. If we added support for a non-Unix OS other than Windows, this would become IF (... "Windows") ... do Windows things ... ELSEIF(... "Symbian") # or whatever ... do Symbian things ... ELSE() ... use date +%Y%m%d%H%M ... although I doubt that will ever happen.
Comment on attachment 73791 [details] [review] cmake cross compile fixes for libexpat find package Review of attachment 73791 [details] [review]: ----------------------------------------------------------------- I still don't like having to have a lot of subtly different FindWhatever.cmake files because people still don't use pkg-config...
(In reply to comment #10) > Comment on attachment 73790 [details] [review] [review] > time stamp generating fixes > > Review of attachment 73790 [details] [review] [review]: > ----------------------------------------------------------------- > > ::: cmake/modules/Macros.cmake > @@ +1,3 @@ > > > > MACRO(TIMESTAMP RESULT) > > + IF(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows") > > CMake's CMAKE_SYSTEM is Autoconf's "host", and CMake's CMAKE_HOST_SYSTEM is > Autoconf's "build", right? yes, see http://www.vtk.org/Wiki/CMake_Cross_Compiling > > (For instance if I use my Linux laptop to compile dbus-daemon.exe for > Windows, my CMAKE_HOST_SYSTEM_NAME is Linux and my CMAKE_SYSTEM_NAME is > Windows?) yes > > @@ +5,5 @@ > > string(REGEX REPLACE "(..)[/.](..)[/.](....).*" "\\3\\2\\1" DATE ${DATE}) > > EXECUTE_PROCESS(COMMAND "cmd" " /C time /T" OUTPUT_VARIABLE TIME) > > string(REGEX REPLACE "(..):(..)" "\\1\\2" TIME ${TIME}) > > set (${RESULT} "${DATE}${TIME}") > > + ELSEIF(CMAKE_HOST_SYSTEM_NAME STREQUAL "Linux") > > What if it's neither Linux nor Windows? > > I think this should just be an "else". D-Bus only supports Windows and > "Unix", where Unix includes Linux, Solaris, *BSD, GNU Hurd and so on. If you > pick a random operating system that is still halfway relevant, it probably > looks a lot like Unix. > > If we added support for a non-Unix OS other than Windows, this would become > > IF (... "Windows") > ... do Windows things ... > ELSEIF(... "Symbian") # or whatever > ... do Symbian things ... > ELSE() > ... use date +%Y%m%d%H%M ... > > although I doubt that will ever happen. this behavior is already implemented, see the full patch
Comment on attachment 73791 [details] [review] cmake cross compile fixes for libexpat find package Review of attachment 73791 [details] [review]: ----------------------------------------------------------------- I still don't like having to have a lot of subtly different FindWhatever.cmake files because people still don't use pkg-config... (Sorry, pressed Publish too soon. Let's try that again.) ::: cmake/modules/FindLibExpat.cmake @@ +12,4 @@ > SET(LIBEXPAT_FOUND TRUE) > > else (LIBEXPAT_INCLUDE_DIR AND LIBEXPAT_LIBRARIES) > + if (CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows") This assumes that you're not cross-compiling from Windows to !Windows, but that seems reasonable. @@ +13,5 @@ > > else (LIBEXPAT_INCLUDE_DIR AND LIBEXPAT_LIBRARIES) > + if (CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows") > + file(TO_CMAKE_PATH "$ENV{PROGRAMFILES}" _progFiles) > + find_FILE(LIBEXPAT_DIR expat Source/lib/expat.h Do Windows people always use unpacked source code for this sort of thing, rather than installing to a "staging" directory? @@ +21,5 @@ > if (LIBEXPAT_DIR) > set (_LIBEXPATIncDir ${LIBEXPAT_DIR}/Source/lib) > set (_LIBEXPATLinkDir ${LIBEXPAT_DIR}/libs) > endif (LIBEXPAT_DIR) > + elseif (CMAKE_HOST_SYSTEM_NAME STREQUAL "Linux" AND CMAKE_CROSSCOMPILING) I suppose nobody is very likely to cross-compile Windows binaries on a non-Linux Unix, but perhaps use CMAKE_HOST_SYSTEM_NAME STRNOTEQUAL "Windows", or whatever the right syntax is? How do you set CMAKE_FIND_ROOT_PATH? Is there any particular reason not to set PKG_CONFIG_PATH instead, then use pkg-config, like in the native Unix code path (and like we do with Autotools)?
(In reply to comment #12) > > > + ELSEIF(CMAKE_HOST_SYSTEM_NAME STREQUAL "Linux") > > > > What if it's neither Linux nor Windows? > > > > I think this should just be an "else". > this behavior is already implemented, see the full patch No, it throws an error if you build on a non-Linux Unix, which would previously have been OK as long as it defined the "UNIX" variable: - ELSEIF(UNIX) + ELSEIF(CMAKE_HOST_SYSTEM_NAME STREQUAL "Linux") EXECUTE_PROCESS(COMMAND "date" "+%Y%m%d%H%M" OUTPUT_VARIABLE ${RESULT}) ELSE() MESSAGE(SEND_ERROR "date not implemented") Does cross-compiling with CMake actually give any advantages over cross-compiling with Autotools? Most people who cross-compile open source software already know how Autotools cross-compilation works, because it's basically the same for every project, and you need to use Autotools already to get basic "infrastructure" things like gcc up and running.
(In reply to comment #9) > Comment on attachment 73789 [details] [review] [review] > check for xmlto first in cmake build systems > > Review of attachment 73789 [details] [review] [review]: > ----------------------------------------------------------------- > > I'd prefer the commit message to mention what we've discussed here, for the > benefit of future maintainers. Perhaps something like this? > > > CMake build system: only check for meinproc if we don't have xmlto > > > > We shouldn't try to build the documentation with meinproc *and* xmlto. > > Prefer xmlto, since it's also the one we use under Autotools. > > We still need to support meinproc as a fallback, because xmlto isn't > > available on Windows. > > review+ with or without that change. committed
Created attachment 73867 [details] [review] Removed obsolate dbus provided find expat package I rechecked the find expat package and found out, that it is complete obsolate and could be replaced by the related cmake provided one.
(In reply to comment #13) > Comment on attachment 73791 [details] [review] [review] > cmake cross compile fixes for libexpat find package > > Review of attachment 73791 [details] [review] [review]: > ----------------------------------------------------------------- > > I still don't like having to have a lot of subtly different > FindWhatever.cmake files because people still don't use pkg-config... > > (Sorry, pressed Publish too soon. Let's try that again.) > > ::: cmake/modules/FindLibExpat.cmake > @@ +12,4 @@ > > SET(LIBEXPAT_FOUND TRUE) > > > > else (LIBEXPAT_INCLUDE_DIR AND LIBEXPAT_LIBRARIES) > > + if (CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows") > > This assumes that you're not cross-compiling from Windows to !Windows, but > that seems reasonable. > > @@ +13,5 @@ > > > > else (LIBEXPAT_INCLUDE_DIR AND LIBEXPAT_LIBRARIES) > > + if (CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows") > > + file(TO_CMAKE_PATH "$ENV{PROGRAMFILES}" _progFiles) > > + find_FILE(LIBEXPAT_DIR expat Source/lib/expat.h > > Do Windows people always use unpacked source code for this sort of thing, > rather than installing to a "staging" directory? > > @@ +21,5 @@ > > if (LIBEXPAT_DIR) > > set (_LIBEXPATIncDir ${LIBEXPAT_DIR}/Source/lib) > > set (_LIBEXPATLinkDir ${LIBEXPAT_DIR}/libs) > > endif (LIBEXPAT_DIR) > > + elseif (CMAKE_HOST_SYSTEM_NAME STREQUAL "Linux" AND CMAKE_CROSSCOMPILING) > > I suppose nobody is very likely to cross-compile Windows binaries on a > non-Linux Unix, but perhaps use CMAKE_HOST_SYSTEM_NAME STRNOTEQUAL > "Windows", or whatever the right syntax is? > > How do you set CMAKE_FIND_ROOT_PATH? Is there any particular reason not to > set PKG_CONFIG_PATH instead, then use pkg-config, like in the native Unix > code path (and like we do with Autotools)? (In reply to comment #14) > (In reply to comment #12) > > > > + ELSEIF(CMAKE_HOST_SYSTEM_NAME STREQUAL "Linux") > > > > > > What if it's neither Linux nor Windows? > > > > > > I think this should just be an "else". > > > this behavior is already implemented, see the full patch > > No, it throws an error if you build on a non-Linux Unix, which would > previously have been OK as long as it defined the "UNIX" variable: > > - ELSEIF(UNIX) > + ELSEIF(CMAKE_HOST_SYSTEM_NAME STREQUAL "Linux") > EXECUTE_PROCESS(COMMAND "date" "+%Y%m%d%H%" OUTPUT_VcomARIABLE > ${RESULT}) > ELSE() > MESSAGE(SEND_ERROR "date not implemented") You're right, I did not had unix system beside linux in mind. Will take a look at this. > > Does cross-compiling with CMake actually give any advantages over > cross-compiling with Autotools? cross compiling kde on linux, which is documented at the kde web site, is mostly based on cmake (485 of 512 packages). The only exception is qt, which is based on qmake.
Created attachment 74083 [details] [review] Time stamp generating fixes (update 1)
(In reply to comment #5) > Comment on attachment 73683 [details] [review] [review] > cmake cross compile fixes (update 1) > > Review of attachment 73683 [details] [review] [review]: > ----------------------------------------------------------------- > > ::: cmake/cross-compile.sh > @@ +1,3 @@ > > #!/bin/sh > > #g > > # cross compile script for cmake > > Philosophically, I don't like having to have a precarious shell script like > this in every cross-compilable project; You're right. This is bad. cmake has special support for such things by using a dedicated cross-compiler config file, which is provided to cmake by the -DCMAKE_TOOLCHAIN_FILE command line switch on configure time. This means cross_compile.sh could be removed. I will add a related patch to this bug.
(In reply to comment #4) > Having thought about this some more over the weekend, I'm starting to lean > towards thinking we should document cross-compilation via Autotools, and > have that as the only supported cross-compilation. > > Autotools cross-compilation is well-understood, and is relatively uniform > between projects: in particular, given a set of projects (e.g. D-Bus, GLib > and dbus-glib), it's often possible to put together a shared set of > configure flags that will work for all of them. > > As far as I'm aware, cmake's major advantage over Autotools is that it can > produce MS Visual Studio "solutions", and has fewer dependencies than > Autotools when run on Windows; but that's only applicable to builds with > build=Windows, host=Windows, i.e. not cross-building anyway. If you're using > Linux for the build, MSVC isn't relevant and it's trivial to obtain D-Bus' > dependencies. > > Here's how I cross-build libdbus: > > ${srcdir}/configure \ > --enable-maintainer-mode --enable-developer \ > --build=x86_64-pc-linux-gnu --host=i686-w64-mingw32 \ > build_alias=x86_64-pc-linux-gnu host_alias=i686-w64-mingw32 \ > --prefix=/opt/i686-w64-mingw32 \ > LDFLAGS=-L/opt/i686-w64-mingw32/lib \ > CPPFLAGS=-I/opt/i686-w64-mingw32/include \ > PKG_CONFIG_LIBDIR=/opt/i686-w64-mingw32/lib/pkgconfig \ > PKG_CONFIG_PATH= > > ... and that's it. This is not specific to Windows at all: substituting > arm-linux-gnueabi for i686-w64-mingw32 would give you ARM EABI Linux > binaries. > gave it a try - cross compiling dbus works for me this way without any problems. > That set of options (apart from the first two which are D-Bus-specific, but > not cross-specific) are common to basically all Autotools projects. > > Needing to specify build_alias and host_alias is probably a bug somewhere; I > should check whether that's still needed. > > Automake automatically knows that when building with > --host=i686-w64-mingw32, it needs to use architecture-prefixed tools like > i686-w64-mingw32-gcc, so there's no need for a separate "here is my C > compiler" option. It will even use i686-w64-mingw32-pkg-config if available, > which can be used to avoid needing the last two options. good to know :-) running make check dot not work this way make[3]: Entering directory `/home/admin/src/dbus-59733-autotools-cross-build/test' /bin/sh: Zeile 9: ./../bus/bus-test.exe: Kann die Datei nicht ausführen. FAIL: ../bus/bus-test.exe /bin/sh: Zeile 9: ./../bus/bus-test-system.exe: Kann die Datei nicht ausführen. FAIL: ../bus/bus-test-system.exe /bin/sh: Zeile 9: ./../dbus/dbus-test.exe: Kann die Datei nicht ausführen. FAIL: ../dbus/dbus-test.exe /bin/sh: Zeile 9: ./shell-test.exe: Kann die Datei nicht ausführen. FAIL: shell-test.exe ======================================================================== 4 of 4 tests failed Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=dbus ======================================================================== Seems that for windows targets wine has to be used in the runner script.
Comment on attachment 73867 [details] [review] Removed obsolate dbus provided find expat package Review of attachment 73867 [details] [review]: ----------------------------------------------------------------- This is more like it! I like reduced duplication :-) Applying.
Comment on attachment 74083 [details] [review] Time stamp generating fixes (update 1) Review of attachment 74083 [details] [review]: ----------------------------------------------------------------- r+, I'll apply it
(In reply to comment #20) > running make check dot not work this way I don't think this is a bug. You can't generally expect "make check" to work when cross-compiling: it will try to run the binaries it just compiled, and if you can't run them transparently, that will fail. For instance, host=i386-linux-gnu on build=x86_64-linux-gnu will usually work (because the x86-64 build machine can run i386 binaries) but host=arm-linux-gnu or host=i586-mingw-w64 on the same build machine will usually not work (because an x86-64 CPU can't run ARM binaries, and Linux can't run Windows binaries). If you have binfmt_misc set up to run Windows executables via Wine, or (for instance) ARM Linux executables via qemu-arm-static, as Debian does, then in principle it ought to be possible to run "make check" even when cross-compiling. I don't know the precise details of how this works, but it's to do with the binfmt-support package, which creates files in /proc/sys/fs/binfmt_misc. Does your distribution (OpenSUSE?) have anything similar? Last time I tried this, some of the regression tests worked under Wine, but others failed. I'd be happy to apply patches to make this setup work better, as long as it doesn't break more normal configurations.
Comment on attachment 73867 [details] [review] Removed obsolate dbus provided find expat package (In reply to comment #21) > This is more like it! I like reduced duplication :-) > > Applying. Fixed in git for 1.7.0
Comment on attachment 74083 [details] [review] Time stamp generating fixes (update 1) (In reply to comment #22) > r+, I'll apply it In git for 1.7.0
Created attachment 74927 [details] [review] Removed precarious cross compile shell script
(In reply to comment #23) > (In reply to comment #20) > > running make check dot not work this way > > I don't think this is a bug. You can't generally expect "make check" to work > when cross-compiling: it will try to run the binaries it just compiled, and > if you can't run them transparently, that will fail. > > For instance, host=i386-linux-gnu on build=x86_64-linux-gnu will usually > work (because the x86-64 build machine can run i386 binaries) but > host=arm-linux-gnu or host=i586-mingw-w64 on the same build machine will > usually not work (because an x86-64 CPU can't run ARM binaries, and Linux > can't run Windows binaries). > > If you have binfmt_misc set up to run Windows executables via Wine, or (for > instance) ARM Linux executables via qemu-arm-static, as Debian does, then in > principle it ought to be possible to run "make check" even when > cross-compiling. I don't know the precise details of how this works, but > it's to do with the binfmt-support package, which creates files in > /proc/sys/fs/binfmt_misc. Does your distribution (OpenSUSE?) have anything > similar? yes, running the following command line from to http://de.wikipedia.org/wiki/Binfmt_misc echo ':DOSWin:M::MZ::/usr/bin/wine:' > /proc/sys/fs/binfmt_misc/register enables this support. One issue I found is that the executable to run must have executable rights, which is not the default when cross compiling > > Last time I tried this, some of the regression tests worked under Wine, but > others failed. same here, unfortunally I did not get the point where the failures come from.
Comment on attachment 74927 [details] [review] Removed precarious cross compile shell script Review of attachment 74927 [details] [review]: ----------------------------------------------------------------- \o/ Ship it!
(In reply to comment #28) > Comment on attachment 74927 [details] [review] [review] > Removed precarious cross compile shell script > > Review of attachment 74927 [details] [review] [review]: > ----------------------------------------------------------------- > > \o/ > > Ship it! in git for 1.7.0
Created attachment 75078 [details] [review] Fixed bug not installing runtime part of shared library in bin dir
Comment on attachment 75078 [details] [review] Fixed bug not installing runtime part of shared library in bin dir Review of attachment 75078 [details] [review]: ----------------------------------------------------------------- I think this will put the runtime library in the wrong place on Unix? On Windows, DLLs should be in the $PATH (but the development and static parts of a library still go in a library directory), so you often see: $prefix/bin/foo-tool $prefix/bin/libfoo.dll $prefix/include/foo/foo.h $prefix/lib/libfoo.dll.a $prefix/lib/libfoo.lib but on Unix, libraries go in the library directory: $prefix/bin/foo-tool $prefix/include/foo/foo.h $prefix/lib/libfoo.a $prefix/lib/libfoo.so.1 $prefix/lib/libfoo.so -> libfoo.so.1
(In reply to comment #31) > Comment on attachment 75078 [details] [review] [review] > Fixed bug not installing runtime part of shared library in bin dir > > Review of attachment 75078 [details] [review] [review]: > ----------------------------------------------------------------- > > I think this will put the runtime library in the wrong place on Unix? > > On Windows, DLLs should be in the $PATH (but the development and static > parts of a library still go in a library directory), so you often see: > > $prefix/bin/foo-tool > $prefix/bin/libfoo.dll > $prefix/include/foo/foo.h > $prefix/lib/libfoo.dll.a > $prefix/lib/libfoo.lib > > but on Unix, libraries go in the library directory: > > $prefix/bin/foo-tool > $prefix/include/foo/foo.h > $prefix/lib/libfoo.a > $prefix/lib/libfoo.so.1 > $prefix/lib/libfoo.so -> libfoo.so.1 thanks for this pointer. KDE uses a specific default argument for installing targets which is defined platform dependent e.g. if (WIN32) set(INSTALL_TARGETS_DEFAULT_ARGS RUNTIME DESTINATION "bin" LIBRARY DESTINATION "lib" ARCHIVE DESTINATION "lib") else set(INSTALL_TARGETS_DEFAULT_ARGS RUNTIME DESTINATION "${EXPANDED_LIBDIR}" LIBRARY DESTINATION "${EXPANDED_LIBDIR}" ARCHIVE DESTINATION "${EXPANDED_LIBDIR}") endif() install(TARGETS dbus-1 ${INSTALL_TARGETS_DEFAULT_ARGS}) I will update the patch.
Created attachment 78609 [details] [review] Fixed bug not installing runtime part of shared libraries into bin dir for cmake builds.
Comment on attachment 78609 [details] [review] Fixed bug not installing runtime part of shared libraries into bin dir for cmake builds. Review of attachment 78609 [details] [review]: ----------------------------------------------------------------- Looks good to me.
(In reply to comment #34) > > Review of attachment 78609 [details] [review] [review]: > ----------------------------------------------------------------- > > Looks good to me. pushed into master
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.