Greets,
I've been messing around with chaz_Core_probe_compiler_syntax(),
adding a loop to determine whether an executable in the current
working directory should be executed using "./dostuff" or ".
\dostuff". Now every possibility for three possible variables --
command_start, include_flag, and object_flag -- might be tested. The
problem I ran into was that /I -- the include directory command for
MSVC, is legal syntax in bash -- it says run the "I" app in the root
directory.
Right now, the test is pretty stringent -- it only succeeds if...
1) The source file gets written
2) The object file gets compiled (difficult)
3) The object file can be run
4) The object file, when run, produces the desired output
However, it's possible that a combination with incorrect syntax might
pass, kicking the error down to the modules. Having includes spec'd
with /I didn't stop the compilation from succeeding (because the
test .c file has no local #include directives, it's just a plain .c
file), and I only exercised that loop iteration because an inner loop
was failing completely.
I'm a little concerned that if we need to tweak that probe in the
future (e.g. when adding support for another compiler with odd
syntax) it may break in unpredictable ways. We may need to augment
those loops with some symbol detection, break them up if possible, or
just come up with a different approach.
The probe is currently flawed because it tests several things at once
and succeeds only when all of them succeed. It would be better if it
broken the problem down more effectively. That's not easy though.
The return value from system() is OS-specific and thus hard to
interpret, so some like this won't work:
if (system("./return_true"))
set_command_start("./");
else if (system(".\return_true"))
set_command_start(".\\");
else
die("Couldn't determine how to run a file in the current
directory");
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
