GH Actions workflow for continuous integration and portability testing #102
Conversation
|
Currently Any hints how to fix this? |
|
I also ran the build locally (on macOS), and no |
|
On Tue, Jun 28, 2022 at 01:54:02PM -0700, Matthias K??ppe wrote:
I also ran the build locally (on macOS), and no `*.help` files are generated in any directory. Is `make dist` actually being used for making `fricas` source distributions?
Help files duplicate data from other documentation files. In principle
they could be made automatically from other files, but nobody
implemented this. Current help files were created by hand.
They are not in repository as the intent is either have automatic
process or drop them if they get out of date.
And yes, `make dist` is used, it just takes help files from
previous release...
…--
Waldek Hebisch
|
|
On Tue, Jun 28, 2022 at 01:54:02PM -0700, Matthias K??ppe wrote:
I also ran the build locally (on macOS), and no `*.help` files are generated in any directory. Is `make dist` actually being used for making `fricas` source distributions?
Sorry, for confusion in previous answer. I make releases using
'src/scripts/mkdist.sh'. I do not use 'make dist'.
…--
Waldek Hebisch
|
What about |
|
I ran |
How does one use |
|
In particular, |
|
Also does not work in an in-tree configured source tree: |
b5e0345 to
78d9f95
Compare
|
On Tue, Jun 28, 2022 at 04:49:14PM -0700, Matthias K??ppe wrote:
In particular, `src/scripts/mkdist.sh` does not work in an out-of-tree configured source tree:
It is not clear to me what you did. Normal usage is as follows:
1) build out-of-source-tree
2) _in the build directory_ run
/path/to/source/tree/src/scripts/mkdist.sh --copy_lisp --copy_phts --copy_help=/path_to_dir_containing_help_files
As result you will get subdirectory called 'dist'. This subdirectory
is than renamed and packed using tar to get distribution tarball
(both steps done by hand).
If you skip --copy_lisp tarball will contain no precompiled Lisp.
If you skip --copy_phts there will be no pre-generated HyperDoc
pages. If you skip --copy_help there will be no help files
in the tarball.
Note: 'mkdist.sh' uses recursive copy, it will fail if you try
to run it inside source tree.
…--
Waldek Hebisch
|
|
I did 1 & 2 but then called |
|
Given that |
|
On Tue, Jun 28, 2022 at 02:57:24PM -0700, Ralf Hemmecke wrote:
> Help files duplicate data from other documentation files. In principle they could be made automatically from other files, but nobody implemented this.
What about
https://github.com/fricas/fricas/blob/master/src/doc/Makefile.in#L528
? I am sure I automated this.
If "make stamp-ug16helpfiles" does not work, you can simply run the awk script by hand.
```
awk -f src/doc/syscmd.awk src/doc/htex/ug16.htex
```
mkdist.sh picks generated help files. But there are several
more which are _not_ generated.
…--
Waldek Hebisch
|
|
Can you tell me the purpose of this PR? Looks like it builds on 135 different systems. Could take hours if not days to finish. On the other hand, FriCAS has very few dependencies and extremely portable among different distros. Also this only tests ECL. I think the added value is minor compared to the effort. |
|
There's no need to worry about the effort that I'm putting in it. |
|
The effort I meant is in Eco-friendly sense. So this is 135x40minutes tests compared with current 3x10minutes. Compared with 180 times more time/energy, the gained value seems small. Also, would this fits more in sage repo? |
We already run this portability suite in the Sage repo. However, when we prepare a package upgrade, such as fricas to 1.3.8 in https://trac.sagemath.org/ticket/34051, we often discover that packages break one or several platforms. The purpose of contributing Our |
Well, Sage has carried patches for FriCAS because it does not compile out of the box on all of our supported platforms. https://github.com/sagemath/sage/tree/develop/build/pkgs/fricas/patches And it appears that FriCAS currently does not have any CI coverage for builds with ECL. As they say, untested, hence broken |
It's easy to configure it so it only runs on tags, etc., if so desired; or to reduce the number of platform tested. |
So for 1.3.8, specifically, what are the problems? From the ticket#34051, see the problems happen if you remove the patch? Well, if you remove https://github.com/sagemath/sage/blob/develop/build/pkgs/fricas/patches/remove_case_insensitive_test.patch , it is fine on released tarball, but will fail on git version. About macOS failure, I wonder if it is the same as #59 , fixed in ECL upstream but not released? |
|
Ticket https://trac.sagemath.org/ticket/34051 removes some of the patches. https://trac.sagemath.org/ticket/34051#comment:14 proposes to add a reduced version of one of the patches back. You can see the macOS failure for example in https://github.com/mkoeppe/fricas/runs/7104014683?check_suite_focus=true My hope would be that versions of our patches can be upstreamed so that we don't have to carry and update them any more. |
Where can I get the FriCAS build log in this link? |
|
Open the section "Print out logs for immediate inspection" in the log output |
|
OK, confirmed, same problem as #59 . We didn't move forward after this suggestion from ECL developer. |
|
New error from Fedora-34,35,36,37 standard: Seems like lto link error? Also this failure to compile should lead to later interpsys crash: |
|
On Tue, Jun 28, 2022 at 11:03:20PM -0700, Matthias K??ppe wrote:
Ticket https://trac.sagemath.org/ticket/34051 removes some of the patches. https://trac.sagemath.org/ticket/34051#comment:14 proposes to add a reduced version of one of the patches back.
You can see the macOS failure for example in https://github.com/mkoeppe/fricas/runs/7104014683?check_suite_focus=true
My hope would be that versions of our patches can be upstreamed so that we don't have to carry and update them any more.
If these portability fixes are something that FriCAS developers are interested in, then the CI in this PR may be a valuable tool.
I do not thing Sage solution (via include files) is good one
for FriCAS. As I wrote FFI declarations contain enough info
to generate extern declarations for C. Remaining question is
who should generate extern declarations. It could be done
at FriCAS side, but would be redundant if ECL is changed
to generate declarations.
More generally about CI: CI is good at detecting that there
are problems, but IME of limited help in fixing them.
…--
Waldek Hebisch
|
Yes, developers still got to develop. |
By the way, to investigate these failures more, you can pull the failing builds as Docker images. |
for instance, it does not work on ECL macOS without our patches. Which were offered here in #59, considered, and apparently fixed, but it happened after 1.3.8 was released. |
|
On Sat, Mar 25, 2023 at 04:10:14PM -0700, Dima Pasechnik wrote:
> So for 1.3.8, specifically, what are the problems?
for instance, it does not work on ECL macOS without our patches. Which were offered here, by the way, I don't know why you cannot get around to merge them.
Sorry for late replay. _Parts_ of your patches are commited. Concerning
declarations for ECL FriCAS in git repo generates extern declarations
for C functions. This is less work for developers and should be more
robust than your proposal with includes. The extern part was commited
after 1.3.8, so if you test only release you will see it in next release,
but other folks reported that the code works as intended on macOS.
…--
Waldek Hebisch
|
Motivated by the SageMath / passagemath distributions, which include FriCAS as an optional package (using ECL and targeting Linux and macOS), this PR adds a continuous integration workflow.
Test runs: https://github.com/passagemath/fricas/actions/workflows/ci-sage.yml