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

Building with make takes an absurd amount of time and space #46

Open
Mego opened this issue Jan 27, 2018 · 4 comments
Open

Building with make takes an absurd amount of time and space #46

Mego opened this issue Jan 27, 2018 · 4 comments

Comments

@Mego
Copy link
Contributor

Mego commented Jan 27, 2018

After running make for about 60 hours, 108 GB of disk space was taken up, and the tests were not finished. I have some suggestions to make building and testing better:

  • Make a configure script to set the languages to build (via the presence of tools on the system and command-line flags like --enable-c and --disable-tm), which will generate a Makefile from a template (via automake).
  • Refactor the Makefile to be more modular:
    • Separate building and testing into different targets (build and test).
    • Create targets for building and testing individual languages (e.g. build-cpp and test-js).
    • Create a test-full target that runs expensive tests (e.g. 3-stage bootstrap tests), which are not included in the regular test target.
    • Properly clean up test files after each test to reduce filesystem impact.
@shinh
Copy link
Owner

shinh commented Jan 28, 2018

As you said, running make is not realistic. However, I doubt splitting the build to configure and make helps. For most cases, you are developing a single target (say xxx) so you'll just enable the single target by something like ./configure --disable-all --enable-xxx. This can be already done by simply running make xxx. It'll check xxx backend is equivalent to EIR representation. Also, make elc-xxx should be able to test target/xxx.c can run on ELVM. IIRC running these two tests almost always makes sure the xxx backend can self-host.

That said, I agree current make is quite confusing. How about

  • make without any target fails with some help messages which suggest using make xxx instead.
  • Split make xxx into make build-xxx and make test-xxx as you suggested.
  • I think make elc-xxx is confusing. Probably this should be renamed to make test-full-xxx.
  • Files in out/ are very useful for debugging. Doesn't just running rm -fr out when necessary work?

@shinh shinh mentioned this issue Jan 28, 2018
@shinh
Copy link
Owner

shinh commented Jan 28, 2018

How about something like #49 ?

@Mego
Copy link
Contributor Author

Mego commented Jan 29, 2018

It's a start, but it would be nice if the Makefile was set up in a more traditional fashion:

  • make builds everything that is enabled by the configure script (or, lacking a configure script, the default options)
  • make test tests everything that is enabled (building if not already built)
  • make build-x builds the x backend
  • make test-x tests the x backend (building if not already built)
  • make test-x-full tests the x backend, including self-hosting
  • make build-all builds everything (even things not built by default)
  • make test-all tests everything
  • make test-all-full tests everything, including self-hosting (the current default target for make)

By cleaning up test files, I mean removing them after successful tests. Naturally, you'd want to keep them after failed tests so you can see what went wrong, but they're unnecessary after successful tests, and it would help save a lot of space if they were cleaned up after each successful test.

@shinh
Copy link
Owner

shinh commented Jan 29, 2018

I changed the behavior of the default make so it now builds tools like out/8cc and out/elc. No tests are built/run by the default make. I also renamed test-full-xxx to test-xxx-full. I've merged my PR as it seemed to be better than the current behavior anyway.

I'm still not sure configure will be useful. Note out/elc have all backends anyway. build-xxx and test-xxx are just about building/running tests.

I tend to prefer keeping intermediate files even after successful tests.

These two points are just my preference. I don't want to do these changes by myself, but I won't oppose them either. If you don't like the current behavior, please feel free to fix it and send PRs. I'll just merge them.

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

No branches or pull requests

2 participants