Re: [dsdp-mtj-dev] MTJ Build Hooks requirements

[David Marques <wtv368@xxxxxxxxxxxx>]

Hi Craig,

   Well I think it would not help much in case the hook acts on the 
last states of the build process, since it would be called several times 
yet. I think we should keep your initial proposal and document that the 
hook providers should keep their hooks "lightweight".

How does it sound to you ??

Regards,

David Marques

Craig Setera wrote:
> David,
>
> I do share your concerns... One possible idea... Have the callback 
> return a boolean.  If true, we continue to call that callback for that 
> particular project/state.  If false, we don't call that hook for that 
> callback any more.  That way the hook is still completely in control 
> of what hook state/project combinations the hook will be called for.
>
> Just a thought.  It may be too complex.
>
> Craig
>
> On Apr 14, 2009, at 7:28 AM, David Marques wrote:
>
> > Hi Craig,
> >
> >   I like your idea to generalize the hooks and make them see the 
> > build system as a "state machine". I have some concerns regarding the 
> > overhead of calling all registered hooks, but let's hope hook 
> > providers will do their job right :)
> >
> > Well if everyone agrees on it, I will do the suggested changes.
> >
> > Regards,
> >
> > David Marques
> >
> > Craig Setera wrote:
> > > Finally found some time to look through your documents and look 
> > > through Jon's questions.  I hate to even make a suggestion this late 
> > > in the game, but I'm going to anyway <grin>
> > >
> > > In terms of the filtering, I think that we should just go ahead and 
> > > call the registered hooks every time.  We should leave it to the 
> > > hook implementor to query the currently selected device or anything 
> > > else of interest from the MTJ project instance and decide if they 
> > > want to do anything within the hook.  That way we don't need to 
> > > depend on a name matching routine or what the various SDK's decide 
> > > they want to use for the identifiers.  In addition, it is much more 
> > > flexible for the hook implementor in terms of how they decide what 
> > > they want to do and when.  We should document (somewhere) that this 
> > > determination needs to be done as quickly as possible in the hook's 
> > > implementation.
> > >
> > > To answer one of Jon's other questions, I think it may make sense to 
> > > generalize the pre/post build to include the *possibility* of more 
> > > states.  (while limiting it for now).  In theory, we have lots of 
> > > build states:
> > >
> > > - Pre Build
> > > - Pre Preprocessing
> > > - Post Preprocessing
> > > - Pre Compile
> > > - Post Compile
> > > ...
> > > - Post Build
> > >
> > > If we create the IMTJBuildHook interface to have a single callback 
> > > method that looks something like:
> > >
> > > public void buildCallback(IMTJProject project, BuildStep step, 
> > > IProgressMonitor _monitor)  throws CoreException
> > >
> > > We can then make BuildStep (or whatever we want to call it) be an 
> > > Enumeration.  I would suggest that until we have more time to work 
> > > through the details, that there would be only the two initial 
> > > BuildSteps in the enumeration of PRE_BUILD and POST_BUILD.  With 
> > > that said, this approach would be more extensible in the future and 
> > > we could add new steps in the future for use by interested hook 
> > > builders.  If we do this, it should be documented that unexpected 
> > > callback types should be *ignored* by the hook.
> > >
> > > Thoughts?  I know it is a departure from your current design, but I 
> > > do think it is more flexible and meets some of the requirements that 
> > > I (think I) hear from Jon for their use.  I apologize again for 
> > > throwing this into the mix so late... I will try to do a better job 
> > > of staying on top some of this stuff.
> > >
> > > Craig
> > >
> > > David Marques wrote:
> > > > Hi Craig,
> > > >
> > > >   I see your point, although mtj does not use the ISDK interface 
> > > > anywhere yet, so for now it would not work. How about doing this 
> > > > change latter when the ISDK interface is used by MTJ ??
> > > >
> > > > Regards,
> > > >
> > > > David Marques
> > > >
> > > > Craig Setera wrote:
> > > > > Sorry... As usual lately, I'm swamped.  I guess I have a concern 
> > > > > with the SDK name being used as the identifier in the general 
> > > > > case... in particular when we get the new SDK extension point up 
> > > > > and going.  It seems to me that we likely need to add a 
> > > > > getIdentifier() method to the SDK object and that that name will 
> > > > > be the SDK name by default for "imported" Devices/SDKs.
> > > _______________________________________________
> > > dsdp-mtj-dev mailing list
> > > dsdp-mtj-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> >
> > _______________________________________________
> > dsdp-mtj-dev mailing list
> > dsdp-mtj-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
>
> _______________________________________________
> dsdp-mtj-dev mailing list
> dsdp-mtj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev