Skip to content

Support taking options from a file #2508

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

Open
davidben opened this issue Apr 19, 2023 · 3 comments
Open

Support taking options from a file #2508

davidben opened this issue Apr 19, 2023 · 3 comments

Comments

@davidben
Copy link

(This is a feature request.)

Bindgen has a lot of parameters that take regexes. --allowlist-file, in particular, takes a regex with file paths. Because bindgen seems to not properly normalize / and \ on Windows, and instead punts this basic cross-platform operation to the user, those regexes get quite complex. Escaping and quoting such things across build systems and platforms is, sadly, a nightmare. (Many build tools pass their inputs through the shell. It's a huge mess.)

Additionally, projects that need to support multiple build systems have to repeat parameters in multiple ways. Right now, a project's expected bindgen flags needs to be repeated in every build sytem.

bindgen should support some kind of config file that allows passing these options in a more defined manner.

@pvdrz
Copy link
Contributor

pvdrz commented Apr 19, 2023

Hi @davidben!

I have some points I'd like to discuss about your proposal:

The first one has to do with the composition and format of such configuration: If you want to avoid repeat parameters I suspect you'd want to have a "global" configuration file and then some platform-specific configuration files. So I'd imagine that you want bindgen to be able to not only read a configuration file but to be able to read several of them and combine them in a predefined manner.

The second thing is, I understand what you mean about / and \ as I've been bitten by that issue before. However, I don't see why having a config file would ease this issue.

Finally, Is there any reason why using bindgen as a library and write any specific logic in rust would not work?

@pvdrz
Copy link
Contributor

pvdrz commented Apr 19, 2023

Somewhat related: #1898

@davidben
Copy link
Author

davidben commented Apr 27, 2023

#1898 would work perfectly for this. We can probably merge this issue into that one. As for the other questions, I probably skipped some steps and should have filed an intermediary bug. 😄

First, why not bindgen as a library is that it does not interact well with other build systems. For my project, we need to support builds other than cargo, e.g. Android. Those often have hermeticity or cross-language requirements, so they cannot use build.rs. They need to drive bindgen via the command-line tool.

To that end, the / vs \ thing was my immediate modification, but I think this would be useful more generally. We're having rather a headache keeping the various bindgen invocations consistent. Something like #1898 would let us easily maintain the bindgen flags in one place and keep everyone using the same one.

The connection between / and \ to this request is extremely silly and frustrating. Some build tools (looking at you, CMake...) have very ill-defined escaping semantics, particularly cross-platform. Even among those that are well-defined (I at least hope the Android and Chromium builds are coherent here!), chasing down how many layers of backslashes I need for each one was too much fuss, so I just switched to [[:punct:]]. A file would avoid all this intermediate processing and I could write [/\\] in the regex.

That said, on reflection, I think / vs \ should just be handled internally by bindgen. On Windows, no one writes #include <openssl\\evp.h>, so I think bindgen should evaluate regexes against the canonical C spelling of the path. Not only that, whether a file appears as \ or / seems to be inconsistent! (I.e. I found that a /-only regex admitted some headers but not others, I suspect based on how the header was first included.) I haven't dug into why yet, when I've gotten details I'll file a bug.

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

No branches or pull requests

2 participants