chicken-scheme: new version 5.4.0

[jpellegrini]

Maintainer: @jpellegrini
Compile tested: x86, master, GCC 13
Run tested: MIPS, Netgear WNDR3800, OpenWRT 23.05.4, used the Chicken compiler and interpreter in the target. The binaries csc, chicken-install, chicken-status have been verified to work. Dynamically loading libraries, both from the interpreter and from compiled programs, works.
Patches: A patch is included in order to get the compiler (csc) to work properly on the target device (comment in the OpenWRT package Makefile).

About the patch:

Chicken includes an interpreter and also a compiler, "csc" which calls gcc.

The Chicken build system will dynamically build the file chicken-config.h, and for OpenWRT this is done inside the buildroot. But then, the values in that file are hardcoded into the csc binary, and they don't work well in the target device:

1. -ldl is passed to ld
2. -fmacro-prefix-map=... is passed to gcc, with the original path from the buildroot.

These two will not work on OpenWRT (and are not needed anyway), so the patch included actually modifies the build system to remove those two flags. Then csc works on the target device!

[jpellegrini]

The test build failed claiming I included a binary patch - but the patch I included actually only changes the build system. What should I do now?

[jpellegrini]

the patch I included actually only changes the build system

Which is not a conventional one (it's not a configure-make-make install system). The file patched is not Makefile, Makefile.am or configure.ac... But it's part of the build system (a header, chicken-config.h is written during the compilation process, but it will get confused in the build system and make the compiler try to use, on the target, flags that only make sense in the host -- so my patch changes the script to remove those)

[BKPepe]

1st) Have you check how other patches in this repository looks like?
That would provide you answers that you are looking for.
2nd) Why do we need to carry this patch in downstream?

[jpellegrini]

Ah, ok.

1. Didn't think the first line would make a difference; I've removed it.
2. I don't understand the question. Do you mean I should include an explanation of why it's needed, in the PR? I will do that.

[jpellegrini]

Didn't think the first line would make a difference; I've removed it.

Indeed, it doesn't make a difference when compiling the package... It only shows up when the test bot looks at it (?).

I will do that.

Done!

[BKPepe]

I havent said anything about the first line.

[jpellegrini]

I havent said anything about the first line.

I don't get it. I have run, locally,

make package/chicken-scheme/clean
make package/chicken-scheme/refresh

and it all works fine (no errors, returns status zero). But when the PR goes through the tests, it complains about dirty patches.

It seems that here (my notebook), in the second time it goes through the patch, all is fine:

Applying patch 00.build
patching file defaults.make

Now at patch 00.build
touch "/home/jeronimo/pkg/openwrt/build_dir/target-mips_24kc_musl/chicken-5.4.0/.quilt_checked"
Applying patch 00.build
patching file defaults.make

Now at patch 00.build
Patch 00.build is unchanged
rm -rf /home/jeronimo/pkg/openwrt/package/chicken-scheme/patches 2>/dev/null >/dev/null

but during the automated tests,

  Applying patch 00.build
  patching file defaults.make
  
  Now at patch 00.build
  touch "/builder/build_dir/target-aarch64_generic_musl/chicken-5.4.0/.quilt_checked"
  Applying patch 00.build
  patching file defaults.make
  
  Now at patch 00.build
  Refreshed patch 00.build
  rm -rf /feed/lang/chicken-scheme/patches 2>/dev/null >/dev/null

Why on my notebook it says "Patch 00.build is unchanged" but on github it says "Refreshed patch 00.build"?