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

[Mehdi AMINI via Phabricator via llvm-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D34197#784285, @ilya-biryukov wrote:

> > Feel free to advocate for it, but except that stating an opinion above I'm missing you arguments.
>
> For a newcomer or even a contributor, not already familiar with LLVM's build system, it's not at all obvious which arguments one must pass to cmake to make build work for him.


OK so we're focusing on newcomers right?

> 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...

> E.g., say someone would like to provide deb packages for clang, lld, etc and is willing to use Dockerfiles we provide. Say, the person is not an LLVM contributor.
>  They won't really want to dive into the complexity of building LLVM,

If someone is only interested in getting a standard release build of LLVM, we already have the release script in the repository: /llvm/utils/release/test-release.sh

> but it won't take them long to figure out they need to run `build_docker_image.sh debian8 myrepo/clang_deb staging --with_clang --with_lld --with_libc++`.

I totally disagree with this.
If you need to understand which subcomponent you want: I don't see why having `--with-clang` is a better interface than `-DLLVM_ENABLE_PROJECTS=clang`, this is the same level of abstraction. The syntax bike shed is not value adding here, and I even advocate that it is more valuable for newcomers to get use the same syntax they'll have to use if they want to `upgrade` to a more direct interaction with LLVM.

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.

> 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


https://reviews.llvm.org/D34197