5 ms·

> Even grabbing libraries from github, I was unsure if I should grab just the headers and DLLs, or import the entire tree and mashup my build scripts with their

> Even grabbing libraries from github, I was unsure if I should grab just the headers and DLLs, or import the entire tree and mashup my build scripts with theirs. Honestly this is something that apt (et al.) make so easy on Linux distros that when you move to Mac or Windows you just have hard time believing people still in 2018 have to _deal with this shit_ (installing libraries and their headers by downloading each one separately and running an "installer" and trying to figure out where it put everything) Like, why. It's one of the principle things keeping me away from developing on Windows for the last 10 or 15 years, the absolute lack of standards with regards to dev package management. Every time I decide I need to get something working on Windows it's an incredible pain in the ass compared to Ubuntu. Oh, now go to THIS website and download this installer and run it, now this one, now this one. And figure out for each one where it decided to put the headers. Now copy the DLLs around, etc. (Yes, there is system32 and Program Files but installers don't adhere to this by any means, and discovery via a build system is not given.) It's just barely worth it, and people only put up with it because of the huge user base. Honestly, for small projects I've found it easier to install MingW32 under Linux and cross-compile instead of working on Windows, it's that much of a pain. At least Mac has Homebrew and Windows has a couple of good solutions now I guess (chocolatey, who came up with that name), but they are not officially supported and that is sad. I understand, they don't want to pay an army of people to package open source software full time, which effectively is what keeps Debian and Fedora going.. but they should. I would say it's one of principle reasons then end up doing something like providing an Ubuntu environment on Windows .. it's not just that people wanted a Unix-like environment, it's that they wanted _package management_.

xnyan 8y ago
Windows continues to move in the right direction with package management. Your comment "not officially supported" may not be correct depending on your definition of official. Package management is native in win10 with OneGet, and PMs like scoop have been improving in quality and reliability to the point that I don't even think about them anymore. I do agree that there is a lot of room for standardizing tool chain and dependency install workflows, but the tools themselves are of high quality now imo.
- radarsat1 8y ago
  I am glad it's getting better.
EForEndeavour 8y ago
> chocolatey, who came up with that name The chocolatey repo (https://github.com/chocolatey/choco/wiki/History https://github.com/chocolatey/choco/wiki/History) explains the name as a pun based on the previous package manager NuGet: "Chocolatey started out as a joke because everyone loves Chocolatey nougat (nuget)."
BeeOnRope 8y ago
For what it's worth, I develop almost exclusively on Ubuntu, but built-in package management is no panacea. You get one version of each package, and it is often years out of date. If you need a newer version you'll have to install it yourself and then try to navigate how to get your projects to use your local version. For any popular package that is still undergoing a fair amount of change it is likely that eventually some project you want to build will need a newer version than the one your distro provides. So you still need a solution to the versioning problem separate from the distro packaging environment, at least for development.
gattr 8y ago
For building my (rather small) projects for Windows I use MSYS2 [0]; it uses pacman for package management and has quite a big library of ready binaries. [0] http://www.msys2.org/ http://www.msys2.org/
- radarsat1 8y ago
  I've been using it too. It's getting better, finally, thank goodness ;) Still a far cry from what is offered on Linuxes but so much better than nothing.
PopsiclePete 8y ago
How is this problem fixed on Linux? Headers/libraries on an Ubuntu LTS may be years out-of-date. Am I supposed to just download a tar.gz and do the configure/make/make install dance to /usr/local or /opt or something for each dependency that I need a more current version of? Even worse - what if my deployment target is 3-4 years older than the machine I'm developing/compiling on? I don't think anything is "solved" with a traditional UNIX environment. Not even close.
- flukus 8y ago
  > Am I supposed to just download a tar.gz and do the configure/make/make install dance to /usr/local or /opt or something for each dependency that I need a more current version of? No, you're (usually)supposed to stick with the out of date version rather than the shiny new version. Doing otherwise is taking on the responsibilities of a distro maintainer, usually not consciously. > Even worse - what if my deployment target is 3-4 years older than the machine I'm developing/compiling on? Either use the older version for developing or at least have a version of that environment for CI.

xnyan 8y ago

Windows continues to move in the right direction with package management. Your comment "not officially supported" may not be correct depending on your definition of official. Package management is native in win10 with OneGet, and PMs like scoop have been improving in quality and reliability to the point that I don't even think about them anymore. I do agree that there is a lot of room for standardizing tool chain and dependency install workflows, but the tools themselves are of high quality now imo.

radarsat1 8y ago
I am glad it's getting better.

EForEndeavour 8y ago

> chocolatey, who came up with that name The chocolatey repo (https://github.com/chocolatey/choco/wiki/History https://github.com/chocolatey/choco/wiki/History) explains the name as a pun based on the previous package manager NuGet: "Chocolatey started out as a joke because everyone loves Chocolatey nougat (nuget)."

BeeOnRope 8y ago

For what it's worth, I develop almost exclusively on Ubuntu, but built-in package management is no panacea. You get one version of each package, and it is often years out of date. If you need a newer version you'll have to install it yourself and then try to navigate how to get your projects to use your local version. For any popular package that is still undergoing a fair amount of change it is likely that eventually some project you want to build will need a newer version than the one your distro provides. So you still need a solution to the versioning problem separate from the distro packaging environment, at least for development.

gattr 8y ago

For building my (rather small) projects for Windows I use MSYS2 [0]; it uses pacman for package management and has quite a big library of ready binaries. [0] http://www.msys2.org/ http://www.msys2.org/

radarsat1 8y ago
I've been using it too. It's getting better, finally, thank goodness ;) Still a far cry from what is offered on Linuxes but so much better than nothing.

PopsiclePete 8y ago

How is this problem fixed on Linux? Headers/libraries on an Ubuntu LTS may be years out-of-date. Am I supposed to just download a tar.gz and do the configure/make/make install dance to /usr/local or /opt or something for each dependency that I need a more current version of? Even worse - what if my deployment target is 3-4 years older than the machine I'm developing/compiling on? I don't think anything is "solved" with a traditional UNIX environment. Not even close.

flukus 8y ago
> Am I supposed to just download a tar.gz and do the configure/make/make install dance to /usr/local or /opt or something for each dependency that I need a more current version of? No, you're (usually)supposed to stick with the out of date version rather than the shiny new version. Doing otherwise is taking on the responsibilities of a distro maintainer, usually not consciously. > Even worse - what if my deployment target is 3-4 years older than the machine I'm developing/compiling on? Either use the older version for developing or at least have a version of that environment for CI.