Community
Participate
Working Groups
Build ID: I20070625-1500 Steps To Reproduce: 1. Create a plugin that uses the CDT's managed builder extensions with a configuration/toolchain hierarchy 2. In one of your base-class toolchains "forget" to assign a builder. 3. Create a project with your new toolchain/builder configuration. 4. Try to access the build properties of said project. More information: The error I get everytime is: !ENTRY org.eclipse.jface 4 2 2007-07-21 01:14:16.468 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface". !STACK 0 java.lang.NullPointerException at org.eclipse.cdt.managedbuilder.internal.core.Configuration.getBuilderForInternalBuilderEnablement(Configuration.java:2061) at org.eclipse.cdt.managedbuilder.internal.core.Configuration.canEnableInternalBuilder(Configuration.java:2036) at org.eclipse.cdt.managedbuilder.ui.properties.BuilderSettingsTab.updateButtons(BuilderSettingsTab.java:136) at org.eclipse.cdt.managedbuilder.ui.properties.BuilderSettingsTab.updateData(BuilderSettingsTab.java:275) at org.eclipse.cdt.ui.newui.AbstractCPropertyTab.setVisible(AbstractCPropertyTab.java:198) at org.eclipse.cdt.managedbuilder.ui.properties.BuilderSettingsTab.setVisible(BuilderSettingsTab.java:334) at org.eclipse.cdt.ui.newui.AbstractCPropertyTab.handleTabEvent(AbstractCPropertyTab.java:507)
Created attachment 74289 [details] Simple proposed solution Attached is my proposed fix for this bug. This is my first bug report, so please let me know if I've done something wrong. -Patrick
Actually the builder is a required element currently. How would the Build System decide which builder to use if there is no one specified? So the problem you are seeing is caused by the buggy tool-chain definition. Basically we could allow tool-chain definitions to NOT specify the builder. In this case the "default" builder could be chosen automatically. This could be the "Internal Builder" for "managed" projects and "make" builder for "makefile" projects. I'll update the bug summary to mostly reflect the problem as I'm seeing it and will mark the bug as "enhancement". Thanks, Mikhail
(In reply to comment #2) Mikhail, thanks very much for your reply. Please forgive me for digging a bit deeper into this. It does seem to me to be a bug when I get an ugly NullPointer exception. I realize that toolchains are meant to have builders associated with them. I also appreciate your willingness to amend that requirement, that is an excellent long-term solution to this "problem" (if it can be called that). What I was looking for though was more of a way for the CDT to protect itself from users who do not know/remember to put one in. Should their projects throw a NullPointerException, or should the CDT degrade nicely. The patch I submitted is just simply a null pointer check that should arguably be there already. To your question "How would the Build System decide which builder to use if there is no one specified?" I would agree that would be a real issue if the toolchain in question here weren't an abstract base class one. An abstract toolchain, at least, should be especially relieved of these requirements as it is guaranteed it will never be instantiated. Just some things to consider, Thanks again for your reply, -Patrick
Sorry, didn't mean to switch severity back to normal -- I'll let you do that if you see fit. -Patrick
