numpy C headers installs

[Ralf Stephan]

Hello,

can you please tell me if it's expected that setup.py installs C headers of numpy

into the python tree associated with the current running python instead

of something under $SAGE_LOCAL/, e.g. include?

If yes then this leads to failure to include numpy C headers when compiling

in unsafe patchbot runs (which clone into /tmp). The cython files have

"cimport numpy" which generates '#include "numpy/...h" ' but this is not found.

Regards,

[Francois Bissey]

Hi,

this is the expected behaviour. At compilation time you should have extra CPPFLAGS
pointing to the right folder. Can you provide detail of the failed compilation?

Francois

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.


This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.

[Ralf Stephan]

It's the first compile that includes numpy headers, i.e. the header

"numpy/ndarrayobject.h". The output is

gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/tmp/tmpr

P11xO-sage-git-temp-15178/local/lib/python/site-packages/numpy/core/include -I/

tmp/tmprP11xO-sage-git-temp-15178/local/include -I/tmp/tmprP11xO-sage-git-temp-

15178/local/include/csage -I/tmp/tmprP11xO-sage-git-temp-15178/src -I/tmp/tmprP

11xO-sage-git-temp-15178/src/sage/ext -I/home/ralf/sage/local/include/python2.7

 -c sage/calculus/riemann.c -o build/temp.linux-x86_64-2.7/sage/calculus/rieman

n.o -fno-strict-aliasing -w

sage/calculus/riemann.c:348:31: fatal error: numpy/arrayobject.h: No such file 

or directory

--
You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/1dpr0__-ssw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.

[Francois Bissey]

This is quite ugly. I notice an unhealthy mix. You’ll notice:
-I/tmp/tmprP11xO-sage-git-temp-15178/local/lib/python/site-packages/numpy/core/include

which should enable you to find the header, but were does
-I/home/ralf/sage/local/include/python2.7
come from?

Francois

[Ralf Stephan]

On Monday, May 19, 2014 12:22:01 PM UTC+2, François wrote:

This is quite ugly. I notice an unhealthy mix. You’ll notice:
 -I/tmp/tmprP11xO-sage-git-temp-15178/local/lib/python/site-packages/numpy/core/include

which should enable you to find the header, but were does
-I/home/ralf/sage/local/include/python2.7
come from? 

Before I try to answer this question, I'd rather want to know why the paths all

point to /tmp/xyz (which is SAGE_ROOT) instead of /home/ralf/sage (where

python lives and python packages were installed) which

is where the header files actually are---and which is to be expected, as you

say in your first answer.

[Ralf Stephan]

Maybe this question is clearer:   in an install that is started from

directory A/sage by cloning into B and 'make', do you expect the python

SPKG to be installed into A/B and which instance of python should then

run 'setup.py' when installing numpy?

[Volker Braun]

Not sure if I understand, but "git clone /path/to/A B" would create B as a completely independent source tree.

[Ralf Stephan]

​

On Mon, May 19, 2014 at 4:25 PM, Volker Braun <vbrau...@gmail.com> wrote:

Not sure if I understand, but "git clone /path/to/A B" would create B as a completely independent source tree.

...which installs back python and its packages into A. And for me as python newb this

doesn't look right. But what do I know?

[Ralf Stephan]

I *think* what happens is that 'make' gets called as subprocess from patchbot (the A python),

and the call inside spkg-install (of B spkgs) somehow gets it wrong and installs the packages

into A. logs can be found at

https://github.com/robertwb/sage-patchbot/issues/35

[Volker Braun]

That makes more sense, if you call from within A's sage-env the makefile of B then you'll have a bunch of environment variables set pointing to A.

[Ralf Stephan]

Is there a way to get the original env *before A/sage clobbers it? Maybe it's backupped

somewhere? Would that help?

[Ralf Stephan]

Please review:

http://trac.sagemath.org/ticket/16377

[leif]

Ralf Stephan wrote:
> Is there a way to get the original env *before A/sage clobbers it? Maybe
> it's backupped
> somewhere? Would that help?

man exec() / execve() ? ;-)


-leif

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[Ralf Stephan]

man exec() / execve() ? ;-)

​That's C but when we get to python's os.environ its already too late.​