Fixed building faiss_c when OPT_LEVEL=avx2

[ava57r]

Fixes #1836

[Enet4]

I am confused about the recent decision to create different library build targets for the instruction set characteristics. Assuming that those faiss_c and faiss_avx2_c have the same set of exported symbols when built by the same machine, it is strange that we're contemplating them as different targets resulting in library files with different names as if the difference was more than implementation details.

I also expressed this concern in #1831 and Enet4/faiss-rs#19, and I would prefer the C API not to be affected by this replication, which so far seems only necessary for delivering "fat" binaries for conda packages. Rather, we would have a single faiss_c that would link against a valid native faiss library (regardless of which CPU capabilities are used).

[ava57r]

Oh, Yes. You are right. I copied from the parent cmake configuration.

[mdouze]

@beauby could you take a look?

[ava57r]

Could you include this fix in v1.7.1? issue #1915.

[Enet4]

As v1.7.1 is already tagged in this repository, I suspect this may have to be delayed to a later version. This can be mitigated by renaming libfaiss_avx2.so to libfaiss.so in the delivery/installation phase.

Still, it might be better to coordinate with #1877, as some of the decisions there might invalidate the need for these changes. In particular, if under a certain building configuration we can always ensure outputs named libfaiss.so or libfaiss.a, then building faiss_c would just work.

[ava57r]

@beauby could you take a look? :-)

[ava57r]

#1877 closed.

the library still does not support avx2 instructions for c_api main branch.