[llvmlinux] Quick build against stable versions of toolchain (llvm and clang) and Linux-kernel?
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.
behanw at converseincode.com
More information about the LLVMLinux