Reorganize directory structure

[kkysen]

Feel free to add more suggestions.

• Should crate names match directory names? Should we keep the c2rust-* prefixes? If so, we should put them on all of them (no analysis/runtime => c2rust_analysis_rt, dynamic_instrumentation => c2rust_dynamic_instrumentation, pdg => c2rust_pdg)?
• Is examples/ still used?
• Reorganize scripts/:
  • provision/:
    • provision.sh => all.sh
    • provision_(.*).sh => $1.sh
  • keys/:
    • llvm-(.*)-key.asc => llvm/$1.asc
  • test/:
    • test_(.*).py => $1.py
    • integration_test_translator.py => translator_integration.py
  • util/:
    • common.py
    • rust_file.py
    • get-binary-names-from-cargo-metadata.mjs
    • pretty-instrument-err.mjs
  • .flake8
  • build_translator.py
  • cborpp.py
  • convert_build_commands.py
  • csmith.py
  • docker_build.sh
  • link_manual.py
  • package.py
  • pdg.sh
  • print_clang_ast.py
  • requirements.txt

[thedataking]

Re. reorganizing scripts, adding subdirectories sounds like a good idea but I'm against renaming most of the scripts just to make them shorter. If anything pdg.sh and other terse names need to be longer and consistent with the overall style of the project.

[kkysen]

Okay, renaming isn't too important (though I thought maybe we don't have to repeat the directory name in the file name), but having more specific directories would definitely help.

[thedataking]

I think the focus should be on the new top level directories. (Whatever we do with scripts is a smaller issue overall.)

The "old" directories say something about what they do "c2rust-ast-exporter", "c2rust-ast-builder", "c2rust-ast-printer", "c2rust-transpile", "c2rust-refactor". Also, the current command line interface is c2rust <verb> where c2rust <verb> causes c2rust-verb to run. E.g. c2rust transpile ... runs c2rust-transpile.

candidates for renaming

• pdg: most folks will not realize that this stands for program dependence graph.
• dynamic_instrumentation: uses underscores instead of kebab case.
• analysis
• rustc-private-link: not sure this is c2rust specific, couldn't this be a crate on crates.io or a separate repo?

suggested organizing principle

We figure out what commands we plan to add to c2rust. If there is going to be a c2rust lift command, we put the related code under a top-level directory called c2rust-lift. Lift is just an example, the actual verbs may be instrument, observe, analyze, rewrite ...

Example (very likely inaccurate, just trying to get an idea across)

/c2rust
/c2rust-transpile
/c2rust-refactor
/c2rust-instrument
  /dynamic-instrumentation
  /instrumentation-runtime
  /program-dependence-graph # or, alternatively, pdg-builder
  /rustc-private-link # assuming this cannot be its own repo or crate
/c2rust-lift
  /static-analysis
/scripts
/tests
/examples

[kkysen]

Re rustc-private-link, that can definitely be moved to an external repo and crates.io package. It does make sense to at least initially keep it as a workspace crate, though, as then it's easier to keep it in sync with the rest of the c2rust code and have branches and PRs be able to modify it, too. Once it's a bit more stable, though, making it a separate repo and package is a good idea I think. Where would I put that? Under immunant/? It seems quite small and pretty general, though, as it'd be useful to any project that's using rustc private crates, so I could also maintain it myself separately as well if you'd like.

[thedataking]

Where would I put that? Under immunant/? It seems quite small and pretty general, though, as it'd be useful to any project that's using rustc private crates, so I could also maintain it myself separately as well if you'd like.

Great. Either option (immunant or under your personal kkysen account) sounds good to me; your call.