> Am 14.12.2024 um 14:09 schrieb Iain Sandoe <idsan...@googlemail.com>:
>
>
>
>>> 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?
Note it‘s Fine to at First restrict to a known set of targets/hosts - usually
the Most problematic Parts are in the runtime Library.
Richard
>
> Iain
>
>
>>
>> thanks
>> Iain
>>
>>>
>>>> Thanks
>>>> Dave
>
