On 28Oct2012 18:24, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
| In some scenarios, configure produces a Makefile which fails because ASDLGEN
| doesn't point to a working Python. In particular, it seems to assume that if
| there is an executable called e.g. "python3.4" on the path, then that will be
a
| system Python.
Or at least a valid python. Given that python installs create a pythonA.B
executable/symlink I would call that a reasonable assumption.
If I invoke the command "python2.7", I expect to get a python 2.7.x
instance. Indeed, I have scripts that expect that (eg my py26+ script
which looks for a sufficiently new python for particular tasks).
| In my perhaps unusual but IMO perfectly valid setup, I have various Python
repos
| set up like so:
|
| $HOME/projects/python
| |
| +- default
| |
| +- 3.3
| |
| + and so on for 3.2, 3.1, 2.7
That's sane.
| In order to facilitate testing some script against multiple Python versions, I
| have shell scripts in $HOME/bin named python3.4, python3.3 etc. which just run
| the programs in the relevant directories in $HOME/projects/python/. (I know I
| can do this using aliases etc., but I think that's beside the point.)
That is not sane. And aliases aren't quite beside the point, though
nearly so. At least aliases aren't used by shell scripts on the whole,
which executables in the $PATH are.
A python install includes a pythonA.B executable. You're providing
"pythonA.B" which is _not_ a python executable!
If you had a shell script in your ~/bin called "ls" that ran "rm", would
you consider it sensible? I wouldn't.
I'm sure you're well aware of the newbie UNIX mistake of calling a test
script "test", too:-) Same issue, really.
| When I run configure in the repo for the default branch, it appears to look
for
| a Python on the path named python3.4, finds one in $HOME/bin, and thus
generates
| an ASDLGEN value of "python3.4". If I happen to have a built Python in the
| default repo, then the script in $HOME/bin will successfully run that, and all
| appears well; but if I clean the default repo and re-run make, it fails at the
| ASDLGEN step, because the $HOME/bin/python3.4 script fails, due to not being
| able to invoke $HOME/projects/python/default/python.
|
| Is this a bug in configure, or is my configuration regarded as too perverse to
| support?
I agree with Antoine; it is slightly perverse. But entirely because of the
executable names you've chosen.
When I run configure I take care to _trash_ my $PATH. Well, to make it
more conventional. Configure relies heavily on $PATH (and a host of
other ill-documented variables, like $ARCH or $CPU, I forget now; I have
wrapper scripts to toss tis stuff and hand me a fresh shell for exactly
this issue).
I have long found it useful to craft my environment before using
configure. Specificly, the $PATH _must_ find the expected executable
names appropriately. I your case it will not.
I would have test scripts do something of this flavour:
PATH={your-test-area-here}/bin:/usr/bin:/bin:/usr/local/bin
export PATH
to ensure that configure finds what it expects.
I would also rename your ~/bin/python3.4 et al scripts to something more
descriptive; I have over the past several years been naming my own
scripts progressively more verbosely. Maybe "test-python-3.4" and so
forth. And make some convenience aliases (_not_ conflicting with
"standard" names like "python3.4", maybe "testpy34" or something equally
short). And having made those convenience aliases, possibly even move
the test wrapper scripts our of my ~/bin depending on how widely that
get used by other higher level scripts.
Hoping this is more helpful than I've probably made it sound,
--
Cameron Simpson <c...@zip.com.au>
Nothing is impossible for the man who doesn't have to do it.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
