4 ms·

Even the slightest attempt at guessing the host system or searching for tools present on a system will quickly convert this into a blog article earnestly beggin

Even the slightest attempt at guessing the host system or searching for tools present on a system will quickly convert this into a blog article earnestly begging for deep societal changes and analyses the inevitable marching of time.

banish-m4 2y ago
Hahaha. Yeap. And project dependency analysis and library feature detection quickly demand the GNU variant, autotools (gasp!), clunky scripts, or something else. Use make for simple things and simple things only.
- patrickmay 2y ago
  Eric S. Raymond has a new project to eliminate the need for autotools: https://gitlab.com/esr/autodafe https://gitlab.com/esr/autodafe It appears to give the benefits of autotools with the simplicity of make.
jimbokun 2y ago
The real reason container systems like Docker became so popular.
- einpoklum 2y ago
  the real _and unfortunate_ reason system like Docker became so popular: Caving in to the problem and creating endless replication and mess.
tomjen3 2y ago
Yeah. Which is why I wouldn't implement that in the first place - I come down hard on the idea that you should ship your dependencies, have them in a standard place or use a third-party resolution system (like every vaugely modern setup does. C#, Python, Ruby, Node, Rust even Java all understand that this is not optional anymore). Its a code smell to me when your build system starts to become too complicated and not fit on a screen.
- ReleaseCandidat 2y ago
  You do know that there is software that runs on more than one version of Linux (or even on a *BSD, MacOS or Windows), works with more than a single version of a compiler,...?
  - tomjen3 2y ago
    Thats only really a problem for C/C++, which I have had the misfortune to make build systems for. The solution is not to ship complicated and bug infested build systems, it is to fix the dependency problem in the same way any other language has done so far and until we do this, ship the dependencies with the program. And if you aren't making a GUI and don't need to target Windows, just wrap it in Docker, which enforces a functional dependency system and means you can ship your dependencies.
    - ReleaseCandidat 2y ago
      > Thats only really a problem for C/C++ Even if that would be true, still every language that isn't C (or JS in the browser) needs to link or build against some C (or Fortran), which results in more or less working solutions on how to integrate with or build C sources. Of course you may not see that (as long as it works), because somebody else has wrapped that up in a package (or whatever) for your language of choice, but somebody has to do that. > ship the dependencies with the program. My post should have been the answer to this argument: this is not possible for example when "shipping" the source for a cross-platform library. Or a cross-platform end-user program/app. Or just about anything which isn't "just" some web-backend or a server of some kind. Does that mean _you_ need a complicated (I'd call that "working for anything but the most basic stuff") build-system? No. I am a bit puzzled by this phrase: > The solution is not to ship complicated and bug infested build systems, it is to fix the dependency problem in the same way any other language has done so far But any other language than C or C++ (sadly, _way_ less than "any other") solves that by using a complicated and bug infested build system(s) and package manager(s) or a combination of both.
      - 2y ago

banish-m4 2y ago

Hahaha. Yeap. And project dependency analysis and library feature detection quickly demand the GNU variant, autotools (gasp!), clunky scripts, or something else. Use make for simple things and simple things only.

patrickmay 2y ago
Eric S. Raymond has a new project to eliminate the need for autotools: https://gitlab.com/esr/autodafe https://gitlab.com/esr/autodafe It appears to give the benefits of autotools with the simplicity of make.

jimbokun 2y ago

The real reason container systems like Docker became so popular.

einpoklum 2y ago
the real _and unfortunate_ reason system like Docker became so popular: Caving in to the problem and creating endless replication and mess.

tomjen3 2y ago

Yeah. Which is why I wouldn't implement that in the first place - I come down hard on the idea that you should ship your dependencies, have them in a standard place or use a third-party resolution system (like every vaugely modern setup does. C#, Python, Ruby, Node, Rust even Java all understand that this is not optional anymore). Its a code smell to me when your build system starts to become too complicated and not fit on a screen.

ReleaseCandidat 2y ago
You do know that there is software that runs on more than one version of Linux (or even on a *BSD, MacOS or Windows), works with more than a single version of a compiler,...?
- tomjen3 2y ago
  Thats only really a problem for C/C++, which I have had the misfortune to make build systems for. The solution is not to ship complicated and bug infested build systems, it is to fix the dependency problem in the same way any other language has done so far and until we do this, ship the dependencies with the program. And if you aren't making a GUI and don't need to target Windows, just wrap it in Docker, which enforces a functional dependency system and means you can ship your dependencies.
  - ReleaseCandidat 2y ago
    > Thats only really a problem for C/C++ Even if that would be true, still every language that isn't C (or JS in the browser) needs to link or build against some C (or Fortran), which results in more or less working solutions on how to integrate with or build C sources. Of course you may not see that (as long as it works), because somebody else has wrapped that up in a package (or whatever) for your language of choice, but somebody has to do that. > ship the dependencies with the program. My post should have been the answer to this argument: this is not possible for example when "shipping" the source for a cross-platform library. Or a cross-platform end-user program/app. Or just about anything which isn't "just" some web-backend or a server of some kind. Does that mean _you_ need a complicated (I'd call that "working for anything but the most basic stuff") build-system? No. I am a bit puzzled by this phrase: > The solution is not to ship complicated and bug infested build systems, it is to fix the dependency problem in the same way any other language has done so far But any other language than C or C++ (sadly, _way_ less than "any other") solves that by using a complicated and bug infested build system(s) and package manager(s) or a combination of both.
    - 2y ago