| RE: [cdt-dev] externalSettingsProvider and built-in settings |
|
Hi
Mario, Unfortunately
I don’t have a direct answer to your question but I can at least say that
I’ve been down this same road and have come to the exact same conclusions
with regards to programmatically adding built-in settings to a project. There
are several ways to “almost” get there but each approach seems to
fall short in at least one way. Hopefully if we’re missing
something someone else will chime in? As
I’ve been wrestling with this for a few months now myself I’ve had
a few observations that I thought I might share. In general it feels to
me as though there are three primary needs for this type of functionality: 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. 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. 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? 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. 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. 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 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 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 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. Thanks, Andrew On Wed, Aug 26, 2009 at 9:00 AM,
Mario Pierro <Mario.Pierro@xxxxxxx>
wrote: Hello, |