Skip to content

Embed custom files.#306

Closed
ralfbiedert wants to merge 3 commits intomozilla:masterfrom
ralfbiedert:embed
Closed

Embed custom files.#306
ralfbiedert wants to merge 3 commits intomozilla:masterfrom
ralfbiedert:embed

Conversation

@ralfbiedert
Copy link
Copy Markdown
Contributor

Addresses #303.

Note that this is a breaking change, as generate_with_config now requires a config_root to be passed, which specifies relative to what embed requests should be loaded.

It could theoretically be done without breaking that call, but then either

  • config would have to contain implementation details about where it was loaded from, or
  • [embed] is likely to break when used as it doesn't know where to get files from

@ralfbiedert
Copy link
Copy Markdown
Contributor Author

Note this also addresses #211.

Copy link
Copy Markdown
Collaborator

@emilio emilio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks reasonable over-all, but I'd rather let @eqrion weigh-in from the API-POV :)

let src_file = self
.root
.as_ref()
.expect("Bindings::root must be set when embedding files.")
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know, using cwd by default, or config location otherwise doesn't seem too bad.

If I specify the path as an absolute file, which is more than likely when ran from build.rs, it doesn't seem necessary to have to provide a root path... But I'm very bad at API design myself, and this seems ok I guess.

Maybe @eqrion can take a look and comment on this?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel strongly that the directory hosting the used cbindgen.toml must be the relative anchor for embeds, as that's the only thing you can rely on without thinking too much. Any working dir is random, and the Cargo.toml can get mildly ambiguous when generating bindings for a sub-project.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think having these paths be relative to 'cbindgen.toml' makes sense. I'm not great at API design either, so it's not a strong feeling.

Copy link
Copy Markdown
Collaborator

@eqrion eqrion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, just one comment. Apologies for the delay.

let src_file = self
.root
.as_ref()
.expect("Bindings::root must be set when embedding files.")
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think having these paths be relative to 'cbindgen.toml' makes sense. I'm not great at API design either, so it's not a strong feeling.


/// A utility function for build scripts to generate bindings for a crate with a
/// custom config.
pub fn generate_with_config<P: AsRef<Path>>(
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we keep this API unchanged and default to no root when providing an in-memory configuration?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can do that, but then I would make embed panic if an embed was requested but no root was given.

@ralfbiedert
Copy link
Copy Markdown
Contributor Author

Just an update. After the problem with the unit tests on Mac #330 I finally got my hands on a Windows machine.

When I try to run the test cases there (cargo test) on the latest master, I now receive a totally different set of error messages, such as

test_transparent stdout ----
Running: "D:\\Development\\Source\\_thirdparty\\cbindgen\\target\\debug\\cbindgen" "--lang" "c" "--cpp-compat" "--style" "type" "-o" "D:\\Development\\Source\\_thirdparty\\cbindgen\\tests\\expectations\\transparent.compat.c" "D:\\Development\\Sourc
e\\_thirdparty\\cbindgen\\tests\\rust\\transparent.rs"
Running: "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\VC\\Tools\\MSVC\\14.21.27702\\bin\\Hostx64\\x64\\cl.exe" "-D" "DEFINED" "-c" "D:\\Development\\Source\\_thirdparty\\cbindgen\\tests\\expectations\\transparent.compat.c" "
-o" "D:\\Development\\Source\\_thirdparty\\cbindgen\\tests\\expectations\\transparent.compat.o"
thread 'test_transparent' panicked at 'Output failed to compile: Output { status: ExitStatus(ExitStatus(2)), stdout: "transparent.compat.c\r\nD:\\Development\\Source\\_thirdparty\\cbindgen\\tests\\expectations\\transparent.compat.c(1): fatal error
C1034: stdarg.h: no include path set\r\n", stderr: "Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for x64\r\nCopyright (C) Microsoft Corporation.  All rights reserved.\r\n\r\ncl : Command line warning D9035 : option \'o\' has been d
eprecated and will be removed in a future release\r\n" }', tests\tests.rs:82:5

While the specific error message changes with the type of environment I load, the result is basically that I can't run the test cases to verify what I do works.

I will close this pull request for now because we worked around the original embedding problem and I'm just sidetracking. I would like to keep #303 open though because it still has value, and it would have saved us work in the first place.

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

Successfully merging this pull request may close these issues.

3 participants