LLVM Targets about repo HOT 17 CLOSED

I think I found a workaround for this situation.

I think for KISS, we should enable -DZIG_PREFER_CLANG_CPP_DYLIB=ON in the Zig CMake config, so that the cross-compiler (in case one doesn't really bother with cross-compiling feature of Zig) feature is up to the user. So if there's a Zig in community, one can choose between having the feature enabled or not (by choosing the LLVM provider, KISS-provided or not). Either way, you'll need to rebuild Zig anyway, but (using ninja, at least), building Zig is actually pleasant, compared to Go, Nim, or Rust.

Note: I believe a provides-like system would shine nicely here. Too bad getting it to work is probably a PITA.

from repo.

I'm reopening this because, reading through the issue you showed me, I've a different problem. After packaging LLD, and omitting the line which disables default targets from the LLVM build script, I have Zig building easily. All that should need to be done is to make this modification to the LLVM build script.

from repo.

I'm measuring them now for you :)
Note: I forgot how long it takes to build LLVM just by normal...

from repo.

Related dylanaraps/community#1623

from repo.

Thank you for pointing me to that!

from repo.

What are the size and compile-time differences between llvm the way we currently build it and the way we would need to build it?

from repo.

My compile time test won't be too accurate since these are done on my personal computer which is running other things, but should give a ballpark indication. This is done on an AMD Ryzen 1600X in a chroot.

from repo.

As you can see, the target change bizarrely decreased the compile time. I would interpret that as the difference in compile time being within margin of error. I'm not sure what you would think, but the 22M sacrifice is worth it for me to be able to build for different targets.

from repo.

On my machine with -O2 -pipe -march=native an installed llvm built with -DLLVM_TARGETS_TO_BUILD="host" takes up 239MB, and the one with all targets enabled takes up 361MB.

from repo.

Ah, I was measuring the tarballs. My total matches your's.

from repo.

That's quite the substantial size increase.
I don't think this change should be made (unfortunately), and here is my reasoning:

1. 100MB is a lot of space to take up on someone's drive, almost especially for a package they will probably never end up using. Certainly they could fork llvm, but that seems like burdening the many for the benefit of very few.
2. llvm exists for precisely two things - mesa and firefox (+ clang & rust). If this distribution only targeted Intel graphics and used chromium instead of firefox, llvm probably wouldn't even be in the main repo afaik. To implement this change for something in community sets an... unruly precedent for how much the main repository should accommodate community.
3. adding something like llvm-zig to community was a possible idea, but it creates a clash with things which require llvm, requiring zig users to fork packages just to ensure they don't have two llvms. This is also an undue burden for users. Having the correct llvm for zig in community is also an option, but it creates a clash with the main repo that I'm not interested in creating.

Ultimately, having zig in community would be a great +1. But I can't find a tractable solution that doesn't inconvenience some number of users, when the most friction-less option is to simply create something like $/Ominitay/kiss-zig that houses llvm, zig, and whatever other fun ziglang projects exist. The maintenance for you doesn't change, and the headache for users doesn't increase. It's worth noting that @mmatongo probably plans on adding zig to his own kiss-lang repo quite soon.

If you can come up with a better option than this, I'm 100% for it. Otherwise, I look forward to a new repo entering the kiss-repo topic, and I'll be mentioning it in April's This Month in KISS :)

from repo.

I opened an issue with the zig development team and the issue was upstreamed to be fixed in the next release 0.8.0.

With how long llvm takes to build, adding more weight to an already heavy package to only be used by one package would set a bad precedent like @dilyn-corner has pointed out.

from repo.

I'll make my own repo for this then. Thank you very much for the feedback!

from repo.

How about a switch set through en environment variable? ZIG=1 kiss b llvm
https://github.com/kiss-community/repo-community/blob/main/community/webkit2gtk/build#L4
Other packages do it by checking if foois available. Unfortunately this could not be done for llvm beforehand.
This would be the first package controlled through a variable. Not the cleanest solution.

from repo.

It isn't exactly a KISS solution. I think just repackaging LLVM in my kiss-zig repo is the best way to go. Doing something like that would be basically implementing something like Portage's USE flags, which, if done, should be through the package manager.

from repo.

@konimex You are a genius! That works, provided that /usr/bin/ld is linked to lld. I will reopen my Zig PR, with the necessary modifications. I should probably be able to modify things to use lld without the symlink too. It is of course, an unsupported configuration, but I think it is worth the sacrifice. When Zig goes self-hosted, we shouldn't have to depend on LLVM at all.

from repo.

The kiss-zig repository will remain alongside the community package I think, as it would still be wanted for cross-compilation support. Thank you all again for your help with getting this packaged!

from repo.