Consider – as time goes by, liblfds supports more platforms. 7.1.0 supports MIPS. 6.1.1 did not. If benchmark benchmarks all version of liblfds, well, then it will try to include the earlier version’s header file and it will try to link to its library.
The header file is fine – it will work, and it can be modified (I can make bugfix releases for earlier versions) to make public which data structures are available. The library file *isn’t* fine, because right now it has to be hard coded in the makefile…!
It’s the libnuma problem all over again. With libnuma, I have a second build type. Adopting that solution for liblfds versions would mean one of two things, depending on whether the assumption is made platform support only increases over time. If as releases go by, platform support extends, then we’d end up with one extra build variant per release, i.e.;
This would be doubled, because of libnuma.
However, if platform support can simply *vary*, then this approach becomes awkward.
I am however strongly inclined to the view it will only increase over time.
However however, this then leaves the user with what on the face of it is an awkward problem – when the user comes to build, he sees these build variant directories, and to select the correct variant, he has to know what releases of liblfds he can build.
OTOH that’s not so hard – he can just try to build them, and see if they build okay.