[llvm-dev] [cfe-dev] [RFC] Proposing libcxx-config.py: a configuration tool for building and using libc++
llvm-dev at lists.llvm.org
Mon Feb 13 17:41:12 PST 2017
On 2017-02-09 18:18, Eric Fiselier via cfe-dev wrote:
> Hi All,
> Configuring a compiler to target or build libc++ is tricky. It often
> requires suppressing and rebuilding large parts of the CC1 compiler
> invocation. Doing this manually can be prohibitive, even for
> experienced users. Even doing it programmatically is hard and requires
> a lot of code because of the sheer number of configurations libc++
Agreed: this is challenging to get right.
> compile and link libc++. The tool will have two main purposes:
> (1) Generating the compile and link flags required to USE THE
> JUST-BUILT LIBC++ LIBRARY.
> (2) Generating the compile and link flags required to BUILD THE LIBC++
I've witnessed these challenges while building and testing libcxx for
Hexagon. There's been at least one occasion where I accidentally
configured it to build and test against the baseline/bootstrap
installation's libc++ and not the just-built one.
> The goals for `libcxx-config.py` are:
> (1) Reduce duplicate configuration logic between the CMake and
From what I've seen, I thought there's a decent amount of cascade from
CMake vars->lit.site.cfg vars, leveraged by the relevant targets'
configs. But IIRC I saw some flags in utils/libcxx/test/config.py that
were the same as CMake ones.
> (2) Allow non-CMake users to correctly generate the flags required to
> build libc++. (Ex buildit)
> (3) Make it easier for projects, including libc++, to correctly
> configure to target the just-built libc++.
> (4) Allow the creation of a `test-libc++` tool which can compile and
> link test programs against libc++ (Often needed when debugging test
> suite failures).
> Would anybody else have a need for this? Are there use cases anybody
> would like to see supported?
I don't see a need for #2 -- wasn't autoconf deprecated for the rest of
LLVM at 3.8? #3 is less of a concern for us because our local test
infrastructure builds/tests our libc++ specifically from a compiler
suite lacking a target libc++. Someone clever must have figured that
failure mode out before I started on this project.
I've hand-rolled a solution for #4 but having a canonical way to do this
seems like a good idea. I'd be worried that the critical element to the
test failure is among the flags in the CMake config. That said, it
would be handy when working with other teams less familiar with
building/testing LLVM-style projects. It turns out that the
libc++/c++abi test suites are great at evoking bugs at various layers
throughout the system.
More information about the llvm-dev