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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

add Fossil dep type #31

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

Conversation

javierguerragiraldez
Copy link

No description provided.

@nektro
Copy link
Owner

nektro commented Sep 2, 2021

Wow, thanks for looking into this! The tests failing seem unrelated to this change so I'll get those fixed up and then get this merged in. 馃槃

@nektro
Copy link
Owner

nektro commented Sep 5, 2021

zigwin32 and hzzp are updated, still waiting on iguanatls

@nektro
Copy link
Owner

nektro commented Sep 15, 2021

Rebased this branch to master and looks all good to go.

Do we have a fossil repo hosted anywhere with some Zig code we can use to verify the functionality doesn't regress going forward?

@javierguerragiraldez
Copy link
Author

Do we have a fossil repo hosted anywhere with some Zig code we can use to verify the functionality doesn't regress going forward?

this is mine: http://chiselapp.com/user/javier/repository/zigqlite
still haven't mastered how to declare dependencies on C libraries, but I have other (unpublished) project that depends on this one.

@nektro
Copy link
Owner

nektro commented Sep 15, 2021

Thanks! I'll give the repo a test and get this merged. Thanks again for pull this together :)

For C libraries you can see an example here https://github.com/nektro/zig-sqlite3/blob/master/zig.mod as well as the system_lib dep type

@nektro
Copy link
Owner

nektro commented Sep 23, 2021

One thing i'm noticing is that in the lockfile its always using the "commit" (in git speak). similarly, it makes me wonder if the fossil type should have equivalents for specifying "branch" or "tag" if those exist

@javierguerragiraldez
Copy link
Author

isn't the lockfile's purpose to "lock" the current version? the dependencies can use any way to specify a version (tag, branch, commit, or none), but the lockfile should use the exact commit... unless i'm missing something.

No longer assume `gpa` global allocator.
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