Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Re: Setting project description confusion

On Thursday 17 September 2009 James Blackburn wrote:

> Hi Vladimir,
> 
> This code is indeed opaque.  I poked at it a while ago and felt
> similar frustration to you.
> 
> The issue, if I recall correctly, is that when the
> CProjectDescriptionEvents are fired consumers have a handle on
> writable project descriptions and can perform modifications. Things
> like scanner discovery, and the build system contribute changes during
> these events, as does the retrofitted ICDescriptorManager.
> 
> Now this is clearly bad. There's no guarantee on the order of access,
> and so there's no way to enforce precedence. I suspect this is why
> there are _three_ applying states in CProjectDescriptionEvent:
> ABOUT_TO_APPLY, DATA_APPLIED,  APPLIED. Which fire at various stages
> of the setProjectDescription.
> 
> Now some time back I did _try_ to make this better, but those changes
> were dropped as I was in the middle of a larger restructuring.  This
> code was/is almost entirely undocumented. What you'll find is that
> some method calls have unexpected side effects (there's one comment:
> "FIXME there is deep magic going on here.  The project descriptions
> are being changed in non-obvious ways").

Yes, I have noticed that comment.

> I think the only way to make progress is to change it.  Run the
> testsuite, see what breaks (and if nothing does, we don't have enough
> tests ;) ).

I am doubtful this will help to reveal higher-level design misteries.
Say, I've previously asked here why there are 'configurations' and also
'configuration data'. This is not something you can discover by removing
either of those ;-)

> Ideally we would abstract it away with a clean tidy EMF model, or
> something similar, if only there were time :(. 

EMF model? I never used those, but I'm suspicious that yet another metatool
will help to fix the core problem, which is contrived and undocumented model.
(Just like ability to describe toolchain in xml does not fix obscurities in
the actual tool model)

> Patches and ideas you
> have in this area would be really appreciated.

I'll try to at least add comments to the things I eventually figure
out.

> 
> Cheers,
> James
> 
> P.S. You didn't say what problem it is you were trying to solve...

I have a custom option for a project -- 'board'. When that option changes,
I want to include in the build the support files for the newly selected
board, and exclude support files from the previous board from the build.
I've tried to hook to DATA_APPLIED handler and modify the project
description I'm given, but I run into the issue above. I'm now catching
ABOUT_TO_APPLY event, and this works fine.

- Volodya


Back to the top