Re: [cdt-dev] Rebuilding managed build project on properties change

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

On Monday 18 September 2006 16:50, Wieant Nielander wrote:
> >> Take a look at https://bugs.eclipse.org/bugs/show_bug.cgi?id=90481.
> >
> > If I'm reading that document correctly, in order to implement
> > toochain-level options I'd need the following:
> >
> >    1. Implement new ValueHandler.
> >    2. Define new option, specifying the ValueHandle
> >    3. Make my ValueHandler store options somewhere.
> >    4. Derive from GnuMakefileGenerator and modify it so that it adds
> > extra command line options to tools, depending on values set in (3) 5.
> > Arrange for my project to use my class derived from
> >    GnuMakefileGenerator, instread of GnuMakefileGenerator itself, which
> >    can be done by editing the 'buildfileGenerator' attribute of the
> >    'builder' element of the <toolChain> element for my project type.
> >
> > Is the right approach? Is there a better one?
>
> It depends a bit on the exact situation, if your global options affect tool
> specific options in the UI (properties dialog) you should use the
> valueHandler to propagate changes on the fly. But if your global options
> only influence the command line of one or more tools you can use another
> approach which is to specify a commandLineGenerator per tool. This
> commandline generator can then retreive the global toolchain-level options
> and convert them to the appropriate tool specific command line options. As
> far as I can see this does not require you to store your global options nor
> does it require you to specify your own GnuMakefileGenerator subclass.

Hi Wieant,
thanks for pointing out an issue I almost forgot! CDT properties dialog has a 
text control that shows command line for each tool. I certainly want my 
global option to affect UI.

But unless I'm missing something, that requires that Tool.getToolCommandFlags 
return additional command line options triggered by toolchain-level options 
in UI. And I'm not quite sure how this can be done with the valueHandler 
mechanism.

For now, I've modified Tool.getToolCommandFlags to contains code like this:

    			IToolChain tc = (IToolChain)getParent();
			
			IOption[] gopts = tc.getOptions();
			for(int i = 0; i < gopts.length; ++i)
			{
				...............
					String command = opt.getCommandForToolKind(getToolKind());
					if (command != null && command.length() != 0)
					flags.add(command.trim());
			}

Where 'Option.getCommandForToolKind' and 'Tool.getToolKind' are also new 
methods I wrote. What's the "official" approach for getting 
getToolCommandFlags return extra options set by toochain-level options?

One possible solution is to make toolchain-level options just go and edit 
tool-level options. But in that case, it will be hard, when the project is 
next opened, if some tool option like -mcpu=NNN was explicitly specified by 
the user, or result of toolchain-level option.

> > Assuming it is, how will auto-clean work for global options. The
> > Configuration.needsRebuild method appear to ignore global options
> > completely, so even if I edit a global option, Configuration.needsRebuild
> > will return false.
> >
> > Likewise, I want global option to affect options of several tools. If
> > that logic is contained in a class derived from GnuMakefileGenerator,
> > then a change in global option won't case Tool.needsRebuild() for the
> > affected tool to return true. Should I call setRebuildState() manually?
>
> If I understood Mikhail correctly the ToolChain MBS object should maintain
> its own rebuild state, so I guess the idea is that changing any toolchain
> level option should enforce a rebuild?

For whatever reason, that does not happen for me.

> I am however also in the process of switching to toolchain-level options
> and seem to experience the same issues.

Good to know it's not just me.

- Volodya