**** Advance Notice ****

This site will be closed on 31 December 2015,

Important Information for users of NXP LPCXpresso

This site is for users of Code Red branded products.

NXP LPCXpresso users should visit the LPCXpresso FAQ's for up-to-date information relevant to that product.

Differences between revisions 11 and 12
Deletions are marked like this. Additions are marked like this.
Line 20: Line 20:
{{{rm "${BuildArtifactFileName}"}}} {{{rm -f "${BuildArtifactFileName}"}}}

Build Behavior when using Library Projects

The current behavior of Eclipse/CDT (which the Code Red IDEs utilise) in the handling of library projects is not ideal. This is an area where improvements are being made in future releases by the Eclipse community.

A library project will be built each time that an application project that references it, is built. So, if source code in the library project changes, a build of the application project will trigger a rebuild of the library project. However, the application project project will not detect the library has changed and will not be relinked - hence the changes in the library project will not be automatically picked up in the application project. See below for an explanation of this.

A simple way to ensure everything is rebuilt if you change library source code is do a clean before doing a build of the application project. However behavior can be modified in one of two ways...

1) Delete the executable

Delete the executable (".axf") file from the Debug (or Release) subdirectory of the application project before triggering a build of the application project. This will mean that when the application project is built, the linker will always be invoked to rebuild the executable, and so will pick up any changed libraries.

The executable can be deleted manually in the Project Explorer view, or can be automated by adding a prebuild step....

Project Properties ->  C/C++ Build -> Settings -> Build Steps

and adding the Pre-build steps Command...

rm -f "${BuildArtifactFileName}"

Remember that you will need to make this change for all Build Configurations (typically Debug and Release).

2) Extend library linkage

The linkage between library and application projects, can be extended by modifying the application projects settings in...

Project Properties ->  C/C++ General -> Paths and Symbols -> References

so that any associated library projects are selected. This will cause a build of the associated library projects every time that the application project is built. However this will typically be a full build of each library project, meaning that even if the library is unchanged, it will still get built - which for large projects may cause a noticeable increase in overall build times.

Thus generally, if you want to modify the default library handling behaviour, we would recommend option 1) above.

Why is the linker not reinvoked?

A Project Reference causes a referenced project to be built. Unfortunately, there is no (make) dependency on the output of a referenced project, and there is no way to specify such a dependency. So, although a library may have been rebuilt, any project that uses that library has no defined dependency on that library and so the build system will not know to reinvoke the linker.

Additional related FAQs

BuildBehaviorLibraryProjects (last edited 2012-02-04 21:17:26 by CrSupportAb)