[cdt-dev] Possible bug in ManagedBuildGnuToolInfo.calculateOutputs

[Raphael Zulliger <zulliger@xxxxxxxx>]

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