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

Sedat Dilek sedat.dilek at gmail.com
Mon Jan 21 14:24:47 UTC 2013 

n Mon, Jan 21, 2013 at 2:42 PM, Tinti <viniciustinti at gmail.com> wrote:
>>> Hi Sedat,
>>>
>>> I have reimplemented the checkpoint feature this weekend and I would like
>>> to
>>> test it with your settings too.
>>>
>>> Can you send me it? Also would be great to see other people trying to use
>>> it. If you have time, please checkout my branch and read
>>> Documentation/settings_file.txt.
>>>
>>
>> We should stop top-posting, eh?
>
> Yes. Thanks.
>
>
>> With my (llvmlinux-patched) LLVM/CLANG toolchain I hit many
>> non-toolchain issues this weekend when trying to build LIBDRM/MESA in
>> an /opt/xorg installation.
>>
>> Following all daily upstream changes in LLVMLinux is NOT possible and
>> NOT wanted by me.
>>
>> I think people are interested in "stable" work against stable releases.
>>
>> I was planning to push my adapted/refreshed LLVMLinux patches against
>> v3.2-stable of llvm/clang/compiler-rt.
>> Are you interested in them?
>
> Yes. But I don't know where to place it. Maybe we could have stable work
> and stable releases at the same time. Honestly, I don't know (even how).
>

*** Some ideas (may be incomplete and untested!) ***

Use (and create) "patches" (upstream) VS. "patches-3.2" (v3.2-stable)
directories (incomplete list here for arch and toolchain only):

[ arch ]

arch/x86_64/patches
arch/x86_64/patches-3.2 <--- NEW

[ toolchain ]

toolchain/clang/patches
toolchain/clang/patches-3.2 <--- NEW (preferred!)

...or...

toolchain/clang/patches/clang
toolchain/clang/patches/clang-3.2 <--- NEW
toolchain/clang/patches/llvm
toolchain/clang/patches/llvm-3.2 <--- NEW

Personally, I would highly appreciate the usage of a $PATCHES_DIR in
$TOP_SRC_DIR!

TOP_SRC_DIR
|
|--- arch
|--- common.mk
|--- COPYING
|--- Documentation
|--- Makefile
|--- patches <--- NEW: All patches are located at one single place!
     |--- arch <--- or simple put the $archnames here directly (x86_64 etc.)
     |--- toolchain
     |--- etc.
|--- README
|--- targets
|--- test
|--- toolchain
|--- tools

NOTE: I am not familiar with the build-system of LLVMLinux and can't
say if this is hacked in a few minutes or needs a lot of rework :-).

HINT:
All the patches which are regularly adapted should get rid of any crap
like "diff git" or "Index" lines (see for example patch-handling of
OpenWrt). Simply use --- a/ and +++ /b!
The git-diff-stats line are in some patches are after getting
refreshed simply wrong.
All this would make refreshing of patches for upstream a bit easier.

My EUR00.2 (aka 2 cents).

- Sedat -

>> I had a look into your settings_file.txt file but did not get wiser,
>> sorry.
>>
>> I am still trying to track a Linux-Next issue with JBD2 (or LOOP).
>> Let's see if linux-fsdevel people can help.
>>
>> Hope this helps you.
>
> For sure it will.
>
> Regards,
> Tinti
>
> - Sedat -
>
>
> On Mon, Jan 21, 2013 at 10:39 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
>>
>> On Mon, Jan 21, 2013 at 1:29 PM, Tinti <viniciustinti at gmail.com> wrote:
>> > Hi Sedat,
>> >
>> > I have reimplemented the checkpoint feature this weekend and I would
>> > like to
>> > test it with your settings too.
>> >
>> > Can you send me it? Also would be great to see other people trying to
>> > use
>> > it. If you have time, please checkout my branch and read
>> > Documentation/settings_file.txt.
>> >
>>
>> We should stop top-posting, eh?
>>
>> With my (llvmlinux-patched) LLVM/CLANG toolchain I hit many
>> non-toolchain issues this weekend when trying to build LIBDRM/MESA in
>> an /opt/xorg installation.
>>
>> Following all daily upstream changes in LLVMLinux is NOT possible and
>> NOT wanted by me.
>>
>> I think people are interested in "stable" work against stable releases.
>>
>> I was planning to push my adapted/refreshed LLVMLinux patches against
>> v3.2-stable of llvm/clang/compiler-rt.
>> Are you interested in them?
>>
>> I had a look into your settings_file.txt file but did not get wiser,
>> sorry.
>>
>> I am still trying to track a Linux-Next issue with JBD2 (or LOOP).
>> Let's see if linux-fsdevel people can help.
>>
>> Hope this helps you.
>>
>> - Sedat -
>>
>> > Best regards,
>> > Tinti
>> >
>> >
>> > On Thu, Jan 17, 2013 at 11:45 PM, Sedat Dilek <sedat.dilek at gmail.com>
>> > wrote:
>> >>
>> >> Hi Tinti,
>> >>
>> >> I have adapted the LLVM/CLANG patches from LLVMLinux project against
>> >> v3.2-stable.
>> >>
>> >> Toolchain is fine...
>> >> Just (mis)used build of mesa-8.x as a test-case [1].
>> >>
>> >> Will look tomorrow into the Linux x86_64 patches.
>> >>
>> >> - Sedat -
>> >>
>> >> [1]
>> >>
>> >> http://lists.freedesktop.org/archives/dri-devel/2013-January/033614.html
>> >>
>> >> On Fri, Jan 18, 2013 at 2:35 AM, Tinti <viniciustinti at gmail.com> wrote:
>> >> > Hi Sedat,
>> >> >
>> >> > About stable versions please check my branch. I have just uploaded
>> >> > the
>> >> > documentation about it (Documentation/settings_file.txt) and an
>> >> > example
>> >> > in
>> >> > rpi target. I think it fits for your purposes.
>> >> > I have not applied on master because I would like to have some
>> >> > reviews
>> >> > and
>> >> > feedbacks. Is anything else that you would like to add?
>> >> >
>> >> > Best regards,
>> >> > Tinti
>> >> >>
>> >> >> What is {the | your | a good} base for the Linux-kernel (speaking of
>> >> >> x86_64)?
>> >> >> v3.7.y (latest stable version)?
>> >> >
>> >> > The LLVMLinux project works from the HEAD of LLVM and the Linux
>> >> > project.
>> >> > Since the goal is to upstream patches to both projects, we really
>> >> > have
>> >> > to
>> >> > work from HEAD.
>> >> >
>> >> > As far as saving checkpoints that work with a particular version of a
>> >> > kernel, somebody merely needs to create a settings file which details
>> >> > the
>> >> > versions of all SW involved. The settings file is described in
>> >> > Documentation/settings_file.txt
>> >> >
>> >> > Tinti is using this to create a checkpoint for the rpi community so
>> >> > that
>> >> > people can play with a stable kernel there for instance. You are
>> >> > welcome
>> >> > to
>> >> > do the same for x86_64.
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Jan 17, 2013 at 2:53 PM, Behan Webster
>> >> > <behanw at converseincode.com>
>> >> > wrote:
>> >> >>
>> >> >> On 13-01-17 09:11 AM, Sedat Dilek wrote:
>> >> >>>
>> >> >>> Hi,
>> >> >>>
>> >> >>> first of all I wish all people from the LLVMLinux project a happy
>> >> >>> new
>> >> >>> year!
>> >> >>
>> >> >> Same to you! :)
>> >> >>
>> >> >>
>> >> >>> After a case of death in my family I dropped all my OSS activities
>> >> >>> for
>> >> >>> a
>> >> >>> while.
>> >> >>
>> >> >> I'm very sorry to hear that.
>> >> >>
>> >> >>
>> >> >>> The last weeks I started to build again mainline and Linux-Next
>> >> >>> kernels.
>> >> >>> ...and playing with Linux Test Project (LTP).
>> >> >>> I would like also to test a llvmlinux-compiled Linux-kernel with
>> >> >>> LTP!
>> >> >>
>> >> >> We are already running LTP with a clang compiled kernel, but
>> >> >> currently
>> >> >> only for the vexpress (ARM based) kernel. It's just a matter of
>> >> >> somebody
>> >> >> porting the code. I too would like to see an automated x86 LTP test
>> >> >> run.
>> >> >>
>> >> >>
>> >> >>> Today, I remembered the $JOBS variable
>> >> >>
>> >> >> "make help" has details about a lot of things, including the $JOBS
>> >> >> variable. The default value of JOBS likely will be close to optimum.
>> >> >> On
>> >> >> my
>> >> >> machine (at least) if I ingrease JOBS much higher than the
>> >> >> calculated
>> >> >> default, it actually slows down the compile.
>> >> >>
>> >> >>
>> >> >>> What is {the | your | a good} base for the Linux-kernel (speaking
>> >> >>> of
>> >> >>> x86_64)?
>> >> >>> v3.7.y (latest stable version)?
>> >> >>
>> >> >> The LLVMLinux project works from the HEAD of LLVM and the Linux
>> >> >> project.
>> >> >> Since the goal is to upstream patches to both projects, we really
>> >> >> have
>> >> >> to
>> >> >> work from HEAD.
>> >> >>
>> >> >> As far as saving checkpoints that work with a particular version of
>> >> >> a
>> >> >> kernel, somebody merely needs to create a settings file which
>> >> >> details
>> >> >> the
>> >> >> versions of all SW involved. The settings file is described in
>> >> >> Documentation/settings_file.txt
>> >> >>
>> >> >> Tinti is using this to create a checkpoint for the rpi community so
>> >> >> that
>> >> >> people can play with a stable kernel there for instance. You are
>> >> >> welcome to
>> >> >> do the same for x86_64.
>> >> >>
>> >> >>
>> >> >>> $ grep "Kernel Configuration" -nr ./
>> >> >>> ./targets/x86_64/config_x86_64:3:# Linux/x86_64 3.7.0 Kernel
>> >> >>> Configuration
>> >> >>> ./targets/x86_64/config_x86_64_default:3:# Linux/x86_64 3.7.0-rc5
>> >> >>> Kernel Configuration
>> >> >>> ./targets/i586/config_i586:3:# Linux/x86_64 3.7.0 Kernel
>> >> >>> Configuration
>> >> >>
>> >> >> That's merely the version of the kernel that was being used when
>> >> >> that
>> >> >> config file was last updated. It doesn't indicate a stable version
>> >> >> of
>> >> >> the
>> >> >> kernel source.
>> >> >>
>> >> >>
>> >> >>> Is the listed kernel-config a good base?
>> >> >>
>> >> >> It is the one we are currently testing with. This file is intended
>> >> >> to
>> >> >> create a bootable kernel on an average x86_64 computer.
>> >> >>
>> >> >>
>> >> >>> Same question to llvm and clang.
>> >> >>> v3.2 (latest stable version)?
>> >> >>
>> >> >> Again, we don't use stable versions of the toolchain. We use HEAD.
>> >> >> Until
>> >> >> our patches are in we have to keep developing and testing with the
>> >> >> latest/greatest code.
>> >> >>
>> >> >>
>> >> >>> Personally, I wanted to test against ***stable*** versions of all 3
>> >> >>> components.
>> >> >>
>> >> >> Great! That would be very helpful.
>> >> >>
>> >> >>
>> >> >>> Some patches are not listed in the appropriate series files
>> >> >>> (so-to-say
>> >> >>> UNUSED).
>> >> >>
>> >> >> The existence of a patch file doesn't mean it's actually being used.
>> >> >> The
>> >> >> series file lists which patches are currently in use.
>> >> >>
>> >> >> Patches which aren't in a series file usually are left in place
>> >> >> until
>> >> >> we're sure we don't need them anymore (or at all).
>> >> >>
>> >> >>
>> >> >>> I am still against all this uncommon naming of patches (speaking
>> >> >>> mostly of the ones for the Linux-kernel).
>> >> >>
>> >> >> In this case many of the patch names for x86_64 have been created
>> >> >> from
>> >> >> the
>> >> >> commit comments by "git format-patch".
>> >> >>
>> >> >> I would encourage you to work within our build framework if you can.
>> >> >> If
>> >> >> we
>> >> >> all work on the same code base, with the same test framework, we can
>> >> >> much
>> >> >> more easily share work and accelerate our efforts.
>> >> >>
>> >> >> Thanks!
>> >> >>
>> >> >> Behan
>> >> >>
>> >> >> --
>> >> >> Behan Webster
>> >> >> behanw at converseincode.com
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> LLVMLinux mailing list
>> >> >> LLVMLinux at lists.linuxfoundation.org
>> >> >> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Vinicius Tinti
>> >> > mail => {viniciustinti at gmail.com, tinti at comp.eng.br}
>> >> > skype => {viniciustinti}
>> >> >
>> >> > _______________________________________________
>> >> > LLVMLinux mailing list
>> >> > LLVMLinux at lists.linuxfoundation.org
>> >> > https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux
>> >> _______________________________________________
>> >> LLVMLinux mailing list
>> >> LLVMLinux at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux
>> >
>> >
>> >
>> >
>> > --
>> > Vinicius Tinti
>> > mail => {viniciustinti at gmail.com, tinti at comp.eng.br}
>> > skype => {viniciustinti}
>
>
>
>
> --
> Vinicius Tinti
> mail => {viniciustinti at gmail.com, tinti at comp.eng.br}
> skype => {viniciustinti}

More information about the LLVMLinux mailing list