Twitter github

Target Definitions

I tend to joke around with Wassim that PDE has certain things that only one person (hi Jeff) in the world uses. A good example of that is Target Definitions which people only come across accidentally when trying to create a Product Configuration. Why is it that only “one” person in the world uses Target Definitions? Is it a doc problem? Maybe, but it’s my opinion that feature adoption always comes down to evangelism via proper channels. However, that’s another discussion, back to Target Definitions 😉

In simplest terms, Target Definitions allow you to manage your target platform in ways you didn’t think was possible before. For example, you may be developing a product or component that only needs a specific set of plug-ins or features. As an example, let’s say you were a handsome developer working on the new Equinox provisioning effort. As a new Equinox provisioning developer, you know that you don’t need the whole SDK checked in your target platform so you used to manually check plug-ins that you didn’t want included. That kind of sucks…. as a smart Equinox provisioning developer you decided to create a target definition that would represent the target you are developing against (provisioning).

Once you do that, it’s easy to craft your target platform the way you want and also share that target platform with your fellow provisioning developers (since target definitions are contained in a shareable .target file).

That’s Target Definitions in a nutshell. I tend to use Target Definitions frequently when working with products that serve as platforms and I’m working with a component that exists on top of a product. So now that you know about them, go use them and file some bugs (or enhancements).