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

Ignore build_h.jl.phony #27628

Merged
merged 1 commit into from
Jun 18, 2018
Merged

Ignore build_h.jl.phony #27628

merged 1 commit into from
Jun 18, 2018

Conversation

staticfloat
Copy link
Member

@staticfloat staticfloat commented Jun 18, 2018

When running version_git.sh to build version_git.jl, we encode whether the current buildtree is modified. Unfortunately, this often runs in parallel with the eneration of build_h.jl, which means that more often than not, build_h.jl.phony is sitting around in the build tree, and since git hasn't been told to ignore that file, we get modified build trees a lot during make -jN.

We don't see this in final builds however, because when we swing back around in make binary-dist, the Makefile regenerates version_git.jl.phony, checks it against version_git.jl and notices that git no longer things the build tree is dirty. (This being because build_h.jl.phony does not exist. Note that we never run make binary-dist in parallel). Thus, we always end up with a version_git.jl that identifies itself as coming from a pristine build, and the price we paid was just that we would always build the system image twice.

This closes #27548

When running `version_git.sh` to build `version_git.jl`, we encode
whether the current buildtree is modified.  Unfortunately, this often
runs in parallel with the generation of `build_h.jl`, which means that
more often than not, `build_h.jl.phony` is sitting around in the build
tree, and since `git` hasn't been told to ignore that file, we get
modified build trees a lot during `make -jN`.  We don't see this in
final builds however, because when we swing back around in `make
binary-dist`, the Makefile regenerates `version_git.jl.phony`, checks it
against `version_git.jl` and notices that `git` no longer things the
build tree is dirty.  (This being because `build_h.jl.phony` does not
exist.  Note that we never run `make binary-dist` in parallel).  Thus,
we always end up with a `version_git.jl` that identifies itself as
coming from a pristine build, and the price we paid was just that we
would always build the system image twice.  Come, global warming, come.
@staticfloat
Copy link
Member Author

Verification run going here: https://build.julialang.org/#/builders/43/builds/1450 . If all goes according to plan, it will only build the sysimg once (well, once for release, once for debug).

@ararslan
Copy link
Member

Looks like the system image built once in make release and once in make debug and that's it! 👏

@staticfloat
Copy link
Member Author

staticfloat commented Jun 18, 2018

.....dropping the total build time from 48 minutes to 23 minutes. 🎉

@ararslan ararslan added building Build system, or building Julia or its dependencies bugfix This change fixes an existing bug labels Jun 18, 2018
@ararslan
Copy link
Member

CI failures are unrelated: FreeBSD build froze, Travis Linux x64 is #27109, Circle x64 got OOM killed.

@staticfloat staticfloat merged commit 0e65980 into master Jun 18, 2018
@martinholters martinholters deleted the sf/subjugate_the_machine_spirit branch June 18, 2018 08:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugfix This change fixes an existing bug building Build system, or building Julia or its dependencies
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Sysimg being built multiple times
2 participants