On Sat, Jul 06, 2024 at 01:49:56PM +0200, Sebastien Marie wrote: > Anon Loli <[email protected]> writes: > > > On Sat, Jul 06, 2024 at 07:10:37AM +0200, Sebastien Marie wrote: > > > > I see, so this full rebuild (ignoring object files) is most useful when for > > example fetching an update to the CVS repository? > > Is that what you meant by old and new elements? > > > > But as far as I understand, for local(not updated) development/changes, > > keeping > > object files is what I want for fast compiling, and to get that I need to > > set > > the KEEPKERNELS variable, and that alone? > > It's weird that one needs a full clean rebuild.. like why even use a version > > control system if it doesn't help when it comes to that? > > > > I don't know how object files are made, and all that is within them, but it > > would be nice if they would prevent a differential between a clean build > > and a > > build with old object files... for example with CVS you can probably see the > > difference between locally made changes and CVS repository updates... > > let's take a simple program: > > $ cat foo.c > #include <stdio.h> > #include <stdlib.h> > > int > main() > { > printf("hello world\n"); > return EXIT_SUCCESS; > } > > $ cc foo.c && ./a.out > hello world > > to build, `cc` will use several files on the system. in the source file, > we could see stdio.h and stdlib.h. > > if the repository contains changes in stdio.h or stdlib.h, these files > should be installed *before* compiling. else, you will use the ones > present on the system at compile time. > > in the previous example, the macro EXIT_SUCCESS comes from stdlib.h, and > the prototype of printf comes from stdio.h . if one of them changed, it > could result on unexpected behaviour (return will return the old > EXIT_SUCCESS value ; or printf will not work as intented and could miss > behave). these are only examples. > > but building programs involve more than just some headers. let's compile > with verbose parameter: > > $ cc -v foo.c > OpenBSD clang version 16.0.6 > Target: amd64-unknown-openbsd7.5 > Thread model: posix > InstalledDir: /usr/bin > "/usr/bin/cc" -cc1 -triple amd64-unknown-openbsd7.5 -emit-obj -mrelax-all > -disable-free -clear-ast-before-backend -disable-llvm-verifier > -discard-value-names -main-file-name foo.c -mrelocation-model pic -pic-level > 1 -pic-is-pie -mframe-pointer=all -relaxed-aliasing -ffp-contract=on > -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 > -tune-cpu generic -mllvm -treat-scalable-fixed-error-as-warning > -debugger-tuning=gdb -v -fcoverage-compilation-dir=/tmp -resource-dir > /usr/lib/clang/16 -internal-isystem /usr/lib/clang/16/include > -internal-externc-isystem /usr/include -fdebug-compilation-dir=/tmp > -ferror-limit 19 -fwrapv -D_RET_PROTECTOR -ret-protector > -fcf-protection=branch -fno-jump-tables -fgnuc-version=4.2.1 > -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc > -fno-builtin-valloc -fno-builtin-free -fno-builtin-strdup > -fno-builtin-strndup -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o > /tmp/foo-8725ea.o -x c foo.c > clang -cc1 version 16.0.6 based upon LLVM 16.0.6 default target > amd64-unknown-openbsd7.5 > #include "..." search starts here: > #include <...> search starts here: > /usr/lib/clang/16/include > /usr/include > End of search list. > "/usr/bin/ld" -e __start --eh-frame-hdr -Bdynamic -dynamic-linker > /usr/libexec/ld.so -o a.out /usr/lib/crt0.o /usr/lib/crtbegin.o -L/usr/lib > /tmp/foo-8725ea.o -lcompiler_rt -lc -lcompiler_rt /usr/lib/crtend.o > > > In order to build, the compiler is using the host system to generate the > binary: here we see: > - a set of default parameters for low-level elements of the compiler > - a set of default paths for includes and libraries > - some libraries (compiler_rt, c) > - some objects (crt0.o, crtbegin.o, crtend.o) > > if any elements change, it could influence the generated code, and so > the resulting behaviour. these elements are installed in the system, and > could not match exactly what it is in the repository. > > so to ensuring reproductibility of the build (not the reproductibility of > the binary, just the fact that all is working on the same way), a full > release(8) build could be necessary. > > as you saw, it is a long process. so if you don't changes the compiler > or elements used by it, you could only rebuild a particular directory. > > Regards. > -- > Sebastien Marie >
I understand, I was a programmer and hopefully will be again.. In my opinion the CVS itself should take care in preventing the "missbehaving", doesn't git do that already? I hope that we're on the same page.. I'm just not always understanding/understandable.. I don't want the reproductibility of the build, as I want to change the source code of the src/sys/dev/pci/azalia.c :) consider me a tester :P And it's such a shame that I have to wait a lot of hours... AGAIN So as far as I understand, in the future, all I need is KEEPKERNELS as I already now how.
