Supporting different targets


#1

What is the recommended way to structure an M2MStudio project so that it can be built for different targets?

eg, GPIO handling changed significantly between OS 4.25 and 6.20 - see: viewtopic.php?f=46&t=3654&p=14112&hilit=changed+significantly#p14112

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:

Product Folder--+---OS_425 Project--+--inc
                  |                   |
                  |                   +--src
                  |
                  +---OS_620 Project--+--inc
                  |                   |
                  |                   +--src
                  |
                  +---Common----------+--inc
                                      |
                                      +--src

I used the -src and -inc Project Wizard options to specify the location of the Common files.

M2MStudio doesn’t seem able to cope with this - it ends up duplicating loads of files! :frowning:

It looks like the “Build Configurations” might be the way to go, but I’m not quite sure what they’re really about from the online help.

In particular, I need to ensure that the 4.25-specific files are not built for the 6.20-specific “target”, and vice-versa.


#2

Doesn’t look like the “Build Configurations” are going to help:

  • I can see how files can be excluded on a per-configuration basis :slight_smile:
  • But I can’t see anywhere to set the firmware, OS, plugin, etc version on a per-configuration basis :frowning:
Product Folder--+---OS_425 Project--+--inc      <--- Needs to build with libs, FW, plugins, etc for v4.25 
                 |                   |
                 |                   +--src
                 |
                 +---OS_620 Project--+--inc     <--- Needs to build with libs, FW, plugins, etc for v6.20
                 |                   |
                 |                   +--src
                 |
                 +---Common----------+--inc
                                     |
                                     +--src

Any ideas? :confused:


#3

Could I make the common bit into a library :question:

I would need to ensure that it doesn’t include anything that’s specific to a particular Wavecom release - is that posible? How?


#4

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.


#5

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.

Hope it will help.