I think this should get split up in multiple PRs in order to better the review process. This issue shall become the tracking issue for the subtasks of the final PR.
After discussing it with @flip1995, it seems that running functional tests within the rust code would be best. This is what clippy does, for example here
This should be split into multiple sub-issues:
[x] Add valid tests application that gets run when executing cargo test #26
[x] Add abstraction around checking the validity of a test (exit code 0) and reporting this result to the developer #26
[x] The test harness shall only be compiled when running tests #26
[x] Checking that the objects created by both rustc and gccrs have the same filename #33
[x] Check for deps in target/[release|debug]/deps #33
[x] #41
[x] Check that static libraries are not empty #37
[x] #45
[x] Check that the objects created are of the correct file type: Executable, Shared object, Static object etc using readelf for example. #37
Once this test harness framework is done, add tests for the project
[x] Add functional testing to the CI #26
[x] Test the basic projects included in the repo as is (tests/binary_project, test/static_lib, etc...) #26
[ ] #43
[x] #44
Since all of these PRs wouldn't make sense by themselves, I think it would be best to create them against a specific branch such as feature/functional-testing and then merge this branch into master once the test harness is complete.
I started work on checking the correct file type for each binary produced, but noticed that gccrs and rustc have a different behavior when producing binaries #35
I think this should get split up in multiple PRs in order to better the review process. This issue shall become the tracking issue for the subtasks of the final PR.
After discussing it with @flip1995, it seems that running functional tests within the rust code would be best. This is what clippy does, for example here
This should be split into multiple sub-issues:
cargo test
#26rustc
andgccrs
have the same filename #33target/[release|debug]/deps
#33Once this test harness framework is done, add tests for the project
Since all of these PRs wouldn't make sense by themselves, I think it would be best to create them against a specific branch such as
feature/functional-testing
and then merge this branch into master once the test harness is complete.