CI for forward-porting GC3 patches to GC4 #147
Conversation
ddeclerck
force-pushed
the
gc3_to_gc4
branch
3 times, most recently
from
6900d8d to
1c95bd0
Compare
build_aux/bootstrap
Outdated
| @@ -96,12 +96,15 @@ autoreconf $AC_OPTS $MAINPATH > $msgs 2>&1; ret=$? | |||
| # Filter aminclude_static as those are only used _within_ another | |||
| # check so reporting as portability problem is only noise. | |||
| # This has the effect of redirecting some error messages to stdout. | |||
| # to be moved to the Makefile - currently only usable for bootstrap, | |||
| # but should be done on autogen, too | |||
libcob/fileio.c
Outdated
| snprintf (file_open_env, (size_t)COB_FILE_MAX, "%s%s", "IO_", s); | ||
| if ((file_open_io_env = cob_get_env (file_open_env, NULL)) == NULL) { | ||
| snprintf (file_open_env, (size_t)COB_FILE_MAX, "%s%s", "io_", s); | ||
| if (f != NULL) { |
There was a problem hiding this comment.
When/why should f be null here?
There was a problem hiding this comment.
Because some functions (open_cbl_file, cob_sys_delete_file, ...) were "improved" to perform file mapping in GC3 (rev 3944), by calling the cob_chk_file_mapping function, which does not take a cob_file argument in GC3 but does in GC4, and that function in turn calls cob_chk_file_env. Since these functions (open_cbl_file, cob_sys_delete_file, ...) do not use a cob_file object, I resorted to passing NULL and coping with that...
There was a problem hiding this comment.
Is this okay for you @GitMensch ?
|
oops, hope I haven't broken the gitignore in f36dcda - if not then we likely should apply that to the gcos3x branch as well. |
Saw your message a bit late, added another commit in the meantime 😅 By wrapping up you mean, committing to SVN ? (after doing the requested modifications of course) |
|
This approach is reasonable in general.
... So you did already check that this piece of code changed in a later commit?
If you see a difference in the current code, then you can use "svn annotate" to check which commit did the change in this party of fileio.c to know what to merge before the refactoring.
:-)
Am 1. Juni 2024 00:07:13 MESZ schrieb OCP David Declerck ***@***.***>:
…
@ddeclerck commented on this pull request.
> + /* apply COB_FILE_PATH if set (similar to ACUCOBOL's FILE-PREFIX) */
+ if (file_paths) {
+ for(k=0; file_paths[k] != NULL; k++) {
+ snprintf (file_open_buff, (size_t)COB_FILE_MAX, "%s%c%s",
+ file_paths[k], SLASH_CHAR, file_open_name);
+ file_open_buff[COB_FILE_MAX] = 0;
+ if (access (file_open_buff, F_OK) == 0) {
+ break;
+ }
+#if defined(WITH_CISAM) || defined(WITH_DISAM) || defined(WITH_VBISAM) || defined(WITH_VISAM)
+ /* ISAM may append '.dat' to file name */
+ snprintf (file_open_buff, (size_t)COB_FILE_MAX, "%s%c%s.dat",
+ file_paths[k], SLASH_CHAR, file_open_name);
+ file_open_buff[COB_FILE_MAX] = 0;
+ if (access (file_open_buff, F_OK) == 0) {
+ snprintf (file_open_buff, (size_t)COB_FILE_MAX, "%s%c%s",
+ file_paths[k], SLASH_CHAR, file_open_name);
+ file_open_buff[COB_FILE_MAX] = 0;
+ break;
+ }
+#endif
+ }
+ if (file_paths[k] == NULL) {
+ snprintf (file_open_buff, (size_t)COB_FILE_MAX, "%s%c%s",
+ file_paths[0], SLASH_CHAR, file_open_name);
+ file_open_buff[COB_FILE_MAX] = 0;
+ }
+ strncpy (file_open_name, file_open_buff, (size_t)COB_FILE_MAX);
+ }
I remember why I haven't refactored that straight away : in case subsequent commits modify the same code, conflicts will be much easier to handle. I was thinking about keeping the refactoring for after all the patches are merged...
--
Reply to this email directly or view it on GitHub:
#147 (comment)
You are receiving this because you commented.
Message ID: ***@***.***>
|
|
I tend to be overly "conservative". Indeed this piece of code is barely modified afterwards, so I'll do the refactoring. |
|
Is this okay to merge (@GitMensch) ? |
|
I'll try to review this (late) evening. |
|
looks_absolute should use "src", not file_open_name directly (merge issue?) "apply_file_paths" should get that via argument as well and have a function comment that it writes to the global buffer. Then add a Changelog "extracted from xyz and also used in abc" to finish that last commit. We either have to remember for later that we need to add a testcase for the new use or (potentially easier) also include it in the last commit as well. |
This change is introduced in a later commit (3993).
Alright ; as for its output, should it write it through its argument or directly to
By "new use", de you mean the fact that we apply file paths to the complex case ? |
yes
good catch - then it is fine to leave as is; if you don't expect any big problem it would be nice to merge that in this bunch to commit that together, but a later bunch is fine as well
Depends on how other functions do it - it is best for now to mimic that (once the merge is completed we may revisit that part, but there are "some" commits left until we get there). |
|
I made the necessary changes.
I find it more convenient to merge consecutive commits. If that's okay for you I could add to the current batch the next eligible commits until 3993 (that would be 6 commits: 3973, 3979, 3988, 3989, 3992 and 3993). |
|
That batch is good to go :-) |
Merged in SVN ;) I see the next commits deal with translation files. Checking the history, it seems those files are usually just copied "as-is" from the GC3 branch to the trunk; is this correct ? |
No, only new files are copied, the others left as-is; before a release I regenerate the files but the files are nearly completely maintained by the translation project. And of course |
|
Alright.
Hope this unfinished sentence did not have any vital info 😅 |
|
I can't remember any important info missing there. |
|
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## gc4 #147 +/- ##
======================================
Coverage ? 66.07%
======================================
Files ? 39
Lines ? 68751
Branches ? 19153
======================================
Hits ? 45427
Misses ? 16114
Partials ? 7210 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Quick question: I sometimes see alternative code for GC4 in I'm talking about those: |
|
That's quite a bunch - any reason to not merge upstream? [we really need to get to commits that have someone else in the ChangeLogs...] |
No good reason. It may be many commits, but the first batch had way more lines (this one is only +1,162 −904).
I'm looking forward to reaching commit 4614 - our first contribution to GC3 ;) |
ddeclerck
force-pushed
the
gc3_to_gc4
branch
from
5926cf4 to
5312a4b
Compare
ddeclerck
force-pushed
the
gc3_to_gc4
branch
from
5312a4b to
dc450d2
Compare
|
So we may replace that with a check for both WIN32 and CYGWIN and adjust comments (or was it Changelog) as useful.
|
ddeclerck
force-pushed
the
gc3_to_gc4
branch
5 times, most recently
from
7c640cb to
9b14e76
Compare
|
This is a bunch of many small commits, mostly cleanup and build/warning fixes (this notably improves testsuite results under MSVC). |
|
bunch is fine for check-in |
|
And that's it for this batch. The biggest part is Boris' contribution for thread-safety of INSPECT/STRING state structures (5302 + my fix 5406). Other notable parts of this batch are the BDB adjustments for keys of different lengths and partial keys (5296 and 5412) and some of Chuck's modifications to moves to NUMERIC-EDITED (5287). The rest is a few things here and there. |
|
Re-posting a note from @chuck-haatvedt as it seem to not be posted by the mail gateway:
|
|
Yeah, those are exactly the 14 tests that still fail under the GC4 MSYS2 CI. They've been failing since I set up the CI before starting the merge - though the number of failing tests went down from 25 to 14. I still hope the next batches will reduce that number... in any case bringing that down to 0 is one of the post-merge task. |
|
adjust/drop that backward comment, then good for upstream |
Follow-up of #146.