Yes, this is the right way.
In the old stuff, we didn’t have the auto-generation of the IPC library fully integrated yet. A big part of 14.07 was to get that stuff working. So, now you don’t have to import libraries anymore. The library names are pretty ugly now, because they include a crypto hash of the .api file contents, so we can support multiple versions of the same API side-by-side when needed (for backward compatibility with older components and to provide smoother migration paths), without being vulnerable to obscure crash bugs, etc. if someone changes a .api file without remembering to update the version number. But, the idea is that you shouldn’t ever have to type that nasty file name, or even copy it. In fact, we could have even left the human-readable parts out of the generated library file names, but we left it in so you can tell what the file is related to when you see it in the target’s file system.
You do have to create a component to get the library generation working. The idea is that we want to encourage component-based software engineering (breaking into functionally coherent blocks, with separation of interface from implementation) to improve mantainability and reusability. But, we also don’t want to make it difficult to use. It does sometimes feel a bit like we are making developers jump through hoops unnecessarily when building small projects.
We have been toying with the idea of allowing a “component:” section in the .adef that would allow you to create components inside .adef files. Anything that can be done inside a Component.cdef file could be done inside of a “component:” section inside a .adef. Then, if your project gets big, or you want to reuse a component defined this way in another application, you could just move the content of your “component:” section from your .adef file into a Component.cdef file.
Does this sound like a good approach to you?
We were also looking at ways to add client-server IPC API interfaces directly to executables in the .adef file, but we feel that the syntax of the “executables:” section could get pretty ugly if we try to “shoehorn” too much into it. Of course, if you have suggestions, please feel free to share them.