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

select all #5

Merged
merged 1 commit into from
Mar 25, 2017
Merged

select all #5

merged 1 commit into from
Mar 25, 2017

Conversation

cmyr
Copy link
Member

@cmyr cmyr commented Mar 24, 2017

depends on xi-editor/xi-editor#179.

Do you have any thoughts on having the core be a git submodule? Doesn't matter hugely right now, but I could imagine versioning being frustrating down the road.

@raphlinus raphlinus merged commit c30332b into xi-editor:master Mar 25, 2017
@raphlinus
Copy link
Member

git submodule is a possibility. We don't use that at all inside google, but it might be the best solution to versioning.

Another thing I've thought of is having (a copy of) the xi-core binary in this repo, pulling in a versioned crate of xi-core-lib (and probably with a Cargo.lock to really nail it down). That, I think, would improve on the usability from git submodules.

@cmyr
Copy link
Member Author

cmyr commented Mar 25, 2017

Hmm. I'm not in thrall to the idea of regularly committing a binary. Or do you just mean a simple crate with a main.rs which imports the core-lib?

Another option that saves having to commit anything but a version number or a commit hash would be shelling out to cargo install as a build script? This can point to either crates.io or to a repo.

@cmyr cmyr deleted the select-all branch March 25, 2017 03:01
@raphlinus
Copy link
Member

I meant a simple crate which imports the core-lib, not the binary itself.

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