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

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").

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 ;) ).

Ideally we would abstract it away with a clean tidy EMF model, or
something similar, if only there were time :(.  Patches and ideas you
have in this area would be really appreciated.

Cheers,
James

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

2009/9/17 Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>:
>> I am looking at SetCProjectDescriptionOperation.executeOperation()
>> and failing to understand why it is written this way. It basically
>> knows ICProjectDescription to set, and a project. However, instead
>> of setting that project description directly, it creates new
>> CProjectDescription, applies 'data' to it, and only then does:
>>
>>       fPrjDescStorage.setCurrentDescription(fNewDescriptionCache, true);
>>
>> What is the reason for this additional CProjectDescription instance?
>
> More confusion follows. The SetCProjectDescriptionOperation.executeOperation()
> also say:
>
>                // fNewDescriptionCache is still writable and may be written to at this point
>                AbstractCProjectDescriptionStorage.fireDataAppliedEvent(
>            fNewDescriptionCache, fOldDescriptionCache, fSetDescription, delta);
>
> Nice, but does not seem to work. Configurations in fNewDescriptionCache are instances
> of CConfigurationDescriptionCache, and pretty much every mutating method throws.
> For example:
>
>        public void setSourceEntries(ICSourceEntry[] entries) {
>                throw ExceptionFactory.createIsReadOnlyException();
>        }
>
> So, what exactly is writable in fNewDescriptionCache?
>
> Thanks,
> Volodya
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>


Back to the top