In my company there is a project, depending on this library. However, it is used by copy-pasting some .c and .h files into the project and adding their names to the makefile.

I would expect the correct way of using a third-party library to be to

  • either get the already compiled static library plus public headers
  • or get a self-contained project to build the above and then user projects to depend on the built library, and not on it's sources.

However, I have been unsuccessful in isolating a solution. The download, that I have linked in the top of the question, is 1.25GB in size, and consists various sources and makefiles.

My target is SAM4S and the board is fully custom.


To clarify, here are my reasons for thinking that my two points above are the cleanest way to integrate a third-party static library.

  • Version control - get the new versions of the library cleanly.
  • Separation - the library is logically not a part of the core project, for example it should not depend on the external project (otherwise - spagetti code).
  • Read-only - do not ever fall for the temptation to modify third-party code. Doing so 1. introduces bugs, because you generally lack the understanding of the library authors and 2. prevents updating to newer versions of the library.
  • \$\begingroup\$ I don't know the license off the top of my head, but generally, copy-pasting sources is a perfectly reasonable way to integrate a library. \$\endgroup\$
    – Dzarda
    Commented Jan 30, 2015 at 16:13

2 Answers 2


I think the question is why is a third party library supplied as source code rather than a pre-compiled object file to be treated as a black box.

Consider the compiler options that affect how code that makes calls to the library functions and handles returns from library functions is built. Are there compiler options that affect, for example:

  • Argument passing conventions (are arguments passed on the stack or in registers or a combination)
  • Endianess (some ARM cores are configurable as either big or little endian...not sure about the SAM4S)

If the same options are not used on both sides of the interface the program will fail.

Consider also that the source code from Atmel is used on several platforms including not only a variety of microcontrollers with ARM cores but also their AVR product line. How many different versions of pre-compiled static libraries would have to exist to cover the combinations of compiler options and microcontroller targets? The number of object files required to cover all of these permutations would simply be unmanageable.

I have to admit I'm a little unclear on how checking out a pre-compiled object file from a version control system is "cleaner" than checking out source files. If checking out only one pre-compiled object file versus checking out several source files is the concern, consider organizing the files such that the library source files are located in a well named sub-directory of their own. This doesn't reduce the number of files but may help with the clean/organizational aspect.


Here is an example of one possible reason:

The code need to set a couple of hardware pins assigned by the developer. If the library is given as source codes, the developer can #define the hardware pins and then the code inside the library could be


The references are constants and the line could compile to one processor instruction.

If the library is given as object files, inside the library the code would have to be something like

port_variable.OUT = (1 << pin0_variable) | (1 << pin1_variable) ;

The references are fetched from variables and the line would need to be a few processor instructions inside the library.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.