building across different hardware

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
woodsb
Active Member
Posts: 61
Joined: Thu Nov 17, 2016 11:24 pm

building across different hardware

Postby woodsb » Fri Mar 09, 2018 2:08 pm

Hi All:

I want to be able to build a single project across different hardware versions. Currently I need to change the TARGET xn file in the Makefile, and #define a flag indicating which hardware I am using and make sure the #define propagates through all relevant parts of the project. I am sure there is a better way to do this, but I am a noob when it comes to this level of project development.

I imagine the best way is to have a different Build Configuration for each distinctive hardware version, but I cannot determine how Build Configuration information is propagated through the Makefile and header and source files in a project. I've looked through various reference pages on Build Configurations but cannot decipher their jargon as it relates to my issue.

I would be grateful for any help on this issue.
User avatar
aneves
Experienced Member
Posts: 93
Joined: Wed Sep 16, 2015 2:38 pm

Postby aneves » Mon Mar 12, 2018 2:54 pm

Hi woodsb!

We currently do this for the exact same reason. The way we do this is we comment out the line in the Makefile which sets the variable TARGET. Create a build configuration for each target you want to support. Then right-click on your project and click Properties. Click on C/C++ Build and look at the field titled Build Command. It might look something like this:

Code: Select all

xmake CONFIG=Default


Append the text "TARGET=<you_target_name_here>" where <your_target_name_here> is the name of the target you want to build for. Make sure the drop down near the top of the window is displaying the correct build config you are editing.

As an example, if you were creating a build config for the xCore 200 Explorer the build command would look like this:

Code: Select all

xmake CONFIG=Default TARGET=XCORE-200-EXPLORER


Essentially, all we're doing is supplying the TARGET variable the Makefile needs via a different means.

Hope this helps.
woodsb
Active Member
Posts: 61
Joined: Thu Nov 17, 2016 11:24 pm

Postby woodsb » Mon Mar 12, 2018 9:38 pm

Thanks, aneves, for the reply. It does seem that the essential difference is where the TARGET variable is defined. I think what I am still missing is, what goes into a build configuration and how is that info accessed during the build?
User avatar
aneves
Experienced Member
Posts: 93
Joined: Wed Sep 16, 2015 2:38 pm

Postby aneves » Tue Mar 13, 2018 4:01 pm

Not to sound facetious, but a build configuration... configures your build!

The build configuration is a container for anything related to how you want to control the build process. By default in the IDE, you do this by modifying the Makefile to specify the various flags you want to pass to the many compilers and sub-processes that execute as part of the build process. These flags dictate optimization level, whether or not to generate debugging info, what libraries you're using if any, the file name of the output firmware image, etc.

Typically you have two build configs, a Debug and Release config. The Debug config will typically turn off optimizations (-O0) and generate debugging info (-g) because that's the point - you want to be able to debug the firmware in the debugger. The Release build typically represents what you will release as the end product so you will usually turn on full optimizations (-O3) and exclude generating debugging info in an attempt to gain better performance and a smaller image. Release builds are harder to debug in the debugger because the compiler does a great job at optimizing out a lot of things you might want to look at in the debugger. Again, this is the main reason for these two build configs.

How are these accessed in the build? Well, the Makefile you edit in the IDE is actually part of a very large Makefile buried somewhere in your IDE's installation. That very large Makefile does all of the heavy lifting. The nice guys at XMOS decided it would be much easier to have users only need to edit a few lines in a much smaller Makefile where all you have to do is specify a few basic variables that specify what flags to pass the compiler, what flags to pass to the linker, what to name the output, what libraries you're using, where are your header files, etc. When you click on the hammer icon in your IDE to build your project, your telling xmake to start the build process with the Makefile you've defined for a specific build config.

Hope this helps.
woodsb
Active Member
Posts: 61
Joined: Thu Nov 17, 2016 11:24 pm

Postby woodsb » Thu Mar 15, 2018 6:32 pm

Thanks for the further info. I think what I'll be doing is using the Makefile for the hardware versioning, and not changing build configuration. That way the info is all in one place and hopefully easier to follow.

cheers.

Who is online

Users browsing this forum: No registered users and 23 guests