<div dir="ltr">On Wed, Jul 31, 2013 at 1:58 AM, Simon Atanasyan <span dir="ltr"><<a href="mailto:simon@atanasyan.com" target="_blank" class="cremed">simon@atanasyan.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
What is the current state of Clang universal driver project<br>
(<a href="http://clang.llvm.org/UniversalDriver.html" target="_blank" class="cremed">http://clang.llvm.org/UniversalDriver.html</a>)? Does anybody work on<br>
that project now?<br>
<br>
Recently I start to implement support for one more MIPS toolchain.<br>
It's directory tree is similar to Code Sourcery toolchain but has some<br>
difference as well. Sure I can add a bit more folder names to the<br>
clang driver and make GCC detection algorithm more complicated. But I<br>
think it is not a right way.<br></blockquote><div><br></div><div>I disagree. I think this is the right way.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's why I'd like to implement the clang driver's configuration file<br>
support. My current plan is to put to this file the following settings<br>
and use these settings in the driver:<br>
- target triple<br>
- include files search paths (-I)<br>
- library search paths (-L)<br>
- program and files search paths (-B)<br>
- explicit paths for files and / or programs<br>
<br>
User will be able to select configuration file by --target=<config name> option.<br></blockquote><div><br></div><div>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:</div>
<div>1) Pick a common and consitent layout of toolchains, and/or</div><div>2) Work with the upstream community to add support for their layout.</div><div><br></div><div>I strongly suspect that doing this the way you are suggesting will have this result.</div>
<div><br></div><div><br></div><div>The design I have advocated for in the past can be summed up as:</div><div><br></div><div>1) Don't start a new driver. Just refactor the current one.</div><div>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.</div>
<div>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.</div><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also I want to code an utility that runs specified gcc with<br>
-print-multi-directory / -print-prog-name / ... options and generates<br>
driver's configuration file.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div></div></div></div>