Building binary using different static library configurations

[plindsath]

Hi,

I try to build/link an application using different library configurations, but make complains about “make: *** No rule to make target <some project path>/<application configuration>/<some lib>.a, needed by `<application configuration>/<application>.elf’.  Stop.”

The problem is that make looks for the archive file in the wrong path. The archive file is in another directory, namely <some project path>/<some lib configuration>. Even though I’ve set the Library directories property in Makefile settings correctly, the generated Makefile still points to the directory stated in the first section above. Why? Is there a workaround?

Regards,

Peter Lindsäth

[support]

Hi,

There should be a workaround for this, however it depends on the project type you are using. Is it an MSBuild project, plain GNU Make project, or CMake project? If it’s a Make project, was it created with VisualGDB wizard or imported from an existing Makefile?

[plindsath]

All projects in the solution was created with the VisualGDB wizard and are GNU Make projects.

The thing is that I have several boards to support and some of them has support for hard float and some not, and instead of creating different projects my thought was to create different configuartions (which make total sense to me anyway).

[support]

Hi,

Thanks for clarifying this. For Make-based projects VisualGDB uses a very basic logic to track references – it will read the target name from the referenced Makefile, and will combine it with the $(BINARYDIR) expression, assuming that the binary directories for both Makefiles are the same. The resulting path will be hardcoded in the EXTERNAL_LIBS variable of the referencing project.

If you prefer using Makefiles to MSBuild, please ensure all projects that reference each other have matching binary subdirectories. Another option would be to switch to MSBuild – in this case the project references are stored as actual MSBuild references and VisualGDB will compute the correct paths during build.

Yet another option would be to try Advanced CMake (VisualGDB can import CMake-based embedded projects, but cannot create them yet). This will let you build your projects outside VisualGDB, but will also provide much better flexibility than MSBuild.

 

[Author]

Posts