I don't know much about hg subrepos, but if they work more or less like a git submodule, your concerns can be addressed. I'm going to assume that they work similarly and start from there (I might be wrong on making that assumption). I'll use git commands here since I don't know their hg equivalent.
When you add a git submodule to a git project, you don't "include" the whole "external" project on your project. Instead, you put a 'pointer' to a specific revision of an external pointer, and assign it to a directory.
But, that directory is empty by default. It will not have any code when your code is downloaded (when you do git clone ...). It only takes a very small space inside the .git directory to store something like "this directory points to this revision of this other repo".
If someone wants to download the submodule, they have to explicitly tell git to download them (with git submodule init && git submodule update). The submodules's source code is then downloaded from its original repositos, not from your own repo; your repo never contains any code belonging to the submodules.
Now, with your concerns:
bartbes wrote:No, you're not supposed to do all your dependencies that way! I mean, do you want us to add SDL as well?!
Yes. And box2d, too. And the other dependencies. It will increase the size of the love repo in less than 1KB.
Robin wrote:but only the libraries in question are in Mercurial themselves, so you don't have to maintain them.
I don't think the "maintainance" would be that much of an issue. You probably already have a 'dependencies' dir where you have all the stuff you need to compile LÖVE. Instead of manually copying it around, just put it on a public repo. It takes less than 5 minutes. It will probably help you save time next time you have to compile LÖVE in a computer that isn't yours.
Robin wrote:And you have to be able to refer to them by some kind of version tag, because otherwise versions get mixed up.
I'm pretty sure that if git is able to do that, mercurial is, too. Those are intelligent chaps.
Robin wrote:Then the only problem is that on Linux dependencies are managed by package management, so asking Mercurial to get the dependencies as well would be wasteful.
Well then the linux guys would have to skip the git submodule init && git submodule update step.
Again, my whole argument is based on the assumption that mercurial subrepos work similarly to git submodules. If they are not, then please disregard this email.