On 28Oct2012 18:24, Vinay Sajip 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 Nothing is impossible for the man who doesn't have to do it.