This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Zero or multiple executables in a project

I'm in the process of migrating a number of projects from an older XP/Eclipse/mspgcc environment to a CCS V6 based environment on Windows 10. The underlying toolchain is MSP430 GCC. In the old environment, builds were performed outside the IDE, but if possible I'd like to use the integrated builds in CCS.

There are a number of cases where the project produces nothing more than static objects, which are referenced by other projects as part of their builds (ie. no executables). The CCS model appears to be a single executable per project, and I'm trying to figure out the best way around this.

I've found a couple of references in the forums to static and dynamic library projects being an option in the project creation wizard, but has missed any sign of these in V6, or any other way of suppressing the linker phase of a project build? If I try and build the project, I get unresolved symbols on rts430.lib's call to main - setting the runtime support library to <none> is not enough, as CCS still tries to generate the .out. using an rts430. I've tried simply deleting the .out from the project specification, but this (not surprisingly) doesn't generate anything (and in particular, doesn't generate the objects). What is the magic to do this?

In a similar vein, some projects generate multiple executables. Many of these are simple test harnesses for the underlying components, but it does make a lot of sense to generate these within the appropriate project. The only way I've found to produce these is to have a separate project for each one. I'm guessing there has to be a better way.

I imagine both of these can be resolved by getting away from the automated make generation, but that gets me back to the old model we used, which is not ideal. I can't imagine what I'm attempting is unique, so I hope I'm missing something obvious! 

Thanks for any pointers or help

Andrew

  • Well, I've just spent the day buried in CCS's make, and making progress, albeit a bit slowly.

    Getting a project to just produce objects was easy to solve. I did find where the Static Library project option was buried, which effectively does this. I was also able to achieve something similar by creating a makefile.target file for the project, create my own target which does not proceed beyond the compilation, and setting the project build behaviours to use this target.

    Setting a project up to support multiple executables has been a lot more challenging. Its definitely possible via the makefile.init and makefile.targets to create definitions for an arbitrary number of executable targets. These can either be built in total using a similar strategy to the compilation only model, or via the Make Target option on the project menu, which allows individual targets to be built. With a bit of playing around with run configurations, I've also been able to download these to a target processor, and execute them. What I am still struggling with is the linker build rules. Whereas the CCS generated make files use generic rules for the compliation steps, the linker step is done with a specific linker rule, which is set up for the singular project executable. This makes it very difficult to use the CCS generated rule to produce multiple executables. At present the only way I've found to do this is take a snapshot of the rule and turn it into a generic rule I can use, but this is pretty nasty, as the copied rule is now disconnected from any linker options changed in CCS. I'm still thinking of a way of stealing the generated rule on the fly, parsing it, and generating a generic form from that, but not sure how to achieve this yet.

    Any other ideas welcome.

    Andrew
  • Andrew,

    Sorry about the delayed reply.

    Andrew McLaren said:
    Getting a project to just produce objects was easy to solve. I did find where the Static Library project option was buried, which effectively does this.

    Looks like you already found the option in CCS to create a Static Library instead of a Executable. A Static Library is essentially an archive of object files that can then be linked in with other Executable projects.

    Andrew McLaren said:
    Setting a project up to support multiple executables has been a lot more challenging.

    Have you looked into Build Configurations? Basically you can have a single CCS project with multiple build configurations, with each configuration using a custom set of source files and build options. The build process will then produce an executable for each configuration. Please see this page for more information.

  • Thanks a heap!

    This was just the pointer I needed. I hadn't found the CSS Build Handbook before, and this was a lot of help in understanding the concepts behind the CSS/Eclipse builds (also a nicely written document, and pitched at just the right level for someone trying to get a general overview of how this fits together). The multiple build configurations opened up a whole world of flexibility I'm still getting my head around, but even in their simplest form, they do exactly what's needed here.

    I've been playing around with a model where all the various underlying facilities are compiled into one or more static libraries, and will probably put all the various support executables (test logic and the like) in a project of their own. Its a little different structurally to what we do now (where we bury these executables in with the logic they relate to), but in many ways its cleaner. I have a bit of a related question pertaining to this (and to referencing static libraries in general).

    When a static library project is referenced, I (maybe naively!) expected that CSS would automatically construct the linker commands to pull this into the executable it is currently building. However, all it seems to do is add the static library to the make dependencies for the executable. I've had to manually tweak the linkers library options in the build configuration to force it to actually reference the static library. Is this how it is supposed to work, or is there something else I'm missing?

    Thanks again

    Andrew

  • Andrew McLaren said:
    When a static library project is referenced, I (maybe naively!) expected that CSS would automatically construct the linker commands to pull this into the executable it is currently building. However, all it seems to do is add the static library to the make dependencies for the executable. I've had to manually tweak the linkers library options in the build configuration to force it to actually reference the static library. Is this how it is supposed to work, or is there something else I'm missing?

    Andrew,

    That is actually how it works, you are not missing anything. Setting up a dependent project simply tells CCS to build the referenced project first (if there have been any changes since last build) and then the main project. You do have to manually add the library created by the library project to the linker options in the main project in order for it to be brought into the link.