On Sat, 18 Feb 2006, Xun Sun wrote: > [...] > One way to heal the problem is to add Python.h location into CPPFLAGS. > Assuming the Python headers are installed in standard location > (otherwise they may be at arbitrary locations and we are unable to > find them programmingly in configure.in, then the user should specify > the CPPFLAGS to include them), I propose a straightforward solution: > > *AC_CHECK_HEADER[/usr/include/$PYTHON_HEADER_DIR/Python.h], if > successful, CPPFLAGS+=-I/usr/include/$PYTHON_HEADER_DIR, else > > *AC_CHECK_HEADER[/usr/local/include/$PYTHON_HEADER_DIR/Python.h], if > successful, CPPFLAGS+=-I/usr/local/include/$PYTHON_HEADER_DIR, else > > *AC_CHECK_HEADER[$PYTHON_HEADER_DIR/Python.h] > > By the last trial, we are assured even if Python headers aren't in > standard location, they still can be found if user specified CPPFLAGS > to us.
Should the configure script really be putting things into CPPFLAGS? I thought CPPFLAGS (and other "well known" things like LDFLAGS) should be left alone for maximum end-user flexibility. Rather, shouldn't configure set up its own variables? (See, e.g. our "LIBNETDEFINES" etc.) Thus configure would (somehow) establish the path to "Python.h" and define something like "@PYTHON_HEADER_PATH@" for use in "Makefile.am", something like: INCLUDES = ... [EMAIL PROTECTED]@ That "somehow" might (for example) be user-supplied CPPFLAGS, or something like the already used "$PKGCONFIG --cflags ..." mechanism. Etc. > Test of other standard locations (as for Solaris or other systems) can > be recommended and added. We tend to try to avoid those, unless they really are standard. And if they really are standard then autoconf generally already knows about them so the question doesn't even arise! If "/opt/csw" is (as I think it might be) the blastwave repository, then it is a sort of pseudo-standard. It might already have its own recommendations, which we should research rather than try to second-guess. If we went a step further and provided packages there, then this question would not arise for the end-user, only for the package maintainer at blastwave. > Any comments or better ideas? Hope the above helps. This is potentially very frutiful, hence the importance of trying to "do it right". -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
