On Sat, 25 Feb 2006, Xun Sun wrote:
> [...]
> 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.
The macro I just unearthed, called "AM_CHECK_PYTHON_HEADERS", basically
does:
python -c "import sys; print sys.prefix"
and returns the path up to (but not including) the "include". So on my
system, with its "/usr/local/python/include/python2.2/Python.h" that
"python" call returns "/usr/local/python/", which the macro then builds up
to "/usr/local/python/include/python2.2/" for use in "@PYTHON_INCLUDES@".
It also does the right thing on Linux.
Overall it looks promising.
It works on my test system (which is not csw/blastwave, but which has an
analogous non-standard placing of our python). I'm going to try to set up
a blastwave environment as an additional check of my idea.
> So "/opt/csw" is the sort of pseudo-standard.
_If_ we have to go down the route of setting up a list of "well-known
possible non-standard locations", then, yes, "/opt/csw" would probably
merit a place in it. But I hope that this "AM_CHECK_PYTHON_HEADERS"
will make that unnecessary.
> 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).
Thanks for your willingness! It's always good to bounce ideas around for
fresh viewpoints!
I hope that "AM_CHECK_PYTHON_HEADERS" (or similar) can solve it cleanly
for most cases (not just Solaris, but any environment where the python
details may not be in the defaults places).
--
: 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/
