Use git submodules for dependencies where possible

[Keno]

I think it might be a good idea to use git submodules to handle dependencies where possible. Not only would that avoid having to use wget/curl, but it would also enable working directly on the dependencies and pushing those changes upstream without much difficulty.

[StefanKarpinski]

This is an excellent idea that I've been pondering for a while. I had been reluctant because the last time I used git submodules it was not a very well-developed feature. Admittedly that was like five years ago or some such.

[StefanKarpinski]

Perhaps we should also make cloned GitHub repos under JuliaLang for the dependencies that aren't already on GitHub? That way there's a consistent way to get everything and even a place to maintain our own patches (although that's a bit more questionable).

[Keno]

I think that would be a good idea.

[Keno]

Also, some of the dependency projects have SVN repositories, so it shouldn't be a problem to use the git svn bridge (this would require to set up a repo that serves as a bridge. LLVM already has it at http:https://llvm.org/git/llvm.git (see http:https://llvm.org/docs/GettingStarted.html#git_mirror).

[ViralBShah]

Isn't there some kind of a github restriction on number of repositories for an organization for free usage? Of course, the github fee is quite reasonable, and we can just start paying that.

[Keno]

I'm fairly certain that github has unlimited public repositories

[ViralBShah]

I think our current build process is working fine, largely. Not sure if this is necessary. Should we close this?

[Keno]

This is more a way of simplifying development, by allowing us to try out upstream branches and/or directly commit changes, rather than a build simplification.

[StefanKarpinski]

I'm designing a package system that uses git submodules and I think it would make everything better if even our code dependencies were installed and managed this way (except LLVM, which is really part of Julia). So no, don't close it.

On May 1, 2012, at 12:47 PM, Keno [email protected] wrote:

This is more a way of simplifying development, by allowing us to try out upstream branches and/or directly commit changes, rather than a build simplification.

---

Reply to this email directly or view it on GitHub:
#398 (comment)

[ViralBShah]

With the recent SuiteSparse website downtime, there is perhaps more reason to use submodules. I say we wait for Stefan's package stuff to be ready.

[StefanKarpinski]

I'm pretty close. I say we make things like sparse matrices some of the first test packages. They might be installed by default, but they should still be bundled up like packages.

[ViralBShah]

arpack, sparse, gmp, and glpk are good first candidates.

-viral

On 29-May-2012, at 9:25 AM, Stefan Karpinski wrote:

I'm pretty close. I say we make things like sparse matrices some of the first test packages. They might be installed by default, but they should still be bundled up like packages.

---

Reply to this email directly or view it on GitHub:
#398 (comment)

[ViralBShah]

What do we do about this issue? I have often thought of taking all of deps and converting it into a git repository. Instead of downloading various packages, one would just clone this repository and get all the dependencies. Keeping it separate also makes it possible for other projects to use it.

[ViralBShah]

Perhaps this is no longer as important, given that we are rapidly moving stuff into packages.