Community
Participate
Working Groups
Four input prompts appear whenever the Variables properties page for a XLC project is accessed. This behaves differently from other CDT projects. To reproduce, create a XLC executable project and access its Variables properties page.
*** Bug 235700 has been marked as a duplicate of this bug. ***
*** Bug 235666 has been marked as a duplicate of this bug. ***
Hi Kong, I have a problem to reproduce this bug. As I choose the XLC executable project in the wizard, the button of "Finish" is disabled and so that I could not create a project of this kind. Could you offer me some info about that? Thank you, Yi
Hi, I found the problem of this bug. In method “checkIntegrity()” of the class org.eclipse.cdt.utils.cdtvariables.CdtVariableResolver, it would get all the macros using SupplierBasedCdtVariableManager.getVariables(). But different with other kinds of projects, the macros returned of XLC executable project have wrappers that wrap them. The wrapper is BuildMacroProvider.VariableWrapper. And In the mothod checkVariableIntegrity() of the class org.eclipse.cdt.internal.core.cdtvariables.CdtVariableManager, the method resolveMacro() is override. And when the macro is an instance of EclipseVariablesVariableSupplier.EclipseVarMacro, it will return a new instance of ResolveMacro, otherwise it will call super.resolveMacro(macro). The problem of this bug is, when the macro is string_prompt, folder_prompt, file_prompt or password_prompt (they are instance of EclipseVariablesVariableSupplier.EclipseVarMacro), it would call super.resolveMacro(macro), because the real type of the macro is BuildMacroProvider.VariableWrapper. That is wrong logically. It should return a new instance of ResolveMacro. But actually it calls super.resolveMacro(macro) and a prompt will jump out to get the stringValue of the macro. The code is shown below: protected ResolvedMacro resolveMacro(ICdtVariable macro) throws CdtVariableException { if(macro instanceof EclipseVariablesVariableSupplier.EclipseVarMacro) return new ResolvedMacro(macro.getName(),""); //$NON-NLS-1$ return super.resolveMacro(macro); } Since the BuildMacroProvider.VariableWrapper is a private inner class of package org.eclipse.cdt.managedbuilder.internal.macros, we could not access it. So I have no idea of correcting this bug right now. Thanks, Yi
(In reply to comment #4) Thanks for your investigation Yi. That's how far I got in my own investigation as well. My questions right now are... Why does the build macro get wrapped in BuildMacroProvider.getMacro()? And is there a documentation that describes the new project model as a whole?
(In reply to comment #5) > (In reply to comment #4) > Thanks for your investigation Yi. That's how far I got in my own investigation > as well. > > My questions right now are... > > Why does the build macro get wrapped in BuildMacroProvider.getMacro()? And is > there a documentation that describes the new project model as a whole? > For the first question, I think, it might have something related with the XLCProjectMacroSupplier or other class only for XLC project. But the codes of this kind of classes could not be seen. I think it is special for XLC project. For the second question, it's a shame, we do not have such docs. There are only some rough docs describing some parts of the model of CDT. I don't know whether you have them. If you haven't, I could attach them to the bug. But in fact I think they have no idea with this bug. However, I still would try to find a way to modify this bug. Thanks, Yi
