[cfe-dev] Clang universal driver project state

[Chandler Carruth]

On Wed, Jul 31, 2013 at 1:58 AM, Simon Atanasyan <simon at atanasyan.com>wrote:

> Hi,
>
> What is the current state of Clang universal driver project
> (http://clang.llvm.org/UniversalDriver.html)? Does anybody work on
> that project now?
>
> Recently I start to implement support for one more MIPS toolchain.
> It's directory tree is similar to Code Sourcery toolchain but has some
> difference as well. Sure I can add a bit more folder names to the
> clang driver and make GCC detection algorithm more complicated. But I
> think it is not a right way.
>

I disagree. I think this is the right way.


> That's why I'd like to implement the clang driver's configuration file
> support. My current plan is to put to this file the following settings
> and use these settings in the driver:
> - target triple
> - include files search paths (-I)
> - library search paths (-L)
> - program and files search paths (-B)
> - explicit paths for files and / or programs
>
> User will be able to select configuration file by --target=<config name>
> option.
>

There is not universal agreement that this is the right long-term
direction. I'm moderately opposed to complicating the distribution and
installation model of Clang. I'm very opposed to worsening the state of
getting distributions to both:
1) Pick a common and consitent layout of toolchains, and/or
2) Work with the upstream community to add support for their layout.

I strongly suspect that doing this the way you are suggesting will have
this result.


The design I have advocated for in the past can be summed up as:

1) Don't start a new driver. Just refactor the current one.
2) Lift the common and often duplicated "configuration" activities from C++
code to a simple table file processed by tablegen to produce C++ code that
implements automatic detection of various configurations.
3) Continue to bake the database of targets and supported layouts into the
driver itself, but now with a very low overhead for adding another config.

We could eventually add support for loading some elements of these configs
at runtime, but I would like to avoid that if at all possible, and at least
ensure that 99.99% of the time it isn't needed.


> Also I want to code an utility that runs specified gcc with
> -print-multi-directory / -print-prog-name / ... options and generates
> driver's configuration file.
>

This doesn't ensure they are correct or sensible, just that they happen to
work today. I would prefer actually being principled about the layouts we
support.

I would also *really* like to see more pressure on people to produce
toolchains in a common and widely used layout. Everyone's life would be
much simpler in that world.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130801/6a1bbf2f/attachment.html>