[llvmlinux] keeping track of working configs?

Sedat Dilek sedat.dilek at gmail.com
Tue Jul 16 07:53:03 UTC 2013


On Tue, Jul 16, 2013 at 8:41 AM, Jens Staal <staal1978 at gmail.com> wrote:
> Hi
>
> While packaging LLVMLinux for Arch, I noticed that the default Arch
> config does not work to build LLVMLinux whereas the default config
> included in the llvmlinux checkout does.
>
> One of the purposes of this packaging is naturally to encourage savvy
> and interested people to test various permutations of the build/config.
>
> What is the purpose of the default config? Should it enable
> everything that has been shown to work?
>
> In that case, BTRFS can also be activated, which I do on the default
> config via sed in the PKGBUILD:
>
> https://aur.archlinux.org/packages/ll/llvmlinux-git/PKGBUILD
>
> is there a wiki somewhere with working/non-working configuration
> options documented?

Hi,

Great! Great? Great???
People fell over and over and over... the same things and have the
same questions.

Quick answer: Some kernel-configs are ("known" to be) BROKEN!

Long version below...

"Known" means after several builds of mine.
"Known" means also-known-by-the-llvmlinux-core-team-but-not-officially-documented.
For me this resulted in ... testing - testing - testing - testing - testing...

I have encouraged people to establish some docs like KNOWN-ISSUES /
WORKAROUNDS where such things are documented.
Some patches have "workarounds" which should be removed (very detailed
explanations by pageexec).
...means these patches should be refreshed - with a proper changelog.
These patches should have a meaningful name...
...means (numbering) "NNNN" should be documented.
What about numbering according to "categories" (like "unneeded
braces", "VLAIS", etc.).
Patches which are not used - should go into the archive - and for
example not deleted (example: 0041-i915 patch).
Patches are not labeled (subsystem) and have no detailed changelog
conform to Linux-kernel development.
I doubt they will be accepted...
Patches known to be "not compatible with Linux-upstream" should be
documented as well.
Best in the llvmlinux-buildsystem - there is a Documentation directory!

Furthermore, I encouraged people to create a so-called checkpoint for
x86-64 - against stable toolchain and Linux-kernel.
I have here a patch done for v3.10 (will rework for v3.10.1) which is
known to be good.
NOTE: I have sent my files with successful setup/configs to the llvmlinux-ML.

Please, read my postings of the last week to the llvmlinux ML.

Some of my ideas were done (refresh x86-64 kernel-config)...
Even my idea of using the prebuild LLVM/Clang toolchain from
LLVM-project is now realized.

Unfortunately, things take long... mostly due to convincing people.
Some people love to make a lot of blablabla like politicians -
defending their work which is definitely not "unvulnerable"
"untouchable" "unquestionable" or done by "G.O.D.".
Software is per definition unperfect.

My wish (this is not new, with new I mean not the last days) is to
have a working setups/configs with proper explained patches.
My focus is x86-64 against stable-versions of toolchain and Linux-kernel.
The produced llvmlinux-kernel should boot into a stable
Linux-environment as well!
Really, I love the idea of a llvmlinux-compilable Linux-kernel!
The idea of checkpoints is great!
x86-64 has (had!?) simply no love!

The llvmlinux-buildbot building latest GIT HEAD seems to do its job.
HEAD means HEAD of LLVM, HEAD of Clang and HEAD of Linux-kernel.
Three areas!
As there exist stable toolchain, my focus would be the Linux-kernel.

Ah, one idea... before it gets lost.
Stuff like building against GIT HEAD can goto a "lllvmlinux-next" repository.
Whereas "llvmlinux" GIT tries to focus against stable release-versions.

For me the last week was so time-consuming and some discussion not
really useless.
Trial and error!?
My headmaster at grammar school gave me once this advice: "If you
don't succeed. Try, try, try..."
Of course you can "try try try"... with endless men-power, endless
time, endless motivation, endless money, endless life, etc.

The situation is ***not*** hopeless :-).
There seems to be some light (see last days commits to llvmlinux-git)!
Unfortunately, for me it seems you have to leave the way of politeness.
It's remarkable to see that people don't know anything about giving
credits to whom it belongs.

As said, read the last days (last week) posting of mine.
I cannot promise, but I try to create a patch with a "checkpoint" for
x86-64 with LLVM/Clang v3.3 and Linux v3.10.1.
I can also do some RFC patch(es) of my ideas especially for docs.
Even, I had some ideas for the build-system.
Really, I am interested in getting them to llvmlinux-upstream, but I
somehow doubt they will and I am not interested in useless long
discussions, again.

One of the greatest news for me was that all toolchain-patches from
lll-project (1st steps of work, deprecated) and llvmlinux (new home)
got upstream.
This means people really can now focus on the Linux-kernel stuff.
This is an immense opportunity!

The world is not perfect, but people felling over and over the same
things makes me reallly GRRR.
( And if I am in GRRR mode people do not like me. )

I am really interested in improving the situation.
The above promised patches will be a good start.
This week I am really busy.

- Sedat -

> _______________________________________________
> LLVMLinux mailing list
> LLVMLinux at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux


More information about the LLVMLinux mailing list