<br><br><div class="gmail_quote">Le 4 novembre 2011 15:55, Sean Hunt <span dir="ltr"><<a href="mailto:scshunt@csclub.uwaterloo.ca">scshunt@csclub.uwaterloo.ca</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Nov 4, 2011 at 07:11, James Molloy <<a href="mailto:james.molloy@arm.com">james.molloy@arm.com</a>> wrote:<br>
> Usecase 3: Clang developer, developing<br>
> --------------------------------------<br>
><br>
> Wants no functionality to change - things keep working as normal [1]<br>
><br>
> Usecase 4: Apple/Darwin developer, using fat binaries<br>
> -----------------------------------------------------<br>
><br>
> Requires fat-binary support. This entails multiple "-arch" arguments<br>
> being supported. [1]<br>
><br>
> .. note::<br>
><br>
>    Describe this some more?<br>
><br>
> Functional requirements<br>
> =======================<br>
><br>
> The following requirements follow from the use cases above and attempt<br>
> to formalise those use cases more precisely.<br>
><br>
> [1] No functional regressions<br>
>  The driver **must** be able to be configured such that it can parse<br>
>  command lines that the current Clang driver accepts. The driver<br>
>  **must** invoke all subtools in the same manner as the current Clang<br>
>  driver, with the possible exception of obtuse, undefined, legacy or<br>
>  otherwise incorrect behaviour, permission for which must be obtained<br>
>  from the mailing list and documented in a subsection of this<br>
>  document for decision tracking.<br>
<br>
</div>I honestly have to disagree with this one. A lot of the reasons for<br>
horribleness in the current driver is compatibility with GCC. I<br>
believe that we should really have two drivers, one being the 'nice'<br>
driver, and one being the compatibility driver. To be honest, I<br>
consider POSIX specifications for CC rather irrigating as well, but<br>
I'm willing to concede POSIX compatibility. Naturally, it should be<br>
easy for these to both be changeable at once so that we don't have<br>
ridiculous levels of maintenance being performed, but I'm of opinion<br>
that the current model is predicated on enough levels of annoyances<br>
that trying to promote a compatible compiler is not a good approach<br>
(the first example that comes to mind is -Wall).<br>
<br>
I'm sure people will disagree with me, though.<br></blockquote><div><br>I fully agree.<br><br>I've tried adding options, in the past, and the seggregation of options is quite... baffling. Some `-fXXX` will influence LLVM while others influence Clang !?!<br>
<br>The dual Options.td cc1Options.td is quite nice too...<br><br>The GCC compatibility is great for a drop-in replacement, but I certainly see no harm into building a "pure" clang driver, where options are seggregated according to Clang usecases.<br>
<br>This would also allow implementing a *sane* option syntax, like for example a hierarchical option parser:<br><br><div style="margin-left: 40px;">--codegen-stackframe-limit=50<br></div><br>Where "stackframe-limit=50" is dispatched to the "codegen" plugin, which itself dispatch "limit=50kB" to its stackframe object, which sets its "limit" attribute to 50000 (for example).<br>
<br>This make it easy to:<br>- group options right where they are used<br>- avoid name collisions<br>- have plugins register their own set of options<br><br>I have been working on such a parser in my spare time, and I don't mind giving the code away as a basis:<br>
=> automatic handling of Integers, Strings, and Enums (which must provide some specific functions for conversion and listing the available values)<br>=> automatic handling of Booleans arguments (at the moment, I use =yes or =no, but it would be trivial to parse --no- as meaning =no providing that no plugin tries to grab the "no" namespace)<br>
<br>Ah, and I also have a configuration file parser which sets the options objects before the command line is parsed... (modelled after the config python module)<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im"><br>
> [3] Extensibility<br>
>  All parts of the driver that are to interact with outside<br>
>  environment (such as interpreting command lines and launching<br>
>  subtools) **must** be able to have their behaviour easily modified.<br>
><br>
>  While there is no requirement for this to be able to be done with no<br>
>  source changes, there **could** be scope for allowing dynamically<br>
>  loadable modules (in the spirit of ``opt -load``) to change the<br>
>  driver's behaviour at invoke-time.<br>
<br>
</div>Oh no, spec files. ;)<br>
<font color="#888888"><br>
Sean<br>
</font><div><div></div><div class="h5"><br>
</div></div></blockquote></div><br>