Directly depend on projects that are not hosted on biicode servers

[smessmer]

One of the problems of biicode is the low number of libraries hosted on biicode. However, I think many C++ libraries (e.g. header-only libraries without further dependencies or libraries that are built using cmake) could be biicode compatible without changing anything (also without adding a biicode.conf file).

We could quickly grow the number of available biicode dependencies if we support depending on libraries that are not hosted on biicode, but somewhere else (github, sourceforge, ...). These projects wouldn't even need a biicode.conf in this case.

I'm not sure on the developer workflow for this, some options are:

1. using a virtual "github" account on biicode

   #include <github/username/repository/path/file.h>
   

2. Adding such repositories to a section in biicode.conf

   [external_dependencies]
   myrepo: git@github.com:username/repository
   

Ideally, the solution would support generic protocols (download project via git, zip over http, ...) as opposed to certain providers (github, sourceforge, ...). Then we could also use it for projects hosted on providers that are used less often (bitbucket, google code, ...)

[drodri]

Thats a good point. I think this is basically the same idea of biicode/biicode#6

Though it looks simple initially, it can be quite complex. For example, there are no notions of the version you are depending on in your proposal, and it is well known (e.g. golang) that this can be a problem. The main complexity is that the meta-information of dependencies should be still stored somewhere, and if reading directly from other sources, that info is not available. In biicode/biicode#6 I start to outline a process of decoupling our backend of retrieval, then possible storing all metainformation in some text-file that could be then committed to git, or maybe computing the information on-the-fly.

Still not sure how to address it, but working on it.

[smessmer]

sounds great