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

Changes for esp-idf-sys cmake build #14

Merged
merged 16 commits into from
Sep 7, 2021
Merged

Changes for esp-idf-sys cmake build #14

merged 16 commits into from
Sep 7, 2021

Conversation

N3xed
Copy link
Collaborator

@N3xed N3xed commented Sep 1, 2021

Third batch for #8.

Steps

  • Refactor mcu detection (decouple it from platformio) (moved to build script)
  • Git utilities
    • Clone specific tag or branch
      • automatic pull if out of date
      • specify the tag or branch which should be kept up-to-date
    • Apply patches
  • Maybe better python utilities
    • Detect python executable
  • File utilities
    • Copy directory/files if contents differ (only files for now)
    • Remove directory with contents
  • cmake utilities (add them here, commit them to the cmake crate, or both)
    • cmake file api
    • cmake toolchain file CMAKE_C_FLAGS/CMAKE_CXX_FLAGS/CMAKE_ASM_FLAGS extraction
      • currently they are silently overridden because the cmake crate sets these
  • bindgen
    • Create bindgen::Builder from cmake metadata
  • Implement LinkArgsBuilder, CInclArgs, CfgArgs for cmake
  • Test

Add dependency `remove_dir_all`
Note: On windows `std::fs::remove_dir_all` doesn't really work (rust-lang/rust#29497).
Publicly export the `which` crate
Remove `log` dependency of `cmd*` macros.
@ivmarkov
Copy link
Collaborator

ivmarkov commented Sep 2, 2021

Looks OK to me. If you want me to merge it, I'll merge it? cmake utils and "maybe better python" can be another iteration.

@ivmarkov
Copy link
Collaborator

ivmarkov commented Sep 2, 2021

Not really sure about this file contents' comparison, but I assume your plan is to use this for small stuff, like sdkconfig's and similar?

@N3xed
Copy link
Collaborator Author

N3xed commented Sep 2, 2021

Not really sure about this file contents' comparison, but I assume your plan is to use this for small stuff, like sdkconfig's and similar?

Yup.
If I copy the files every time the build script is executed, cmake detects that the file has been modified (even if its content didn't actually change) and reconfigures the project. To get around this I copy the file only if its content is different.

An addition to that would be to copy an entire directory if its content is different (and then only copy the files that are different), but I was too lazy to implement that just yet.

Looks OK to me. If you want me to merge it, I'll merge it? cmake utils and "maybe better python" can be another iteration.

I'd prefer to merge only after I can at least build the esp-idf-sys with this. I'm creating the esp-idf-sys native build script along with modifying embuild so that I can see what I still need to add or move here.

@N3xed N3xed changed the title WIP: Changes for esp-idf-sys cmake build Changes for esp-idf-sys cmake build Sep 6, 2021
@N3xed N3xed marked this pull request as ready for review September 6, 2021 16:05
@N3xed
Copy link
Collaborator Author

N3xed commented Sep 6, 2021

Okay, this should do it for now. I've also updated my PR on the esp-idf-sys repo.

Comment on lines +22 to +30
pub fn from_scons_vars(scons_vars: &pio::project::SconsVariables) -> Result<Self> {
let clang_args = cli::NativeCommandArgs::new(&scons_vars.incflags)
.chain(cli::NativeCommandArgs::new(
scons_vars
.clangargs
.as_deref()
.unwrap_or_default(),
))
.collect();
Copy link
Collaborator Author

@N3xed N3xed Sep 7, 2021

Choose a reason for hiding this comment

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

I've not tested this yet. But I guess this would only cause problems if SconsVariables::incflags and clangargs contained unescaped doube-quotes (") which would be removed by NativeCommandArgs on windows. And on unix unescaped ', " or \.

Copy link
Collaborator

@ivmarkov ivmarkov left a comment

Choose a reason for hiding this comment

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

Overall: I think the code quality is very good, so I'm willing to merge as-is (and to give you commit privileges if you want) afterwards.

There are two comments that need addressing (see below), but that you can surely fix post-merge.

There are a few more in the esp-idf-sys native build patch that definitely should be addressed, but I'll put them there, and the esp-idf-sys PR is still a Draft, so having those issues is OK.

I've given you approve privileges so you can merge yourself before/after fixing these changes.

Please let me know if you would like to have commit privileges.

src/git.rs Show resolved Hide resolved
src/cmake/file_api/toolchains.rs Show resolved Hide resolved
Add `git::Repository::apply_once`
Add `git::Repository::is_applied`
Publicly export `anyhow` (hidden from docs) because some macros need it.
Fix `cmd_spawn`
Add `cmd` variation that returns `Result<ExitStatus>`
Check the cmake version for support of a specific file-api object kind.
@N3xed
Copy link
Collaborator Author

N3xed commented Sep 7, 2021

Please let me know if you would like to have commit privileges.

I would very much appreciate that. We'd have to coordinate development then somehow, wouldn't we?

you can merge yourself before/after fixing these changes

Nope, github still says "Only those with write access to this repository can merge pull requests.".

@ivmarkov
Copy link
Collaborator

ivmarkov commented Sep 7, 2021

Please let me know if you would like to have commit privileges.

I would very much appreciate that. We'd have to coordinate development then somehow, wouldn't we?

Indeed. For small bugfixes, I think no coordination necessary. For refactoring (big API breakages) as well as for introduction of new APIs, we should probably still file PRs, or at least write a short suggestion in the form of a new issue so that we can peer review.

you can merge yourself before/after fixing these changes

Nope, github still says "Only those with write access to this repository can merge pull requests.".

I've send you the invitation now. Once you confirm, you should be able to get write access.

@N3xed
Copy link
Collaborator Author

N3xed commented Sep 7, 2021

Indeed. For small bugfixes, I think no coordination necessary. For refactoring (big API breakages) as well as for introduction of new APIs, we should probably still file PRs, or at least write a short suggestion in the form of a new issue so that we can peer review.

Agreed.

Ok, I'll squash merge this now, so that I can continue with solving the command-line length problem.

@N3xed N3xed merged commit 6fdf7ea into esp-rs:master Sep 7, 2021
@N3xed N3xed deleted the dev branch September 7, 2021 18:36
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.

2 participants