On 2/20/06, David Lee <[EMAIL PROTECTED]> wrote: > 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.
My former proposal of doing so was based on the assumption that "/opt/csw" was a randomly chosen (by the blastwave system that I was not aware of) place, hence the user had to explicitly specify it in some way (CPPFLAGS) the user was already familiar with. So the assumption is invalid. Is blastwave (csw) packaging system popular anyway? > 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]@ This is doable only if we have some fixed places (e.g., /usr/include, /usr/local/include, /opt/csw/include) to search, and don't have to search arbitrary location. > > That "somehow" might (for example) be user-supplied CPPFLAGS, or something > like the already used "$PKGCONFIG --cflags ..." mechanism. Etc. Unfortunately this mechanism is missing from python, at least on my Fedora Core 2 Linux. > > > 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! OK. > > 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. So "/opt/csw" is the sort of pseudo-standard. > > If we went a step further and provided packages there, I would like to help to make it happen:) However don't expect too much from me, due to my zero knowledge with Solaris packaging system(s). > 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/ > -- Thanks & regards Xun Sun _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
