Best Practices for Starting a New Project in SES Based on Example Application

[kw_martin]

I am about to start a new project for the nRF52840DK using SES in Ubuntu 18.04. I would like to start with an existing application but I don't want to change the original example application that comes with SES in case I get things wrong and need to start a second time. I have been reading the chapter in the SES manual on projects, but it is not clear to me what best practices are:

1) I am guessing I need to start a new "Workspace", and copy an existing example into this workspace. Is there a recommended location relative to $(StudioDir) that this new workspace should be located (aside: where is $(StudioDir) defined? I can't find it in Tools->Options or Project->ContxtMnu->Options). The PrjName.emProject files all use relative addressing for everything needed to build the project. Such as:

      c_user_include_directories="../../../config;../../../../../../components;../../../../../../components/ble/ble_advertising;../../../../../../components/ble/ble_dtm;../../../../../../components/ble/ble_racp;../../../../../../components/ble/ble_services/ble_ancs_c;../../../../../../components/ble/ble_services/ble_ans_c;../../../../../../components/ble/ble_services/ble_bas;../../../../../../components/ble/ble_services/ble_bas_c;../../../../../../components/ble/ble_services/

... for many many lines

Do we need to modify all of these by hand using an editor, or is there some automated way we can copy an example project to a new Workspace, and have the PrjName.emProject file updated automatically? Should we place the new workspace somewhere in $(StudioDir) to make this process easier?

My previous experience had under the File menu, a choice "New->Project->From Existing Project" choice that looked after almost all of the necessary changes of the configuration files. Does SES have something like this? Or is there a recommended best practices way to simplify this task? Sort of related, is there an automated way of making the PrjName.emProject file based on a template, and say a value for $(StudioDir) that will look after most of the boiler plate, compilation flags, etc.?

Finally, is there a link to a tutorial that starts a new project based on an existing project, or should I write one (I need it for future projects for student groups).

[Vidar Berg]

kw_martin said:

Anyways, thank you for your help. Due to my inexperience, I can not follow your directions, but I think that just by copying to the carefully chosen location that didn't break relative paths, I can continue on.

It should be correct as long as you don't get any build errors. You don't have to use the project macro as I suggested, I guess my main point was that it can be both quick and easy to update source and include paths if you work directly with the project file in a code editor rather than doing it manually in SES.

Attached below are the screenshots I took earlier in a .zip file in case you're interested. Hopefully they are easier to read.

screenshots.zip

[kw_martin]

Thank you Vidar, being able to see the screen shots made all the difference. I now realize that the "Macro" was simply setting a value for the environment variable SDK_ROOT which could then be used in the search and replace window. For some reason, clicking on the screen shots did not enlarge them previously, it does now and it makes it completely clear.

[Vidar Berg]

Thanks for the update. Glad to hear that it worked.

[Don]

Hi,

Unless I missed something, this leaves you still pointed at all the original source code.  If you need to edit something in the example, say main.c or sdk_config.h, you would be editing the original example source files in the SDK.

Now if you want to back up your work, you need to back up these files, which may be scattered throughout the SDK.  Unless you have better tools than I do, you now need to back up the entire SDK folder.  Not only that, but now the SDK isn't pristine for the next project (or programmer).

My philosophy has been that to back up the project, should require 3 pieces: the compiler, the SDK, and the project.  In this case I would archive the SES installer, which as I recall includes the gcc compiler I'm using. Since the project directory is small relative to the other two, it is much easier to back up regularly.  The compiler and SDK only need to be backed up once not only for this project, but for all others that use the same versions.

This requires that any file you EVER edit gets put in the project directory, and should be referenced relative to the project directory.  In the example above, I would copy main.c and sdk_config.h from the SDK to the project directory, re-reference them in the project, then commence editing.

This way, after I retire and my computer is destroyed in a freak accident, the only things needed to resurrect the project are the 3 archived parts, and the only configuration that needs to be done is to tell the project where the SDK and the compiler are located on the new computer.  In other IDE's I've used this is easy, but appears a bit more work in SES.

Does this make sense, or am I (being new to SES) missing something vital to the structure?

[Vidar Berg]

Hi,

With the approach I tried to describe above, main.c and sdk_config.h will both be kept in the project directory outside of the SDK tree. Maybe I am missing something, but it seems to me like we have the same idea of how it should be done.

Don said:

Now if you want to back up your work, you need to back up these files, which may be scattered throughout the SDK.  Unless you have better tools than I do, you now need to back up the entire SDK folder.  Not only that, but now the SDK isn't pristine for the next project (or programmer).

If there other SDK source files you need to modify, then you can make a copy of those and import them to your project directory, instead of altering the sources in the original SDK.

Don said:

My philosophy has been that to back up the project, should require 3 pieces: the compiler, the SDK, and the project.  In this case I would archive the SES installer, which as I recall includes the gcc compiler I'm using. Since the project directory is small relative to the other two, it is much easier to back up regularly.  The compiler and SDK only need to be backed up once not only for this project, but for all others that use the same versions.

I agree with this approach. And I can confirm that SES uses GCC.

Don said:

This requires that any file you EVER edit gets put in the project directory, and should be referenced relative to the project directory.  In the example above, I would copy main.c and sdk_config.h from the SDK to the project directory, re-reference them in the project, then commence editing.

Yes, but usually you don't have to edit SDK sources (?), and if you do, you can import them to your project first.

Don said:

In other IDE's I've used this is easy, but appears a bit more work in SES.

I think this may have more to do with how we set up our projects and the way our SDK is structured. We support Keil uvision and IAR as well, but they are set up in the same way.