@pazos Actually, do you know which CMake F-Droid uses? I just realized the second commit may be a bit overenthusiastic.

@Frenzie: https://packages.debian.org/stretch/cmake (3.7.2)

There's also a backport: https://packages.debian.org/stretch-backports/devel/cmake (3.16.3) that should be available to install via sudo apt-get in https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/org.koreader.launcher.yml#L21

Thanks. Well, I'll just revert that second commit. I don't think CMake <3.11 really gives us much extra anyway, although I do vaguely seem to recall @NiLuJe complaining about CMake <3.7 recently?

Whatever passes as "modern" CMake would be great^Wless terrible ;).

CMake 3+ and especially 3.4+ is called "modern" CMake afaik. :-P

As a point of reference, I can't even install anything older than 3.13 over here ;p.

@NiLuJe Sidenote, are you familiar with this argument fs by any chance? That's for the Sony build.

  CXXLD    libdjvulibre.la
libtool:   error: cannot find the library '' or unhandled argument 'fs'
Makefile:527: recipe for target 'libdjvulibre.la' failed
make[3]: *** [libdjvulibre.la] Error 1
make[3]: Leaving directory '/home/ko/base/thirdparty/djvulibre/build/arm-linux-gnueabihf/djvulibre-prefix/src/djvulibre/libdjvu'
Makefile:429: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/ko/base/thirdparty/djvulibre/build/arm-linux-gnueabihf/djvulibre-prefix/src/djvulibre'
Makefile:361: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/ko/base/thirdparty/djvulibre/build/arm-linux-gnueabihf/djvulibre-prefix/src/djvulibre'
ninja: build stopped: subcommand failed.
Makefile.third:163: recipe for target 'build/arm-linux-gnueabihf/libs/libdjvulibre.so.21' failed
make: *** [build/arm-linux-gnueabihf/libs/libdjvulibre.so.21] Error 1

Exited with code exit status 2

@Frenzie: That doesn't ring a bell, no. Hard to say what's happening without a verbose build to see the crazy libtool command line ;).

The Android image issue should be resolved in koreader/virdevenv#65.

I hadn't realized it was pulling in openjdk-11 (and was therefore defaulting to it).

tl;dr Should be almost done.

Well missed the chance to request cmake 3.11..next time..

Just state your reasons.

Well FetchContent and optimisations :)

Could you please be a lot more concrete?

Cmake 3.13 has Quality of life changes...https://cmake.org/cmake/help/latest/release/3.13.html#id8 Maybe better…
Yeah… new dev easilly excitable..

But what do you want to do with FetchContent? How is DownloadProject insufficient? Which specific optimizations would be made possible?

It ensures no duplicating of dependencies thoughout the project tree..

Which duplication are you referring to?

Of source files ,no double downloads

Which double downloads are you referring to?

No specific examples... I guess our big tree can can be help by caching deps that may be used in many subprojects