[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-mtj-dev] MTJ Build Hooks requirements
|
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.
