2 ms·

> First of all, bake does not rely on an online package repository. As long as you have access to git, or have local copies of your git repositories, you're goo

by adev_ 8y ago

> First of all, bake does not rely on an online package repository. As long as you have access to git, or have local copies of your git repositories, you're good. You'll never lose productivity because your internet connection went down (well- at least not because of bake). It does not change anything to all the other problems of bundling dependencies. Including the problems related to diamond dependencies. > Bake is a package manager for developers, and it provides a nice & seamless workflow for integrating remote git dependencies into your local workflow Then just use a developper package manager like Nix, Guix, Spack or EasyBuild that do the staff. Instead of converting every other project to Bake for the sake of it.

ajmmertens 8y ago
> It does not change anything to all the other problems of bundling dependencies. Including the problems related to diamond dependencies. As you put so eloquently before, that should not be the prerogative of build systems like bake, but of package managers like apt-get, brew and vcpkg. Bake is blissfully agnostic to those problems (thank god). One thing that hasn't been discussed so far and I would like to highlight is code that is not distributed through package managers, as so often is the case for commercial closed source code. Bake is a great fit for these use cases, as these projects can simply zip up the bake environment (together with miscellaneous files like HTML, JS and what have you), unzip it on a different machine, and everything just "magically" works. > Then just use a developper package manager like Nix, Guix, Spack or EasyBuild that do the staff. Instead of converting every other project to Bake for the sake of it. If you got the impression that I am on a quest to convert every non-bake project to bake, then let me put that concern to rest. I love using bake, it is saving me lots of time and, TBH, I think there are some neat ideas in bake that other people might like, but that's it. After the code is built, it's like every other C/C++ library, and people are free to use whatever build system they feel comfortable with to link with those libraries.

by adev_ 8y ago

ajmmertens 8y ago

> It does not change anything to all the other problems of bundling dependencies. Including the problems related to diamond dependencies. As you put so eloquently before, that should not be the prerogative of build systems like bake, but of package managers like apt-get, brew and vcpkg. Bake is blissfully agnostic to those problems (thank god). One thing that hasn't been discussed so far and I would like to highlight is code that is not distributed through package managers, as so often is the case for commercial closed source code. Bake is a great fit for these use cases, as these projects can simply zip up the bake environment (together with miscellaneous files like HTML, JS and what have you), unzip it on a different machine, and everything just "magically" works. > Then just use a developper package manager like Nix, Guix, Spack or EasyBuild that do the staff. Instead of converting every other project to Bake for the sake of it. If you got the impression that I am on a quest to convert every non-bake project to bake, then let me put that concern to rest. I love using bake, it is saving me lots of time and, TBH, I think there are some neat ideas in bake that other people might like, but that's it. After the code is built, it's like every other C/C++ library, and people are free to use whatever build system they feel comfortable with to link with those libraries.