How to handle bindings generated as 'unkown' if they are in the specified namespace?
shakfu opened this issue ยท 4 comments
Hi, I've used binder in a couple of other projects (pyhola and also my fork of libpd). It's an awesome tool, and works amazingly well once you get going. Thanks for sharing it ๐
More recently, I have attempted to generate pybind wrappers for the taskflow header library, and my latest efforts are in this repo.
This has been going well (I can generate my binders so far without errors), however, a significant chunk of those are in the unknown category.
bind
โโโ taskflow
โ โโโ utility
โ โโโ uuid.cpp
โโโ taskflow.cpp
โโโ taskflow.modules
โโโ taskflow.sources
โโโ unknown
โโโ unknown.cpp
โโโ unknown_1.cpp
โโโ unknown_2.cpp
โโโ unknown_3.cpp
โโโ unknown_4.cpp
โโโ unknown_5.cpp
I saw in a reponse to close issue #1 that @lyskov defines unknown
as occurring
[if] C++ classes [are] not in the particular namespaces then bindings files for them will be located in /unknown/ dir,
In my case, there are functions and entities in unknown
that are clearly defined within the specified namespace (tf
).
Am I doing something wrong? The part in the makefile to generate the binding is:
SYS_CPP_INCLUDE=/Library/Developer/CommandLineTools/usr/include/c++/v1
SYS_C_INCLUDE=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include
PWD=$(shell pwd)
NAME=taskflow
ALL_INCLUDES=all_includes.hpp
CPP_STANDARD=-std=c++17
CONFIG_FILE=config.txt
NAMESPACE_TO_BIND=tf
NAMESPACE_TO_SKIP=std
all: regen
bind:
@mkdir -p bind
@binder \
--root-module $(NAME) \
--prefix $(PWD)/bind \
--config=$(CONFIG_FILE) \
--bind $(NAMESPACE_TO_BIND) \
--skip $(NAMESPACE_TO_SKIP) \
$(ALL_INCLUDES) \
-- $(CPP_STANDARD) \
-isystem $(SYS_C_INCLUDE) \
-I/usr/local/include \
-I$(SYS_C_INCLUDE) \
-I$(SYS_CPP_INCLUDE) \
-I$(PWD)/include \
-DNDEBUG
Thanks in advance, Any help on this issue would be greatly appreciated.
@shakfu could you please elaborate why having files in unknown
is problematic? From technical perspective we can put generated code in arbitrary named files/dirs. However for convenience Binder tries to name generated files after name of include file that declare them (see logic here: https://github.com/RosettaCommons/binder/blob/master/source/context.cpp#L47 ). But if relevant include could not be determent then code will be placed into unknown/unknown_x.cpp
file which seems the best thing to do in this case.
Hi @lyskov
Thanks for your reply. Actually, it's not problematic (just a bit time consuming) since usually the content of the unknown
files is very useful and I just have to categorize them myself manually. I'm actually doing this right now with my pyhola project.
I just thought from your earlier comment that I missed something or other configuration which could improve the hit rate of the auto-classifying mechanism you provided a reference to.
@shakfu i certainly agree that having generated code placed into unknown files is suboptimal. Such cases arise when this function https://github.com/RosettaCommons/binder/blob/master/source/type.cpp#L79 fail to calculate include file from which particular declaration comes from. So any PR's that could improve this would be welcome. As workaround: in my main project we use angular-includes even when including local project files and that allow Binder to always determent relevant include file name. Hope this helps.
Thanks for your tips. I'll make sure to follow your advice and see if the hit rate improves ๐