gnucobol-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GnuCOBOL-Dev] GnuCOBOL pangaea-branch -fmf-files - compiler dialect


From: Simon Sobisch
Subject: Re: [GnuCOBOL-Dev] GnuCOBOL pangaea-branch -fmf-files - compiler dialect options
Date: Thu, 6 Jun 2019 14:37:41 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

Hi fellow hackers,

Am 06.06.2019 um 00:26 schrieb James K. Lowden:
> On Thu, 16 May 2019 13:13:47 -0400
> "James K. Lowden" <address@hidden> wrote:
>
>> Can you see your way toward completing the merge in that way?  When
>> do you think it could be ready?
>
> Hey, Simon, it's been quite a while.  If you could briefly enumerate
> any issues holding up the merge from your point of view, perhaps Ron
> and I could help things along?

There are no issues with the merging so far. I wanted to start this week
to be finished "mid of june" as Ron already wrote he'll have time then
to do the necessary cleanup then.

> We could also agree to defer certain issues until after the merge.

I totally agree. Actually the only things that needs to be done after
the merge and before integrating lmdb + splitting fileio are the file
related things (-fmf-files is the big one), so far I think Ron will do
that this month.

> It's in no one's interest to delay a merge; it only prevents anyone
> else from working while they wait for it.

I agree.

> Where do we stand?

In general I make good progress on "trunk to 3.1rc1" including set-up of
CI (currently only handling trunk, working are Ubuntu [16.04+18.04] and
win32-posix [cygwin64/32, mingw32], maybe VS2019 will get in, too)

The most important thing for the merge was the "build issues", and now
all of those are solved but the GNU make dependency (coverage testing,
generation of manpage via build-order) [and hard libm dependency].

I'll postpone the adjustments for gmake to "after the merge" and those
adjustments won't be part of 3.1 (I'll hand-remove those parts when
updating the 3.x branch [again], where the rc1 and its update will be done).

I've came back to checking pangaea status yesterday as I wanted to make
sure I don't mix in too much bugs - testsuite and NIST pass with
multiple systems (+gmake) from trunk (with BDB).
pangaea did not build on some systems (I've committed a fix) but BDB
seems to be broken - Ron is working on it. I guess the fix will be
available today/tomorrow allowing me to update pangaea to ensure no new
breakage gets in.

After the update we can discuss if it is reasonable to do the changes
related to -fmf-files on pangaea (I'll only finish 3.1 in the 3.x
branch) and merge back to trunk then or if we want to directly do it.


@Jim: Actually there is one thing in trunk that you *could* help with -
adjust configure to check if libm is needed at all (it maybe is not even
available) and to check if the generated modules (in pangaea) need it,
too (or if it is enough to link it into libcob).
Are you able to take on this (I won't find any time soon to do it and it
is the last dependency that is very hard-wired)?

Thanks,
Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]