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

rebuild plugin upon library changes #252

Closed
DieracDelta opened this issue Sep 30, 2020 · 4 comments
Closed

rebuild plugin upon library changes #252

DieracDelta opened this issue Sep 30, 2020 · 4 comments

Comments

@DieracDelta
Copy link
Contributor

Based on this, when a library dependency to a binary is updated, the binary is not relinked to support the new library. The solution here is, when the plugin is changed, to clean the plugin directory, then rebuild. This forces linking to the new version of the library. To accomplish this, we can watch the library from the root makefile, and on a change to that file, -clean the plugin before rebuilding.

@DieracDelta
Copy link
Contributor Author

This may be a fix. It adds in a an extra file under _build in the plugin folder that make tracks. Then when any of the library files have been modified after this extra file, bapbuild -clean is run. I'm not sure if this is the most idiomatic solution, but it seems to work (if just as a temporary fix). If this seems reasonable, I can open a PR.

I had initially wanted to use the version of the installed library, but that gets written to each time since currently invoking make always reinstalls the library.

@jtpaasch
Copy link
Collaborator

Off the top of my head, I don't think I have any objections to this.

The problem you're trying to solve is a problem caused by ocamlbuild, rather than from something we're doing. So really it's ocamlbuild that's forcing us to either (i) reinstall every time (which seems rather contrary to the whole point of make), or (ii) find some other solution.

This seems like a simple and clean way of accomplishing (ii). It's just a humble file, which doesn't intrude upon any of the other workings of anything. It can be removed easily if we ever get a better solution. Anybody else have any thoughts?

@fortunac
Copy link

I also have no objections! The change is very clean, and easy to read too.

@DieracDelta
Copy link
Contributor Author

closed with #255

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