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

Ekam takes unnecessarily long for multi-step builds (almost all builds) #63

Open
jyn514 opened this issue Oct 13, 2021 · 1 comment
Open

Comments

@jyn514
Copy link
Contributor

jyn514 commented Oct 13, 2021

Imagine a simple C++ project with main.c++ and helper.c++. One possible execution for Ekam is:

  1. Compile main.c++ -> main.o
  2. Attempt to link main.o -> main (since it has a main symbol). Fail, since helper.o isn't yet compiled.
  3. Compile helper.c++ -> helper.o. Notice that the new object file has symbols that were missing in step 2.
  4. Link main.o + helper.o -> main

Step 2 is unnecessary and slows down the build. This problem becomes worse as more steps are added (e.g. if some .c++ or .h files are generated by capnp or another tool).

One possible way to fix this is to allow .ekam-rule files to specify a priority, so that .capnp files are built before .c files, and .c before .o.

@kentonv
Copy link
Member

kentonv commented Oct 15, 2021

A simple priority doesn't work since to build a .capnp file you first need to build the capnp compiler tool which is itself compiled and linked from C++ source code. But with knowledge of the dependency tree from a previous run, we could be smarter about running things in the expected dependency order.

I'm not entirely convinced that Ekam actually wastes a whole lot of time on premature linking, though. The linker fails pretty quickly if symbols are missing. It would be nice to quantify this problem before spending time on it.

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