On Sat, Jul 06, 2024 at 01:49:56PM +0200, Sebastien Marie wrote:
> Anon Loli <anonloli@autistici.org> 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.
No comments:
Post a Comment