This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CI/CD in glibc


* Rafal Luzynski:

> Such a mechanism would be useful to detect use cases like:
> * something goes wrong but the problem is only in my machine
>   because the online service confirms there is no problem;
> * the code works fine in my machine and in all other developers'
>   machines but fails in one exotic hardware architecture.

We already have build and test bots, but I haven't been able to make any
sense of their output. 8-(

I would love to have a better contributor experience.  CI could be part
of that, but the kind of resources needed to give feedback in a
reasonable time frame (say, less than one hour) are difficult to come by
at this point.  (And we are not even talking about actually running
tests, just making sure that everything still builds.)

Some more notes about the build system:

Most of my development work involves short-circuiting the build system
for testing (make -j8 -O subdirs=… check).  I have to be really careful when I
do that because in some cases, it will corrupt your build tree, and then
I need to throw everything away and build from scratch again.  It's
considerably safer to do this instead:

  make -j8 -O && make -j8 -O subdirs=… check

But for me, it adds 12 seconds to every test tweak.  (For reference:
musl builds from scratch in less than 10 seconds on this hardware.)

What's worse, for me, the test-in-continer framework has made things
quite worse, but no one has been able to reproduce that.  Given things
are so brittle, I hesitate to encourage adoption of this style.  But not
being able to do something like that makes it really hard for new
contributors.

One experiment I'd like to do (and maybe someone wants to help with
that): Instrument CC and CXX invocations with something that captures
the current directory and the command lines during a regular build.
Afterwards, replay all the compiler invocations, in parallel.  (This may
need some manual tweaks for adding barriers, but perhaps not if we run
this test on an already-built tree.)  This should gives a number: How
much time does it take, at minimum, to build glibc, without make
overhead or artificial serialization.  It will tell us how inefficient
the current build system really is.  Is the make overhead for a
from-scratch build just those 12 seconds I mentioned above, or is it
much larger?

This should give us some guidance whether we need to focus on
from-scratch performance, or on making incremental builds accurate.

My feeling is that we need to tackle this first before we can offer a CI
workflow because even with remote CI, local builds will still be an
important part of the developer experience.  And if we can speed up
building significantly, we perhaps do not have to investigate ways to
run build-many-glibcs.py in a distributed fashion, on a cluster of
machines.

Thanks,
Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]