[llvm-dev] [cfe-dev] [RFC] Proposing libcxx-config.py: a configuration tool for building and using libc++

[via llvm-dev]

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

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

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

 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.

-Brian