[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Re: gr_python.m4
From: |
Martin Dvh |
Subject: |
Re: [Discuss-gnuradio] Re: gr_python.m4 |
Date: |
Tue, 12 Jul 2005 00:54:21 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030823 |
Eric Blossom wrote:
OK.
Running python on windows, can you please send me the output of this:
$ python
import distutils.sysconfig
print distutils.sysconfig.get_python_inc(plat_specific=False)
This is similar to what I did before my last post.
If I start the python command promt on windows and just type in:
import distutils.sysconfig
print distutils.sysconfig.get_python_inc(plat_specific=False)
The output is:
D:\Python24\include
Which is probably NOT good.
Since we are building using m4 macros and configure scripts and makefiles which
all interpret a backslash as a special character.
If the output were /d/Python24/include (or possibly even d:/Python24/include)
There would probably not be a problem.
Maybe the following will make things clear.
I typed in the following commands at the msys/mingw bash prompt which is the
environment we are using for the windows build of gnuradio.
address@hidden ~
$ python -c "import distutils.sysconfig; \
> print distutils.sysconfig.get_python_inc(plat_specific=False)"
d:\Python24\include
Now I try to see the contents of the found directory with ls
$ ls d:\Python24\include
ls: d:Python24include: No such file or directory
The backslashes disappear when used as parameter to any command.
So the value returned by distutils is not ok.
This has to do with the fact that this is the binary distribution of python for
win32 which is not mingw specific.
If I escape the backslashes by doubling the backslashes it works ok
address@hidden ~
$ ls d:\\Python24\\include
Numeric dictobject.h longintrepr.h py_curses.h stringobject.h
Python.h enumobject.h longobject.h pyconfig.h structmember.h
abstract.h errcode.h marshal.h pydebug.h structseq.h
bitset.h eval.h metagrammar.h pyerrors.h symtable.h
boolobject.h fileobject.h methodobject.h pyfpe.h sysmodule.h
bufferobject.h floatobject.h modsupport.h pygetopt.h timefuncs.h
cStringIO.h frameobject.h moduleobject.h pymactoolbox.h token.h
cellobject.h funcobject.h node.h pymem.h traceback.h
ceval.h genobject.h object.h pyport.h tupleobject.h
classobject.h graminit.h objimpl.h pystate.h ucnhash.h
cobject.h grammar.h opcode.h pystrtod.h unicodeobject.h
codecs.h import.h osdefs.h pythonrun.h weakrefobject.h
compile.h intobject.h parsetok.h pythread.h
complexobject.h intrcheck.h patchlevel.h rangeobject.h
datetime.h iterobject.h pgen.h setobject.h
descrobject.h listobject.h pgenheaders.h sliceobject.h
But if you put this in a m4 macro variable you have to escape every backslash
again
The more easy solution is to use the special mingw way of accessing windows
drives which is
/driveletter/path/name/using/forwardslashes
in this case
/d/Python24/include
address@hidden ~
$ ls /d/Python24/include
Numeric dictobject.h longintrepr.h py_curses.h stringobject.h
Python.h enumobject.h longobject.h pyconfig.h structmember.h
abstract.h errcode.h marshal.h pydebug.h structseq.h
bitset.h eval.h metagrammar.h pyerrors.h symtable.h
boolobject.h fileobject.h methodobject.h pyfpe.h sysmodule.h
bufferobject.h floatobject.h modsupport.h pygetopt.h timefuncs.h
cStringIO.h frameobject.h moduleobject.h pymactoolbox.h token.h
cellobject.h funcobject.h node.h pymem.h traceback.h
ceval.h genobject.h object.h pyport.h tupleobject.h
classobject.h graminit.h objimpl.h pystate.h ucnhash.h
cobject.h grammar.h opcode.h pystrtod.h unicodeobject.h
codecs.h import.h osdefs.h pythonrun.h weakrefobject.h
compile.h intobject.h parsetok.h pythread.h
complexobject.h intrcheck.h patchlevel.h rangeobject.h
datetime.h iterobject.h pgen.h setobject.h
descrobject.h listobject.h pgenheaders.h sliceobject.h
mingw also supports paths in the following format (just using forward slashes
with normal driveletter)
address@hidden ~
$ ls d:/Python24/include
Numeric dictobject.h longintrepr.h py_curses.h stringobject.h
Python.h enumobject.h longobject.h pyconfig.h structmember.h
abstract.h errcode.h marshal.h pydebug.h structseq.h
bitset.h eval.h metagrammar.h pyerrors.h symtable.h
boolobject.h fileobject.h methodobject.h pyfpe.h sysmodule.h
bufferobject.h floatobject.h modsupport.h pygetopt.h timefuncs.h
cStringIO.h frameobject.h moduleobject.h pymactoolbox.h token.h
cellobject.h funcobject.h node.h pymem.h traceback.h
ceval.h genobject.h object.h pyport.h tupleobject.h
classobject.h graminit.h objimpl.h pystate.h ucnhash.h
cobject.h grammar.h opcode.h pystrtod.h unicodeobject.h
codecs.h import.h osdefs.h pythonrun.h weakrefobject.h
compile.h intobject.h parsetok.h pythread.h
complexobject.h intrcheck.h patchlevel.h rangeobject.h
datetime.h iterobject.h pgen.h setobject.h
descrobject.h listobject.h pgenheaders.h sliceobject.h
This last format workes most of the time although libtool has a problem with
this format for dll absolute pathnames
I think the only way to get things right on windows/mingw is to make an
exeption for mingw
and parse the output of the command
distutils.sysconfig.get_python_inc(plat_specific=False)
and reformat it using sed into the /d/Python24/include format.
An alternative is to not support the binary distribution of python for windows
but requiring building python on mingw.
(In this case distutils.sysconfig.get_python_inc(plat_specific=False) should
return /d/Python24/include)
End users would then also need this mingw built version.
With any luck it's d:\Python24\include and my patch patch should work.
Well unluckily it is d:\Python24\include and your patch will not work, I am
sorry.
Greetings,
Martin