`ioreg` under cargo

[tamird]

baby steps toward building with cargo. @farcaller any advice on how to integrate cargo build/cargo test into the current rakefile infrastructure?

[farcaller]

Swap this

compile_rust :ioreg_crate, {
  source:    'ioreg/ioreg.rs'.in_source,
  produce:   'ioreg/ioreg.rs'.in_source.as_dylib.in_build,
  out_dir:   true,
  build_for: :host,
}

with a call to cargo. Effectively it's

task 'ioreg/ioreg.rs'.in_source.as_dylib.in_build => 'ioreg/ioreg.rs'.in_source do |task|

end

block

[tamird]

I'm not sure that cargo is expressive enough to capture all the arguments being passed in compile_rust. I don't suppose you know how that could be achieved?

[farcaller]

Based on the command line

rustc
  --opt-level 2 # covered by cargo
  -Z no-landing-pads
  --cfg cfg_mcu_has_spi --cfg mcu_lpc17xx --cfg arch_cortex_m3 # deprecated
  --target thumbv7m-none-eabi # covered by cargo
  -Ctarget-cpu=cortex-m3 -C relocation_model=static -C no-stack-check # covered by target spec json
  -g # covered by cargo
  -L /Users/farcaller/src/zinc/build # transient; solvable with symlinks
  --out-dir /Users/farcaller/src/zinc/build # ditto

there's only one flag (-Z no-landing-pads) that cannot be handled yet and it's not exactly a show stopper, I think.

[tamird]

@farcaller just rebased this - running into issues with the task syntax you suggested:

Gumby:zinc tamird$ rake PLATFORM=k20 -T
rake aborted!
Missing rule ioreg_crate
/Users/tamird/src/zinc/support/build/helpers.rb:33:in `block in resolve_deps!'
/Users/tamird/src/zinc/support/build/helpers.rb:31:in `map'
/Users/tamird/src/zinc/support/build/helpers.rb:31:in `resolve_deps!'
support/rake.rb:26:in `compile_rust'
support/rake.rb:141:in `rust_tests'
/Users/tamird/src/zinc/Rakefile:68:in `<top (required)>'
(See full trace by running task with --trace)

Any ideas on how to satisfy the dependency resolution?

[farcaller]

I'm actually working on the same problem from different point of view. Most of zinc can be built with cargo as is, only the actual application build process is different and will require additional handling. I'm trying to figure the proper extent of the linking issues, as some of them do belong to rustc, while others are really cargo's job. The point is, we'll hopefully get rid of ruby build toolchain.

[tamird]

@farcaller alright, awesome. I'll close this PR and let you take it from here.