[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Suggested change to String option command generation.
|
Hi
Sean,
I
agree that a numeric input option type would be useful, but I don't think it
will handle all of the cases. Here are some other types of options that
take a string:
1. Options like -o (that is currently handled specially) that take
a file specification (could be handled with a specific option type
also...)
2. Options like -I (that is currently handled specially) that take
a directory specification (could be handled with a specific option type
also...)
3. Options that take a list of options to pass to a "sub-tool" -
for example, options for a compiler driver to pass to a
preprocessor.
4. Options that take any string - for example Intel Fortran has a
-bintext:text option that places the specified string into the object
file. This can be used for things like version numbers, copyrights,
whatever...
I
agree with your analysis that a method of validating string input would be very
useful. I would also agree that it is not required for the 2.0
release.
Regards,
Leo
Thanks Leo,
That's a very interesting suggestion, but I am not sure it completely
solves your problem. Here is my thinking on this point.
The problem with string options is that they can
contain anything. Based on your suggestion, the user could type anything in
that field and we would put -unroll<user_input> on the command line.
Despite your fix, we still would not check the user input to see that it is a
number.
The meta-problem is that
there are other types of options that we did not consider in our initial set
of types. In your example, you have a numeric argument and no way to enter it.
We could address that oversight by creating an option type that accepts
numeric inputs (maybe with a thumbwheel control). At least in this case, we
can control the correctness of the user inputs. Alternatively, perhaps what we
need is specialized string option that parses the values it contains for
correctness.
It would relatively
easy to add a new option type that accepts numbers. This would eliminate any
issues surrounding up-versioning older project descriptions.
A "string option with parser"
would require a new, optional field in the schema that could specify a parser
class. That's more work than I have time for, and there would be implications
on how the parser would interact with the UI. As the user types makes the most
sense, but that would mean we would have to intercept each keystroke event and
parse the input. It would also mean we would need a way to tell the user when
there is an error.
Let me know
what you think about these alternatives.
Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario,
Canada
"Treggiari, Leo"
<leo.treggiari@xxxxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx
03/03/2004 11:32 AM
|
|
To
| <cdt-dev@xxxxxxxxxxx>
|
|
cc
| "Treggiari, Leo"
<leo.treggiari@xxxxxxxxx>
|
|
Subject
| [cdt-dev] Suggested
change to String option command
generation. |
|
I'd like to suggest a change to how String options generate their
tool command line contribution. Currently, the build model ignores what it
finds in the command attribute. This is fine for the current use of
String options - that is, to collect "additional options" where the user
enters a full command or commands. See the Cygwin Executable "Other
optimization flags" and "Other debugging flags" as examples.
I also
want to use String options for other individual "options that cannot be easily
specified using lists or enumerations", as the managed build design spec says.
For example, Intel C++ has a "Loop Unroll Count" optimization. The
command line syntax is -unrolln. I want to be able to define a "Loop
Unroll Count" property and have the user enter the value of n. To do
that, I would like to define a String option where the command is "-unroll",
and the value is whatever is entered by the user into the text
field.
The proposal is that the build model does NOT ignore what it
finds in the command attribute. Instead, if the defaultValue attribute
is present, and contains a string of length > 0, then the command string
(if any) is prepended to the defaultValue string to form the command line
string.
The change is mostly upward compatible as the current
uses of String options in the CDT "reference" tool chains do not need to be
changed because the command attribute is not specified. Therefore
whether the command is ignored, or not, makes no difference.
The change
to the code is small and I have included proposed patches
below.
Regards,
Leo Treggiari
Intel Corp.
Index:
Tool.java
===================================================================
retrieving
revision 1.7
diff -u -r1.7 Tool.java
--- Tool.java
2 Mar 2004 16:35:03 -0000
1.7
+++ Tool.java
3 Mar 2004 16:00:52 -0000
@@
-216,8 +216,11 @@
break;
case IOption.STRING :
+
String strCmd =
option.getCommand();
String val = option.getStringValue();
if (val.length() >
0) {
+
if (strCmd !=
null)
+
buf.append(strCmd);
buf.append(val + WHITE_SPACE);
}
break;
Index:
ToolReference.java
===================================================================
retrieving
revision 1.6
diff -u -r1.6 ToolReference.java
--- ToolReference.java
2 Mar 2004 15:26:50
-0000 1.6
+++
ToolReference.java 3
Mar 2004 16:01:24 -0000
@@ -182,8 +182,11 @@
break;
case
IOption.STRING :
+
String strCmd = option.getCommand();
String val =
option.getStringValue();
if (val.length() > 0) {
+
if (strCmd != null)
+
buf.append(strCmd);
buf.append(val + WHITE_SPACE);
}
break;
_______________________________________________
cdt-dev
mailing
list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
