3 ms·

The two options of reproducible builds and prebuilt artifacts is still a significantly limiting situation. There are plenty of situations where the desired preb

by dzaima 3y ago

The two options of reproducible builds and prebuilt artifacts is still a significantly limiting situation. There are plenty of situations where the desired prebuilt artifacts aren't available, and you'd prefer to not have 5 clang-s and 7 gcc-s installed. There can be problems with updating toolchains, sure, and it's reasonable to write software assuming a specific one, but -Werror adding a very unnecessary roadblock is just not nice.

charcircuit 3y ago
>There are plenty of situations where the desired prebuilt artifacts aren't available, and you'd prefer to not have 5 clang-s and 7 gcc-s installed You don't need to install a toolchain to use it. The build tool should handle everything for you and should handle clearing caches of unsued toolchains that are no longer needed. >but -Werror adding a very unnecessary roadblock is just not nice. Warnings should be looked at. If the errors are not important you can add flags to silence them.
- dzaima 3y ago
  > You don't need to install a toolchain to use it. The build tool should handle everything for you and should handle clearing caches of unsued toolchains that are no longer needed. I don't want a dozen clangs and gccs wasting disk space (& increasing initial build times) regardless of who manages them! And I don't mean one project having a bunch of toolchains (I pray that never happens), I mean having dozens of random projects on my computer, most having been built just once and which won't be touched for an indeterminate amount of time. > Warnings should be looked at. If the errors are not important you can add flags to silence them. Yes, developers should look at them (and developers can look at them even without -Werror! or, as said elsewhere, it could be enabled conditionally). Users won't get much out of them, other than being annoyed at the project if they prevent the project from being built.
  - charcircuit 3y ago
    >I mean having dozens of random projects on my computer, most having been built just once and which won't be touched for an indeterminate amount of time. You don't have to persist all of the build time dependencies forever. It can redownload them if you need to rebuild one of them.
    - dzaima 3y ago
      But at which point would they stop being persisted? Surely not right after the build completing, so.. requiring manually running some "ok now clean redownloadable dependencies" command (noone's gonna bother, and at that point a regular clean makes more sense)? adding a cron job on my system (please don't)? on some other build command invocation after some time (will likely never happen)? Most of your suggestions here make sense under the assumption that the project in question is one whose development I participate in/with some regularity engage with, but that simply isn't the case for most projects a given person may have some desire/need to build from source.
      - charcircuit 3y ago
        >But at which point would they stop being persisted? You can either manually run the cleanup after the build or when you need free space. Alternatively a systemd timer that deletes old stuff that hasn't been accessed in weeks would work too. The same issue exists even only the system toolchain is used. There will me gigabytes of dependencies or object files that aren't needed taking up space. This is a problem of all dependencies. Toolchain dependencies are not special.
        dzaima 3y ago
        > There will me gigabytes of dependencies or object files that aren't needed taking up space. Among the couple dozen things I've got built from source, most have their object files sum up to less than the 117MB of a libLLVM-15.so.1, and if not, are only slightly larger (200-300MB). (and, as for the topic in question, maybe only one downloaded its own toolchain, and everything else freely allowed me to give a local gcc or clang in 'CC='/'CXX='). I think a build of all targets of QEMU is the only significantly larger thing I have (1.9GB of binaries, 2.1GB of object files). > Alternatively a systemd timer that deletes old stuff that hasn't been accessed in weeks would work too. Besides being awful (why does a build system need to even know about systemd?!?!!? much less make a semi-permanent addition), that also would fail if I moved the build directory to somewhere else (which, granted, would probably mean a clean would be needed to rebuild, but I will not care when I'm moving all of my git clones from one drive to another).

by dzaima 3y ago

charcircuit 3y ago

>There are plenty of situations where the desired prebuilt artifacts aren't available, and you'd prefer to not have 5 clang-s and 7 gcc-s installed You don't need to install a toolchain to use it. The build tool should handle everything for you and should handle clearing caches of unsued toolchains that are no longer needed. >but -Werror adding a very unnecessary roadblock is just not nice. Warnings should be looked at. If the errors are not important you can add flags to silence them.

dzaima 3y ago
> You don't need to install a toolchain to use it. The build tool should handle everything for you and should handle clearing caches of unsued toolchains that are no longer needed. I don't want a dozen clangs and gccs wasting disk space (& increasing initial build times) regardless of who manages them! And I don't mean one project having a bunch of toolchains (I pray that never happens), I mean having dozens of random projects on my computer, most having been built just once and which won't be touched for an indeterminate amount of time. > Warnings should be looked at. If the errors are not important you can add flags to silence them. Yes, developers should look at them (and developers can look at them even without -Werror! or, as said elsewhere, it could be enabled conditionally). Users won't get much out of them, other than being annoyed at the project if they prevent the project from being built.
- charcircuit 3y ago
  >I mean having dozens of random projects on my computer, most having been built just once and which won't be touched for an indeterminate amount of time. You don't have to persist all of the build time dependencies forever. It can redownload them if you need to rebuild one of them.
  - dzaima 3y ago
    But at which point would they stop being persisted? Surely not right after the build completing, so.. requiring manually running some "ok now clean redownloadable dependencies" command (noone's gonna bother, and at that point a regular clean makes more sense)? adding a cron job on my system (please don't)? on some other build command invocation after some time (will likely never happen)? Most of your suggestions here make sense under the assumption that the project in question is one whose development I participate in/with some regularity engage with, but that simply isn't the case for most projects a given person may have some desire/need to build from source.
    - charcircuit 3y ago
      >But at which point would they stop being persisted? You can either manually run the cleanup after the build or when you need free space. Alternatively a systemd timer that deletes old stuff that hasn't been accessed in weeks would work too. The same issue exists even only the system toolchain is used. There will me gigabytes of dependencies or object files that aren't needed taking up space. This is a problem of all dependencies. Toolchain dependencies are not special.
      - dzaima 3y ago
        > There will me gigabytes of dependencies or object files that aren't needed taking up space. Among the couple dozen things I've got built from source, most have their object files sum up to less than the 117MB of a libLLVM-15.so.1, and if not, are only slightly larger (200-300MB). (and, as for the topic in question, maybe only one downloaded its own toolchain, and everything else freely allowed me to give a local gcc or clang in 'CC='/'CXX='). I think a build of all targets of QEMU is the only significantly larger thing I have (1.9GB of binaries, 2.1GB of object files). > Alternatively a systemd timer that deletes old stuff that hasn't been accessed in weeks would work too. Besides being awful (why does a build system need to even know about systemd?!?!!? much less make a semi-permanent addition), that also would fail if I moved the build directory to somewhere else (which, granted, would probably mean a clean would be needed to rebuild, but I will not care when I'm moving all of my git clones from one drive to another).