[cfe-dev] Command line compiler options

[mats petersson]

As my previous comment said, I'm not entirely sure that simply having
command line options documented is sufficient to solve the type or problem
that (I think) you are trying to solve: What options does compiler version
X, Y and Z support, and what option do I need to use to get access to
compiler feature F, G or H. Because, as I said, compiler option may say
"-std=support for C++11" (or C99, or whatever), but it doesn't mean that a
particular version FULLY supports that standard (unless you are actually
expecting something like "-std=C++11 enabled C++11 standard complience -
version X supports all C++11 features {,except} [list of features {,not}
supported]".

I'm not saying the current documentation is great, but I'm not sue that
your quest will immediately be solved by having better documentation of the
command line options alone. You still need to read other documentation
items to understand exactly what is supported and what is not.

And even then you still have the issue that "feature X is supported" in the
documentation, but due to some bug or limitation in the compiler, stuff
doesn't work. So to say that "compiler version X works for <my source>"
will still be dependent on testing with EXACTLY compiler version X in some
way, to ensure that for all supported targets, for all supported options,
the code generated by the compiler works correctly. This is very hard to
maintain good test coverage on, and gets increasingly worse with the number
of supported configurations...

--
Mats



On 17 June 2015 at 15:20, Edward Diener <eldlistmailingz at tropicsoft.com>
wrote:

> On 6/16/2015 11:43 PM, Nikola Smiljanic wrote:
>
>> On Wed, Jun 17, 2015 at 11:22 AM, Edward Diener
>> <eldlistmailingz at tropicsoft.com
>> <mailto:eldlistmailingz at tropicsoft.com>> wrote:
>>
>>     I would suggest that clang actually spend some time telling
>>     programmers how to use their product.
>>
>>
>> If only the compiler could document itself :)
>>
>> On a more serious note, patches in this area are more than welcome. It
>> took me some time to realize this, but people working on clang are
>> mostly employed by companies that want them to work on whatever's
>> important to them. This means that those people know exactly how to use
>> the compiler. If you're buying a product based on clang then you can
>> request the company that's selling it to provide documentation. But for
>> you, me and everyone else using the open source compiler it means that
>> anything we see missing we'll have to do ourselves or just wait until
>> someone gets to it, if they do. I'm sure you'll find out the list of
>> possible values for -std switch, why not contribute a patch documenting
>> them once you do?
>>
>
> I am not a clang contributor. I do use clang when testing Boost libraries
> and I am appreciative of the clang support I get here.
>
>
>> On a personal note, I find your tone unacceptable if you expect a
>> productive discussion.
>>
>
> My "humor" was borne out of frustration. I need to know not only about the
> latest clang, but previous versions, because Boost supports many versions
> of many compilers in most of its libraries. I understand that clang
> developers work on the compiler itself and that documentation gets
> overlooked. But no matter how good the compiler is, if an end-user has a
> hard time using it because documentation is poor or entirely lacking in
> some areas, how much good will the product be to end-users ?
>
>  I understand your frustration as I've been there
>> many times but you have to understand that people in this community are
>> doing their best and are aware of shortcomings, which is why patches are
>> more than welcome.
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150617/1f797ca1/attachment.html>