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
