3 ms·

> In practice, there are libraries and also dev-libraries which actually add headers and link-objects to use these same libraries. When developing software, yo

by exDM69 9y ago

> In practice, there are libraries and also dev-libraries which actually add headers and link-objects to use these same libraries. When developing software, you need both installed. Not every distro has -dev packages to install headers. > IMO you use submodules only for libraries not already included in your package manager. This approach is full of problems, most importantly that this isn't reliably reproducible (without using docker images or something for a reproducible environment). Your package manager may have different libs or different versions of libs than another developer's package manager. But the bigger issue is version requirements mismatches. Say your web browser (or other must-have app) requires libwidget-1.0, but you're writing an app that needs libwidget-2.0 or libwidget-0.8 or both (e.g. your latest supported release was 0.8 and next release is 2.0). You can't install 2.0 or 0.8 because it would break an app you need for daily work. Using your distro package manager for development is a partial solution at best.

twic 9y ago
> Not every distro has -dev packages to install headers. Really? I would be surprised if every distro didn't have a mechanism to install the headers and static libraries for all of its dynamic library packages. How would the distro's own build process work otherwise? > But the bigger issue is version requirements mismatches. This is the killer. Distros are based on the idea that there should be only one version of any package installed at once. A development package manager needs to be able to handle many. This feels like it should be relatively straightforward to add to distro package managers, though. You would need a package-space concept analogous to a container - a consistent set of packages separate from the host's, and some way to run a build process within it. So i can say: dnf create-pkgcontainer ~/dev/myproject dnf --pkgcontainer ~/dev/myproject install zlib-devel-1.2.8 Then inside ~/dev/myproject i have some sort of metadata listing what is installed in that container - say, a bunch of symlinks to pkgconfig files, a ld.so.conf and a ld.so.cache, etc. Then i can say: dnf pkgcontainer-run ~/dev/myproject make And make will somehow pick up the environment inside the container, rather than the global environment. That's easier said than done, of course, given how many different independent parts of the toolchain there are, and how intertwined but uncoordinated they are. You could use the sledgehammer of constructing an actual container, or at least a chroot, but ideally you wouldn't have to.
- exDM69 9y ago
  Containers are a workaround and an overkill solution to this problem. It's a pain in the ass when you need to enter a "blessed" environment to build your project. By "blessed", I mean a container environment, a chroot or just some environment variables that need to be set. > dnf pkgcontainer-run ~/dev/myproject make The issue with this kind of builds is that they integrate poorly with your $EDITOR (or IDE). When I run a build, I want the results to be piped back to my editor so I can comfortably jump to the files with errors and warnings in them. And it's not only the build, it's also running your application, running the debugger, static analysis, linters, etc. Requiring a special environment will introduce friction to all of these. Additionally, your suggestion of using "dnf" would require every developer in the project to use an OS where "dnf" runs. Builds should be reproducible as much as possible without depending on the OS. Development package managers solve lots of these problems, although having a package manager for every language is an issue.

by exDM69 9y ago

twic 9y ago

> Not every distro has -dev packages to install headers. Really? I would be surprised if every distro didn't have a mechanism to install the headers and static libraries for all of its dynamic library packages. How would the distro's own build process work otherwise? > But the bigger issue is version requirements mismatches. This is the killer. Distros are based on the idea that there should be only one version of any package installed at once. A development package manager needs to be able to handle many. This feels like it should be relatively straightforward to add to distro package managers, though. You would need a package-space concept analogous to a container - a consistent set of packages separate from the host's, and some way to run a build process within it. So i can say: dnf create-pkgcontainer ~/dev/myproject dnf --pkgcontainer ~/dev/myproject install zlib-devel-1.2.8 Then inside ~/dev/myproject i have some sort of metadata listing what is installed in that container - say, a bunch of symlinks to pkgconfig files, a ld.so.conf and a ld.so.cache, etc. Then i can say: dnf pkgcontainer-run ~/dev/myproject make And make will somehow pick up the environment inside the container, rather than the global environment. That's easier said than done, of course, given how many different independent parts of the toolchain there are, and how intertwined but uncoordinated they are. You could use the sledgehammer of constructing an actual container, or at least a chroot, but ideally you wouldn't have to.

exDM69 9y ago
Containers are a workaround and an overkill solution to this problem. It's a pain in the ass when you need to enter a "blessed" environment to build your project. By "blessed", I mean a container environment, a chroot or just some environment variables that need to be set. > dnf pkgcontainer-run ~/dev/myproject make The issue with this kind of builds is that they integrate poorly with your $EDITOR (or IDE). When I run a build, I want the results to be piped back to my editor so I can comfortably jump to the files with errors and warnings in them. And it's not only the build, it's also running your application, running the debugger, static analysis, linters, etc. Requiring a special environment will introduce friction to all of these. Additionally, your suggestion of using "dnf" would require every developer in the project to use an OS where "dnf" runs. Builds should be reproducible as much as possible without depending on the OS. Development package managers solve lots of these problems, although having a package manager for every language is an issue.