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

[David Marques <wtv368@xxxxxxxxxxxx>]

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