Clean rocksdb on make update.

[bhartnett]

Clean rocksdb on make update so that if rocksdb has been updated to a newer version, when running make nimbus rocksdb will be completely rebuilt from source.

[arnetheduck]

This won't catch manual updates to rocksdb - ie if I manually switch to a different nim-rocksdb commit, rocksdb should be automatically rebuilt (because the library it build previously is no longer valid)

[bhartnett]

This won't catch manual updates to rocksdb - ie if I manually switch to a different nim-rocksdb commit, rocksdb should be automatically rebuilt (because the library it build previously is no longer valid)

Are there any examples in the codebase that do something similar to what you are suggesting? Just thinking through the best way to implement that.

[arnetheduck]

nim-nat-traversal maybe

[arnetheduck]

basically, every time we build, we should run make in that folder in a way where rocksdb updates itself - the situation is the same as running make after switching checkouts in rocksdb manually, I'm sure they have some instructions for that ..

[arnetheduck]

and regarding cleaning, the ideal would be that after building the library (librocksdb.*), we would remove all intermediate .o files and other temporary build artefacts so they don't linger and take up disk space

[bhartnett]

and regarding cleaning, the ideal would be that after building the library (librocksdb.*), we would remove all intermediate .o files and other temporary build artefacts so they don't linger and take up disk space

Doing this is problematic at the moment because if I do a clean after building and copying the libraries then next time it will trigger another full rebuild which is very slow. I might need to redo/rewrite the nim-rocksdb build system to use a proper Makefile so that it can be smarter. Currently its just using a few build scripts.

[arnetheduck]

I might need to redo/rewrite the nim-rocksdb build system to use a proper Makefile so that it can be smarter.

yeah, possible - though I'd be a bit surprised if the Makefile that rocksdb ships can't deal with this, seems like a basic thing ..

[bhartnett]

I might need to redo/rewrite the nim-rocksdb build system to use a proper Makefile so that it can be smarter.

yeah, possible - though I'd be a bit surprised if the Makefile that rocksdb ships can't deal with this, seems like a basic thing ..

Well it does do the usual stuff like if files have changed then it will do a rebuild of the artifact. What it doesn't do is automatically do a clean if you update the files. The problem you ran into was that rocksdb was doing a rebuild as it should have because the files had changed but the build failed because the rocksdb version had changed and likely some src files removed or added etc between versions.

I'll need to somehow look at the git submodule status or something and if it changes then run the clean script to force the full rebuild.

[arnetheduck]

The problem you ran into was that rocksdb was doing a rebuild as it should have because the files had changed but the build failed because the rocksdb version had changed and likely some src files removed or added etc between versions.

oh weird, sounds like a bug to report to them.. ie if I switch tags in their checkout, they should rebuild their deps automatically.

[bhartnett]

The problem you ran into was that rocksdb was doing a rebuild as it should have because the files had changed but the build failed because the rocksdb version had changed and likely some src files removed or added etc between versions.

oh weird, sounds like a bug to report to them.. ie if I switch tags in their checkout, they should rebuild their deps automatically.

Actually if I switch from using the RocksDb Makefile to using vcpkg to build the static libraries, that might fix this problem.