> 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
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
