On Mon, 10 Mar 2025 17:34:40 +0100
Richard Biener <richard.guent...@gmail.com> wrote:
> index 10a42cb1dd7..8e666618ef1 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> ...
> +# user-defined functions for GCOBOL
> +udfdir = $(datadir)/gcobol/udf
> ..
> @@ -4031,7 +4035,9 @@ installdirs:
> $(mkinstalldirs) $(DESTDIR)$(includedir)
> $(mkinstalldirs) $(DESTDIR)$(infodir)
> $(mkinstalldirs) $(DESTDIR)$(man1dir)
> + $(mkinstalldirs) $(DESTDIR)$(man3dir)
> $(mkinstalldirs) $(DESTDIR)$(man7dir)
> + $(mkinstalldirs) $(DESTDIR)$(udfdir)
>
> while generating man3dir is probably OK when not configuring COBOL
> the udfdir creation looks spurious and is repeated(?) in
> cobol/Make-lang.in:
>
> cobol.install-common: installdirs
> $(INSTALL_PROGRAM) gcobol$(exeext) $(DESTDIR)$(bindir)/
> $(INSTALL_PROGRAM) cobol1$(exeext) $(DESTDIR)
> $(libexecsubdir)/ $(INSTALL) -m 755 $(srcdir)/cobol/gcobc $(DESTDIR)
> $(bindir)/ mkdir -p $(DESTDIR)$(datadir)/gcobol/udf
> $(INSTALL_DATA) $(srcdir)/cobol/udf/* $(DESTDIR)
> $(datadir)/gcobol/udf/
>
> I don't know exactly what UDF is, but I'm going to prune the
> gcc/Makefile.in UDF changes. Does that analysis look OK?
We need the UDF directory, but it's enough to create it jjst once, and only for
cobol.
UDF stands for "user defined function". COBOL, which used to define
only "intrinsic functions", supplied with the compiler (similar to a
standard library), and otherwise had no functions. For the last 20
years or so, COBOL has also allowed the user to define functions himself
in COBOL, and invoke them the same way intrinsic functions have always
been invoked.
Because their use is syntactically identical, we supply UDFs to
emulate functions that other COBOL compiler supply as non-standard
intrinstic functions. So far, that set is small; we supply only one
UDF to date:
$ ls /tmp/build-try/share/gcobol/udf/
stored-char-length.cbl
I think you're suggesting it would be better *not* to create the udf
directory in gcc/Makefile.in, since that would leave an empty directory
unless the user built gcobol.
This patch seems to work, and uses mkinstalldirs instead of "mkdir -p":
[snip]
diff --git a/gcc/cobol/Make-lang.in b/gcc/cobol/Make-lang.in
index de967e3d78e..7447118ab3e 100644
--- a/gcc/cobol/Make-lang.in
+++ b/gcc/cobol/Make-lang.in
@@ -281,7 +281,7 @@ cobol.install-common: installdirs
$(INSTALL_PROGRAM) gcobol$(exeext) $(DESTDIR)$(bindir)/
$(INSTALL_PROGRAM) cobol1$(exeext) $(DESTDIR)$(libexecsubdir)/
$(INSTALL) -m 755 $(srcdir)/cobol/gcobc $(DESTDIR)$(bindir)/
- mkdir -p $(DESTDIR)$(datadir)/gcobol/udf
+ $(mkinstalldirs) $(DESTDIR)$(datadir)/gcobol/udf
$(INSTALL_DATA) $(srcdir)/cobol/udf/* $(DESTDIR)$(datadir)/gcobol/udf/
cobol.install-man: installdirs
@@ -291,7 +291,6 @@ cobol.install-man: installdirs
cobol.install-info:
cobol.install-pdf: installdirs gcobol.pdf gcobol-io.pdf
- mkdir -p $(DESTDIR)$(datadir)/gcobol/pdf
$(INSTALL_DATA) gcobol.pdf gcobol-io.pdf $(DESTDIR)$(pdfdir)/
cobol.install-plugin:
[pins]
That leaves the creation of all directories up to Makefile.in, except for the
udf directory, which cobol creates for itself if configured.
> Building gcobol with GCC 7 shows
>
> gcc/cobol/except.cc:285:70: sorry, unimplemented: non-trivial
> designated initializers not supported
I'm surprised that's the only occurence! For example, in
gcc/cobol/symbols.cc,
static symbol_elem_t
elementize( cbl_field_t& field ) {
symbol_elem_t elem = { .type = SymField, .elem = {.field = field} };
return elem;
}
What is the right answer? Designated initializers are part of C99, but
weren't added to C++ until C++20
(https://en.cppreference.com/w/cpp/language/initialization). Strictly
speaking, we should remove all of them, because our baseline is C++14.
> that needs to be sorted out (post-merge is OK).
>
> I'm preparing a branch with squashed merged from cobol-patched and
> will push that later
> today to a branch on gcc.gnu.org git and tomorrow from there to trunk.
Excellent, excellent news. Thank you for your patience and guidance.
Regards,
--jkl
