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.
