Thank you for opening the discussion.

If I get it correctly you would prefer independent miner releases for each back-end.
From the perspective of a non experienced user the different back-ends will confuse. Some of the user not know which hardware they own but will be interested in mining.

Hashrate stats are preserved as we can use ifdefs to have xmr-stak flavours version differently

This is still possible after #8

Allows us to have different binary builds that don't need NVIDIA users to get AMD dlls (and vice versa)

With the current code base there is not need that a AMD miner needs any NVIDIA libs. I uploaded a windows binary compiled from the current code base where you should be able to run it on all Windows systems independent if cuda or opencl is installed. (please see binary at the end of the post)

Allows us to easily create GUI and non GUI versions

Following the rule that we build by default with full features, we will always try to build gui + cli including all backends, if the dependency is missing the user can disable e.g. the gui. Build both will not increase the build time because the backend code is compiled only once and linked as static lib into gui and cli later on.

As the current mock up shows the flavor branch is only a preset of compiler flags. I find the idea of presets very intuitive and good! This helps user non experienced users those try to compile the miner from the source.
I would suggest to add a cmake option instead of different repositories where the user can select build presets e.g AMD.

# will build all backends but give the user hints how dependencies can be disabled if it is missing
-DXMR-MINER_BACKEND=generic
# will enforce that the user have installed the dependency for the backend (e.g. CUDa for nvidia)
-DXMR-MINER_BACKEND=amd
-DXMR-MINER_BACKEND=nvidia
-DXMR-MINER_BACKEND=cpu

Releases

To minimize the release work I suggest that we only release generic binaries. For linux we should provide binaries for the common distributions.

• windows cli+gui
• ubuntu 14.04 cli+gui
• ubuntu 16.04 cli+gui
• ...
• macOSX cli+gui (we need to check where we can create those binaries)

To split it into different flavors we end up with DISTRO * List_I * List_II different binaries which is not possible to handle. For the four distributions above we end up with 24 binaries.

@fireice-uk Currently I don't see the advantage of splitting in flavor branches but I am open to try to understand our visions.

Generic Windows 64 Binary (fit all back-ends)

This binary should run on all windows systems independent if Cuda or OpenCL is available.
https://mega.nz/#!xeJhnRoJ!YArutfHvKx1Y-M0tpft9etpfPeJ4hcESKgY5cKHz38g

sha256: a4e93cd0963bba4395d1bd3c5d768c93182326605e732e2a53202d3b7794530a

from xmr-stak.

Keep in mind that I'm a meritocrat. I will like whatever works best - and I like your solution. I like the dynamic loading idea especially. Provided that it works. If everything checks out we will do it your way.

Question then is what to do with the current xmr-stak-cpu, -amd and -nvidia repos. I don't want to invalidate old links.

from xmr-stak.

I had a couple helpful people from supportxmr.com run the code and it works, when there are no dependencies LoadLibrary fails cleanly. I'm on board with this solution.

In fact I think the first order of business would be to extend it to TLS libs.

from xmr-stak.

Abandoned.

from xmr-stak.