Add upper bound on efl.1.24.0

[mtelvers]

This package uses effect as a function name, which is a reserved keyword in OCaml 5+.

let effect name list = ...

[jmid]

Nice! Should we also add the upper bound to efl.1.12.0 to efl.1.22.0 while we are at it,
as the previous versions on the opam repo seem to have the same issue?
https://github.com/axiles/ocaml-efl/blob/1.12/src/write_fun/elm_transit.ml

[mtelvers]

@jmid I have added a commit for the older versions.

[jmid]

Ouch, lots of red CI lights on this one. I wonder how long it has been since this built cleanly... 😮

1.12.0-1.22.0 seem to fail consistently with automake-1.14: command not found (or automake-1.16: command not found). Perhaps they are missing an implicit conf-automake dependency? 🤔

[mtelvers]

effect is a reserved keyword in OCaml 5.3+, so I have revised my PR.

The automake failures are very interesting and unrelated to the PR. automake shouldn't be needed as a dependency; it should only be needed when the source files have changed, as noted in the build log.

# WARNING: 'automake-1.14' is missing on your system.
#          You should only need it if you modified 'Makefile.am' or
#          'configure.ac' or m4 files included by 'configure.ac'.

The build works on opam < 2.2, and this is because, as @dra27 pointed out to me, the copy behaviour changed in opam 2.2. Previously, the source tarball was extracted in place where in opam >= 2.2 it is extracted into the source directory, then copied to the build directory. The copy does not retain the original time stamps, which results in make deciding that it needs to regenerate the configure script.

This can be shown be adding ["ls" "--full-time"] in to the build steps:

With opam 2.2

- -rw-r--r-- 1 opam opam     70 2025-09-11 09:48:54.629100490 +0100 AUTHORS
- -rw-r--r-- 1 opam opam  27447 2025-09-11 09:48:54.629100490 +0100 COPYING
- -rw-r--r-- 1 opam opam    833 2025-09-11 09:48:54.629100490 +0100 INSTALL
- -rw-r--r-- 1 opam opam    262 2025-09-11 09:48:54.589101345 +0100 META.in
- -rw-r--r-- 1 opam opam   1377 2025-09-11 09:48:54.589101345 +0100 Makefile.am
- -rw-r--r-- 1 opam opam  17149 2025-09-11 09:48:54.630100469 +0100 Makefile.in
- -rw-r--r-- 1 opam opam   5437 2025-09-11 09:48:54.589101345 +0100 README
- -rw-r--r-- 1 opam opam   3793 2025-09-11 09:48:54.589101345 +0100 _tags
- -rw-r--r-- 1 opam opam  34936 2025-09-11 09:48:54.589101345 +0100 aclocal.m4
- -rwxr-xr-x 1 opam opam     24 2025-09-11 09:48:54.589101345 +0100 autogen.sh
- -rwxr-xr-x 1 opam opam   7333 2025-09-11 09:48:54.589101345 +0100 compile
- -rwxr-xr-x 1 opam opam 156920 2025-09-11 09:48:54.629100490 +0100 configure
- -rw-r--r-- 1 opam opam   2964 2025-09-11 09:48:54.589101345 +0100 configure.ac
- drwxr-xr-x 2 opam opam   4096 2025-09-11 09:48:54.589101345 +0100 examples
- -rwxr-xr-x 1 opam opam  13997 2025-09-11 09:48:54.630100469 +0100 install-sh
- drwxr-xr-x 2 opam opam   4096 2025-09-11 09:48:54.630100469 +0100 m4
- -rwxr-xr-x 1 opam opam   6872 2025-09-11 09:48:54.629100490 +0100 missing
- -rw-r--r-- 1 opam opam  10434 2025-09-11 09:48:54.589101345 +0100 myocamlbuild.ml.in
- drwxr-xr-x 6 opam opam  16384 2025-09-11 09:48:54.583101474 +0100 src

With opam 2.1

- -rw-r--r-- 1 opam opam     70 2014-12-12 17:21:29.000000000 +0000 AUTHORS
- -rw-r--r-- 1 opam opam  27447 2014-10-29 06:50:37.000000000 +0000 COPYING
- -rw-r--r-- 1 opam opam    833 2019-10-27 16:47:14.000000000 +0000 INSTALL
- -rw-r--r-- 1 opam opam    262 2014-12-12 17:56:52.000000000 +0000 META.in
- -rw-r--r-- 1 opam opam   1377 2016-11-15 02:55:36.000000000 +0000 Makefile.am
- -rw-r--r-- 1 opam opam  17149 2019-10-27 16:47:24.000000000 +0000 Makefile.in
- -rw-r--r-- 1 opam opam   5437 2019-10-27 16:46:57.000000000 +0000 README
- -rw-r--r-- 1 opam opam   3793 2015-03-14 22:26:05.000000000 +0000 _tags
- -rw-r--r-- 1 opam opam  34936 2019-10-27 16:44:50.000000000 +0000 aclocal.m4
- -rwxr-xr-x 1 opam opam     24 2016-02-19 13:41:23.000000000 +0000 autogen.sh
- -rwxr-xr-x 1 opam opam   7333 2016-03-07 23:32:33.000000000 +0000 compile
- -rwxr-xr-x 1 opam opam 156920 2019-10-27 16:44:50.000000000 +0000 configure
- -rw-r--r-- 1 opam opam   2964 2019-10-27 16:44:32.000000000 +0000 configure.ac
- drwxr-xr-x 2 opam opam   4096 2019-10-27 16:48:37.000000000 +0000 examples
- -rwxr-xr-x 1 opam opam  13997 2014-11-27 16:48:20.000000000 +0000 install-sh
- drwxr-xr-x 2 opam opam   4096 2019-10-27 16:48:37.000000000 +0000 m4
- -rwxr-xr-x 1 opam opam   6872 2014-11-27 16:48:20.000000000 +0000 missing
- -rw-r--r-- 1 opam opam  10434 2017-07-08 20:57:18.000000000 +0100 myocamlbuild.ml.in
- drwxr-xr-x 6 opam opam  12288 2019-10-27 15:33:55.000000000 +0000 src

With thanks to @jonludlam and @dra27 for the analysis.

p.s. Even when this is patched, the builds of efl < 1.24.0 fail with C compilation errors

[jmid]

Oh wow, nice digging! 😄 I wonder why macOS is passing? Perhaps the runners just happen to have automake installed, because I can see they are using opam.2.3? 🤔

Anyway: Knowing what is causing this issue, what would be a good way to proceed?
Can an available-field depend on opam-version (I recall a restriction about some variables cannot be used in there)?

[raphael-proust]

I added a commit to limit availibility to old opams only.

[jmid]

Hm. I can see

• 1.12.0 was added 11 years ago,
• ...
• 1.22.0 6 years ago, and
• 1.24.0 (the latest) 5 years ago.

We are now trying to maintain these old versions - and so a fair option is to collectively decide on x-maintenance-intent: ["(latest)"] for efl, and let versions 1.12.0-1.22.0 be archived soon as these older versions haven't been maintained for years. WDYT?

[mseri]

I disagree with this. The package works with new opam versions if you have a suitable automake for example

[mseri]

We had these issues with various packages, also stdcompact for example. I'd say for this PR we should just have the upper bound on 5.3.0 and we could ask maintainers if we can add x-maintainership-intent: [(latest)] as to just keep one version.

This problem with automake is really annoying. Is there a way to fix it in opam itself?

[dra27]

I agree with your disagreement! This can indeed be fixed in opam - the issue is that extraction of tarballs was altered in opam 2.2, and the timestamps from the tarball aren't being applied to the files.