On Mon, Feb 17, 2025 at 6:50 PM James K. Lowden
<jklow...@schemamania.org> wrote:
>
> On Sat, 15 Feb 2025 21:24:52 +0000
> Sam James <s...@gentoo.org> wrote:
>
> > > +prototypes.cpp: posix.txt
> > > + awk -F'[/.]' '{ print $$6 }' $^ | \
> > > + while read F; do echo "/* $$F */" && man 2 $$F | \
> > > + ./scrape.awk -v funcname=$$6; done > $@~
> > > + @mv $@~ $@
> > > +
> > > +posix.txt:
> > > + zgrep -l 'POSIX[.]' /usr/share/man/man2/*z > $@~
> >
> > This will need reworking. It assumes the location of the man pages on
> > the system, assumes 'zgrep' exists, and assumes 'zgrep' can read the
> > man pages (the man pages may be compressed with something else; I know
> > such systems exist).
> >
> > I'm not sure this is really any less brittle or more robust than just
> > listing the actual functions you scraped out from your system.
>
> You might be reading more into this than you want to.
>
> As you saw in gcc/cobol/posix/README.md, the files in that directory are not
> part of the compiler. They are tools we provide that potentially make it
> easier to generate user-defined COBOL functions that call functions in the C
> standard library, in particular syscalls. IMO they don't need to be perfect;
> it is enough that they are good.
>
> The user need never touch this part of the system. The compiler functions
> without it. It's there as a convenience and demonstration. I hope to
> encourage contributions from users to this directory in a "contrib/" kind of
> way.
>
> There are dependencies beyond the ones you mention, not least (as documented)
> the Python PLY module. Anyone sitting down with this tool will have to
> wrestle with it a bit. I contend that, if the user needs more than a few
> functions, it will be less trouble to engage the tool than to write them by
> hand.
>
> I agree it could be improved. For example,
>
> > +posix.txt:
> > + zgrep -l 'POSIX[.]' /usr/share/man/man2/*z > $@~
>
> could be
>
> posix.txt:
> $(ZGREP) -l 'POSIX[.]' $(MANDIR)/man/man2/*z > $@~
>
> but that doesn't gain us much, does it? We could start over with autoconf &
> automake, to ensure full portability. But that would defeat the purpose.
> What I want to provide here is a prototype, not a robust foolproof tool.
>
> I think a simple example -- even a brittle one loaded with assumptions -- is
> easier to understand and serves as a better illustration than a complicated
> one. I want to provide such a tool as part of gcobol, to give the user a
> facility not available from any other COBOL compiler. I think it's better
> included in the gcc distribution than as an SO post or FAQ at
> http://www.cobolworx.com.
>
> I'm sure you agree we don't want to let this tail wag the dog. With my
> exegesis in mind, what would you recommend? If it's limited to more
> judicious use of makefile variables, I could surely implement those
> suggestions.
So to simplify things at this point can we postpone merging this bit
then? If you say it's more like a "contrib", wouldn't
putting it in the toplevel contrib/ directory be more appropriate?
Maybe in a contrib/cobol/ subdirectory?
Richard.
>
> --jkl
>
