[Toybox] scripts/llvm-buildall.sh?

[Rob Landley]

On 8/5/21 2:16 AM, Patrick Oppenlander wrote:
> On Thu, Aug 5, 2021 at 3:28 PM Rob Landley <rob at landley.net> wrote:
>> > If you want the llvm build system to build multiple builtin or runtime
>> > targets there's a lot of configuration required :(
>>
>> For the _compiler_, it's just:
>>
>> mkdir -p build-llvm && cd build-llvm &&
>> cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$PREFIX \
>>     -DLLVM_ENABLE_PROJECTS="clang;lld" "$TOP/llvm-project/llvm" &&
>> ninja all install &&
>> cd .. && rm -rf build-llvm || exit 1
>>
>> With $PREFIX and $TOP set appropriately, of course. The resulting clang
>> --print-targets lists 39 options, from aarrcchh6644 to whatever "xcore" is.
>>
>> There's no reason their version of libgcc should be noticeably harder to
>> configure, AND YET. (What do you mean by "runtime targets"?)
> 
> My understanding, which might be incorrect, is that "builtins" is a
> subset of "runtimes".

Why can I LLVM_ENABLE_PROJECTS=clang but have to whack-a-mole
-DCOMPILER_RT_BUILD_BUILTINS=ON -DCOMPILER_RT_BUILD_SANITIZERS=OFF
-DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_MEMPROF=OFF ?

How does that make ANY sense?

> Runtimes includes the compiler runtime (libclang_rt.builtins.a, ala
> libgcc), atomics, unwind, sanitizers, libc, libc++, ...
> 
> Builtins just builds libclang_rt.builtins.a

I haven't tackled the "build a native compiler for each target" can of worms
yet, but I'm assuming since clang is sadly written in C++ it's going to need 37
more libraries than building C does.

>> > There's a bunch of cmake "caches" in the llvm project which set a
>> > bunch of these variables for some canned configurations (e.g. see
>> > llvm-project/clang/cmake/caches/BaremetalARM.cmake).
>>
>> Yeah, I rm -rf the build directory each time because otherwise it ignores what
>> you tell cmake's command line. (Not a fan.)
> 
> cmake is just so broken.

Eh, autoconf's still worse.

> I can't even get it to generate usable makefiles (parallel builds seem
> to be permanently broken). And building llvm single threaded takes a
> ridiculous amount of time.

It's building in parallel for me. But then I'm following it with ninja, not make.

I wrote my own one of these, "bake" (better make) back in college, for OS/2.
Give it a list of source files and the tool figured out how to compile them into
a binary (or library).

Since then I just use make shell scripts: you're calling the compiler in a loop.
Doing so in parallel with & and "wait" isn't a big lift. (Heck, bash has "wait
-n" now. Which sadly does not remove the job from the jobs list for reasons I
STILL don't understand, but you can count 'em yourself. Why there isn't a $^ or
$% for the current background job count, I couldn't tell you either. Or at least
a "jobs -c". Ideally "wait -n" would remove the job from the jobs list and
update $! to its pid. It's like the people writing bash don't actually use bits
of it much...)

Speaking of what would be nice, the compiler COULD parallelize itself so that
when you go "gcc main.c lib/*.c toys/*/*.c" it would use the appropriate number
of parallel tasks automatically. But alas gcc was an intentionally tangled
unmaintainable hairball for license reasons (no really,
https://gcc.gnu.org/legacy-ml/gcc/2000-01/msg00572.html is EXPLICIT about that)
and sadly llvm just copied what gcc did so no "cc -j *.c"...

>> > I've submitted a bunch of patches to phabricator which are in various
>> > states of landed (their word for merged), accepted (waiting for..
>> > something?), and bikeshedding.
>>
>> Never heard of it. Is that how you get stuff in there?
> 
> Yes. See https://reviews.llvm.org/.

An admin just emailed me today saying she's subscribed me to the mailing list.
No traffic from it yet, but yay progress?

Alas removing gratuitous libc dependencies from the build kinda requires being
able to build what's there as-is first for testing...

> AFAIK the cfg file has to be next door to the clang binary. It looks
> for argv[0].cfg and uses the contents of that file as command line
> arguments.
> 
> I also had to hack in a thing to get it to switch relative sysroot
> path based on the target, which it can't seem to do out of the box?
> 
> https://github.com/apexrtos/musl-cross-make/blob/clang/patches/llvm-project-12.0.1.src/0007-clang-support-expanding-target-triple-in-sysroot-pat.patch
> 
> actually lets you move the toolchain around, otherwise the sysroot
> path had to be baked into the cfg files as an absolute path.

Technical problems are easy to fix. Political problems are not. There are layers
of Fortune 500 "process" constipation all over this thing already. Unsurprising
given its history...

>> So either somebody else does it perfectly all by themselves, or I don't use it.
>> Because I'm not very interested in contributing patches to such a system. (And
>> yes that's why I'm not a buildroot developer.)
>>
>> I've already got a 70 shell script that does all but one package of this. That
>> one package is compiler-rt, and every time I dig into it I wind up scoping what
>> it would take to REPLACE...
> 
> I'd be happy if someone else did it imperfectly, as long as it works.
> I've got better things to do than wade through llvm's build system :(

I dunno about better, but I've definitely got _other_ things to do...

> Patrick

Rob