Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Passing build configuration options to a project template via a method.
Thanks James, this cleared my thoughts.

On 06/17/2011 07:41 PM, James Blackburn wrote: 
On 17 June 2011 11:19, Petri Tuononen <petri.tuononen@xxxxxxxxx> wrote:

1) How External Settings Provider adjusts to different locations in
different machines? Does this happen automatically or if not then what
checks or tricks should one implement?

When your external settings provider is invoked, you return the -Is,
-Ds -Ls and -ls that are needed to build against the requested
libraries.


2) Pkg-config outputs OS-specific paths so does External Settings Provider
work cross-platform as well?

The settings your provide should be the same as the setting that are
needed when executing the applicable tool.  So it's your job, as the
settings provider, to get the paths right for when the tool is invoked
on the current platform
Ok. I can easily get checked packages and just compute paths again and set external settings again. However this leads to a new dilemma at which point should the paths be recalculated (without too much overhead).

      

        
3) How to add a value to "Other flags" field in Compiler's Miscellaneous
group? ICSettingEntry doesn't exist for that.


      

      
Currently you can't.  What are you trying to put in there? That's
really for additional user specified switches.



    

    For Windows -mms-bitfields and e.g -pthread for
    Linux. I guess I can (and have to) pass these other way.

    

      

      

        
4) For some reason ICConfigurationDescription#setExternalSettingsProviderIds
doesn't have effect on AbstractCPropertyTab#updateData but works via
preference page or pop-up menuitem etc. Any ideas what's wrong?


      

      
See ICConfigurationDescription#updateExternalSettingsProviders(String[] ids).
So you set the provider ids, and when the user changes which package
they want to have tools options for, you call updateExtSetProv. on the
like configuration description and the settings will be loaded in.

I notice in the code I have that does this does it in a job:
// Update the project configuration in a different thread, or badness will ensue
...
Job j = new Job("...") {
	@Override
	protected IStatus run(IProgressMonitor monitor) {
		ICConfigurationDescription[] cfgs = new ICConfigurationDescription[]{cfgd};
		if (cfgd instanceof ICMultiConfigDescription)
			cfgs = (ICConfigurationDescription[])((ICMultiConfigDescription)cfgd).getItems();
		for (ICConfigurationDescription cfgd : cfgs) {
			// FIXME remove and re-add our settings provider, otherwise the
update doesn't happen properly...
			Set<String> externalSettingsProviders = new
LinkedHashSet<String>(Arrays.asList(cfgd.getExternalSettingsProviderIds()));
			externalSettingsProviders.remove(ID);
			cfgd.setExternalSettingsProviderIds(externalSettingsProviders.toArray(new
String[externalSettingsProviders.size()]));
			externalSettingsProviders.add(ID);
			cfgd.setExternalSettingsProviderIds(externalSettingsProviders.toArray(new
String[externalSettingsProviders.size()]));

			cfgd.updateExternalSettingsProviders(new String[] {ID});
		}
		return Status.OK_STATUS;
	}
};
j.setPriority(Job.INTERACTIVE);
j.schedule();

This clearly shouldn't be necessary, and is very racy. I can't
remember why I did this - it *should* work inline. If it doesn't we
should fix it.



    

    Thanks for this code excerpt. Maybe running the code in thread
    prevents the freezing of property pages and hopefully the problem
    that prevents showing the values in Settings tab in the first place.

    

      

      

        
As a side note this approach seem to take more time.


      

      
Time to implement, or computation time? 


    

    Computation time. Although I can only confirm this after the whole
    functionality I plan to do is implemented. The main reason is
    probably that all flags need to be recalculated for every checked
    package every time there's any related chance.

    Implementation in this case is a bit faster for external setting
    provider compared to similar ManagedBuildManager#setOption route.
    Although lack of documentation and examples provide more challenge,
    but managed anyway.

    

      
Fundamentally you have an issue in that your paths need to be kept
separate from the user's defined paths.  So if the project is moved
from linux to windows, the linux paths should be replaced by the
windows paths, rather than just adding the windows paths on top.
The external settings manager provides this functionality as it keeps
track of which paths originated from an external provider, so when
your paths change, it removes the original paths and replaces them
with your new paths.  Clearly you could keep track of this yourself in
your model, but then CDT would have yet another path tracking
mechanism...



    

    Thanks for this help James. I wasn't aware of External Setting
    Provider before Doug mentioned it but now I have get to know it.
    Seems to fit perfectly for this task.

    

    Cheers,

    Petri

    

    

      
HTH
James
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


    

    

  



























  Back to the top