Redub: A faster build system promising 90% compatibility with dub

[Hipreme]

Hello, people.
Here I come announce a package I've just released:

# [**redub**](https://code.dlang.org/packages/redub) : A faster 
build system based on dub

It is meant to be an almost drop-in replacement on dub.
Right now, I've been implementing only features that dub already 
has. But in the future, I can't guarantee I'll keep following the 
same direction from dub since there is a bunch I disagree with.


## Warning
- This is not a *reggae* clone (it is a lot easier to use by the 
way). This is a dub that simply can build with parallelization.
- It completely ignores optional dependencies
- Version range won't be implemented, at least not by me


### Raw package management
It has a very raw package management (by using dub CLI) and 
semver matching.

## But who should use that?

1. People with a project with many dependencies: Those people 
will get a big speedup on recompilations since each library can 
be built independently (if they don't mess up with pre/post 
commands)
2. People which don't rely on version ranges: Personally, I have 
0 interest on implementing that, if you wish support for it, 
issue a pull request.
3. People which wants rule-based software instead of exception 
based: The features are designed around rules instead of 
workarounds. If you need an exception in using it, I won't listen 
to this request or pull request. Only generalizations may be 
implemented.
4. People which wants better caching: Dub currently is completely 
buggy on caches with string import paths, (and actually, for some 
unknown reason, can't even detect up to date redub when running 
it. )


## What has changed?
- dub recipe files are parsed lazily, which means, you can use 
inexistent dependencies inside other configurations, and also 
faster parsing even though I'm using std.json
- The code is following a 95% functional style. Almost no state 
is changed in between compilation steps
- This project is focused on readability and easy of maintenance: 
Don't try to be too smart, unless real difference can be made on 
its performance
- Libraries are always built recursively. (Currently was only 
achieved with --deep flag). Which for me was simply a big "why"
- The default output now is inside a separate folder: "bin". This 
makes it easier for making the caching system to behave better 
since they will be check on other root.
- I won't focus on any moment into implementing support for a 
single file build, this is too much work for no real gain, if you 
want to do it, do it on a completely isolated file.




## Development story
- This software was built in 2.5 weeks, which first was a 1 week 
project, but, it was so successful in what it done that I decided 
to expand its scope (I would initially only support what Hipreme 
Engine needs). Some people said that no one done better than dub 
until now, so, I've done this project because it was simply 
unbelievable that dub wasn't able to do any level of 
parallelization.

- I have tried contributing to dub's project on parallelization, 
I waste 1 week trying that and could not get it working, so, I 
decided it would be a better use of my time into rewriting a 
completely new dub which would focus on being easy to read -- An 
example of that is how easily someone was able to integrate an 
experimental support to building C with it.


This project has been tested with
- [Hipreme Engine](https://code.dlang.org/packages/hipreme_engine)
- [Fluid](https://code.dlang.org/packages/fluid)
- [arsd](https://code.dlang.org/packages/arsd-official)
- [dplug](https://code.dlang.org/packages/dplug)


And possibly more to come. I didn't done a complete vibe-d 
support because there was too many features which I am not going 
to use (hello arch-based filters on dub.json).


## Why should you use it?
- A full rebuild on Hipreme Engine reduced its compilation time 
from 14 seconds to 3. One could say that full rebuilds aren't 
common, but this is untrue. Specially when I was developing my 
own standard library (util), this would get into my nerves.

You may test it with `dub run redub`. But since `dub` is buggy, 
it will always be identified as not up to date :)


By the way: People which hates `dub` and use `dmd -i` instead: 
your project ought to be built faster by modularizing them :)