Make dub part of the standard dmd distribution

[Morbid.Obesity via Digitalmars-d]

On Monday, 1 June 2015 at 05:05:21 UTC, Brad Anderson wrote:
> On Monday, 1 June 2015 at 04:36:06 UTC, Andrei Alexandrescu 
> wrote:
>> On 5/31/15 8:48 PM, Manu via Digitalmars-d wrote:
>>> As for dub, I'd use it if it worked like a package manager; 
>>> dub get
>>> libcurl-d libqt-d zlib-d libsdl2-d etc
>>> I have no use for it as a build system, and therefore it's 
>>> expression
>>> of dependencies is no use to me. I just want something that 
>>> works the
>>> same way as '-dev' packages already work perfectly well in 
>>> linux, that
>>> is, they fetch headers and libs, and put them in a standard 
>>> location
>>> that all the tooling can find.
>>
>> I thought it does that.
>>
>> If dub doesn't allow me to type one command to download and 
>> install all I need about a package, we need to add that 
>> pronto. I consider it a dealbreaker.
>>
>>
>> Andrei
>
> dub fetch does this already (though probably not quite what you 
> are thinking of). You'd need to specify the paths manually 
> because if it installed them to the global compiler paths we'd 
> have dependency hell (what if 5 projects I have need 3 
> different versions of a library?). Also, you'd need root 
> permissions.
>

I wonder if essentially hashing a library(ultimately each file) 
could be used to avoid dll hell. Essentially hash the .d files 
and then different versions will have different hashes. When you 
compile your project and it is successful, the compiler/linker 
can write a configuration file that includes the hashes of the 
various files used. This then could be used to avoid dll, if one 
has a proper way to "check" for versioning(online database) then 
one can find the proper versions.

Obviously small changes to any d file, even if it is non-breaking 
will change the hash. This is not a bad thing but since there 
will be no correlation between hashes and versions one must have 
a database of versions and their hashes.

The good thing is that if, say, a project doesn't compile after 
updating a "library" to the "wrong" versions, the configuration 
file won't be modified since the compiler won't be able to 
compile the code. One can then easily use the (old) config file, 
if it exists from a previous (working) build, to deal with the 
versioning issue. (e.g., hash is different for mylib.d, means 
wrong version. Get correct version)

In fact, maybe the way to go is for the config file essentially 
to keep a history of several last working builds, e.g.,

05/31/15 - mylib.d[3FAB9999ABCCC34C3C] - Compiled OK
          - myotherlib.d[4C934DFFFFFFF34C3C] - Compiled OK
          - myproject.d [FFABC33CCA4367C4EE] - Compiled OK
          - Project [3493493428439294292] - Compiled OK

06/01/15 - mylib.d[3FAB9999ABCCC34C3C] - Compiled OK
          - myotherlib.d[4C954D5F3F2F434EEC] - Compiled OK
          - myproject.d [FFABC33CCA4367C4EE] - Failed
          - Project [3493493428439294292] - Failed

In the above case, the myotherlib.d's hash changed. the project 
did not compile. Hence we have a versioning issue. It is easy to 
see what the problem is. One then simply needs an online datable 
to match the hashes to the versions or simply search all 
"versions" and hash them.

Also, one benefits from simply hashing any file to get it's 
"version". If you had 10 myotherlib.d files from the past but 
don't know which is which(different copies scattered across 
different backups, etc), simply hashing them and finding the 
correct one(in this case, 4C934DFFFFFFF34C3C) can be used to get 
the project working again.

Since most of this stuff can be automated, it seems like it would 
be a better way to deal with versioning than the standard methods 
which relies on users correctly defining the versions and 
maintain them.