Forum: GNU Radio QtGUI QWT #includes?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
781e96b7bd64e8833d71e3914cb1594a?d=identicon&s=25 Michael Dickens (Guest)
on 2009-03-17 13:03
(Received via mailing list)
I've been trying to get QTGUI to compile on OSX and openSUSE ...
neither provides a pre-compiled package for qwt or qwtplot3d, so I
have to install from source ("by hand").  I've figured out that the
"traditional" way for installing the headers (e.g., in Linux pre-
compiled RPM) for these is into a subdirectory, e.g., 'qwt' in $
{prefix}/include/qwt or ${prefix}/include/qwt-qt4 (or -qt3 if using
qt3), qwtplot3d in ${prefix}/include/qwtplot3d or ${prefix}/include/
qwtplot3d-qt4 (or -qt3 if using qt3) -- so the include subdirectory is
unknown a priori unless the user has specified it in an environment
variable before executing 'configure' or argument to configure.

Since I'm using ${prefix}=/usr/local -- which is a standard one
searched for by the modern autoconf configure scripts -- the qwt and
qwtplot3d headers are found correctly by GNU Radio's configure script
(in this case, in ${prefix}/include/qwt and .../qwtplot3d).  But then
compilation fails because the headers can't be found with the known
include path.  I traced this down to the file config/
grc_gr_qtgui.m4:61-86, which does the checking and then assumes that
the include path is "/usr/include" -- which isn't necessarily true
because of the way autoconf works.  [In the qtgui C++ code, headers
are included directly via "#include <qwt.h>" etc., so-as to try to
avoid the unknown subdirectory name containing the headers.  This is
normal and fine; just means that the correct #include path needs to be
in CXXFLAGS.]

I haven't been able to track down a way to use AC_CHECK_HEADER to
obtain the path to the header.  Best I've found is done by config/
ax_boost_base.m4:102-114, which checks over each of "/usr /usr/local /
opt /opt/local" for "include/boost" and breaks when it finds one.  The
script then goes on to check to see if <boost/version.hpp> works, and
then (again looping over the directories above) that the version # is
new enough (per that provided as input to the macro by the user).

It seems to me that something to the effect of what boost is doing
could be implemented for QWT (assuming the user doesn't specify a path
via an environment variable or configure flag): loop over "/usr /usr/
local /opt /opt/local" and an inner loop over "qwt qwt-qt4 (etc)" and
"qwtplot3d qwtplot3d-qt4 (etc)"; the first path of each which passes
some appropriate test would then be appended to CXXFLAGS ($
{found_prefix}/include) and LDFLAGS (${found_prefix}/lib).  This
search would be much more robust than the current method.

Yes, I know I can set the "--with-qwt-incdir=[path]" and "--with-
qwtplot3d-incdir=[path]" flags to configure ... I'm just trying to
find ways to automate the process, to work for "more" or "most"
typical installs.

Comments?  Thoughts? - MLD
This topic is locked and can not be replied to.