on Sat, Jul 06, 2024 at 12:40:27PM +0000, Anon Loli wrote:
> 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.
>
OH OKAY I think I see where the confusion was.. when I said "I don't know
exactly how object files are made", I meant like "I don't know if you can know
if the object file is too old or not", but I realize now how stupid that
sounds... of course you can't verify it without compiling the files...
UNLESS you can somehow use datetime of the source code files in order to
determine wether or not the object files is outdated or not.
Isn't this genius?
It makes sense to me
(from my (I think)last reply)
"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? "
No comments:
Post a Comment