Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Language Settings and the new build system
Thanks Andrew. The gerrit review is up and almost ready to submit. Feel free to take a look and comment. I still need to figure out the best place to create IBuildConfiguration's that match ICConfigurationDescriptions that isn't in a resource delta while the workspace is locked.

https://git.eclipse.org/r/#/c/68475/



On Wed, Mar 16, 2016 at 4:45 PM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:
Hi Doug,
It is hazy in my mind by now but I recall that ICConfigurationDescription is not a vital piece for LanguageSettingsProviders. The idea was to give implementers a hook to retrieve bits of data if they need it. Another use of configuration was as a storage for the list of providers and the data they collected. Back then I asked on the mailing list and James Blackburn an advise about the interface and passing ICConfigurationDescription seemed as a good idea. It is also used by managed build providers to retrieve the name of compiler and dialect options from MBS toolchain.

I wish I could help you with your work but I just would not have enough time to work on CDT these days.

Thanks,
Andrew

On Tue, Mar 15, 2016 at 4:32 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
An interesting though crossed my mind as I was working through IBuildConfiguration'ing the language settings provider, and am now looking at the environment variable manager.

As I mentioned at the summit, I'm not sure what James Blackburn had planned for his platform work in this area. I have a feeling I'm carrying it forward today in a way that he intended. Making IBuildConfiguration an IAdaptable clearly lends itself to representing a variety of different stacks at that level. ICConfigurationDescription is an obvious candidate in the end.

But what I won't do and I'm not sure what he was intending there, is replace ICConfigurationDescription. The new build system is a new stack separate from the old configurations. What it does give us the ability to share functionality between the two systems. There are some core features that aren't really related to managed build and that's where I'm heading.

Doug.

On Tue, Mar 15, 2016 at 4:00 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
Initial gerrit review is up. I want to see how the tests run across the board. I also find it easier to review on Gerrit since it handles space changes due to formatting quite well.


Doug.

On Tue, Mar 15, 2016 at 1:40 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
Cool. The hardest part so far is fixing up the tests. Glad we have them :). Found a couple of things but I think I found a home for the IBuildConfiguration creation as a result.

Will post the patch when ready. Not too much longer.

On Tue, Mar 15, 2016 at 1:25 PM, Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx> wrote:
This would be perfect if you can make it to work.

-sergey

On Tue, Mar 15, 2016 at 10:08 AM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
That's what I'm trying. I also have adapters back and forth between them. Seems to be working. I need to find the right place to create the IBuildConfiguration for new configuration descriptors. Doing it lazily caused workspace locked exceptions.

This strategy might also allow me to leverage the environment variable manager.

Love to hear any feedback before I go to far.

Doug.

On Tue, Mar 15, 2016 at 1:03 PM, Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx> wrote:
Does this mean that the type of the first parameter in ILanguageSettingsProvider.getSettingEntries will be changed from ICConfigurationDescription to IBuildConfiguration?

On Tue, Mar 15, 2016 at 7:02 AM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
OK, that seemed to be a good direction. Seems like the config description is just passed around for the most part.

Now, I'm going to get brave and use IBuildConfiguration instead. We'll create these things on the fly as needed and provide an adapter back to ICConfigurationDescription. Wish me luck :).

Doug.

On Mon, Mar 14, 2016 at 3:12 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
The other option would be to pass configuration id's around as Strings. They easily map to IBuildConfiguration, project.getBuildConfig(String). They providers could try and map them to a ICConfigurationDescription to get info out of there, or adapt them to the new CBuildConfiguration to get stuff out of there.

On Mon, Mar 14, 2016 at 2:58 PM, Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx> wrote:
It's worth noting that LanguageSettingsSerializableProvider.getSettingEntries(ICConfigurationDescription, IResource, String) doesn't use its first parameter. One possible approach is to replace ICConfigurationDescription in ILanguageSettingsProvider.getSettingEntries with ICSettingContainer and to add instanceof checks in classes like ScannerInfoExtensionLanguageSettingsProvider and PathEntryScannerInfoLanguageSettingsProvider that depend on ICConfigurationDescription.

-sergey

On Mon, Mar 14, 2016 at 11:20 AM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
One of the actions I took back from the CDT summit was to explore how to use the Language Settings Provider with it. I think we agree that we do need the same functionality that it provides for all types of projects.

My initial investigation, though, shows that the provider system is intrinsically tied to the project descriptor system, and ICConfigurationDescription in particular. Almost all APIs reference it.

The new system is based on the platform resource's IBuildConfiguration. It appears to me that I will probably have to duplicate the entire language settings provider system to work in that new architecture. I'm OK with that. I just wanted to give people a heads up and see if anyone can think of a better approach.

The only one I can think of is to bridge ICConfigurationDescriptor to IBuildConfigurations, but that wouldn't work for the new style projects as I want to avoid the old project descriptor system.

Doug.

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev




_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top