4 ms·

> Because, like many other things in programming, you'll end up with a half-baked and buggy implementation of make anyways. I'd argue that make is a half-baked

> Because, like many other things in programming, you'll end up with a half-baked and buggy implementation of make anyways. I'd argue that make is a half-baked and buggy implementation of make - so that's not really a drawback so much as the status quo. E.g. I have scripts that exist mainly to carefully select the "correct" version of make for a given project to deal with path normalization and bintools selection issues on windows - and none of these ~3 versions of make work on all our Makefiles. One of those versions appears to have some kind of IO bug - it'll invoke commands with random characters missing for sufficiently large Makefiles, which I've already gone over with a hex editor to make sure there wasn't some weird control characters or invisible whitespace that were to blame. So, buggy and brittle.

Cyph0n 9y ago
> path normalization and bintools selection issues on windows make was never intended to be a cross-platform tool. If you face problems using it on Windows, then that's on you.
- EdSharkey 9y ago
  That is, unless the folks who maintain and champion make want me to use make. It's on them to court me, the cross-platform developer, not the other way around.
  - Cyph0n 9y ago
    Again, if you're a cross-platform developer, make is not for you. Do you also expect zsh enthusiasts to court Windows devs?
    - asveikau 9y ago
      I kind of disagree, it's quite possible to use gnu make on Windows with msys (though requires some scripting discipline and probably not for everyone). I'm currently doing this for a cross platform c++ project. Same makefile used for Linux, Mac, and windows+msys+cl.exe. (yes, fair amount of extra variables and ifdefs to support the last one...)
- MaulingMonkey 9y ago
  All the more reason to use a regular scripting language for building, then, since there are several that are plenty cross-platform.
falcolas 9y ago
I'd argue that there are some major concerns with the makefiles if they require the use of 3 different versions of make to get it all working - a situation I've never personally seen before. I'd suggest prioritizing fixing that before attempting tracking down the cause of other issues. As it stands, there are too many points of interaction to attribute any bugs to any one program. That said, Windows has never been a strong platform on which to run make (or git, gcc, or any other [u/li]nix originated CLI tools). When I hear of folks using make, I tend to make the assumption that they're running on a [u/li]nix or BSD derivative.
- MaulingMonkey 9y ago
  > I'd suggest prioritizing fixing that I've already had one upstream patch rejected on account of the additional complexity fixing it introduces, and would rather not indefinitely support my own fork of other people's build setups. Or if I am going to indefinitely support my own fork, I might as well rewrite the build config to properly integrate with the rest of whatever build system I happen to be using - at least then I'll get unified build/compilation options etc.

Cyph0n 9y ago

> path normalization and bintools selection issues on windows make was never intended to be a cross-platform tool. If you face problems using it on Windows, then that's on you.

EdSharkey 9y ago
That is, unless the folks who maintain and champion make want me to use make. It's on them to court me, the cross-platform developer, not the other way around.
- Cyph0n 9y ago
  Again, if you're a cross-platform developer, make is not for you. Do you also expect zsh enthusiasts to court Windows devs?
  - asveikau 9y ago
    I kind of disagree, it's quite possible to use gnu make on Windows with msys (though requires some scripting discipline and probably not for everyone). I'm currently doing this for a cross platform c++ project. Same makefile used for Linux, Mac, and windows+msys+cl.exe. (yes, fair amount of extra variables and ifdefs to support the last one...)
MaulingMonkey 9y ago
All the more reason to use a regular scripting language for building, then, since there are several that are plenty cross-platform.

falcolas 9y ago

I'd argue that there are some major concerns with the makefiles if they require the use of 3 different versions of make to get it all working - a situation I've never personally seen before. I'd suggest prioritizing fixing that before attempting tracking down the cause of other issues. As it stands, there are too many points of interaction to attribute any bugs to any one program. That said, Windows has never been a strong platform on which to run make (or git, gcc, or any other [u/li]nix originated CLI tools). When I hear of folks using make, I tend to make the assumption that they're running on a [u/li]nix or BSD derivative.

MaulingMonkey 9y ago
> I'd suggest prioritizing fixing that I've already had one upstream patch rejected on account of the additional complexity fixing it introduces, and would rather not indefinitely support my own fork of other people's build setups. Or if I am going to indefinitely support my own fork, I might as well rewrite the build config to properly integrate with the rest of whatever build system I happen to be using - at least then I'll get unified build/compilation options etc.