Community
Participate
Working Groups
We have the current build output parser command pattern failing for a very standard use case. i.e. currently it is: (gcc)|([gc]\+\+)|(clang) which will then fail to trigger discovery for makefile projects when the underlying system calls on /usr/bin/c++ instead of just c++. To workaround, we update this pattern to: (.*gcc)|(.*[gc]\+\+)|(.*clang) Despite it working, I'm not sure that the .* pattern is the right solution as it may easily trigger on incorrect patterns. At this point, we then run into a second problem - there is no easy way to export this setting. Most other settings in eclipse can be easily exported and imported via the File->Import/Export->General->Preferences interface and so we use this whenever we generate a new workspace. However every workspace we generate has to have this single parameter hand modified before eclipse cdt becomes usable for us. It would be great if 1. a more usable command pattern that could detect /usr/bin/c++ and others was the default. 2. Language Settings Provider Options were exported via the general eclipse preferences mechanism. This also applies to the Building-in Compiler Settings pattern where we often like to include -std=c++11. Last point, quite a few members of our team are turned off by the fact that such a straightforward use case doesn't work out of the box and requires constant working around. These guys are quite adaptable and used to beta software, but I can't really blame them when they shift to an alternative solution. Right now my only solution is to hack the plugins of cdt of each release (specifically the org.eclipse.cdt.managedbuilder.core plugin.xml) and provide them our own customised usable tarball of eclipse-cdt.
There is no export feature for this in UI but the settings are stored in file .metadata\.plugins\org.eclipse.cdt.core\language.settings.xml (or project.settings.xml). You can use this file when you generate your workspace.
unfortunately the file .metadata\.plugins\org.eclipse.cdt.core\language.settings.xml which seems to contain the global defaults from preferences|C/C++|Build|Settings|Discovery is completely ignored when creating a new project, this must be a separate bug in itself, there seems to be yet another hardcoded set of settings inside the CDT that cannot be influenced at all and that gets applied whenever a new project is created. I'm doing mainly cross compiling work for embedded (for example arm-none-eabi-gcc) and this default compiler command pattern is completely unusable. Currently I can identify the following problems which account for 95% of all my eclipse problems and make it very hard for me to argue in favour of Eclipse when something that should be so simple (check out an existing project from version control and just use it) just won't work because some essential settings get reset to unusable defaults without a warning. These are the problems: (1) the default pattern is not very useful, it should be changed to allow for more common scenarios, especially allow for cross compiler prefixes (2) there is no way to change the default settings of this property page at all, there seem to be some hardcoded defaults buried somewhere deep in the CDT code. (3) when checking out a perfectly well configured project from version control and importing it into the workspace it will silently reset the build output parser settings and replace them with the hardcoded settings from 2 which are unusable.
