-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Prevent make all
from thinking it needs to run twice
#443
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
Conversation
The dependencies/ordering of the building of the .bc files were subtly incorrect. This meant that running `make clean` followed by `make build` would work, but then the next time `make build` was run, the whole build would erroneously run again, rather than detecting everything was up to date. In particular, the 'out/sqlite3.bc' file would get built, and THEN the extensions would get built. However, when the extensions got built, only then would it copy the extensions.c file into the sqlite-src/amalgamation folder, thus updating that the sqlite-src/amalgamation folder timestamp. The next time `make` was run, `out/sqlite3.bc` would detect that the `sqlite-src/amalgamation` folder was newer than the sqlite3.bc file, and it would get rebuilt, thus cascading into a full rebuild.
|
||
sqlite-src/$(SQLITE_AMALGAMATION): cache/$(SQLITE_AMALGAMATION).zip | ||
mkdir -p sqlite-src | ||
sqlite-src/$(SQLITE_AMALGAMATION): cache/$(SQLITE_AMALGAMATION).zip sqlite-src/$(SQLITE_AMALGAMATION)/$(EXTENSION_FUNCTIONS) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm open to solving this a different way, but I'm basically saying, "you can't have a src amalgamation folder without the extension functions file too."
unzip -u 'cache/$(SQLITE_AMALGAMATION).zip' -d sqlite-src/ | ||
touch $@ | ||
|
||
sqlite-src/$(SQLITE_AMALGAMATION)/$(EXTENSION_FUNCTIONS): cache/$(EXTENSION_FUNCTIONS) | ||
mkdir -p sqlite-src | ||
mkdir -p sqlite-src/$(SQLITE_AMALGAMATION) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that this runs before the unzip above, we need to manually create the amalgamation folder
@@ -188,5 +192,4 @@ sqlite-src/$(SQLITE_AMALGAMATION)/$(EXTENSION_FUNCTIONS): cache/$(EXTENSION_FUNC | |||
.PHONY: clean | |||
clean: | |||
rm -f out/* dist/* cache/* | |||
rm -rf sqlite-src/ c/ | |||
|
|||
rm -rf sqlite-src/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the c/
- appeared erroneous
@@ -168,18 +170,20 @@ cache/$(EXTENSION_FUNCTIONS): | |||
|
|||
## sqlite-src | |||
.PHONY: sqlite-src | |||
sqlite-src: sqlite-src/$(SQLITE_AMALGAMATION) sqlite-src/$(EXTENSION_FUNCTIONS) | |||
sqlite-src: sqlite-src/$(SQLITE_AMALGAMATION) sqlite-src/$(SQLITE_AMALGAMATION)/$(EXTENSION_FUNCTIONS) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this was a bug previously, that it depended upon src//$(EXTENSION_FUNCTIONS)
and not src/$(SQLITE_AMALGAMATION)/$(EXTENSION_FUNCTIONS)
.
I think it was never noticed because we don't ever manually build the sqlite-src
target
@@ -149,8 +149,10 @@ out/sqlite3.bc: sqlite-src/$(SQLITE_AMALGAMATION) | |||
# Generate llvm bitcode | |||
$(EMCC) $(CFLAGS) -c sqlite-src/$(SQLITE_AMALGAMATION)/sqlite3.c -o $@ | |||
|
|||
out/extension-functions.bc: sqlite-src/$(SQLITE_AMALGAMATION)/$(EXTENSION_FUNCTIONS) | |||
# Since the extension-functions.c includes other headers in the sqlite_amalgamation, we declare that this depends on more than just extension-functions.c | |||
out/extension-functions.bc: sqlite-src/$(SQLITE_AMALGAMATION) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is a more correct dependency declaration, and has the benefit of saying, "If you build either of these .bc files, you'll need to unpack the whole sqlite src amalgamation folder"
Thank you @Taytay for finding the bug and for fixing it! |
The dependencies/ordering of the building of the .bc files were subtly incorrect. This meant that running
make clean
followed bymake build
would work, but then the next timemake build
was run, the whole build would erroneously run again, rather than detecting everything was up to date.In particular, the 'out/sqlite3.bc' file would get built, and THEN the extensions would get built. However, when the extensions got built, only then would it copy the extensions.c file into the sqlite-src/amalgamation folder, thus updating that the sqlite-src/amalgamation folder timestamp. The next time
make
was run,out/sqlite3.bc
would detect that thesqlite-src/amalgamation
folder was newer than the sqlite3.bc file, and it would get rebuilt, thus cascading into a full rebuild.Note that I also fixed what appears to be an erroneous line in clean:
rm -rf sqlite-src/ c/
It now says:
rm -rf sqlite-src/
I don't know what the
c/
thing was.