5 ms·

Seems like they only should depend on the parts of dependency that actually get incorporated in the dependent. For instance: - Changes to C source files of a

by devit 5y ago

Seems like they only should depend on the parts of dependency that actually get incorporated in the dependent. For instance: - Changes to C source files of a shared library should not require a rebuild of dependents (assuming you don't LTO with shared library bitcode) - Changes to an executable in a dependency that you run as a child process during usage but not at build time should not require a rebuild of dependents

jcelerier 5y ago
> Changes to C source files of a shared library should not require a rebuild of dependents Yes it should, as dependents may be looking for the existence of a given function being exported from the library at build time (through dlopen/dlsym) and enable / disable features accordingly
- devit 5y ago
  Yeah, that only applies if the build process of the dependents does not actually use the shared library itself (other than for linking to it).
- kevincox 5y ago
  This issue can be solved by extracting the "interface" and using that as the input. So for a shared library the interface may be all exported symbols. If that changes in any way you should rebuild the dependencies (to be cautious). I think the ideal way to do this is to make a "dummy" library with the same interface and expose that to the build of the other program. That way you know it doesn't depend on anything else. Of course there are complexities: - What if the library is called in the build. Maybe the shim can proxy back to the original? But now you risk it depending on something. For tests proxying may make sense for build maybe not. - For Nix you still want to produce a new output that is hardcoded to the new library version. You can skip the compile, but you still need to update the references.
patrec 5y ago
> - Changes to C source files of a shared library should not require a rebuild of dependents (assuming you don't LTO with shared library bitcode) Not so. Nix does dynamic linking right, too, which means you dynamically link to a unique content (or build recipe) addressable name. Concrete example: > readlink -f $(which tmux) /nix/store/vhbhhg82h62j0qnhrd323792c989idsz-tmux-3.1c/bin/tmux > ldd /nix/store/vhbhhg82h62j0qnhrd323792c989idsz-tmux-3.1c/bin/tmux | fgrep libc.so libc.so.6 => /nix/store/90illc73xfs933d06daq6d41njs8yh66-glibc-2.32-37/lib/libc.so.6 (0x00007f21a0e93000) The 90illc73xfs933d06daq6d41njs8yh66 bit identifies an unique version of glibc. This way it's actually reproducible and you don't have DLL-hell clashes.

by devit 5y ago

jcelerier 5y ago

> Changes to C source files of a shared library should not require a rebuild of dependents Yes it should, as dependents may be looking for the existence of a given function being exported from the library at build time (through dlopen/dlsym) and enable / disable features accordingly

devit 5y ago
Yeah, that only applies if the build process of the dependents does not actually use the shared library itself (other than for linking to it).
kevincox 5y ago
This issue can be solved by extracting the "interface" and using that as the input. So for a shared library the interface may be all exported symbols. If that changes in any way you should rebuild the dependencies (to be cautious). I think the ideal way to do this is to make a "dummy" library with the same interface and expose that to the build of the other program. That way you know it doesn't depend on anything else. Of course there are complexities: - What if the library is called in the build. Maybe the shim can proxy back to the original? But now you risk it depending on something. For tests proxying may make sense for build maybe not. - For Nix you still want to produce a new output that is hardcoded to the new library version. You can skip the compile, but you still need to update the references.

patrec 5y ago

> - Changes to C source files of a shared library should not require a rebuild of dependents (assuming you don't LTO with shared library bitcode) Not so. Nix does dynamic linking right, too, which means you dynamically link to a unique content (or build recipe) addressable name. Concrete example: > readlink -f $(which tmux) /nix/store/vhbhhg82h62j0qnhrd323792c989idsz-tmux-3.1c/bin/tmux > ldd /nix/store/vhbhhg82h62j0qnhrd323792c989idsz-tmux-3.1c/bin/tmux | fgrep libc.so libc.so.6 => /nix/store/90illc73xfs933d06daq6d41njs8yh66-glibc-2.32-37/lib/libc.so.6 (0x00007f21a0e93000) The 90illc73xfs933d06daq6d41njs8yh66 bit identifies an unique version of glibc. This way it's actually reproducible and you don't have DLL-hell clashes.