[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[cdt-dev] Possible bug in ManagedBuildGnuToolInfo.calculateOutputs
|
Hi
While searching a problem in my own plug-in code (which is heavily using
CDT), I stumbled over code that doesn't make sense to me. As it could be
a bug, I decided to write my founding to the list.
In ManagedBuildGnuToolInfo.calculateOutputs:
...
// Calculate the output name
// The inputs must have been calculated before
we can do this
...
// Replace the % with the file name
if (primaryOutput) {
myCommandOutputs.add(namePattern.replaceAll("%", fileName)); //$NON-NLS-1$
}
typeEnumeratedOutputs.add(namePattern.replaceAll("%", fileName));
//$NON-NLS-1$
if (variable.length() > 0) {
List<IPath> outputs = new
ArrayList<IPath>();
outputs.add(Path.fromOSString(fileName));
if
(myOutputMacros.containsKey(variable)) { // !!! May this be a bug? !!!
List<IPath> currList =
myOutputMacros.get(variable);
currList.addAll(outputs);
myOutputMacros.put(variable, currList);
} else {
myOutputMacros.put(variable, outputs);
}
}
}
In case of a tool that represents a "C++ Compiler", the variable named
'variable' typically contains the value "OBJS" and the filenames of the
compilers output will typically have file extension ".o". In the
situation I have been debugging, 'namePattern' was "%.o" and 'fileName'
was "test" (originating from a file named "test.cpp"). These values make
absolutely sense to me. Therefore, 'myCommandOutputs' and
'typeEnumeratedOutputs' both were added the value "test.o" which, again,
makes sense to me.
What does *not* make sense to me is that "test" (instead of "test.o")
will later be added to 'outputs'. About 5 lines after, this causes that
the map entry "OBJS" of 'GnuMakefileGenerator.buildOutVars' will be
extended by "test" as well (where I would have expected "test.o"). Sure,
I haven't completely understood all use cases of 'buildOutVars' and its
content, but does this behavior really make sense?
Note: I'm not aware that this "anomaly" causes any real-world problems.
Best regards,
Raphael