These necessarily include actions for setting up supported backend Prolog compilers. I currently make available actions for setting up ECLiPSe, GNU Prolog, and SWI-Prolog environments.
Also available are some demo repos illustrating the provided workflows. Notably, the demo repo shows how to automatically run tests, publish test reports, and regenerate API documentation and diagrams on a push event.
There are also third-party repos from Logtalk + SWI-Prolog users such as Paul Brownās TicTacToeTalk that illustrate how to automatically generate and make available QLF files as build artifacts so that you can download the game and start playing immediately.
The setup-swi-prolog action can also be used for repos that donāt make use of Logtalk. The community challenge here is twofold:
Get users with open source repos into the habit of writing tests and documentation and then benefit from automatically running those tests and regenerating and publishing documentation every time they commit and push a new version.
Writing and sharing actions and workflows for common usage scenarios.
The GitHub action below is designed specifically for Prolog pack projects, especially those with foreign libraries where compilation across all the major Prolog platforms (macOS, Ubuntu and Windows) is a useful testing component. It also usefully supports coverage and coverage shields. royratcliffe/swi-prolog-pack-cover: GitHub action for SWI-Prolog pack installation with test coverage
Hopefully this might be useful to others as well.
Can I kindly ask for some help? I have cloned the environ pack from swi-prolog.org, added your test.yaml and some trivial unit test that always succeeds.
Nevertheless, the github action fails. Did I misunderstand something?
The error seems to come from the coverage integration that is called. Possibly that code fails as SWI-Prologās coverage tools and API has been rewritten a few years ago.
% gcc -fPIC -pthread -I"/usr/lib/swi-prolog/include" -c -o c/environ.o c/environ.c
% mkdir -p lib/x86_64-linux
% /usr/bin/cc -shared -o lib/x86_64-linux/environ.so c/environ.o
% gmake: Nothing to be done for 'check'.
% gmake: Nothing to be done for 'install'.
% halt
Run swipl -s "/home/runner/work/_actions/royratcliffe/swi-prolog-pack-cover/main/action.pl"
% Found 0 .plt test files, loaded 0
% Start unit: environ
% [1/1] environ:one ................................. passed (0.002 sec)
% End unit environ: passed (0.006 sec CPU)
I guess the āNothing to be done for ācheckā.ā from the Makefile is not related to the problem, or is it? Just asking. The issue with code coverage (the one that generates the failure) clearly appears below, not shown here.
FYI, and you might consider updating pack(environ) accordingly. In the fork at GitHub - mgondan/environ, I changed the code to return each variable individuallyāinstead of a list. The code now illustrates a pack with a nondeterministic predicate written in C.
I think the pack mainly serves educational purposes (we have getenv/2), so the change will probably not break anything.
No. It is just the dummy target in the Makefile. No tests are defined.
Indeed. Iām not so keen on complicating the code itself. The pack mostly illustrates creating a pack that involves foreign code, keeping the code itself more or less as simple as it can be. It is probably more interesting to update the pack to use CMake and, indeed, show CI at work. Building binaries for (notably) Windows on Github would also be interesting.
Alternatively, we could could write an educational pack that illustrates a lot more, including the use of C++, much more of the C and C++ APIS, binding to external libraries (with some useful CMake configuration), CI and distribution.
With pleasure (2h per week, say, maybe more, but I cannot promise it). I am currently putting together some lapack support, it uses libarmadillo as an external binding. In case it is of public interest. But I am still at a stage at which I mostly ask dumb questions and donāt produce anything really meaningful.
Hm. In my defence, the updated version does not use lists (therefore, less complicated) and exports a nondeterministic predicate (therefore, more prologgy).
(But I see your point, it may be more interesting to write a proper tutorial)
I could try, since building an interface for OGDF is my target, but I feel Iām the first one needing to learn more about CMake and the interop toolingā¦ indeed I didnāt succeeded in building the Windows version, following the docsā instructions.
Some of the documentation for C++ and examples in test_cpp.cpp are intended as examples, especially for non-deterministic predicates. Iām in the middle of adding some more documentation and test examples, mainly because Iāve run into a bug with pack(rocksdb) and I need to make some simpler examples to narrow down the problem.
And I can review whatever examples you write in C++.
It helps to use pack_version(2) ā I found that some of the version-1 environment variables leaked through to submodules and caused subtle build errors.
