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

Experiment with generating all #75

Closed
adetaylor opened this issue Nov 8, 2020 · 5 comments · Fixed by #438
Closed

Experiment with generating all #75

adetaylor opened this issue Nov 8, 2020 · 5 comments · Fixed by #438
Labels
good first issue Good for newcomers

Comments

@adetaylor
Copy link
Collaborator

At the moment, it's mandatory to provide one or more allow directives. They builds the allowlist which we feed to bindgen. However, if no allowlist is fed to bindgen it attempts to generate bindings for everything which it encounters in the header files.

It might be worth adding an allow_all directive which bypasses the creation of the NoAllowlist error but has no other effect: this should be sufficient to ask bindgen to generate bindings for everything.

In practice, with realistically complex headers (i.e. using STL), I expect problems correctly interpreting some of the items in the headers. But that's probably a good reason to try.

@adetaylor adetaylor added the good first issue Good for newcomers label Nov 8, 2020
@adetaylor
Copy link
Collaborator Author

allow has since been renamed to generate so this would become generate_all

@martinboehme
Copy link
Collaborator

I think there could be a worthwhile middle ground here: Generate bindings not for everything, but for all definitions contained directly in the headers mentioned in the include_cpp! (i.e. not in transitively included files) and for all types used in those definitions.

This would be in the spirit of "include what you use". It would also avoid producing the really large amounts of output that a true "generate all" might produce on a header that pulls in a lot of definitions through transitive includes. It would, however, require some modifications to bindgen, I think.

BTW, should the title of this bug be renamed to "Experiment with generate_all"?

@adetaylor adetaylor changed the title Experiment with allow_all Experiment with generating all Apr 19, 2021
@adetaylor
Copy link
Collaborator Author

Thanks for the suggestion. I hadn't thought of it, but I'd be a bit concerned that some projects might expose a "logical" header to their clients which actually just #includes a further set of headers for their implementation. C++ projects might feel free to move things around internally between header files, so this could cause breakage when people upgrade to new versions of those projects. WDYT?

@martinboehme
Copy link
Collaborator

Hm, that's true.

Essentially, this would require something akin to pub use on the C++ side to mark a header as "re-exported". The "include what you use" tool defines the export pragma for this, but this is obviously specific that particular tool, so it wouldn't be suitable for our purposes.

Probably, the only good solution to this is to use C++ modules, which make all of this explicit, but this doesn't seem worth doing before C++ modules come into widespread use.

It might still be worth offering this a "generate all from header" option for use in projects that have a convention that only declarations from a header itself should be used.

@adetaylor
Copy link
Collaborator Author

OK, I had a crack at this today in #438.

Conclusions:

  • We need to think on the syntax for this. It would be nice to generate everything by default in the absence of any generate! directives so that people can just do:
autocxx::include_cpp! {
  #include "foo.h"
}

... but that conflicts with the current POD declaration style.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants