It could be the case that the default python is python 3.x, and we don't really test this, I think. Or the default python on the system is too old for our build system, but the default can't be changed for other reasons. We simply don't know the platform details of our clients, so being flexible is a worthwhile goal IMHO, especially if it's only such a comparatively trivial change, which doesn't really introduce any real complexity.
On Wed, Nov 21, 2012 at 1:17 PM, Jakob Kummerow <[email protected]>wrote: > > On Wed, Nov 21, 2012 at 11:15 AM, Sven Panne <[email protected]>wrote: > >> Probably something like update-alternatives is the cleaner way than doing >> any symlinking by hand, >> > > Of course. I was assuming that any sane package management system would > install a /usr/bin/python symlink or script or binary anyway... > > >> but the question is: Does the platform in question have something like >> that? >> > > ... and in the absence of that my suggestion is a hand-managed symlink. > > Anyway I think that providing the ability to specify all build tools >> explicitly if needed without any platform tweaks or PATH kung-fu is >> preferable. We do it for CXX etc., too (like in 'make CXX='blahblah' >> ia32'), and it is very handy for packagers, I think. >> > > The difference is that having several C++ compilers installed and choosing > one on a case-by-case basis depending on the desired results (e.g. cross > compile vs. native) is a common and valid use case. For script interpreters > where the exact interpreter being used doesn't (or at least shouldn't) > matter for the end result, I think it's perfectly reasonable to depend on > the commonly used default. > > That said, since this CL doesn't seem to break anything, I'm not strictly > opposed to landing it; however I don't see the added complexity justified > yet. > > >> >> >> On Wed, Nov 21, 2012 at 11:04 AM, <[email protected]> wrote: >> >>> How about this instead: >>> >>> sudo /usr/bin/python2.7 /usr/bin/python >>> >>> That fixes all your scripts/applications/**buildsystems at once, which >>> is an >>> approach that scales much better than adding complexity to 150 other >>> projects. >> >> -- >> v8-dev mailing list >> [email protected] >> http://groups.google.com/group/v8-dev >> > > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
