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

the compile rule should be smarter about when it can avoid rebuilds. #28

Open
zenhack opened this issue Feb 20, 2020 · 3 comments
Open

Comments

@zenhack
Copy link
Contributor

zenhack commented Feb 20, 2020

In particular, right now I'm doing some print debugging and tracing an issue I'm having in the bridge down into stuff defined in libkj. Adding a simple print statement to a .c++ file should only require re-building the one file, and re-linking anything that uses the resulting object. Instead, ekam is re-compiling a whole bunch of stuff downstream in capnp and in sandstorm.

@zarvox
Copy link
Contributor

zarvox commented Feb 20, 2020

Is that behavior wrong? I'm imagining that changes to libkj would dirty the capnp compiler binary, and then any generated code output by the capnp compiler is dirtied (since it was one of the inputs to that rule), and then anything that depends on that generated code is also dirtied, which covers the rest of the stuff in capnp and sandstorm.

@zenhack
Copy link
Contributor Author

zenhack commented Feb 20, 2020 via email

@kentonv
Copy link
Member

kentonv commented Feb 20, 2020

Yes, this is probably what's going on. It is admittedly very annoying.

Maybe capnpc.ekam-rule should be adjusted to support specifying an external compiler binary as an environment variable, in which case it won't use the one built by the ekam build itself. You could use that while developing if you know you are going to change files that become part of capnp but you do not expect to be modifying the output.

A better solution would be for ekam to recognize when the code generated by capnp is identical to what was generated before the change, and then it can skip rebuilding anything that depended on that code. But that's a lot more complicated...

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

3 participants