On 15/10/2015 02:02, Buck Evan wrote:
Are you idealogically opposed to the relpath strategy? Under this scheme, no absolute paths would be encoded in any binary, only relative paths.
I'm not ideologically opposed to the relpath strategy, I don't *hate* it, but I think it has important drawbacks that prevent it from being an acceptable fit for skarnet.org software. - Going all relative is a pretty intrusive policy decision. Since you can't rely on installation paths such as /bin and /libexec, in order to ensure consistency of your intra-package dependencies, you basically have to reserve a whole hierarchy to place all your stuff - binaries, libexecs, data, you name it, it needs to be available in a place you can find by just the location of the current binary. So, you can say goodbye to old-fashioned installations with /bin and friends: it's everything under a subtree, à la slashpackage but without the benefits of guaranteed absolute paths, and no /command. Which means the more packages you install this way, the more "interesting" your PATH becomes, unless you have a single entry point to link to /bin (like gcc). It's a fundamentally different approach from run-time locations that are known at compile-time; and it requires specific support. And either you design your package that way univocally, and you end up with software that has an even more annoying installation policy than slashpackage (which is the very reason why slashpackage didn't catch, to my dismay); or you make it a compile-time option, and that option has consequences in the form of #ifdefs in all your binaries, which has an important maintainability cost (and is unfathomably ugly). - You thought you had it easy with intra-package dependencies? Then try *inter*-package dependencies. If you depend on a piece of some other package that is not handled by an ad-hoc mechanism (dynamic linker configuration for shared libs, PATH for exported binaries), then it's basically impossible to find it unless your installation system supports that case, and even then you need to add hooks to your code to make it work: more ad-hoc ugliness. - Nit, but still worth mentioning: having to getcwd() in every binary that has a dependency can get old real fast. It's not only the getcwd, it's that the getcwd() interface can fail and either you allocate PATH_MAX bytes for it, or you bring in malloc() and dynamic string management functions. For heavy stuff like gcc, that's completely negligible, but for small binaries designed for intensive chain loading, such as execline programs, this may be a significant relative cost. - Finally, a personal taste: I don't like depending on the value of argv[0]. It's useful for very special cases such as busybox, but in the general case, I don't think a program should act differently depending on the way the binary is named or located. I want users to be able to link binaries anywhere and call them however they want. With the relpath strategy, this is simply not possible: in order to access the rest of its package's data, a binary has to be very precisely located inside its package, and cannot be called as an external link. Paradoxically, not knowing your installation path at compile-time enforces *stricter* location constraints on the binaries! Conclusion: the "all relative" policy works, it's used with success by gcc and probably other packages I'm not thinking of, but it's not something to take lightly, it requires designing the software around the policy, which I don't like, and it's definitely not suited to skarnet.org packages - so I'm not going to go the extra mile to accommodate it. -- Laurent
