5 ms·

FWIW, I read through each of your links. They don't address cross-compilation at all, or the needs of software packagers. I can 100% promise you that somebody

FWIW, I read through each of your links. They don't address cross-compilation at all, or the needs of software packagers. I can 100% promise you that somebody packaging this library for any Linux distro (or for a Yocto/Buildroot system) would grind their teeth in frustration at everything in the those links. The solution to having inconsistent packaging paths isn't to introduce _yet another_ packaging path system, but this one specific to djb stuff. It's to use a standard build system with overrideable paths, and not to assume the author knows better than the packager.

geocar 8y ago
> or the needs of software packagers. They address the needs of users. I don't care about software packagers at all, except insofar as they can address the needs of users. > The solution to having inconsistent packaging paths isn't to introduce _yet another_ packaging path system, but this one specific to djb stuff. It's to use a standard build system with overrideable paths, and not to assume the author knows better than the packager. Having "inconsistent packaging paths" isn't the problem. The problem is I have a program called "foo" and I don't know if it should begin with: #!/usr/local/bin/python or: #!/usr/bin/python Somebody who doesn't have a real job made the joke that it should "obviously" use "overridable paths" like this: #!/usr/bin/env python but that person hasn't used very many unix systems so they're unaware that this doesn't work on some systems. Eventually the "package manager" compromised with: #!/bin/sh ''':' if type python2 >/dev/null 2>/dev/null; then exec python2 "$0" "$@" else exec python "$0" "$@" fi ''' And users are like "what the fuck!?" All we needed to agree was that python "lives" in /usr/local/bin/python and python3 (an incompatible alternative to python) lives someplace else, we would have been fine. And for what? Why did we bother with this? What did we actually gain for all this extra shit? Some package manager felt like he was doing the job of a tarball? > They don't address cross-compilation at all, or the needs of software packagers. Cross-compilation is tricky for programs that need to run programs to figure out how they need to be built; neither cmake or GNU autoconf do anything to address it. The best solution package managers seem to suggest is to "not do that" but those programs are slow.
- numbsafari 8y ago
  Also, is cross-compilation even a goal for a software library written with the clear caveat that it makes use of specific CPU features?
  - nrclark 8y ago
    Let's say I'm writing firmware for a TV. Why wouldn't I want to use the chip's CPU to the fullest extent at runtime? That doesn't mean I want to compile my TV firmware _on_ the TV.
    - geocar 8y ago
      > Why wouldn't I want to use the chip's CPU to the fullest extent at runtime? Because you'd rather use GNU autoconf? If you wanted the fastest possible performance, you'd try each algorithm, profile them, then select the one that works best. This build process can do that automatically. GNU autoconf cannot. You can tell autoconf which to use, but the package maintainer can't be trusted to do this. Then the user will just complain that it's not that much faster than qsort. The package maintainer would be to blame for users thinking this was slow software simply because they chose poor defaults, and nobody would ever know...
      - aseipp 8y ago
        > If you wanted the fastest possible performance, you'd try each algorithm, profile them, then select the one that works best. This build process can do that automatically. GNU autoconf cannot. Except doing it at build time is a terrible idea anyway. That is because the set of CPUs it will be used on is actually unknown, unless it's literally not meant for anyone else to use that compiled object. But that's not how people actually develop at all. They distribute the software objects and users link against it on their CPUs, which the original build system cannot possibly have knowledge of. Requiring AVX2 or whatever by default really has nothing to do with this. High speed software that's actually usable for developers and users selects appropriate algorithms at runtime based on the characteristics of the actual machine they run on (for example, Ryzen vs Skylake, which have different throughput and cycle characteristics.) This is the only meaningful way to do it unless you literally only care about ever deploying to one machine, or you just don't give a shit about usability.

geocar 8y ago

> or the needs of software packagers. They address the needs of users. I don't care about software packagers at all, except insofar as they can address the needs of users. > The solution to having inconsistent packaging paths isn't to introduce _yet another_ packaging path system, but this one specific to djb stuff. It's to use a standard build system with overrideable paths, and not to assume the author knows better than the packager. Having "inconsistent packaging paths" isn't the problem. The problem is I have a program called "foo" and I don't know if it should begin with: #!/usr/local/bin/python or: #!/usr/bin/python Somebody who doesn't have a real job made the joke that it should "obviously" use "overridable paths" like this: #!/usr/bin/env python but that person hasn't used very many unix systems so they're unaware that this doesn't work on some systems. Eventually the "package manager" compromised with: #!/bin/sh ''':' if type python2 >/dev/null 2>/dev/null; then exec python2 "$0" "$@" else exec python "$0" "$@" fi ''' And users are like "what the fuck!?" All we needed to agree was that python "lives" in /usr/local/bin/python and python3 (an incompatible alternative to python) lives someplace else, we would have been fine. And for what? Why did we bother with this? What did we actually gain for all this extra shit? Some package manager felt like he was doing the job of a tarball? > They don't address cross-compilation at all, or the needs of software packagers. Cross-compilation is tricky for programs that need to run programs to figure out how they need to be built; neither cmake or GNU autoconf do anything to address it. The best solution package managers seem to suggest is to "not do that" but those programs are slow.

numbsafari 8y ago
Also, is cross-compilation even a goal for a software library written with the clear caveat that it makes use of specific CPU features?
- nrclark 8y ago
  Let's say I'm writing firmware for a TV. Why wouldn't I want to use the chip's CPU to the fullest extent at runtime? That doesn't mean I want to compile my TV firmware _on_ the TV.
  - geocar 8y ago
    > Why wouldn't I want to use the chip's CPU to the fullest extent at runtime? Because you'd rather use GNU autoconf? If you wanted the fastest possible performance, you'd try each algorithm, profile them, then select the one that works best. This build process can do that automatically. GNU autoconf cannot. You can tell autoconf which to use, but the package maintainer can't be trusted to do this. Then the user will just complain that it's not that much faster than qsort. The package maintainer would be to blame for users thinking this was slow software simply because they chose poor defaults, and nobody would ever know...
    - aseipp 8y ago
      > If you wanted the fastest possible performance, you'd try each algorithm, profile them, then select the one that works best. This build process can do that automatically. GNU autoconf cannot. Except doing it at build time is a terrible idea anyway. That is because the set of CPUs it will be used on is actually unknown, unless it's literally not meant for anyone else to use that compiled object. But that's not how people actually develop at all. They distribute the software objects and users link against it on their CPUs, which the original build system cannot possibly have knowledge of. Requiring AVX2 or whatever by default really has nothing to do with this. High speed software that's actually usable for developers and users selects appropriate algorithms at runtime based on the characteristics of the actual machine they run on (for example, Ryzen vs Skylake, which have different throughput and cycle characteristics.) This is the only meaningful way to do it unless you literally only care about ever deploying to one machine, or you just don't give a shit about usability.