====== 2016-01-07 - ar vs. cmake ======

some time ago i've came across an interesting "feature" of //ar//((tool for creating static libraries on linux)) -- it does not store full paths to object files internally. instead it just keeps its name. most of the time this is not a problem. however, if you happen to have more files than command line can fit, creating archive need to be split into multiple calls: creating a libraries and then adding objects groups (multiple times, if needed). //cmake// does that by default. now if you happen to have object files, named the same, but stored in different directories, and try to add such objects to a static library with //ar//, you'll end up overwriting old object file, stored inside the archive, with a new file, that just happened to have the same name.

effect? linking error! it's extremely user fiendly((it's not a typo! ;) )) as you can clearly see your objects are being added to the archive, yet linker says implementation, stored there is missing!

the only way i could think of, to overcome this coincidence of 3 random facts/rules/limitations, is to create helper libraries, that are small enough, to be linked into a single libraries, and then add these libraries as a dependency to "final" library, so that users will not need to be aware of this implementation detail.

btw: if you think 32k is a lot, consider how long nested, auto-generated paths inside build directories, can be! it may not take that many files to trigger such behavior... but took over an hour to find. IT -- every day something new! ;)