I'm collecting my remarks in one reply here, hopefully for easier
reading. I want to offer my thanks, and also my assessment of the
situation as I understand it. My critique is intended as purely
constructive.
I understand vaguely what's going on. I'll use the -findicator-column=
form because it works, and because that's today's convention.
I assert:
1. I did define my option to take an argument.
2. The documentation is incomplete and incorrect.
3. The naming convention is inconsistent.
Joseph Myers answered my question directly:
> The .opt files control how options are parsed, both in the driver and
> in the compiler programs such as cc1. Passing of options from the
> driver to those compiler programs is based on specs in the driver; -f
> options are passed down because of the use of %{f*} in cc1_options
> (and the use of %(cc1_options) in the specs for most languages).
IIUC, it's not lang.opt, but lang-specs.h:
$ nl lang-specs.h
1 /* gcc-src/gcc/config/lang-specs.h */
2 {".cob", "@cobol", 0, 1, 0},
3 {".COB", "@cobol", 0, 1, 0},
4 {".cbl", "@cobol", 0, 1, 0},
5 {".CBL", "@cobol", 0, 1, 0},
6 {"@cobol", "cobol1 %i %(cc1_options) %{!fsyntax-only:%
(invoke_as)}", 0, 1, 0},
The contents of that file are unspecified. gccint.info says only:
> 'lang-specs.h'
> This file provides entries for 'default_compilers' in 'gcc.c'
> which override the default of giving an error that a compiler for that
> language is not installed.
I implemented the above by cargo-cult coding. Until today I had no
idea what line 6 does. Now I have only some idea.
I don't understand where the %{} syntax is processed. I'm guessing
autoconf, which on this project is above my pay grade.
On Thu, 17 Mar 2022 17:39:00 +0000
Jonathan Wakely <jwakely....@gmail.com> wrote:
> You didn't define your option to take an argument in the
> .opt file.
Of course I did:
indicator-column
Cobol Joined Separate UInteger Var(indicator_column) Init(0)
IntegerRange(0, 8)
Column after which Region B begins
That says it takes an argument -- either Joined or Separate -- as an
unsigned integer initialized to 0 in the range [0,8]. Not only that,
the option is accepted by gcobol; it's just not passed to the
compiler.
The documentation does not say an option taking an argument must
end in "=" and does not recommend it begin with "f".
Marek Polacek <pola...@redhat.com> wrote:
> > 2. GCC accepts a -fno- alternative, automatically
>
> Right, unless it's RejectNegative.
Yes, and RejectNegative is an instrument of accidental complexity. If
-f options automatically accept a -fno- option, then a -f option that
does not want a -fno- alternative should use another name. There are
25 other lowercase letters available.
> > 3. The "f" stands for "flag", meaning on/off.
>
> It does stand for "flag", and it looks like at some point in ancient
> history if was on/off, but then came options like -falign-loops=N.
IME, someone made a mistake in the past, and that mistake is now
becoming mistaken for a standard. I don't mind living with some cruft
-- it's not as though gcc is unique in that regard -- but at the same
time I see no reason to vernerate it or perpetuate it.
In plain words, if we recognize that -f indicates an on/off switch,
let's use it that way, deprecate those that don't, and not add new -f
options that take arguments.
One last, final minor point,
> > By default, all options beginning with "f", "W" or "m" are
> > implicitly assumed to take a "no-" form.
> > More accurate would be
> > to say a "fno-" form is automatically accepted or generated.
>
> TBH, I don't see how that would be any more accurate that what we
> have now.
Words matter. No one is assuming anything, a fact hidden by the passive
"are implicitly assumed". I don't know whether -fno- is "accepted" or
"generated", or by what. I'm suggesting the agent be stated and the
verb not hide what's happening. I would say:
"Options beginning with "f", "W" or "m" also
<accept/produce/create>
a "no-" form generated by <technology>.
I wouldn't say "by default", because it's not by default. It's by
design, and the alternative is contained in the next sentence.
I've said my peace. I have my option, and I'll use it. If any of my
assertions is incorrect, I'd be happy to be corrected. I hope my
observations, if correct, contribute to better option names and
documentation.
My thanks for your help. I'm sure we've spent more time on
this corner of configuration than we expected to.
--jkl
