6 ms·

My question was and is, why is there so much complexity? If there are valid reasons, then fine, but from what I'm looking at a lot of it seems unnecessary. At

My question was and is, why is there so much complexity? If there are valid reasons, then fine, but from what I'm looking at a lot of it seems unnecessary. At its core, what is a build system meant to do? Build packages based on set configurations, right? In other words: 1. Set compiler flags. 2. Define/include/build dependencies. 3. Set build paths. 4. Build and test packages. All of the required steps can be managed manually via the command line, and at its core a build system is just a way to automate this work. Why are other command-line tasks so much simpler to automate than package compilation? That's what I want to know.

di4na 9y ago
How do you setup the rest of dependencies configuration ? How do you know that there are no hidden dependencies ? How do you handle time ? How do you ensure that it can be reproduce ? How do you define the dependencies ? How do you make sure that nothing change the build paths ? The deps paths ? That your environment is exactly the one you want ? That you dynamicly link to the correct lib ? And let's not talk about cross compilation. Also how do you clean behind yourself ? Same thing for testing with even more setup.
- ZenoArrow 9y ago
  > "How do you setup the rest of dependencies configuration ? How do you know that there are no hidden dependencies ?" Each dependency has its own build configuration file. You build a tree of dependencies and start compilation from the lowest level (i.e. the build objects without any non-compiled dependencies). With such an approach, why would you have a hidden dependency? > "How do you handle time ?" What do you mean by this? > "How do you ensure that it can be reproduce ?" Semantic version control on the dependencies. > "How do you define the dependencies ?" Is this a hard problem? > "How do you make sure that nothing change the build paths ? The deps paths ? That your environment is exactly the one you want ?" By testing during the build process. In the case of the environment, it's just a question of checking against a list of expected environment settings (e.g. OS version, processor architecture, processor features, etc...). > "That you dynamicly link to the correct lib ?" This comes down to version control. > "Also how do you clean behind yourself ?" Again, is this a hard problem? Even the simplest of makefiles can describe how to handle this. Perhaps it's best to give a concrete example of a task which is hard for a build system to manage, because I'm still not seeing the complexity here.
  - benley 9y ago
    There have been a bunch of papers published discussing these topics at great length, and many attempts at producing simpler systems that still work at non-trivial scales. I'd suggest taking a look at https://nixos.org/~eelco/pubs/phd-thesis.pdf https://nixos.org/~eelco/pubs/phd-thesis.pdf and/or https://nixos.org/~eelco/pubs/nspfssd-lisa2004-final.pdf https://nixos.org/~eelco/pubs/nspfssd-lisa2004-final.pdf for an overview of the origins of Guix and the reasoning behind its apparent complexity.
    - ZenoArrow 9y ago
      Thank you. That's all I was looking for.
      - gnufx 9y ago
        Looking in the paper at issue and the Guix web site might have helped.
soapdog 9y ago
In my humble opinion, there is a lot of difference in complexity depending on what you're trying to do. If you just want to build software, then, like you I agree that is quite easy. If you want reproducible builds, things start to get tricky. If you want deterministic reproducible builds, then it get really complex. Guix goes beyond being a simple package manager/build system. It has a ton of features, even more if you read about GuixSD which is a complete distro managed by Guix. Really wonderful stuff inside.
archgoon 9y ago
This is what build systems do. What additional complexity are you referring to? Is there a particular project that you are thinking of?

di4na 9y ago

How do you setup the rest of dependencies configuration ? How do you know that there are no hidden dependencies ? How do you handle time ? How do you ensure that it can be reproduce ? How do you define the dependencies ? How do you make sure that nothing change the build paths ? The deps paths ? That your environment is exactly the one you want ? That you dynamicly link to the correct lib ? And let's not talk about cross compilation. Also how do you clean behind yourself ? Same thing for testing with even more setup.

ZenoArrow 9y ago
> "How do you setup the rest of dependencies configuration ? How do you know that there are no hidden dependencies ?" Each dependency has its own build configuration file. You build a tree of dependencies and start compilation from the lowest level (i.e. the build objects without any non-compiled dependencies). With such an approach, why would you have a hidden dependency? > "How do you handle time ?" What do you mean by this? > "How do you ensure that it can be reproduce ?" Semantic version control on the dependencies. > "How do you define the dependencies ?" Is this a hard problem? > "How do you make sure that nothing change the build paths ? The deps paths ? That your environment is exactly the one you want ?" By testing during the build process. In the case of the environment, it's just a question of checking against a list of expected environment settings (e.g. OS version, processor architecture, processor features, etc...). > "That you dynamicly link to the correct lib ?" This comes down to version control. > "Also how do you clean behind yourself ?" Again, is this a hard problem? Even the simplest of makefiles can describe how to handle this. Perhaps it's best to give a concrete example of a task which is hard for a build system to manage, because I'm still not seeing the complexity here.
- benley 9y ago
  There have been a bunch of papers published discussing these topics at great length, and many attempts at producing simpler systems that still work at non-trivial scales. I'd suggest taking a look at https://nixos.org/~eelco/pubs/phd-thesis.pdf https://nixos.org/~eelco/pubs/phd-thesis.pdf and/or https://nixos.org/~eelco/pubs/nspfssd-lisa2004-final.pdf https://nixos.org/~eelco/pubs/nspfssd-lisa2004-final.pdf for an overview of the origins of Guix and the reasoning behind its apparent complexity.
  - ZenoArrow 9y ago
    Thank you. That's all I was looking for.
    - gnufx 9y ago
      Looking in the paper at issue and the Guix web site might have helped.

soapdog 9y ago

In my humble opinion, there is a lot of difference in complexity depending on what you're trying to do. If you just want to build software, then, like you I agree that is quite easy. If you want reproducible builds, things start to get tricky. If you want deterministic reproducible builds, then it get really complex. Guix goes beyond being a simple package manager/build system. It has a ton of features, even more if you read about GuixSD which is a complete distro managed by Guix. Really wonderful stuff inside.

archgoon 9y ago

This is what build systems do. What additional complexity are you referring to? Is there a particular project that you are thinking of?