luarocks_dir compatibility with luarocks 3.x

[yparitcher]

luarocks 3.x supports one luarocks install with multiple lua versions.
archlinux already uses 3.x, debian and friends still use 2.x

this will change the directory structure in the release (not sure if that is important)

as documented in:
https://github.com/luarocks/luarocks/blob/master/CHANGELOG.md

Breaking change: The support for deprecated unversioned paths (e.g. /usr/local/lib/luarocks/rocks/ and /etc/luarocks/config.lua) was removed, LuaRocks will now only create and use paths versioned to the specific Lua version in use (e.g. /usr/local/lib/luarocks/rocks-5.3/ and /etc/luarocks/config-5.3.lua).

[Frenzie]

this will change the directory structure in the release (not sure if that is important)

Only if it affects these lines:
https://github.com/koreader/koreader/blob/34090c2f222f54f51094af793e08d64e0e5a68c3/setupkoenv.lua#L2-L7

[yparitcher]

this will change the directory structure in the release (not sure if that is important)

Only if it affects these lines:
https://github.com/koreader/koreader/blob/34090c2f222f54f51094af793e08d64e0e5a68c3/setupkoenv.lua#L2-L7

it does not look like affects them.

[Frenzie]

Alright, thanks!

[poire-z]

Dunno if it's just me, but now, each time I rebuild (even when no change, just to install plugins), I get a (quick - but I don't remember seeing it before):

v2019.10-25-ga5419439
************ CMAKE_MAKE_PROGRAM: "make" **********
make -C base
make[1]: Entering directory '/koreader/base'
************ CMAKE_MAKE_PROGRAM: "make" **********
************ Building for MACHINE: "x86_64-linux-gnu-debug" **********
************ CHOST: "" **********
install -d thirdparty/lua-Spore/build/x86_64-linux-gnu-debug
rm -f /koreader/base/thirdparty/lua-Spore/build/x86_64-linux-gnu-debug/lua-Spore-prefix/src/lua-Spore/../lua-Spore-stamp/lua-Spore-build
rm -f build/x86_64-linux-gnu-debug/rocks/lib/luarocks/rocks-5.1/lua-spore/0.3.1-1/lua-spore-0.3.1-1.rockspec
cd thirdparty/lua-Spore/build/x86_64-linux-gnu-debug && \
        cmake   -DOUTPUT_DIR="/koreader/base/build/x86_64-linux-gnu-debug" \
        -DLUA_SPORE_VER=lua-spore-0.3.1-1 -DLD="gcc" \
        -DCC="gcc" -DCFLAGS="-Og -g -pipe -fno-omit-frame-pointer   -march=native -fPIC -I/koreader/base/thirdparty/luajit/build/x86_64-linux-gnu-debug/luajit-prefix/src/luajit/src" \
        -DLUAROCKS=luarocks \
        -DLUA_INCDIR="/koreader/base/thirdparty/luajit/build/x86_64-linux-gnu-debug/luajit-prefix/src/luajit/src" \
        -DLUA_LIBDIR="/koreader/base/build/x86_64-linux-gnu-debug/libs/" \
         \
        /koreader/base/thirdparty/lua-Spore && \
        make
-- Configuring done
-- Generating done
-- Build files have been written to: /koreader/base/thirdparty/lua-Spore/build/x86_64-linux-gnu-debug
make[2]: Entering directory '/koreader/base/thirdparty/lua-Spore/build/x86_64-linux-gnu-debug'
make[3]: Entering directory '/koreader/base/thirdparty/lua-Spore/build/x86_64-linux-gnu-debug'
make[4]: Entering directory '/koreader/base/thirdparty/lua-Spore/build/x86_64-linux-gnu-debug'
make[4]: Leaving directory '/koreader/base/thirdparty/lua-Spore/build/x86_64-linux-gnu-debug'
make[4]: Entering directory '/koreader/base/thirdparty/lua-Spore/build/x86_64-linux-gnu-debug'
[ 12%] Performing build step for 'lua-Spore'
lua-spore 0.3.1-1 is now installed in /koreader/base/build/x86_64-linux-gnu-debug/rocks (license: MIT/X11)

[ 25%] No install step for 'lua-Spore'
[ 37%] Completed 'lua-Spore'
make[4]: Leaving directory '/koreader/base/thirdparty/lua-Spore/build/x86_64-linux-gnu-debug'

So, dunno if it's missing some other checks so CMake can notice it's not needed.
(Or if I need to cleanup some other directories - I had to rm many stuff to get a succesfull build with this last week's changes :)

[Frenzie]

@poire-z No, some part of the Makefile must not have been updated correctly in this PR. In my earlier message I only referred to possible hidden effects, not to regular Makefile behavior.

[Frenzie]

Right, so the problem is that the path as currently written is only for luarocks 3 — not what I thought "compatibility with" meant. ;-)