Makefile.amand it did not have a
Makefiledid, although it was blank so it seemed strange to add my function that environmental variable since that does not seem to be the usual route. I also searched both of these make files for any other mentions of .cpp files (the function I want to add requires C++) and did not find any such files listed (like walktrap_communities.cpp, for example). So I'm not sure what to add where to get my file (truss.cpp, truss.h, and the code in examples/simple/igraph_truss.cpp) incorporated into the build system.
truss.h, there should not be one. You already added the function to
igraph_community.h. The functions you declare in that header are all private to one file, and are never used outside of that one. If you need forward declarations, I suggest you put them directly in that file.
\functionname must match the name of your function. https://github.com/igraph/igraph/pull/1034/commits/2bfd70fd7e035049a3ff4ccdddafe4ef4603d7df#diff-2423e8c5cf30a2ba737e72edce931764R35
iostream? I can't find where it's used. If it's not used, remove it. Note that igraph functions should not be writing to the terminal. https://github.com/igraph/igraph/pull/1034/commits/2bfd70fd7e035049a3ff4ccdddafe4ef4603d7df#diff-2423e8c5cf30a2ba737e72edce931764R28
Thank you, that works! I am able to build it successfully now. The problem was I was looking at
igraph/Makefile.am and not
igraph/src/Makefile.am. I have now updated
I will address the other comments soon.
@ntamas I would like to implement something for C/igraph that essentially looks like an iterable in Python. Is there anything I need to pay attention to to make sure that it can be included as an actual iterable in the Python interface?
To give an example, it would be comparable to finding cliques. Right now these problems are handled with callback functions: there's a function that generates all cliques and invokes the callback for all of them. The callback can signal to the main function to stop. But once we stop, we can't resume. What I want instead is to store the generator state in an object, and draw cliques from it as needed. I can resume any time for as long as I still have the generator object.
This would be a nicer design for cliques too, but in this case it would be for generating all graphs with a given property.
Hmmm, never tried to implement a Python iterable directly with the C API, but I guess it would go like this. Suppose that I add a new method on the
Graph object called
itercliques(). This would probably call down to your C function, which would then return some kind of a C data structure that stores the state of the iteration. I would then wrap it on the Python side in a Python capsule (https://docs.python.org/2/c-api/capsule.html), and create another Python object (the iterator) that stores a reference to the capsule and provides an
__iter__() method (returning itself) and a
next() method. The
next() method would then extract your data structure from the capsule call back to your C function to retrieve the next item.
The only thing to watch out for is probably to construct your iterable in a way that the invocation of the first function that constructs the iterable does not start the actual clique search process until someone calls
next() from the Python layer and invokes the second function.
examples/simple. But a test is not educational and an educational example is not a good test. What do you think about adding a new
testssubdirectory specifically for tests?