@Gabor What was the plan with lsap.c and igraph_solve_lsap? Is it used for match_vertices in the R interface?
Is this equivalent to igraph_maximum_bipartite_matching? I am not very familiar with the topic.
Not sure but igraph_solve_lsap() is not used anywhere in the C core, so if it is R-specific, it should be moved to igraph/rigraph.
I am currently experimenting with the CMake build and it seems like excluding lsap.c from compilation does not change anything. igraph_solve_lsap() was never documented, but igraph_lsap.h is referred to from igraph.h, so if we are strict, we must say that it’s part of the public API now.
I agree with this.
I don’t think we should remove it.
It is used in R/igraph’s match_vertices, which would be nice to move to the C core eventually.
One thing that we need to sort out then is how to handle “unused” stuff inside these source files. I have started experimenting with CMake today, and I simply copied my usual CMake settings from another project of mine, which included -Wall -Wextra -Werror for gcc and /W4 /WX for MSVC. This makes the compiler complain loudly about all the unused functions that we leave lying around in source files that we vendor from elsewhere.
Sometimes this is useful; for instance, I got to discover today that the maxcompno argument was not handled in the strongly connected components algorithm (it was unused, and the compiler warned me that it was unused). But sometimes this is only a nuisance, especially in case of vendored source files. OTOH, I don’t want to micro-manage the compiler flags for every single source file; the best would be to say that we ensure that everything compiles even with -Wall -Wextra -Werror and then we can be relatively sure that we are not doing things that certain versions of C compilers don’t like.