[llvmlinux] Quick build against stable versions of toolchain (llvm and clang) and Linux-kernel?

Behan Webster behanw at converseincode.com
Mon Jan 21 16:04:34 UTC 2013

On 01/21/13 09:58, Sedat Dilek wrote:
> On Mon, Jan 21, 2013 at 3:37 PM, Behan Webster
> <behanw at converseincode.com> wrote:
>> On 01/21/13 07:39, Sedat Dilek wrote:
>>> I think people are interested in "stable" work against stable releases.
>> We don't have "releases". The output of this project isn't a compiler and a
>> kernel; the output is test results, and upstreamed patches. The LLVMLinux
>> project is a meta-project.
> Hmmm, I don't like this approach as I am concerned this will lead to a
> "development loop and never-ending cycle".
> Working against mainline (upstream) is hard enough.
> Even harder you do against toolchain (LLVM plus CLANG) and the Linux-kernel!
For a traditional project which has a binary output, I would agree. But 
that's not what we're building.

The project sends patches to both those projects. The only way to write 
upstreamable patches and test them before we can upstream them is to 
track upstream.  The only alternative is to work on stable and then 
rebase on each release, or before a code submission. That would be a lot 
more work in our case.

The patches from this project are being sent to upstream maintainers who 
are tracking upstream code, so they need to be written and tested 
against upstream code. Anything else is a waste of time.

> Is there something speaking against to backport LLVMLinux against the
> latest ***stable*** toolchain and Linux-kernel release-versions?
As I said: (in most cases) no backport is needed. The patches for a 
version of the upstream code is already in our repo. It just hasn't been 
tagged as such.

> And integrate others work into the build-system?
> What is speaking against offering snapshots or even pre-build
> toolchains for downloading?
> The LLVM project itself offers prebuild-toolchains for Ubuntu as an example.
> BTW, it is not ***your*** time :-).
> Think a bit of a more user and/or developer friendly way.
You are free to do this if you choose. But that's not the point of this 

This project is trying to get the patches upstream so that they are 
built into the Ubuntu packages by Ubuntu themselves. That is 
considerably MORE developer friendly. Especially since there are so few 
LLVM patches left.

> Personally, I do not want to waste my time with building toolchains
> the whole day.
And we don't. I certainly don't. Unless I'm working on a patch for LLVM, 
I build LLVM no more than once a week (and that's a choice, I don't have 
to do that).

Our buildbot checks our LLVM patches against the tip of the LLVM/Clang 
repos for us.

> I want to spend my time squashing CLANG bugs in mainline kernels
> (preferred -rcX).
> Switching the toolchain can cause extra work, I am not willing to
> parallelly fix my toolchain.
> I want to use my toolchain.
Sounds exactly like what I'm doing, other than building it the first 
time, or when there is another fix I need.

Based on your comments, I'm guessing you've never tried building with 
the LLVMLinux build system. I would suggest you give it a try. You may 
find that it provides you with a much easier way to "just work on the 
kernel code". I know it does for me. Many of our targets (including 
x86_64) even provide a qemu test bed to try out your CLANG kernel 
without having to reboot each time.

> Shall I sent or sent not my patches to the LLVMLinux ML?
> If there is no interest, please let me know.
Sending patches to this mailing list are the preferred way of sending us 
patches. Feel free to send them.


Behan Webster
behanw at converseincode.com

More information about the LLVMLinux mailing list