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

Fix make cleanall && make #18417

Merged
merged 1 commit into from
Sep 9, 2016
Merged

Fix make cleanall && make #18417

merged 1 commit into from
Sep 9, 2016

Conversation

tkelman
Copy link
Contributor

@tkelman tkelman commented Sep 9, 2016

since cleanall was deleting shlibdir but not manifest,
was unable to link suitesparse_wrapper against cholmod etc

the buildbots have not been very happy, see e.g. https://build.julialang.org/builders/build_ubuntu14.04-x64/builds/1405/steps/shell_1/logs/stdio

since cleanall was deleting shlibdir but not manifest,
was unable to link suitesparse_wrapper against cholmod etc
@tkelman tkelman added the domain:building Build system, or building Julia or its dependencies label Sep 9, 2016
@staticfloat
Copy link
Sponsor Member

This seems pretty straightforward; going to merge it so that the buildbots can continue spitting out binaries. The takeaway from this is that there is now no difference between cleanall and distclean for the julia build; the only difference is for dependencies.

@staticfloat staticfloat merged commit 85f2bc7 into master Sep 9, 2016
@tkelman tkelman deleted the tk/cleanall branch September 9, 2016 21:20
@tkelman
Copy link
Contributor Author

tkelman commented Sep 9, 2016

right. the previous make cleanall would force all deps to redo their install because the shared libs were used as the makefile dependencies. now that's no longer the case, deleting the shared libs doesn't trigger anything as far as make is concerned. not ideal imo.

an alternative to deleting the whole prefix here would be running uninstall for all the deps, but i don't trust that to be fully working yet.

@staticfloat
Copy link
Sponsor Member

This is due to the new manifest files that make depends on, right? @vtjnash, I believe you were the one to make this change recently, could you give us an idea on how these manifest files are supposed to deal with a situation like this? Is the "proper" answer to delete the manifest files to force the reinstallation of libraries? What benefit do these manifest files have over simply relying on the libraries themselves? It seems to me that this will make it very easy for devs to delete a shared library, expecting it to be reinstalled when they run make again, then being surprised when the files are not installed again.

@vtjnash
Copy link
Sponsor Member

vtjnash commented Sep 9, 2016

Yeah, now you could just delete manifest/dep instead of trying to guess the random correct library file to delete to get it to reinstall. Or you can just remove all of usr (install is fast now). Or you can run make -C deps reinstall-dep.

We could even put the total set of installed files into the manifest file and check manually in the makefile to check that none are missing.

@staticfloat
Copy link
Sponsor Member

We could even put the total set of installed files into the manifest file and check manually in the makefile to check that none are missing.

I think that is important, because make should "just work". Especially if I've somehow deleted a library, I don't remember which one, and I want to run make to build everything again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:building Build system, or building Julia or its dependencies
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants