Which classes and functions are left out? about binder HOT 11 CLOSED

Binder will generate bindings code for all classes/functions/enums that is bindable. Besides that the only reason for skipping code generation is if bindings for such namespace was not requested. To request bindings for particular namespace/class/function please use configuration file options described here: http://cppbinder.readthedocs.io/en/latest/config.html#config-file-directives

If you believe you have a case when particular class should be bound but did not: could you please create a minimal code example to reproduce it and post it here?

from binder.

Just to elaborate on my previous comment: unless you have set of template classes without instantiation points they all should be bound. If this does not happening then it must be configuration issues (i.e. Binder does not think that it should bind these classes)- please check your configuration options. If you can post your namespace layout and config options i can try to figure out what might be wrong.

from binder.

Okay, thanks for the clarifications!

I tried to make a minimal example, but that became really weird. My process was as follows:

1. Delete some (probably) not needed headers.
2. Run binder and check whether anything changed.
3. Repeat until minimal example found.

But while deleting files, suddenly there were bindings for the classes that were previously missing. So I played around a bit, also commented out some functions and #include directives in some headers etc, and every time I got different classes being bound and others not.

So far, I was not able to boil it down to some cause and effect. So, there seems to be some weird issue with the order of including other files, dependencies between headers or something like that.

If you want, I can prepare a not-so-minimal example and some instructions on how to reproduce at least one of those weird changes. But first I wanted to ask whether you have any idea what is going on there. This might help me pinning it down a bit.

from binder.

Aha! This sounds very much like a problem with include guards or forward declarations. If you getting getting different results depending on file orders in 'all_includes.hpp' that you use as an input to Binder then the most probable cause is that some of the .h files might have same include guards as the other. Also, note that if you have old files in the same dir which might have the same include guards it will causes similar issues.

Also, i just double check on code that decide bind/not-to-bind particular class/struct and in short logic is following:

1. class must have complete definition (i.e. be fully declared not forward declared)
2. it should not be anonymous class (you probably do not need to be worry about this one)
3. if class is template specialization it should be fully specialized (no free template arguments left)
4. class should be in namespace that is configured for binding

So in short, you should see code for all bindable classes unless they was specifically excluded.

How big is your not-so-minimal example?

from binder.

Thanks for the quick feedback!

It might indeed be an issue of header order and forward declarations. However, I am not sure whether the issue is with my code or yours.

• Duplicate header guards: I actually have a script to check this, so it is not the problem.
• Order of includes: I try to keep everything clean and order-independent, but there might be a flaw that I never noticed before.
• Forward declarations: I am not sure whether I understand what the problem there is. Can binder 'misinterpret' them somehow?

Please find attached an as-minimal-as-I-dared-to-make-it example:

lib.tar.gz

It contains a folder with headers and a script run_all.sh. There, set the three paths as needed.
In the last part of the script, I deactivated an rm command, so that you don't accidentally lose files. Activate it once you have set the correct path to the output dir.

The script first creates a header genesis.hpp that includes all other headers. Then it runs binder and shows the created files for the subdirectory placement.

1. In the first run, there is one file placement_tree.cpp. Others are missing.
2. Now delete the according header placement/placement_tree.hpp. Run the script again. Now it contains pquery.cpp and a dir with one file pquery/name.cpp. The other file pquery/placement.cpp (for which there is a header) is still missing though.
3. Now for the totally weird part. In tree, delete both directories function and iterator. Run the script again. Suddenly, the pquery.cpp is gone from the output again. As far as I can tell, there are no dependencies between the remaining files in placement and the two now-deleted directories in tree.

Let me know if you have any idea what is going on, or need further clarification. Oh, and sorry for the weird names of my classes...
Thanks a lot!

from binder.

Okay, now I get it. It seems that the bindings are all generated, but scattered over different files. As the output files are all named after actual files from my lib, I simply assumed that there would be one output file for each input file, containing the bindings for classes and functions declared in that file.

This seems not to be the case. There can be many classes per output file. Using the binder option --max-file-size 1, I now was able to generate separate files for each input file/class (and suddenly I understand what this option is for!). The documentation is a bit sparse on this.

Now however I get a warning

Warning: file_name_for_decl could not determent file name for decl: std::hash<unsigned long>, result is too short!

which maybe can be ignored.

This still does not explain why the generated files change when deleting totally unrelated headers (see step three in my last post). Maybe it does not matter, but still is confusing.

I am now trying to figure out whether actually all bindings are generated and work. Sorry for not checking this before!

from binder.

Glad to hear that this is sorted out!

Reason for existence of option --max-file-size is to limit amount of generated code in single file (because other wise compilation will slowdown to crawl and memory requirements will skyrocketing).

Re 'why bindings changed if i defeated some files': Binder tries to be 'smart' and tries to avoid generating new source files if previous file is still below max-file-size so deleting some of the includes will change how generated code split between the files and potentially change the names of generated files as well. So in short: this is expected behavior.

Re Warning: file_name_for_decl could not determent file: - this is probably could be ignored if results is compiling ok. If not, we can revisit it later. On what platform this is happening? Linux or Mac?

I am going to close this for now, but let me know if you still thing there is an issues with this.

from binder.

Thank you very much! I'm using Ubuntu 14.04.
Re "if result is compiling": See issue #13, unfortunately it is not compiling...

from binder.

I'm currently trying to compile the Binder-generated code, and for this it would really be helpful if Binder simply wrote the binding code for each class and function into a file that is named like the file where the class/function was declared. Is there an option for this?

from binder.

Currently there is no option for such output. But may i ask why would you like to have something like that? It seems to me as a very inconvenient way to organize things since we can not guarantee that each source files will be matched to generated binding file (because some source files will not produce any bindings).

Or do you need a way to track what files was generated? If so then in the output directory you should be able to see <root-module>.sources file which contain list of source files that was generated during bindings - simply feed it into CMake or other build system of your choice.

Also if you need to track all Python sub-modules that was generated: see file <root-module>.modules in output dir.

from binder.

This would be helpful to manually edit the generated bindings files, in cases where Binder did not generate the code that I need (or does not compile, see #13). Then, if there is an issue with MyClass, I could simply look into the binding file my_class.cpp, instead of needing to grep for where the binding for this class was generated to. Also, I just find it a more 'natural' way of creating bindings files. In case of files that do not produce any bindings, of course, no file would need to be written.

As for knowing which files and modules are generated, I already figured out the .sources and .modules as helpful, thanks. Right now, my CMake script does a glob search anyway, so this is not an issue for me. (I know, this is not really recommended, but there is a way of making CMake search for new files while still being able to incrementally build, so this is working for me.)

from binder.