On Thu, 12 Dec 2024 12:56:36 -0500
"James K. Lowden" <jklow...@schemamania.org> wrote:
> The following 8 patches constitute the 80 files needed to build and
> document the COBOL front end.
Below is a list of issues with the COBOL front end, listed in
order of priority, most important first. Each is tagged with who
raised it and a brief status. It is intended to be comprehensive; if
something is missing, please say.
Our git repository is maintained at
https://gitlab.cobolworx.com/COBOLworx/gcc-cobol
The next set of patches will be against
commit 7d6dc2130970ccf6555d4e9f977515c6c20f7d2f
Author: Jonathan Wakely <jwak...@redhat.com>
Date: Fri Dec 13 16:53:06 2024 +0000
I think the issue that raised the most concern is the one I think is
most important: diagnostics. It was unclear -- still is, to me --
whether the COBOL front end must or should use the gcc diagnostic
framework. (In my defense, the system goes unmentioned in gccint.info.)
>From where I sit now, having not yet opened the hood, I think we could
have gcc diagnostics incorporated in January. Probably it's one of
those things that's easy if you know how, and getting to step #1 is the
hard part.
We regard translatable messages as something that can be deferred. I
would very much like to see the compiler in the hands of users, and
respond to their actual needs. When someone volunteers to translate the
messages, I would make it a priority to support the effort.
== Build Issues ==
* Some files were mislabled in the ChangeLog heading [Marc]
- Hopefully all fixed
* gcc/cobol/config-lang.in was in both bld and cfg patches. [Marc]
- We Regret the Error
* regenerate gcc/cobol/lang.opt.urls [David]
- David's patch will be included verbatim as patch #9
* Makefile variables DESTDIR, YACC, LEX, udfdir [Joseph]
- IIUC, YACC = BISON and LEX = FLEX
- unclear what default definition of udfdir should be
* install directory for gcobc script
- will try to correct
* uninstall shouldn't remove anything from the build directory [Joseph]
- understood
* If m4 is needed for something other than regenerating configure
scripts, or if the requirements on m4 for COBOL are stricter
- unsure what to do
* a version of gm4 that recognises ?gnu [Marc]
- Not as far as I know
* trivial fix to placate older C++ compilers [David]
- applied, thanks
* Please make sure to do all regeneration with *unmodified* versions
[Joseph]
- I don't understand.
* does not build on Darwin/macOS [Iain]
- We have built only on Linux, on aarch64 x86_64 (per arch(1)).
- We rely on support for 128-bit integer and floating point to meet
ISO COBOL requirements.
- We want to build on any 64-bit Posix OS, BE and LE.
- 32-bit architectures are not a consideration.
* building on the compile farm? [Iain]
- No, don't know how yet. Willing.
* does your testing include bootstrap builds? [David]
- No, we normally use
--disable-bootstrap
--disable-multilib
* How would it be regression tested? [Andi]
- need to discuss licensing and feasibility
* ideal would be a branch with just the 8 patches [Iain]
- I test the patches on the cobol-patched branch, but I don't normally
push them.
== Front-end Issues ==
* Bison dependency [Iain]
- we require Bison 3.5.1, released nearly 6 years ago. As a point of
comparison, it predates GCC 8.4.
* Bison dependency needs to be documented [Joseph]
- will do
* there isn't any HTML documentation [David, Joseph]
- patches include the changes required to update_web_docs_git for mdoc
files
- will post HTML and PDF versions for reference
- can include generated HTML on request
* check asprintf [Joseph]
- The only examples I find where the returned value of asprintf is not
checked is in symbols_dump(), which is used only to debug the front
end.
* symbol versioned on targets [Jakub]
- We will endeavor to use symbol versioning
- We have no experience with it
* Leading underscores [Joseph]
- pending discussion
* Static buffers with a PATH_MAX size will probably break the build on
Hurd host. [Joseph]
- Hurd probably not relevant to COBOL
- PATH_MAX is Posix. There is no perfect solution.
- If any provided filename is too long, the front end should report it
as an error. That's what tar(1) does.
== Diagnositics ==
* diagnositics [David, Joseph]
- We intended to move to using the gcc diagnositic framework before
submitting the patches. It's still on the front burner.
- Is it OK to apply David's SARIF patch to our branch, subsuming it
into our patches?
- prefer explicit locations, check
- Regarding translation support, we would prefer to add that soon
after the front end is accepted.
== Infeasible ==
* Please use `git send-email` with threading. [Sam]
- dev machines have no email
* please make sure that every function has such a comment [Josef]
- There are 2074 functions, 1295 of which are static. I estimate the
effort would require 86 man-days.
- IMO this is not the best way to write documentation, nor a measure
of its quality.
= [end] =
I hope this captures everything. There are a few open questions I need
to follow up on, and some technology to learn. Please let me know if
the indicated disposition presents a problem.
I plan to provide a new set of patches remedying the technical problems
(hopefully) to be followed by another set dealing with diagnostics.
--jkl
