[cfe-dev] Command line compiler options

[Edward Diener]

On 6/17/2015 10:42 AM, mats petersson wrote:
> 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 don't think it is unreasonable to expect a given version of a compiler 
to state somewhere in its documentation what it means when it says that 
C++11 is 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.

Agreed.

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

Agreed. But testing something is my responsibility as an end-user which 
I accept. Having documentation which tells me what things mean to the 
compiler, aka a command-line compiler option, is the responsibility of 
those who create the compiler. I don't see how an end-user can use a 
product successfully if the basic documentation of what things mean 
becomes guesswork.

I realize that clang is usable even when there are areas of the 
documentation which are poorly explained. But ask yourself whether it 
would not be easier for developers if they did not have to answer 
questions about the compiler from users because the documentation is 
non-existent or poor.

I know of no other C++ compiler where the basic documentation regarding 
command-line options is so poor. And yet technically clang is a leading 
compiler. I would think this might be cause for concern among clang 
developers.

>
> --
> Mats
>
>
>
> On 17 June 2015 at 15:20, Edward Diener
> <eldlistmailingz at tropicsoft.com
> <mailto: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>
>         <mailto: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.