Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

GC4 ci adjustments #190

Draft
wants to merge 2 commits into
base: gc4
Choose a base branch
from
Draft

GC4 ci adjustments #190

wants to merge 2 commits into from

Conversation

GitMensch
Copy link
Collaborator

@GitMensch GitMensch commented Oct 7, 2024 •
edited
Loading

merging the changes of #189 and make gc4 ci more similar to gc3

@GitMensch
ci adjustments
11dd7df 
* ubuntu:
  * only run jobs for "coverage" and "additional warnings" if the main ci build works
    and use its generated tarball in both cases
  * add two new artifacts: test binaries and windows source
* ubuntu+msys1+msys2+macos:
  * upload config.log after the build - because we may need it to debug build issues
  * always upload the testsuite.log (additional build documentation)
* ubuntu+msys1+msys2:
  * use --with-pkgversion to mark CI binaries
* msys2+macos:
  * uploading NIST test results
* msys1:
  * GMP url changes, building it again for performance reasons
  * building BDB with all relevant patches from MSYS2
  * drop GC install log step and therefore extra prefix
  * using msys-build instead of building Bison (only necessary for GC4)
  * drop extra CFLAGS previously necessary for local cJSON (fixed in 3.x)
  * enable NIST85 (+ comment-code in case we ever need to skip something there
    and/or ignoring failing NIST) --> as after last upstream update everything works
  * ci cache adjustment:
    * remove split per matrix
    * split per software, enabling smaller updates
  * use CI tarball like for the minimal build, drop flex+bison
  * drop workflow specific expected failures that now work fine
  * move env to MSYS job
  * resolve env vars by build API instead of runner
* integrate msys1.yml into ubuntu.yml, renaming to build_nightly.yml
* msys2:
  * split NIST + internal testsuite and run the later with less jobs to prevent hanging
  * split between "prepare" and "build" job, with the former generating a full distribution
    inclusive documentation, and the later having less packages installed,
    allowing to enable i386 again
  * disable BDB for 32bit build as MSYS2 doesn't provide that any more
  * switch cjson to json-c (more commonly used, MSYS2 still providing 32bit build)
  * explicit list of dependencies for configure
* msvc:
  * testsuite skip adjustments from the generated testsuite
  * enable building binary package and artifact
  * export dependencies and artifact

(cherry picked from commit 7d4a2fd)
@GitMensch GitMensch marked this pull request as draft October 7, 2024 13:47
@GitMensch GitMensch changed the title ci adjustments GC4 ci adjustments Oct 7, 2024
@GitMensch GitMensch force-pushed the gc4-ci branch 6 times, most recently from 95f8be6 to 726eb49 Compare October 7, 2024 19:32
@GitMensch
ci adjustments
2f9b170 
* ubuntu:
  * only run jobs for "coverage" and "additional warnings" if the main ci build works
    and use its generated tarball in both cases
  * add two new artifacts: test binaries and windows source
* ubuntu+msys1+msys2+macos:
  * upload config.log after the build - because we may need it to debug build issues
  * always upload the testsuite.log (additional build documentation)
* ubuntu+msys1+msys2:
  * use --with-pkgversion to mark CI binaries
* msys2+macos:
  * uploading NIST test results
* msys1:
  * GMP url changes, building it again for performance reasons
  * building BDB with all relevant patches from MSYS2
  * drop GC install log step and therefore extra prefix
  * using msys-build instead of building Bison (only necessary for GC4)
  * drop extra CFLAGS previously necessary for local cJSON (fixed in 3.x)
  * enable NIST85 (+ comment-code in case we ever need to skip something there
    and/or ignoring failing NIST) --> as after last upstream update everything works
  * ci cache adjustment:
    * remove split per matrix
    * split per software, enabling smaller updates
  * use CI tarball like for the minimal build, drop flex+bison
  * drop workflow specific expected failures that now work fine
  * move env to MSYS job
  * resolve env vars by build API instead of runner
* integrate msys1.yml into ubuntu.yml, renaming to build_nightly.yml
* msys2:
  * split NIST + internal testsuite and run the later with less jobs to prevent hanging
  * split between "prepare" and "build" job, with the former generating a full distribution
    inclusive documentation, and the later having less packages installed,
    allowing to enable i386 again
  * disable BDB for 32bit build as MSYS2 doesn't provide that any more
  * switch cjson to json-c (more commonly used, MSYS2 still providing 32bit build)
  * explicit list of dependencies for configure
* msvc:
  * testsuite skip adjustments from the generated testsuite
  * enable building binary package and artifact
  * export dependencies and artifact

(cherry picked from commit 7d4a2fd)
@GitMensch
Copy link
Collaborator Author

@ddeclerck This is nearly done but the MSVC is broken and I have no clue why (also when comparing with the GC3 one).
Using cobc to generate something (already for building gcdiff, but otherwise also later in the testsuite) always result in "CL no source file" error message (both with and without setting/unsetting CL).

If I take the resulting binaries from the artifacts I get something that seems to be a working compiler.

Any idea? If not I'd suggest to wrap this up - skipping the testsuites (as it was before, just commented out) and package everything "as is" (without gcdiff)... at least we get all other CI environments working (much extended than before).

Note: the part that took me the most time was the BSD sed - which is a bit different than other implementations (I haven't checked, we possibly can use the BSD format in all build definition scripts). Oh, and I've learned that after -i you "normally" add an extension which is used for the backup file (if any).

@ddeclerck
Copy link
Contributor

ddeclerck commented Oct 7, 2024 •
edited
Loading

@ddeclerck This is nearly done but the MSVC is broken and I have no clue why (also when comparing with the GC3 one). Using cobc to generate something (already for building gcdiff, but otherwise also later in the testsuite) always result in "CL no source file" error message (both with and without setting/unsetting CL).

Welcome to the seventh circle of MSVC hell ;)
Looking at the cl.exe command called by cobc:

executing:	cl.exe /c
		/I"D:\a\gnucobol\gnucobol\build_windows\x64\Release\"
		/I"D:\a\gnucobol\gnucobol\build_windows\x64\Release\include"
		/I"D:\a\gnucobol\gnucobol"
		/I"D:\a\gnucobol\gnucobol\build_windows" /MD
		/Fo"C:\msys64\tmp\cob4720_0.obj" "gcdiff.c"

I'd say (~90% sure) this is due to the trailing backslash at the end of the first include path (please don't ask..).
Yeah, this sh*t is extremely sensitive to even the slightest inaccurracy.

@ddeclerck ddeclerck closed this Oct 7, 2024
@ddeclerck ddeclerck reopened this Oct 7, 2024
@ddeclerck

This comment was marked as outdated.

Sign in to view
@GitMensch
Copy link
Collaborator Author

I'd say (~90% sure) this is due to the trailing backslash at the end of the first include path (please don't ask..).
Yeah, this sh*t is extremely sensitive to even the slightest inaccurracy.

I've rechecked - yes, that trailing slash kicks cl.exe into Nirvana. You know, I'd create a PR to fix that if it would be at least open source... checking what cobc does - it removes any trailing slash (since 2020 - r4051 only for MSVC and since r4974 in general) via the remove_trailing_slash() function.

I'll adjust the CI definition...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@GitMensch @ddeclerck