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

Schema rebuild #780

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Schema rebuild #780

wants to merge 2 commits into from

Conversation

mgalgs
Copy link
Collaborator

@mgalgs mgalgs commented Jan 24, 2023

If people are checking the repo out from git and installing manually they
won't be getting the latest settings since the binary gschema file is
currently out of date.

This PR also adds a note about rebuilding the schema to the README.

If people are checking the repo out from git and installing manually they
won't be getting the latest settings since the binary gschema file is
currently out of date.
@mgalgs
Copy link
Collaborator Author

mgalgs commented Jan 24, 2023

Cc: @ZimbiX

@ZimbiX
Copy link
Collaborator

ZimbiX commented Jan 24, 2023

I was wondering what to do about this. Given it's generated with make install as per the installation instructions in the readme, I was thinking maybe it wasn't supposed to have been committed. I'd tried to leave it out of PRs to avoid merge conflicts.

@mgalgs
Copy link
Collaborator Author

mgalgs commented Jan 24, 2023

The readme has a section for manual installation for development (symlink rather than make install):

image

I agree that it's a bit unorthodox to have binary files committed. If we don't want to keep it updated in the repo we should delete it and add a make extension step to the section above. I'm good with either solution but as it stands the dev instructions don't actually result in a working dev environment.

@ZimbiX
Copy link
Collaborator

ZimbiX commented Jan 25, 2023

Ah, I forgot that was there 😅 I've just been doing VERSION=9999 make install (setting the version to prevent auto-upgrade to the published version).

I'm not sure what's the norm. I guess until we decide otherwise, let's continue with how it is already? In which case, these added instructions are good.

If/when we do go with removing the binary files, it could be good to have something perform the generation of them automatically on change - using something like guard.

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.

None yet

2 participants