Hello Glen,
Thank you very much for sharing your
experience with scanner discovery / built-in paths.
I share your views about the approaches to
scanner discovery. Some more comments on them according to my experience.
1.) The simplest case is taken care of by the
buildDefinitions/listOptionValue that Andrew mentions below where a tool has a
single static set of settings that can be defined once in plugin.xml. This
seems to work great and I assume that it satisfies users that fall into this
category.
Yes.
Unfortunately build macros in listOptionValues are not expanded, otherwise include
paths contribution would have been really easy.
2.) The most complex case is something like a per-file
scanner discovery profile which, as you’ve noted, seems to be heavily
biased towards GNU tools. Integrating non-GNU compatible tools requires a
significant amount of code and (in my experience at least) has proven to be
extremely brittle. Small changes in seemingly unrelated code almost always seem
to cause something subtle to break. The complexity of the current discovery
framework also makes unit testing quite hard so some of these subtle breakages
often go unnoticed until they get into a users hands.
3.) The middle ground is where I’m guessing quite a
few folks like you and I live. We have a particular set of tools for which
we’d like to dynamically add built-in settings at runtime. We know how to
get these settings from our tools, we simply need a straight forward way to
tell the build system about them. This use case is where I think we’re
falling a bit short. I really don’t need anything remotely
approaching the complexity of scanner discovery but at the same time the
simpler methods don’t quite let me do what I need to do.
I agree. A way to contribute include paths
and symbols is to reuse the PerProjectSICollector class together with an scannerInfoProvider,
which in turn invokes an IExternalScannerInfoProvider2 instance which actually
provides the paths and symbols. This has proven to be very fragile and break
due to small changes (e.g. source folders “forgetting” include
paths at project load time).
Some
thoughts I’ve had regarding ways we might fix this:
1.) I’ve heard that “fixing” scanner
discovery is one of the agenda items for Helios. I’m not entirely sure
what this means at this early stage but maybe this would be the time to try and
address some of these deficiencies?
I hope
so too, since I feel this is one of the most obscure tasks in integrating a
non-gcc compiler in Eclipse.
2.) Is there a reason why externalSettingsProvider
doesn’t allow a built-in flag? Is this something that we could simply
address? I’d be more than happy to take a swing at providing a
patch if I had a sense that there wasn’t some bigger picture reason why
it shouldn’t be done.
Other
than via externalSettingsProvider s , also programmatically creating e.g. CIncludePathEntry
instances with the BUILTIN flag set in an ICLanguageSettingEntry does not work.
3.) What about adding a way to programmatically add
listOptionValues to an IOption? We already have
IOption.getBasicStringListValueElements() that allows me to retrieve the list.
Could we perhaps add a method like
IOption.addBasicStringListValueElement(OptionStringValue value) that lets a
user programmatically modify the list? Again I’d be happy to open a bug
and supply a patch if there was some consensus that it’s a reasonable
thing to do.
Having a
method to add elements would be great. I tried to hack addition of built-ins by
relying on the fact that Option.getExactBuiltinsList() returns the original
list of builtins, which can be manipulated. This contributes the paths but does
not refresh the project in the UI. An addBasicStringListValue() in IOption which
refreshes the project appropriately would solve the situation.
/Mario
Anyway,
so my for my pontificating :) Just thought I’d let you know that we both
seem to have had much the same experiences with this particular topic.
Glen
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mario Pierro
Sent: Thursday, August 27, 2009
9:15 AM
To: CDT
General developers list.
Subject: RE: [cdt-dev]
externalSettingsProvider and built-in settings
An
update to this: I also tried to use my project listener to programmatically add
a CIncludePathEntry with the ICSettingEntry.BUILTIN flag, following the
guidelines found at the unofficial CDT FAQ
http://cdt-devel-faq.wikidot.com/
I am
able to add the path, but its BUILTIN flag is ignored.
This
discussion
http://www.nabble.com/Project-model:-More-questions-and-some-feedback-td9840195.html
seems to
hint that there is no way to modify the builtin settings programmatically! This
would also explain why the flags set by the externalSettingsProvider are
ignored when the values are actually stored in the project.
So, is
the scanner discovery the only viable option to dynamically modify include
paths/etc?
Thanks
again,
/Mario
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mario Pierro
Sent: den 26 augusti 2009 16:08
To: CDT
General developers list.
Subject: RE: [cdt-dev]
externalSettingsProvider and built-in settings
Hi
Andrew,
Thanks
for your suggestion.
Unfortunately
the information provided by the externalSettingsProvider is always dynamic so
it can’t be stored in the project or in the toolchain…
I also
tried to hack scannerDiscoveryProfile for the same purpose – which seems
to be tailored for gcc-like compilers. That almost works but I am getting weird
behavior in projects using source folders, so I’d rather go for the
externalSettingsProvider way which seems more robust and concise.
The only
thing I am missing is the built-in flags to be stored…
/Mario
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Gvozdev
Sent: den 26 augusti 2009 15:16
To: CDT
General developers list.
Subject: Re: [cdt-dev]
externalSettingsProvider and built-in settings
Hi Mario,
As an alternative, you could
use org.eclipse.cdt.managedbuilder.core.buildDefinitions extension point
which lets you define the paths and set builtin flag in listOptionValue.
On Wed, Aug 26, 2009 at
9:00 AM, Mario Pierro <Mario.Pierro@xxxxxxx>
wrote:
Hello,
I am trying to use the externalSettingsProvider extension point to add
include/library paths and predefined symbols programmatically to my
custom project type.
Following the instructions at
http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg15279.html
and
http://dev.eclipse.org/newslists/news.eclipse.tools.cdt/msg17432.html
I managed to successfully add an external settings provider which is
added to my projects via an ICProjectListener class.
However, flags in the ICSettingEntry instances contributed by the
external settings provider seem to be ignored.
For instance, I am doing the following
public CExternalSetting[] getSettings(IProject project,
ICConfigurationDescription cfg) {
// We provide the same settings for all
configurations
// Create include path entries for all the
contributed paths
List<ICSettingEntry> includeSettings = new
ArrayList<ICSettingEntry>();
List<String> includePaths =
convertToForwardSlashes(getIncludePaths());
for (String path : includePaths)
includeSettings.add(new
CIncludePathEntry(path,
ICSettingEntry.BUILTIN));
.
.
.
where the getIncludePaths() will return my custom includes. I also
create CLibraryPathEntry and CMacroEntry objects in a very similar way.
I then create the CExternalSetting containers and send them out to CDT.
.
.
.
return new CExternalSetting[] {
// Include paths, for
C/C++/ASM
new CExternalSetting(new
String[] {
"org.eclipse.cdt.core.gcc",
"org.eclipse.cdt.core.g++" },
new String[] { "org.eclipse.cdt.core.asmSource"
},
null, includeSettings.toArray(new
ICSettingEntry[0])),
// Library
new CExternalSetting(
null,
new String[] {
"org.eclipse.cdt.managedbuilder.core.compiledObjectFile" },
null, librarySettings.toArray(new
ICSettingEntry[0])),
// Symbols
new CExternalSetting(new
String[] {
"org.eclipse.cdt.core.gcc",
"org.eclipse.cdt.core.g++" }, null, null,
symbolSettings.toArray(new ICSettingEntry[0])),
};
This succeeds in contributing the paths and symbols to the project, but
they are not shown as built-in e.g. in the Include paths tab. Also, the
compiler will be invoked with -D options which attempt to redefine its
predefined symbols...
Is an external settings provider able to contribute built in
symbols/includes/etc.? I have not been able to find any further
documentation on this, nor any examples.
Thank you very much for your help!
/Mario
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev