5 ms·

Hear, hear. Though I believe the best way to make that happen is to make your language play nice with automake. Nobody believes me.

by endgame 14y ago

klodolph 14y ago
I believe you. This is why I don't use CMake / SCons / Jam / etc -- they're nice for developers but bad for the package maintainers and sysadmins.
- mpyne 14y ago
  CMake is widely distributed now if only because of KDE, so the package maintainers and sysadmins have figured it out one way or the other already.
shadowmint 14y ago
Even fink uses cmake to build and install a whole bunch of packages now. The future, it's not with automake.
jack12 14y ago
I'd love to see support for writing directly into distribution's package managers' databases added to things like pip, npm, gems, etc. too but I'm curious what playing nicely with automake gains here. I'm not too experienced with it, and I don't quite see where it would fit into that process. I think of automake as being more part of the build process. But if things worked as you and inopinatus suggest, and you have taught something like pip 2.0 to bypass the rpm package manager and instead add records directly to the RPM database for a binary wheel package that pip has installed, aren't you kind of routing around any problems of a distribution's compatibility with a language's custom build process entirely? Or did you mean to reply one level up? Though, again, I'm not sure where automake would help with converting one binary package format into a distribution-specific binary format.
- endgame 14y ago
  Automake is most definitely a build tool, and I believe that should be orthogonal to the package manager (even though we're seeing convergence in this area with things like go, virtualenv, npm and so on). The thing with automake is: 1. Distros know how to package it. With cdbs, a debian/rules file for a properly autotooled package is only a couple of lines. 2. Because everything boils down to shell and makefile fragments, you can extend it to fit your corner cases fairly easily.

Hear, hear. Though I believe the best way to make that happen is to make your language play nice with automake. Nobody believes me.

by endgame 14y ago

Hear, hear. Though I believe the best way to make that happen is to make your language play nice with automake. Nobody believes me.

klodolph 14y ago

I believe you. This is why I don't use CMake / SCons / Jam / etc -- they're nice for developers but bad for the package maintainers and sysadmins.

mpyne 14y ago
CMake is widely distributed now if only because of KDE, so the package maintainers and sysadmins have figured it out one way or the other already.

shadowmint 14y ago

Even fink uses cmake to build and install a whole bunch of packages now. The future, it's not with automake.

jack12 14y ago

I'd love to see support for writing directly into distribution's package managers' databases added to things like pip, npm, gems, etc. too but I'm curious what playing nicely with automake gains here. I'm not too experienced with it, and I don't quite see where it would fit into that process. I think of automake as being more part of the build process. But if things worked as you and inopinatus suggest, and you have taught something like pip 2.0 to bypass the rpm package manager and instead add records directly to the RPM database for a binary wheel package that pip has installed, aren't you kind of routing around any problems of a distribution's compatibility with a language's custom build process entirely? Or did you mean to reply one level up? Though, again, I'm not sure where automake would help with converting one binary package format into a distribution-specific binary format.

endgame 14y ago
Automake is most definitely a build tool, and I believe that should be orthogonal to the package manager (even though we're seeing convergence in this area with things like go, virtualenv, npm and so on). The thing with automake is: 1. Distros know how to package it. With cdbs, a debian/rules file for a properly autotooled package is only a couple of lines. 2. Because everything boils down to shell and makefile fragments, you can extend it to fit your corner cases fairly easily.