Sorry for the late reply, I forgot about this. E-mail notification would be nice :)
On Wed, 04 Sep 2013 18:11:03 GMT, Sönke Ludwig wrote:
It does install packages, just that they are source packages and not binary packages. It's no different from all those package managers for the various interpreted languages if you want. But if you have a good idea how to sanely install binary packages considering that there is almost no guarantee for binary compatibility unless everything is exactly the same, I'm all ears.
What needs to be exactly the same? I guessing here:
- Compiler
- Architecture
- version flags
Compiler:
The compiler needs to be exactly the same since it doesn't have any binary or source compatibility. A field for specifying the supported compiler would probably be a good idea. An idea would be to hook dub up with DVM, if you're interested. Then dub could automatically install a switch compilers for different packages.
Architecture:
When installing a package it would be only for that given operating system. So what's useful here is having 32bit and 64bit packages. On Mac OS X it's already solved with universal binaries, we don't need to bother with that. On Linux, FreeBSD and Windows it should compile one 32bit package and one 64bit package. Don't know if it should do that by default or compile the native architecture only. Flags for controlling this would be needed. A field for specifying the supported architecture is needed as well.
When the package is installed it will install into a directory structure, like this:
~/.dub
|
|__ packages
|
|__ foo
|
|__ lib
|
|__ lib64
|
|__ src
|
|__ ... (and so on)
Possibly put the lib folders in an architecture directory to support corss-compiling in the future.
Version flags:
This might be a bit tricky. Macports on Mac OS X uses something called "variants". A package would have a list of variants, basically corresponding to version flag. Macports uses the plus sign (+) to indicate a variant. When depending on a specific variant of a package it would look something like this:
"dependencies": {
"ddbc +mysql +sqlite": ">=0.2.9"
}
The above would install the "ddbc" package with the variants "mysql" and "sqlite". The directory structure could look something like this:
~/.dub
|
|__ packages
|
|__ ddbc+mysql+sqlite
|
|__ lib
|
|__ lib64
|
|__ src
|
|__ ... (and so on)
Or put the variants in a sub directory:
~/.dub
|
|__ packages
|
|__ ddbc
|
|__ variants
| |
| |__ +mysql+sqlite
| |
| |__ lib
| |
| |__ lib64
|
|__ src
|
|__ ... (and so on)
I think I don't fully get the question. You can register any package to make it available. The registry currently only supports GitHub and BitBucket hosted repositories, though. If you need something else like sourcing form a locally hosted .zip file or from a git URL, that's quite simple to add, I'm sure we can work something out there.
Looking at the registry, http://code.dlang.org/, I see that some packages have "~master" as the latest version, some have "2.2.2" and some have "~issue/2". I would most likely never want "master" to be available. I'm certainly never, ever want "~issue/2" to be available.