-
Notifications
You must be signed in to change notification settings - Fork 2
AS Build Process
When buildin AS projects that containe mixed C and ST code (f.ex. some Libraries are in C, some in ST, some C Libraries have .fun files, some don't export any ST interface), the build process can fail in mysterious ways.
This page aims to document how AS builds projects in order to understand the process better and be able to fix AS build problems. The text here represents grey-box reverse engineering, that is the AS build process is semy transparent, because it partly uses tools such as gnu make and can be configured to leave traces of the build process behind. As such the information presented here is based on educated guesswork and can be inacurate. Please improve the docu if you find a problem with it.
In the "Physical View -> Properties -> Compilation" you can add a "-save-temps" switch to the "Additional compile options" field. This results in gcc not cleaning up intermediate files, which can help you finding out how things were compiled.
Additionaly AS itself leaves behind .mak (Makefile) and other kinds of files in the Temp/ directory which lets you see how AS compiled and linked the parts of your project.
AS will build libraries and link Task in the order they appear in the CPU.sw configuration. If there are any dependencies that you are unable to correctly communicate to AS, you can use this explicit ordering to impose them during the build process.
What AS does first is to create .h files from the various .fun, .typ and .var files. That means that Temp/Includes is populated first during the build process. Which means that your C libraries do have access to those generates headers during their build.
Next AS will build the libraries.
It seems that AS will link libraries that contain .typ, .var or .fun files, in other words libraries with an ST interface, against all pure (without ST interface) C libraries. That means that pure C libraries must occur before any ST-interface-libraries, in the CPU.sw list, otherwise they will not yet be built and the build will fail with a link error.
Since AS is allway linking ST-interface C libraries with all pure C libraries it is also including all headers of those pure C libraries during the compilation of those ST-interface C libraries.
- always place pure C libraries before ST-interface C libraries and ST libraries in the CPU.sw configuration
If and only if a library has an IEC component - that is a .typ, .var or .fun file - then AS will:
- make a dynamic library out of it
- scrub the exported symbols and only leave symbols in it, that were defined via the .typ, .var or .fun files. That means, that if your C library has additional functions, then as of today you can't use them from outside of the library because AS will remove the corresponding exported symbols.
Otherwise, if there is no .typ, .var or .fun interface, AS will build a static library. Static libraries are rendered in a blue font in the Configuration->CPU.sw view and since they're static they are not transmitted indivudually to the target and thus are not displayed on the target.