|
From: Hoyt, D. <ho...@ll...> - 2011-03-08 00:02:16
|
I have what may be a rather unique environment -- I'm using python and jhbuild from an msys prompt. Python, as a standard Windows executable, expects standard Windows paths (C:\blah). I'm extending jhbuild (which is python based) to try and understand msys paths since it automatically launches configure and make scripts. I was wondering what a good way to test for msys' existence is so I can do a basic path translation. e.g. jhbuild has a "sanitycheck" operation which launches "aclocal-1.8 --print-ac-dir" which prints an msys path (/mingw/share/aclocal), which is to be expected. jhbuild sees that and tries, of course, to determine if the directory does indeed exist and that certain m4 scripts are present. It fails this check, so I'm augmenting it by first checking to see if we're in an msys environment. To do that, I look for the existence of "msysinfo" in the PATH. If it's there, I assume we're in an msys env. My main question is if there's a better way of doing that (I realize there's all sorts of potential pitfalls with the approach I took -- it's simply "good enough" for now). After I've determined that we're running in an msys env., I do a path translation via launching a process from the python script to get the actual path (sh "cd /mingw/share/aclocal && pwd -W"). My next question is if that's a decent enough way to get the normal Windows path from an msys path or if there's a better/easier way to do it. Really the fact that I'm using python is irrelevant -- it comes down to: How do I easily determine from an arbitrary executable that it's being executed in an msys env.? (e.g. check an env. var.? look for standard msys executables in the PATH?) How do I translate an msys-style path into a standard Windows path from an executable that is not linked to the msys dll? (e.g. launch a program that does link to the msys dll and can do the translation?) Thanks so much for any advice/suggestions/wisdom that you can impart. |