Open kkysen opened 2 years ago
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.
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.
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
.
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?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
...
/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
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.
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.
Feel free to add more suggestions.
c2rust-*
prefixes? If so, we should put them on all of them (noanalysis/runtime
=>c2rust_analysis_rt
,dynamic_instrumentation
=>c2rust_dynamic_instrumentation
,pdg
=>c2rust_pdg
)?examples/
still used?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