Bugzilla – Full Text Bug Listing
| Summary: | Compiler Arguments are stored differently in the internal Map | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Martin Schreiber <Martin.SCHREIBER> |
| Component: | Tycho | Assignee: | Project Inbox <tycho-inbox> |
| Status: | CLOSED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, jan.sievers |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 460487, 461651 | ||
(In reply to Martin Schreiber from comment #0) > 2) The new way with one arg: > <compilerArgs> > <arg>-log mylog.xml</arg> > </compilerArgs> this is not how compilerArgs is supposed to be used. One argument at a time. if you have spaces inside one arg, it will be quoted and treated as one argument (In reply to Jan Sievers from comment #1) > (In reply to Martin Schreiber from comment #0) > > 2) The new way with one arg: > > <compilerArgs> > > <arg>-log mylog.xml</arg> > > </compilerArgs> > > > this is not how compilerArgs is supposed to be used. > > One argument at a time. if you have spaces inside one arg, it will be quoted > and treated as one argument I see, in that case this bug does not make sense (In reply to Martin Schreiber from comment #0) > The code [1] should be cleaned up, so that for case 1) and 2) we can call > compilerConfiguration.getCustomCompilerArgumentsAsMap().get("-log") and get > the value of the argument (key=-log; value=mylog.xml). I think case 3) > doesn't make sense - although it gets passed correctly to the compiler. case 3 is the correct way. case 1 also works but is deprecated because it has severe limitations in terms of argument syntax, see bug 400307 as to the internal representation of arguments, IIRC either you have a key with a non-null value -> case 1, or you have a key with null value -> case 3 I'll just add that, in the abstract, it's not just spaces, that "mess things up" ... but, occasionally, in Ant, or Bash itself, I've had argument values that contained special characters such as a quote character, or apostrophe, or, even other variables, such as "${subdir}" (which itself might have spaces or quotes, etc.), and these all get handled well (in Ant, or Bash) without any special knowledge of "how stored" or "how escaped" internally.
So, for myself, I was glad to learn about "case 3"!
|
If you want to configure the compiler log file, there are 3 valid cases to configure such an argument (valid in the sense of working): 1) The deprecated way: <compilerArguments> <log>mylog.xml</log> </compilerArguments> 2) The new way with one arg: <compilerArgs> <arg>-log mylog.xml</arg> </compilerArgs> 3) The new way with 2 args: <compilerArgs> <arg>-log</arg> <arg>mylog.xml</arg> </compilerArgs> The arguments are stored in a LinkedHashMap[1]. The pain is, that for the 3 cases, the maps look different: For 1): key=-log; value=mylog.xml For 2): key=-log mylog.xml; value=null For 3): key=-log; value=null key=mylog.xml; value=null With this different values in the Map it is quite hard to get the value for "-log" out of the map (especially case 3). The code [1] should be cleaned up, so that for case 1) and 2) we can call compilerConfiguration.getCustomCompilerArgumentsAsMap().get("-log") and get the value of the argument (key=-log; value=mylog.xml). I think case 3) doesn't make sense - although it gets passed correctly to the compiler. [1] https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-compiler-plugin/src/main/java/copied/org/apache/maven/plugin/AbstractCompilerMojo.java#n458