Skip to content

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

Merged
merged 1 commit into from
Mar 15, 2021

Conversation

Taytay
Copy link
Contributor

@Taytay Taytay commented Mar 14, 2021

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.

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.

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)
Copy link
Contributor Author

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)
Copy link
Contributor Author

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/
Copy link
Contributor Author

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)
Copy link
Contributor Author

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)
Copy link
Contributor Author

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"

@lovasoa lovasoa merged commit 23234ea into sql-js:master Mar 15, 2021
@lovasoa
Copy link
Member

lovasoa commented Mar 15, 2021

Thank you @Taytay for finding the bug and for fixing it!

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

Successfully merging this pull request may close these issues.

2 participants