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 ? 65.69%
======================================
Files ? 38
Lines ? 67808
Branches ? 18958
======================================
Hits ? 44544
Misses ? 16112
Partials ? 7152 ☔ View full report in Codecov by Sentry. |
|
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 ;) |
|
Current bunch is fine for upstream as well (and I've got some extra hours to spare today as well ;-) . Note: we do know that the bdb collation stuff needs fixing (as we did that some months ago), but as I don't expect someone to use trunk in production, it is fine to merge those later on. Side note: Appveyor CIs for Win32 is passing again as well. |
I think that was SVN revision 5398 - it is a very short patch, I could probably add it to this batch. |
ddeclerck
force-pushed
the
gc3_to_gc4
branch
from
e266614 to
314a2a7
Compare
|
Well, I just merged the profiling (and a few small commits, one necessary for MSVC builds), and this is quite big already (the profiling itself brings a big new file and a large test). |
|
For some reason, the "Coverage" CI suddenty started to incorrectly detect readline as being present even though not installed... I don't see how the changes made to |
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
from
d385884 to
4b4c8b3
Compare
ddeclerck
force-pushed
the
gc3_to_gc4
branch
from
9b967f3 to
710229b
Compare
ddeclerck
force-pushed
the
gc3_to_gc4
branch
from
9426032 to
c97ba6f
Compare
ddeclerck
force-pushed
the
gc3_to_gc4
branch
from
ecabe30 to
7c640cb
Compare
ddeclerck
force-pushed
the
gc3_to_gc4
branch
from
7c640cb to
9b14e76
Compare
Follow-up of #146.