Bugzilla – Full Text Bug Listing
| Summary: | Remote Build with GNU toolchain doesn't work | ||
|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Roland Schulz <roland> |
| Component: | RDT | Assignee: | Project Inbox <ptp-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | genly, recoskie, timothydossett |
| Version: | 4.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
Although that code in CDT ought to have a null check to prevent the NPE from happening, the real underlying problem here is that thre is no remote GNU toolchain that uses a functioning remote mechanism for scanner discovery. (In reply to comment #1) > Although that code in CDT ought to have a null check to prevent the NPE from > happening, the real underlying problem here is that thre is no remote GNU > toolchain that uses a functioning remote mechanism for scanner discovery. What does that mean? Is GNU toolchain for remote build not supported at all at the moment? Or is it possible to build without the scanner or some other configuration change? If it is not supported we should remove it from the Wizard so that the user can't select it. And adding it should be made a high priority enhancement. I assume that the GNU toolchain is one of the most commonly used. (In reply to comment #2) > (In reply to comment #1) > > Although that code in CDT ought to have a null check to prevent the NPE from > > happening, the real underlying problem here is that thre is no remote GNU > > toolchain that uses a functioning remote mechanism for scanner discovery. > > What does that mean? Is GNU toolchain for remote build not supported at all at > the moment? Or is it possible to build without the scanner or some other > configuration change? > > If it is not supported we should remove it from the Wizard so that the user > can't select it. > > And adding it should be made a high priority enhancement. I assume that the GNU > toolchain is one of the most commonly used. By deactivating "Automate discovery of paths and symbols" it is possible for me to build. Do I understand it correctly that this has to be deactivated at the moment for the GNU toolchain to work? Or should one use a different toolchain at the moment even when using a GNU compiler? If it is correct that it has to be deactivated at the moment, than we should deactivate it by default to not confuse users. And deactivate disable the box in the project properties so that the user can't activate it. What is the reason that the discovery doesn't work remote? Is their already a bug report opened to address that issue? (In reply to comment #3) > By deactivating "Automate discovery of paths and symbols" it is possible for me > to build. Do I understand it correctly that this has to be deactivated at the > moment for the GNU toolchain to work? Or should one use a different toolchain > at the moment even when using a GNU compiler? If you're using the GNU compiler then currently your best option is to use the existing GNU toolchain and turn off scanner discovery. There are a few other things that won't work right with it as well, such as the environment variables shown in the build settings will be from your local machine instead of the remote machine. > If it is correct that it has to be deactivated at the moment, than we should > deactivate it by default to not confuse users. And deactivate disable the box > in the project properties so that the user can't activate it. > What is the reason that the discovery doesn't work remote? Is their already a > bug report opened to address that issue? The existing discovery provider from CDT was not written with remote development in mind. It creates some empty .c and .cpp files in the workspace metadata directory, then invokes a hidden compile on them with certain compiler flags enabled, in order to parse the output and determine the built-in macros and include paths. The remote version we created instead creates these files on the remote machine in ~/.eclipse, and uses the remote builder to invoke the compiler. The tricky part about creating a remote GNU toolchain will be that the local one wasn't really architected with re-use in mind, and especially not for remote development. Unfortuantely, to get scanner discovery to work fully, you have to associate a discovery profile ID to your compiler's input types, and the existing toolchain already has input types that map to the local scanner discovery profile. With the IBM toolchains, we had the luxury of being able to rearchitect them so that local input types wouldn't carry over to the remote toolchain, so we could then specify the remote scanner discovery profile IDs instead. Unfortunately the upshot of all this is that to make a remote GNU toolchain, we'll have to do a lot of cut and pasting from CDT. As far as disabling the UI, it's needed for those toolchains that do have funcioning scanner discovery mechanisms, so I don't support disabling it without there being some better mechanism to determine which toolchains are remote and which ones aren't. Otherwise we have no real way to know for which toolchains to enable or disable the UI. Can you provide a brief summary of what would need to be implemented to get this to work? IMHO this is a significant shortcoming in RDT , since most users are likely to require GNU toolchain support. *** Bug 328959 has been marked as a duplicate of this bug. *** (In reply to comment #5) > Can you provide a brief summary of what would need to be implemented to get > this to work? IMHO this is a significant shortcoming in RDT , since most users > are likely to require GNU toolchain support. What needs to happen is the following: 1. create a remote GNU toolchain 2. use RemoteConfigurationEnvironmentSupplier in this toolchain so that environment variables come from the remote system 3. create a new remote-enabled scanner discovery profile that is EFS aware and scans GNU compiler output. Couple this with the RemoteRunSpecsRunSIProvider to make scanner discovery work for GNU 4. make new input types in this toolchain (e.g. "Remote C/C++ Sources") that hook up to the new scanner discovery profile to the remote toolchain created in #1 It is looking like we will be working on this for Indigo. *** Bug 333673 has been marked as a duplicate of this bug. *** Roland, I'm closing this as worksforme as I can create a remote GNU C/C++ project. Please reopen if you still have the problem. |
I created a remote project with RemoteTools and RC4 build and get a NPE. The same error occurs when running eclipse from the workbench. The folder I used included 2 C-files and a Makefile. I used the Gnu-C Remote Makefile project. The make does not work. In the log I get: java.lang.NullPointerException at org.eclipse.cdt.make.internal.core.scannerconfig.gnu.GCCPerFileBOPConsoleParser.processCommand(GCCPerFileBOPConsoleParser.java:124) at org.eclipse.cdt.make.internal.core.scannerconfig.gnu.AbstractGCCBOPConsoleParser.processSingleLine(AbstractGCCBOPConsoleParser.java:300) at org.eclipse.cdt.make.internal.core.scannerconfig.gnu.AbstractGCCBOPConsoleParser.processLine(AbstractGCCBOPConsoleParser.java:141) at org.eclipse.cdt.internal.core.ConsoleOutputSniffer.processLine(ConsoleOutputSniffer.java:181) at org.eclipse.cdt.internal.core.ConsoleOutputSniffer.access$0(ConsoleOutputSniffer.java:179) at org.eclipse.cdt.internal.core.ConsoleOutputSniffer$ConsoleOutputStream.checkLine(ConsoleOutputSniffer.java:109) at org.eclipse.cdt.internal.core.ConsoleOutputSniffer$ConsoleOutputStream.close(ConsoleOutputSniffer.java:77) at org.eclipse.ptp.rdt.core.remotemake.RemoteMakeBuilder.invokeMake(RemoteMakeBuilder.java:426) at org.eclipse.cdt.make.core.MakeBuilder.build(MakeBuilder.java:98) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343) at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:344) at org.eclipse.ui.actions.GlobalBuildAction$1.run(GlobalBuildAction.java:179) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)