Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packaging details for building against FAISS C++ API #669

Closed
cjnolet opened this issue Dec 21, 2018 · 6 comments
Closed

Packaging details for building against FAISS C++ API #669

cjnolet opened this issue Dec 21, 2018 · 6 comments

Comments

@cjnolet
Copy link
Contributor

cjnolet commented Dec 21, 2018

The documentation describes that FAISS builds shared & static libraries but these do not appear to end up in the installed Python packaging. Rather, the Python conda packaging only installs the swig-converted artifacts.

If a codebase, dependent on FAISS, is being built against the libfaiss.so and/or libfaiss_gpu.so artifacts, this leaves developers with the option of forcing contributors to build FAISS themselves, or including the libs in the codebase.

Further clarification on the ideal way of packaging against FAISS C++ API's would be ideal.

@mdouze
Copy link
Contributor

mdouze commented Dec 23, 2018

Yes, the .o files are combined into libfaiss.a + libgpufaiss.a.
For C++ packaging, they could just be combined into a single .so that depends on CUDA and a CPU BLAS implementation (usually MKL).
The problem is that properly linking with MKL is hard, and CUDA changes at each version. Therefore we have not done a binary distribution so far.

@cjnolet
Copy link
Contributor Author

cjnolet commented Jan 7, 2019

Assuming the users build your source before building libraries that depend on it, Would it make sense to have FAISS install the so files into a common directory already on the LD path (e.g. /user/lib64/faiss)?

We would also need to install the include files in /usr/include as well. This would allow other projects to depend on FAISS and just point their users to the FAISS source.

@mdouze
Copy link
Contributor

mdouze commented Jan 7, 2019

Absolutely. IMO the proper paths would be

/usr/lib64/faiss.so
/usr/include/faiss/Index.h
/usr/include/faiss/IndexFlat.h
...

I will talk to @beauby on where we can standardize this an if we can distribute a binary package.

@cjnolet
Copy link
Contributor Author

cjnolet commented Jan 7, 2019

Sounds good. I certainly don't mind providing a PR.

@cjnolet
Copy link
Contributor Author

cjnolet commented Jan 15, 2019

@mdouze @beauby, I'm preparing to get some changes merged in a project that depends on FAISS. Do you have any objections to changing the default libname / includedir in the build to be /usr/lib64 & /usr/include?

@beauby
Copy link
Contributor

beauby commented Jan 15, 2019

@cjnolet The current default values for libdir/includedir come from autoconf (see here). I do not feel strongly about it though, but in the meantime you can do ./configure --libdir=/usr/lib64 --includedir=/usr/include.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants