[PATCH] D34197: Added Dockerfiles to build clang from sources.

Ilya Biryukov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 19 23:24:10 PDT 2017


ilya-biryukov added a comment.

>> For software distributions, the things that really matter are:
>> 
>> - Which components do you include in the distribution, i.e. clang, lld, libc++, sanitizers, etc.
>> - Configurations of those components, i.e. whether to build with sanitizers, whether to use LTO, which backends to include, etc. (This is the trickiest part from my perspective)
> 
> Right, same as above: CMake provide option for these. If there are options missing we can add them.
>  Another kind of CMake interface is the preconfigured cache files, for example: clang/cmake/caches/Apple-stage2-ThinLTO.cmake

My point was not that CMake **can't** do that, but rather that it makes those things complicated.

> OK so we're focusing on newcomers right?

We're planning to make clang distribution in docker images using these scripts. It was not our original intention to focus on newcomers.

>> Given that the docker images we're producing is a distribution of LLVM tools, rather than a build/testing framework, there's no point in coupling its interface to the LLVM buildsystem, effectively making it as complicated as the buildsystem itself.
> 
> Or as simple / expressive...

Of course cmake is as expressive as you can get when building LLVM.
After playing around with cmake and multistage builds, I actually agree with you. It's so much less hassle to reuse the bootstrapping logic inside cmake scripts.
And a single cmake invocation seems to be enough to do basically everything one could want.

> Also, if you want to provide an abstraction over the build system, I don't see any reason to couple this to Docker, this seems like a separate discussion to have than having Docker images. This should be implemented orthogonally: if such script is useful, it should live separately in the repo and be used to build within or outside of Docker. The docker invocation can invoke this script or not (let's punt the exact interface) the same way a build outside of Docker could.

I totally agree with both points. There's no reason it should be coupled to Docker and it's actually a separate discussion.
Since cmake is already there, let's use it to give full flexibility.
I would still argue that a highler-level interface similar to `llvm/utils/release/test_release.sh` has its uses.


https://reviews.llvm.org/D34197





More information about the llvm-commits mailing list