|
From: Bart V. A. <bar...@gm...> - 2008-07-28 14:15:07
|
Some DRD regression tests link against the Qt4 library, and that is why there is a test for Qt4 in Valgrind's configure.in. That test currently uses built-in autoconf macro's like AC_TRY_COMPILE(). This is a rather cumbersome way to find out e.g. the path of Qt4 include files. Would it be OK to rewrite this test using the autoconf macro's provided by pkg-config, e.g. PKG_CHECK_EXISTS() ? This would add an extra requirement however when building Valgrind, and I'm not sure where to document this. Bart. |
|
From: Julian S. <js...@ac...> - 2008-07-29 08:23:10
|
On Monday 28 July 2008 16:15, Bart Van Assche wrote: > Some DRD regression tests link against the Qt4 library, and that is > why there is a test for Qt4 in Valgrind's configure.in. That test > currently uses built-in autoconf macro's like AC_TRY_COMPILE(). This > is a rather cumbersome way to find out e.g. the path of Qt4 include > files. Would it be OK to rewrite this test using the autoconf macro's > provided by pkg-config, e.g. PKG_CHECK_EXISTS() ? This would add an > extra requirement however when building Valgrind, and I'm not sure > where to document this. I prefer not; we spent already a lot of time and effort getting rid of dependencies of various kinds. How bad does the cumbersome code look? Is it the Qt4 checking stuff in configure.in r8465, or some other un-committed changes you have? J |
|
From: Bart V. A. <bar...@gm...> - 2008-07-29 09:20:21
|
On Tue, Jul 29, 2008 at 10:14 AM, Julian Seward <js...@ac...> wrote: > On Monday 28 July 2008 16:15, Bart Van Assche wrote: >> Some DRD regression tests link against the Qt4 library, and that is >> why there is a test for Qt4 in Valgrind's configure.in. That test >> currently uses built-in autoconf macro's like AC_TRY_COMPILE(). This >> is a rather cumbersome way to find out e.g. the path of Qt4 include >> files. Would it be OK to rewrite this test using the autoconf macro's >> provided by pkg-config, e.g. PKG_CHECK_EXISTS() ? This would add an >> extra requirement however when building Valgrind, and I'm not sure >> where to document this. > > I prefer not; we spent already a lot of time and effort getting rid of > dependencies of various kinds. > > How bad does the cumbersome code look? Is it the Qt4 checking stuff > in configure.in r8465, or some other un-committed changes you have? Writing configure tests for detecting e.g. the Qt4 package compared to using pkg-config is something like reinventing the wheel. E.g. for some distro's the Qt4 include path is /usr/include, for other distro's it is /usr/include/qt4 and maybe there exist even other choices. I don't think there even exists a clean way to find out from the configure script any path a distro could come up except by using pkg-config. Additionally, sometimes additional compiler flags have to be passed to the compiler for compiling Qt4 code. Trying to figure out these flags from the configure script would be more duplication of information already known by pkg-config. As an example, the relevant info for Qt4 is as follows: $ pkg-config --cflags QtCore -DQT_SHARED -I/usr/include/QtCore $ pkg-config --libs QtCore -lQtCore -lz -lm -lrt -lpthread -ldl Bart. |
|
From: Julian S. <js...@ac...> - 2008-07-30 09:39:44
|
> > How bad does the cumbersome code look? Is it the Qt4 checking stuff > > in configure.in r8465, or some other un-committed changes you have? > > Writing configure tests for detecting e.g. the Qt4 package compared to > using pkg-config is something like reinventing the wheel. E.g. for > some distro's the Qt4 include path is /usr/include, for other distro's > it is /usr/include/qt4 and maybe there exist even other choices. I > don't think there even exists a clean way to find out from the > configure script any path a distro could come up except by using > pkg-config. Additionally, sometimes additional compiler flags have to > be passed to the compiler for compiling Qt4 code. Trying to figure out > these flags from the configure script would be more duplication of > information already known by pkg-config. Is it at least possible to arrange it so that configure does not fail if pkg-config is not installed? I don't want to acquire a dependency on pkg-config. Also, what happens if I want to use a non-default Qt4, that is, one which I build from source and pkg-config knows nothing about? What then? J |
|
From: Bart V. A. <bar...@gm...> - 2008-07-30 11:34:41
|
On Wed, Jul 30, 2008 at 11:31 AM, Julian Seward <js...@ac...> wrote:
>
> Is it at least possible to arrange it so that configure does not fail
> if pkg-config is not installed? I don't want to acquire a dependency
> on pkg-config.
>
> Also, what happens if I want to use a non-default Qt4, that is, one which
> I build from source and pkg-config knows nothing about? What then?
The configure.in file as present on the DRDDEV branch has the
following properties:
* pkg-config must be installed before running ./autogen.sh such that
the PKG_* macro definitions can be expanded properly.
* When running ./configure on a system where pkg-config has not been
installed, configure will finish successfully but will print the
following message (can be simulated e.g. as follows: ./configure
PKG_CONFIG=pkg-config-has-not-been-installed):
checking pkg-config is at least version 0.9.0... ./configure: line
2548: pkg-config: command not found no
The above message will be printed whether or not the QTCORE_CFLAGS and
QTCORE_LIBS variables have been passed to the configure script.
* When running ./configure on a system where pkg-config has been
installed, pkg-config will be used to find out QTCORE_CFLAGS and
QTCORE_LIBS.
Is this behavior acceptable ?
Bart.
configure.in patch:
@@ -50,6 +50,9 @@
# place.
AC_SUBST([DISTCHECK_CONFIGURE_FLAGS], [--with-vex=$VEX_DIR])
+# pkg-config initialization.
+PKG_PROG_PKG_CONFIG()
+
# Checks for programs.
CFLAGS="-Wno-long-long"
@@ -1251,15 +1254,6 @@
sys/types.h \
])
-# Checks for C++ header files.
-AC_LANG(C++)
-AC_CHECK_HEADERS([ \
- QtCore/QMutex \
- QtCore/QSemaphore \
- QtCore/QThread \
- ])
-AC_LANG(C)
-
# Checks for typedefs, structures, and compiler characteristics.
AC_TYPE_UID_T
AC_TYPE_OFF_T
@@ -1273,7 +1267,6 @@
AC_TYPE_SIGNAL
AC_CHECK_LIB([rt], [clock_gettime])
-AC_CHECK_LIB([QtCore], [_ZN6QMutex4lockEv]) # QMutex::lock()
AC_CHECK_FUNCS([ \
clock_gettime\
@@ -1401,26 +1394,17 @@
AM_CONDITIONAL(BUILD_MPIWRAP_SEC, test x$ac_have_mpi2_sec = xyes)
-# does this compiler have the include file <Qt/qmutex.h> and does it have
-# libQtCore.so ?
+# Has the QtCore package been installed ?
-AC_MSG_CHECKING([for Qt4 core library])
-
-AC_TRY_COMPILE([ ],
-[
-#if ! defined(HAVE_LIBQTCORE) || ! defined(HAVE_QTCORE_QMUTEX)
-#error Qt4 not supported.
-#endif
- return 0;
-],
+PKG_CHECK_EXISTS([QtCore],
[
+ PKG_CHECK_MODULES([QTCORE], [QtCore])
ac_have_qtcore=yes
- AC_MSG_RESULT([yes])
],
[
ac_have_qtcore=no
- AC_MSG_RESULT([no])
-])
+]
+)
AM_CONDITIONAL([HAVE_QTCORE], [test x$ac_have_qtcore = xyes])
|
|
From: Tom H. <to...@co...> - 2008-07-30 09:48:38
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> Also, what happens if I want to use a non-default Qt4, that is, one which
> I build from source and pkg-config knows nothing about? What then?
Then you set PKG_CONFIG_PATH to point at the directory with the .pc
file for your build ;-)
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Bart V. A. <bar...@gm...> - 2008-07-30 10:03:43
|
On Wed, Jul 30, 2008 at 11:48 AM, Tom Hughes <to...@co...> wrote:
> In message <200...@ac...>
> Julian Seward <js...@ac...> wrote:
>
>> Also, what happens if I want to use a non-default Qt4, that is, one which
>> I build from source and pkg-config knows nothing about? What then?
>
> Then you set PKG_CONFIG_PATH to point at the directory with the .pc
> file for your build ;-)
Another approach is to pass the path to the non-default Qt4 through
the variables added by pkg-config to the configure script:
$ ./configure -h
...
QTCORE_CFLAGS
C compiler flags for QTCORE, overriding pkg-config
QTCORE_LIBS linker flags for QTCORE, overriding pkg-config
...
Bart.
|
|
From: Julian S. <js...@ac...> - 2008-07-30 10:03:41
|
On Wednesday 30 July 2008 11:48, Tom Hughes wrote: > In message <200...@ac...> > Julian Seward <js...@ac...> wrote: > > > Also, what happens if I want to use a non-default Qt4, that is, one which > > I build from source and pkg-config knows nothing about? What then? > > Then you set PKG_CONFIG_PATH to point at the directory with the .pc > file for your build ;-) Well ok :-), but how about if I am trying to build against Qt4 on a machine which doesn't have pkg-config installed? Using pkg-config seems ok providing it doesn't induce a hard dependency; but I think there needs to be a way to force the build to use a particular path to Qt4 if pkg-config is either missing or doesn't produce the required results for whatever reason. Maybe something like a --with-qt4= configure flag? J |
|
From: Bart V. A. <bar...@gm...> - 2008-07-30 10:35:02
|
On Wed, Jul 30, 2008 at 11:55 AM, Julian Seward <js...@ac...> wrote: > Well ok :-), but how about if I am trying to build against Qt4 on a > machine which doesn't have pkg-config installed? Using pkg-config > seems ok providing it doesn't induce a hard dependency; but I think > there needs to be a way to force the build to use a particular path > to Qt4 if pkg-config is either missing or doesn't produce the required > results for whatever reason. Maybe something like a --with-qt4= > configure flag? Since the file /usr/share/aclocal/pkg.m4 is distributed under the GPLv2 license, we could distribute this file together with Valgrind. This would require less work than implementing a --with-qt4 configure option. Does anyone know whether it is possible to start autoconf in such a way that m4 reads the system-provided pkg.m4 if present, and the pkg.m4 file distributed with Valgrind if there is no system-provided pkg.m4 ? Bart. |
|
From: Bart V. A. <bar...@gm...> - 2008-08-01 17:04:27
|
On Tue, Jul 29, 2008 at 10:14 AM, Julian Seward <js...@ac...> wrote:
>> [ ... pkg-config ... ]
> I prefer not; we spent already a lot of time and effort getting rid of
> dependencies of various kinds.
The patch below changes the Qt4 test as follows:
- AC_CHECK_HEADERS() / AC_CHECK_LIBS() tests are removed.
- If pkg-config was not installed at the time autogen.sh was run,
./configure prints a warning and proceeds as if Qt4 has not been
installed.
- If pkg-config was installed at the time autogen.sh was run,
./configure will detect the presence of the Qt4 QtCore library.
pkg-config settings can be overridden via the configure variables
QTCORE_CFLAGS and QTCORE_LIBS (added by the pkg-config m4 macro's).
Please let me know if there are any objections against this patch.
Bart.
diff -u configure.in ../valgrind-drddev/configure.in
--- configure.in 2008-07-29 19:51:53.000000000 +0200
+++ ../valgrind-drddev/configure.in 2008-08-01 18:57:39.000000000 +0200
@@ -1251,15 +1251,6 @@
sys/types.h \
])
-# Checks for C++ header files.
-AC_LANG(C++)
-AC_CHECK_HEADERS([ \
- QtCore/QMutex \
- QtCore/QSemaphore \
- QtCore/QThread \
- ])
-AC_LANG(C)
-
# Checks for typedefs, structures, and compiler characteristics.
AC_TYPE_UID_T
AC_TYPE_OFF_T
@@ -1273,7 +1264,6 @@
AC_TYPE_SIGNAL
AC_CHECK_LIB([rt], [clock_gettime])
-AC_CHECK_LIB([QtCore], [_ZN6QMutex4lockEv]) # QMutex::lock()
AC_CHECK_FUNCS([ \
clock_gettime\
@@ -1401,26 +1391,25 @@
AM_CONDITIONAL(BUILD_MPIWRAP_SEC, test x$ac_have_mpi2_sec = xyes)
-# does this compiler have the include file <Qt/qmutex.h> and does it have
-# libQtCore.so ?
-
-AC_MSG_CHECKING([for Qt4 core library])
+# Has the QtCore package been installed ?
-AC_TRY_COMPILE([ ],
-[
-#if ! defined(HAVE_LIBQTCORE) || ! defined(HAVE_QTCORE_QMUTEX)
-#error Qt4 not supported.
-#endif
- return 0;
-],
-[
- ac_have_qtcore=yes
- AC_MSG_RESULT([yes])
-],
-[
- ac_have_qtcore=no
- AC_MSG_RESULT([no])
-])
+ifdef(
+ [PKG_CHECK_EXISTS],
+ [PKG_CHECK_EXISTS(
+ [QtCore],
+ [
+ PKG_CHECK_MODULES([QTCORE], [QtCore])
+ ac_have_qtcore=yes
+ ],
+ [
+ ac_have_qtcore=no
+ ]
+ )
+ ],
+ AC_MSG_WARN([pkg-config has not been installed or is too old.])
+ AC_MSG_WARN([Detection of Qt4 will be skipped.])
+ [ac_have_qtcore=no]
+)
AM_CONDITIONAL([HAVE_QTCORE], [test x$ac_have_qtcore = xyes])
|
|
From: Julian S. <js...@ac...> - 2008-08-01 20:24:05
|
Seems harmless enough, + I'm not really sure what the effects will be, so commit on, and let's see what happens. One thing though: > - If pkg-config was installed at the time autogen.sh was run, > ./configure will detect the presence of the Qt4 QtCore library. > pkg-config settings can be overridden via the configure variables > QTCORE_CFLAGS and QTCORE_LIBS (added by the pkg-config m4 macro's). Could you include this, or something like it, as comments, for the benefit of future visitors to configure.in :-) J |
|
From: Bart V. A. <bar...@gm...> - 2008-08-02 10:20:33
|
On Fri, Aug 1, 2008 at 10:15 PM, Julian Seward <js...@ac...> wrote: > > Seems harmless enough, + I'm not really sure what the effects will > be, so commit on, and let's see what happens. One thing though: > >> - If pkg-config was installed at the time autogen.sh was run, >> ./configure will detect the presence of the Qt4 QtCore library. >> pkg-config settings can be overridden via the configure variables >> QTCORE_CFLAGS and QTCORE_LIBS (added by the pkg-config m4 macro's). > > Could you include this, or something like it, as comments, for the > benefit of future visitors to configure.in :-) OK, done. Bart. |