On Sat, Dec 14, 2024 at 8:09 AM Iain Sandoe <idsan...@googlemail.com> wrote: > > > > > On 14 Dec 2024, at 11:56, Iain Sandoe <idsan...@googlemail.com> wrote: > > > > > > > >> On 14 Dec 2024, at 10:11, Sam James <s...@gentoo.org> wrote: > >> > >> David Malcolm <dmalc...@redhat.com> writes: > >> > >>> On Thu, 2024-12-12 at 12:56 -0500, James K. Lowden wrote: > >>>> The following 8 patches constitute the 80 files needed to build and > >>>> document the COBOL front end. They assume that following exist: > >>>> > >>>> gcc/cobol/ChangeLog > >>>> libgcobol/ChangeLog > >>>> > >>>> The messages are grouped by files in a more or less logical order, > >>>> but groups are somewhat arbitrary. The primary constraint afaik is > >>>> to > >>>> keep them from getting too big, fsvo $too. We have: > >>>> > >>>> 460K hdr header files > >>>> 484K par the parser > >>>> 760K gen GENERIC interface > >>>> 556K cbl other supporting C++ files > >>>> 432K cfg libgcobol/configure > >>>> 788K lib libgcobol, all of it > >>>> 72K doc man pages, for now > >>>> 24K bld "meta" files, such a gcc/cobol/Make-lang.in > >>>> > >>>> Except for "bld", these all contain new files, can be applied in any > >>>> order. > >>>> > >>>> If you would like the patches smaller or larger, I'm happy to > >>>> rearrange > >>>> them. Some of exceed the 400 KB mail limit, but I'm assured they'll > >>>> be > >>>> moderated through. > >>>> > >>>> This patchset excludes tests. While we do have tests, it's not clear > >>>> how or if to add them to gcc. They use a combination of (largely) > >>>> 3rd > >>>> party sources and GNU Autotest. > >>>> > >>>> A word about C style, always a lively topic. For any files already > >>>> present in gcc, the existing style was followed, and any variation > >>>> from > >>>> it is unintentional. Files related to the parser use K&R style. The > >>>> GENERIC interface and runtime library use Whitesmiths style. All C++ > >>>> code uses spaces for indentation. > >>>> > >>>> The COBOL front end has been and is being written by two guys with > >>>> decades of experience. We hope the code is a testament to that > >>>> experience. Our relatively recent experience, these last four years, > >>>> is that it has been more productive to keep using the styles to which > >>>> we've long become accustomed. The position of curly braces is hardly > >>>> any hindrance to read another's code, but it's a burden to write that > >>>> way. We think, 83,068 lines later, the proof of the pudding is in the > >>>> eating. > >>>> > >>>> Thank you for your kind consideration of our work. > >>> > >>> Please forgive me if you've already said this elsewhere, but is this > >>> work available in a public git repo somewhere? > >>> > >> > >> https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/ > > > > But (IIUC) this is the development branch; what would be ideal would be > > a branch with just the 8 patches. > > > > ==== > > > > NOTE0 : the decision to use different whitespace rules from the rest of GCC > > means the that patches apply only with a very large number of whitespace > > errors .. which might be fine - but, of course, you cannot now tell > > intentional > > whitespace errors from actual mistakes …. > > > > NOTE1 : patch 8 did not apply for me without editing - there seems to be a > > duplicate of gcc/cobol/config-lang.in in patches 4 and 8. > > > > NOTE2 : the top level Makefile.in needs to be regenerated. > > > > Will try this on Darwin - (I removed the config-lang.in from patch 8 and > > regenerated the top level Makefile.in) - hopefully the patch 4 > > config-lang.in > > is OK to use. > > > > Is it intentional that this requires bison at build-time or is there a > > missing > > “touch” for some generated file? > > OK so, unfortunately, this does not build on Darwin/macOS. > > It seems > 1) to introduce new build dependencies on: > - bison (we normally commit generated files to the repo not expect the > end-user > to need bison installed). > - a version of gm4 that recognises —gnu >
Note that if this is due to what I think it is, it corresponds to this bug in upstream autoconf: https://savannah.gnu.org/support/?111139 > perhaps this is an oversight and the generated files can be committed ? > > if not ... neither of these tools exist in the Xcode installs that most > macOS users have, > so that they will need to build them before they can configure GCC > —enable-languages=all > > 2) the build then failed for me with … > > /src-local/gcc-master/gcc/cobol/symbols.h:66:39: error: missing binary > operator before token ‘(’ > 66 | #if ! (__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)) > > ** You cannot assume that all targets have glibc - e.g. Darwin has it’s own > libc, others might > use muscl etc. > > I can hack around this .. but then I get lots more errors .. > > /src-local/gcc-master/gcc/cobol/copybook.h:50:40: error: ‘ino_t’ has not been > declared; did you mean ‘wint_t’? > 50 | bool cobol_filename( const char *name, ino_t inode ); > > from /src-local/gcc-master/gcc/cobol/cdf.y:32: > /src-local/gcc-master/gcc/cobol/symbols.h:71:23: error: ‘output’ was not > declared in this scope > 71 | static_assert( sizeof(output) == sizeof(long double), "long doubles?" > ); > | ^~~~~~ > /src-local/gcc-master/gcc/cobol/symbols.h: In function ‘_Float128 > strtof128(const char*, char**)’: > /src-local/gcc-master/gcc/cobol/symbols.h:75:18: error: ‘nptr’ was not > declared in this scope > 75 | return strtold(nptr, endptr); > | ^~~~ > /src-local/gcc-master/gcc/cobol/symbols.h:75:24: error: ‘endptr’ was not > declared in this scope > > etc. etc. > > Unfortunately, I do not have time to chase all these down. > > Did you try building this on Solaris and AIX on the compile farm? > > > Iain > > > > > > thanks > > Iain > > > >> > >>> Thanks > >>> Dave >
