So, say, if one has some devices in the field with OS 4.25 and some with 6.20, how can an M2MStudio project best be structured to support both these targets?
With Visual Studio, I did it by having an OS_425 project in a folder with 4.25-specific files, and an OS_620 project in a folder with 6.20-specific files, and another folder with “common” files:
I’m using preprocessor to include or exclude version specific parts of program. And to change the OS and plugin settings of the project I’m using options of the project, so there are not less than 2 steps to change build settings from one wireless cpu type to another. If you set preprocessor to exclude parts of the program depending on OpenAT SDK version you can reduce steps to only one: setting used open at sdk version in project options.
Indeed, Open AT package dependencies are common to all build configurations. We plan somewhere in the roadmap to study how to make this configurable in each build configuration, but it needs a so deep refactoring that it is not scheduled in a particular release for the moment.
It’s possible to make a library with no dependencies at all on any Open AT package: just uncheck everything in the project creation wizard or in the project properties.
This would allow you to have a generic C library just depending on your own stuff.
Then you can create several application projects, based on different package versions, and implementing “adaptation layers” accordingly with these versions.
You may have also some Open AT interfaces depending code in the generic part, you want to compile vs different packages versions without duplicating source files.
You can handle this by using linked resources:
Store these generic files in a location which is not a source path for any project. You can even create a new simple non Open AT project just to store the files (File > New > General > Project)
In a project where you want to compile these files vs a given package version create a linked folder: File > New > Folder > Advanced > Check “linked to folder in the filesystem” > Variables > Select workspace_loc > Extend… > browse to your folder location. Click OK everywhere and eventually change the folder name. In the project explorer, you will see the linked folder, with the contained resources. Not that the resources are not duplicated, but just linked. If you edit them, you edit the file in its original location.
Finally, promote the newly created linked directory as a source folder: File > new > source folder > just enter the name of the linked folder. After that, a build will also gather the files under the linked folder.