On 2008-12-12, at 06:47EST, Donald Anderson wrote:
cm/CompilationManager.java has in getInfoXML() a set of lines:
boolean isDebug = "true".equals(props.getProperty("debug"));
boolean isProfile =
"true".equals(props.getProperty("profile"));
boolean isBacktrace =
"true".equals(props.getProperty("backtrace"));
String lfc = LPS.getLFCname( runtime, isDebug, isProfile,
isBacktrace);
While CompilationEnvironment agrees with the names for "debug" and
"profile",
it lists BACKTRACE_PROPERTY as "debugBacktrace". Furthermore,
servlets/responders/ResponderCompile.java is looking for
"lzbacktrace".
I take this to mean that that "debugBacktrace" is used as the
internal name in CompilationEnvironment,
and is also the property to set with lzc if you want this. Whereas
"lzbacktrace" is used in URL arguments.
But the props in getInfoXML() come from ResponderAPP_CONSOLE and
ResponderINFO_XML,
so I would think this would also need to be "lzbacktrace" and not
merely "backtrace"?
Is there another option namespace out there?
Your guess is as good as mine here. That there are too many ways and
too many paths to discover the compile options is a long-standing
issue. We have slowly reduced the number of paths as the number of
options has grown, but not always successfully.
Historically, the URL options started out as simple names like `debug`
and `profile`, but we realized that polluted the query-args namespace,
so more recent additions are prefixed with `lz` (and there is http://jira.openlaszlo.org/jira/browse/LPP-3479)
. These query args are translated into internal properties, which are
defined in CompilationEnvironment.java, but also note the TODO on line
448 of sc/Compiler.java, where many of these names a duplicated only
because the guy writing this code did not know how to share the
constants table (using some whacky define the shared constants on an
interface and then declare an implementation to get at them trick that
he later discovered). The command-line interface used normal command
flags which it translates into the internal environment names, but
also has the escape hatch of you being able to use -D and the internal
name (if you can figure out what the internal name is -- obviously
this is not meant to be a public interface).
As to the getInfoXML mystery, that just plain looks broken. Why it is
querying props with strings rather than the constant prop names seems
bogus. Luckily nothing really uses the output of that... or so it
would appear. The app_console responder is presumably providing the
xml so that xslt can customize the wrapper based on what options were
called for, but I bet it doesn't do anything special with
backtracing. The info_xlm responder is only for human consumption, so
it could be wrong and no one notice; but, it sure would be a lot
better if it were correct; in particular, if it told you the LFC
flavor that was being used accurately. (I had to look at the Firebug
net pane to figure out which LFC was actually being loaded.)
